Warum sollte ich überhaupt parallel testen?

Organisatorische Gründe (Sprints, Product-Teams)

Wenn eine Plattform (z.B. ein Online-Shop) relativ groß ist, ist es wahrscheinlich, dass es mehrere Product Teams / Owner gibt. Zum Beispiel ein Team für Such-Funktion, einen Product Owner für den Checkout, ein Brand-Marketing Team für die Homepage... Die Teams kümmern sich unabhängig um die Performance von Teilen der Webseite und nicht nur um harte KPIs wie Purchases, sondern auch darum, wie viele Kunden sich für den Newsletter anmelden, oder darum, wie viele interne Suchanfragen zu einer Produkt-Detail-Ansicht führen (Micro Conversions).

In einer solcher Organisation werden Teams nicht unbedingt auf einen Test verzichten wollen, weil ein anderes Team bereits einen Test durchführt. Stattdessen ist dafür Sorge zu tragen, dass der Test im Optimalfall laufen kann - ohne andere Tests zu stören.

Inhaltliche Gründe

Wenn ein Feature bereits erfolgreich nach einem Test etabliert wurde und ein neues Feature (räumlich / thematisch in der Nähe) ebenfalls erfolgreich getestet wurde, dann sollten auch beide Features auch in einer Variante getestet werden, in der sie beide aktiv sind, um Wechselwirkungen analysieren zu können.

Gibt es überhaupt ein Problem?

Die Annahme, das ein Experiment das andere beeinflusst, ist nicht falsch. In der Praxis ist das aber oft nicht relevant. Nehmen wir an, Experiment A und B laufen parallel. A ist ein Test auf der Homepage (Hero Banner Variationen) und B ist ein Test auf der Produktseite (Galerie mit / ohne Thumbnails). Während A vor allem auf Klick-Rate getestet wird, wird B eher auf das Engagement mit der Galerie oder Add-To-Cart getestet. Inwieweit stören sich diese Experimente gegenseitig? Man muss schon den Edge Case phantasievoll konstruieren, um ein Problem zu finden: Ein User öffnet eine Produktseite, spielt mit der Galerie, geht zur Homepage und ist vom neuen Banner abgeschreckt? Es gibt hier kein Problem, bzw. die gegenseitige Beeinflussung ist hier so gering, dass sie vernachlässigt werden kann.

Wann gibt es wirklich ein Problem?

wenn ich nicht mehr sauber attributieren kann

Nehmen wir an, dass auf der Produktseite ein Experiment A läuft ("der Add-to-Cart Button wird umpositioniert") und gleichzeitig läuft auf dem gleichen Seitentyp ein Experiment B ("Highlighting der Informationen zum Ratenkauf"). Wir testen in beiden Fällen 50/50 und messen primary auf Add-to-Cart und secondary auf Purchases.

Woher soll ich wissen, ob A oder B für einen Up- oder Down-Lift gesorgt hat?

Denn Wären die User perfekt verteilt, dann würde folgendes gelten:

  1. 25% der User sind Control/Control, also sowohl in Experiment A in der Kontrollgruppe als auch in Experiment B in der Kontrollgruppe
  2. 25% der User sind Experiment/Control, also in Experiment A im Test, aber in Experiment B in der Kontrollgruppe
  3. 25% der User sind Control/Experiment, also in Experiment A in der Kontrollgruppe, aber in Experiment B im Test
  4. 25% der User sind Experiment/Experiment, also in Experiment A im Test als auch in Experiment B im Test

Wenn wir uns die Ergebnisse im Reporting von Experiment A ansehen, dann gibt es die Kontrollgruppe (in der auch Teilnehmer aus Experiment B) und der Gruppe der Herausforderer-Variante (in der auch Teilnehmer aus Experiment B sind). Wenn das Experiment B gar keinen Up- oder Downlift hat, dann spielt dies keine Rolle für die Ergebnisse aus A, ansonsten verzerrt das Experiment B Experiment A mitunter erheblich. Und natürlich auch umgekehrt.

Lösung ABN Test

ABN Tests - Wir testen A und B parallel

Anstatt die beiden Features in jeweils in zwei Tests durchzuführen, führen wir einen Test mit 3 Varianten (bzw. 2 + Control) durch. Dadurch sind unsere Daten wieder "sauber", weil User im Bucket Variante 1 niemals im Bucket Variante 2 sind.

  • Control 34% Traffic
    • Feature A nicht aktiv
    • Feature B nicht aktiv
  • Variante 1 33% Traffic
    • Feature A aktiv
    • Feature B nicht aktiv
  • Variante 2 33% Traffic
    • Feature A nicht aktiv
    • Feature B aktiv

Lösung multivariater Test

multivariater Test - Wir testen 2 x 2 Variationen A und B parallel, weil wir auch die Wirkung von A+B kennen wollen.

Wir fügen noch eine Variante hinzu, nämlich die Variante in der Feature A und B gemeinsam aktiv sind. Wir haben dann 22 Buckets. Die Daten sind "sauber".

  • Control 25% Traffic
    • Feature A nicht aktiv
    • Feature B nicht aktiv
  • Variante 1 25% Traffic
    • Feature A aktiv
    • Feature B nicht aktiv
  • Variante 2 25% Traffic
    • Feature A nicht aktiv
    • Feature B aktiv
  • Variante 3 25% Traffic
    • Feature A aktiv
    • Feature B aktiv

Was ist, wenn mehr als eine Software für Personalisierung und Testing verwendet wird?

Szenario
Sie verwenden beispielweise Salesforce Marketing Cloud E-Mail und testen Email A und Email B gegeneinander. Der Kunde gelangt in beiden Fällen zu einer Produkt-Landingpage. Auf dieser Produkt-Landingpage läuft ein Test. Es wird getestet, ob ein Ratenkaufrechner dazu führt, ob die Conversion steigt.

Lösung 1 Audiences im Targeting
Erstellen Sie eine Audience für E-Mail A-Kunden und eine Audience für E-Mail B. Nutzen Sie dazu bspw. einen UTM Parameter, der die E-Mails unterscheidet. Testen Sie das Ratenkauf-Feature für E-Mail A-Kunden separat von den E-Mail B-Kunden.


Targeting utm_campaign=email-xyz-A

  • Control 50% Traffic
    • Feature "Ratenkauf" nicht aktiv
  • Variante 1 50% Traffic
    • Feature "Ratenekauf-Rechner" aktiv

Targeting utm_campaign=email-xyz-B

  • Control 50% Traffic
    • Feature "Ratenkauf" nicht aktiv
  • Variante 1 50% Traffic
    • Feature "Ratenekauf-Rechner" aktiv

Lösung 2 Audiences im Report (empfohlen)
Erstellen Sie eine Audience für E-Mail A-Kunden und eine Audience für E-Mail B-Kunden. Testen Sie beide Audiences gleichzeitig. Schlüssel Sie den Report nach den Audiences von E-Mail A und E-Mail B auf.

Lösung 3 Webanalytics
Dynamic Yield ist mit z.B. Google Analytics connected. Bilden Sie vier Segmente:

  1. Email A* - ohne Ratenkauf**
  2. Email A - mit Ratenkauf
  3. Email B - ohne Ratenkauf
  4. Email B - mit Ratenkauf

*verwenden Sie wieder den UTM Parameter als Bedingung in der Session
**verwenden Sie das "Test"-Event als Bedingung in der Session

Untersuchen die Effekte in Google Analytics auf zum Beispiel E-Commerce KPI bei Auswahl aller vier Segmente.