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.
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.
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:
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.
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.
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".
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
Targeting utm_campaign=email-xyz-B
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:
*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.