Was unterscheidet innovative, wachstumsstarke Unternehmen wie Amazon, Microsoft, Uber, Airbnb oder booking.com von anderen? Sie führen, unter anderem, Tausende Experimente parallel durch¹.

Sie tun das, weil sie den (strategischen) Wert von Experimentation Programmen verstanden haben und wissen, dass die Anzahl der durchgeführten Tests – neben dem Anteil der positiven Ergebnisse und dem durchschnittlich erzeugten Uplift – ein entscheidender Erfolgsfaktor ist².

Und sie sind bereit in Testing zu investieren, weil sie sich vor allem eines Vorteils bewusst sind: paralleles Testing liefert schnell Insights, die in allen Bereichen der Organisation verwendet werden können.

Aber ist paralleles Testing tatsächlich der heilige Gral der Skalierbarkeit? Lässt sich dadurch wirklich Zeit sparen?

So einfach wie das klingt, ist es jedoch nicht, wie teils kontroverse Diskussionen zeigen. “Die Durchmischung von Nutzer:innen führt zu einer viel höheren Wahrscheinlichkeit eines Fehlers, sowie zu einer größeren täglichen und durchschnittlichen Varianz, was bedeutet, dass es schwieriger ist, verwertbare Ergebnisse zu erhalten”, mahnt Andrew Anderson, Head of Optimization bei Malwarebytes. Aber heißt das, parallele Tests liefern verwässerte oder gar falsche Ergebnisse?

Im Kontext von parallelem Testing gibt es einige Bedenken:

• Ist es nötig, parallel laufende Tests voneinander zu isolieren, um ihre Ergebnisse nicht zu verwässern?
• Ist paralleles Testing überhaupt geeignet, um valide Ergebnisse zu generieren?
• Oder bremst die Komplexität von parallelen Tests sogar Innovation?

Um diese Bedenken zu adressieren [Spoiler: und aufzulösen], müssen wir uns zunächst der Alternativen bewusst sein, ergo ein Verständnis für die verschiedenen Testmodelle entwickeln.

Übersicht verschiedener Testmodelle

1. Serielles Testen

Beim seriellen Testen laufen die Tests hintereinander ab. Du startest mit Test 1, wartest bis dieser abgeschlossen ist und beginnst dann Test 2. Beide Tests laufen auf beliebig wählbaren Anteilen des gesamten Traffics.

2. Isoliertes Testen

Beim isolierten Testen finden Test 1 und Test 2 im gleichen Zeitraum statt. Vorher wurde jedoch definiert, dass ein Teil der Nutzer:innen in Test 1 und der andere Teil in Test 2 landen. Diese Tests laufen zeitgleich, jede:r Nutzer:in sieht allerdings nur einen Test.

Für Organisationen mit viel Traffic auf ihrer Website kann das ein echter Wettbewerbsvorteil sein, da sie (fast) beliebig viele Tests parallel durchführen können. Um dabei mit derselben Testpower testen zu können, müssen in dem Fall aber die Testlaufzeiten entsprechend verlängert werden.

Vereinfacht ausgedrückt: Bei der doppelten Anzahl an Tests halbiert sich die Stichprobengröße, wodurch sich die Testlaufzeit verdoppelt.

3. Paralleles Testen

Beim parallelen Testen laufen Experimente tatsächlich parallel, wodurch jede:r Nutzer:in gleichzeitig an Test 1 und Test 2 teilnehmen kann und dementsprechend mit den jeweils ausgelösten Zielen auch in beiden Tests mitgezählt wird.

So würden sich also beispielsweise 100.000 Nutzer:innen zu je 50.000 Nutzer:innen in der Control und in der Variante des ersten Tests und in die Control und Variante des zweiten Tests aufteilen (siehe Abbildung unten). Wenn keine außergewöhnliche Abhängigkeit zwischen den Tests besteht und die Randomisierung des Testingtools funktioniert wie erwartet, sollten sich die Nutzer in jeder Variante des einen Tests ungefähr gleich auf die Varianten des zweiten Tests verteilen.

Das bedeutet: In der Kontrollgruppe von Test 1 befinden sich zu ca. 50 % Nutzer:innen aus der Control des zweiten Tests sowie 50 % aus der Variante des zweiten Tests, ebenso wie sich in der Variante des ersten Tests gleich viele Nutzer:innen aus der Control und der Variante des zweiten Tests befinden. Dadurch sollten alle Effekte, die ein paralleler Test auf das Nutzerverhalten hat, im gleichen Maß in allen Varianten auftreten, wodurch die Vergleichbarkeit grundsätzlich gegeben ist.

Vor diesem theoretischen Hintergrund können wir nun die eingangs erwähnten Kritikpunkte diskutieren und klären, inwieweit diese tatsächlich als Nachteil von parallelen Tests zu verstehen sind. Demgegenüber stehen ohnehin verschiedene Vorteile, die paralleles Testing unserer Meinung nach zu einem überlegenen Ansatz machen.

Vorteile von parallelem Testing

1. Wir können unbegrenzt viele Tests durchführen

Können Tests einfach parallel laufen, gibt es keine logische Grenze für die Anzahl an Tests, die ein Unternehmen durchführen kann. Egal ob im seriellen oder im isolierten Testing, der zur Verfügung stehende Traffic begrenzt die Anzahl an Tests in einem bestimmten Zeitraum (unabhängig vom Betrachtungszeitraum).

Mit parallelen Tests können Organisationen selbst auf Webseiten mit relativ wenig Traffic unbegrenzt experimentieren und dadurch die gleichen Wachstumstreiber nutzen, wie die eingangs genannten Marktführer. Da alle Hypothesen getestet werden können, verbreitet sich dadurch ein echtes Innovation-Mindset. Können aufgrund von Traffic Beschränkungen nur einige wenige Tests im Jahr durchgeführt werden und werden deswegen zahlreiche Ideen niemals getestet, sinkt die Motivation, kontinuierlich nach neuen Optimierungsmöglichkeiten (auch und gerade den kleinen) zu suchen.

Trotz des Hypes um grenzenloses Testing kann es aber durchaus technische Grenzen geben, die die Anzahl der gleichzeitig laufenden Tests in der Praxis beschränken kann. Müssen beispielsweise clientseitig beim Seitenaufruf zu viele Skripte des Testingtools ablaufen, kann dies Einfluss auf die Performance der Website haben und somit die UX grundsätzlich verschlechtern.

2. Hypothesen können sofort getestet werden

Wie viel einfacher fällt die Planung aus, wenn zunächst keine Rücksicht auf andere Tests genommen werden muss, um ein Experiment zu starten? Kein Warten darauf, bis der aktuelle Test beendet ist! Keine Diskussionen darüber, welcher Test eine höhere Relevanz hat! Keine Kompromisse bei der Testlaufzeit und damit auch der statistischen Power, weil der nächste Test nicht so lange warten kann!

Wenn alle Tests parallel laufen können, muss ein Experiment “nur” entwickelt und qualitätsgesichert werden, bevor er starten kann. Natürlich kann es gelegentlich Gründe dafür geben, mit dem Start eines Tests zu warten, bis ein anderer abgeschlossen ist; nämlich genau dann, wenn die Tests inhaltlich nicht zusammen passen bzw. sich widersprechen.

Ein plakatives Beispiel hierfür wäre, wenn Test 1 die Farbe Spacegrey als neue Hintergrundfarbe testet und ein weiterer Test 2 dieselbe Farbe als Schriftfarbe oder zum Einfärben von Icons benutzen möchte. Etwas praxisbezogener ist die Vorstellung, dass in einem Test ein Element (bspw. eine Menüleiste) entfernt wird, um das Layout zu vereinfachen, während ein weiterer Test Änderungen am Inhalt oder Design eben dieses Elements überprüft.

3. Einflüsse (Interferenzen) können sichtbar gemacht werden

Wenn wir in der Praxis Tests parallel laufen lassen möchten, hören wir häufig die Bedenken darüber, dass man ja nicht wissen kann, ob und wie die parallel laufenden Tests einander beeinflussen. Vielleicht funktionieren die Veränderungen aus Test 1 nur deswegen, weil Nutzer:innen einen bestimmten Reiz aus einem anderen Test erhalten haben (oder sie funktionieren gegenteilig genau deswegen nicht)? Vielleicht (dazu gleich mehr), aber gerade durch paralleles Testing und einer anschließenden segmentierten Auswertung nach Varianten-Zugehörigkeit in anderen Tests können wir diese Interferenzen wirklich sichtbar machen! Das ist also weniger ein Argument gegen paralleles Testen, sondern vielmehr eines dafür.

Ein Beispiel: Angenommen, es liefen zwei Tests mit jeweils einer Control und einer Variante parallel und wir möchten analysieren, ob die Variante des zweiten Tests das Ergebnis des ersten Tests beeinflusst hat. Zu diesem Zweck können in Test 1 zwei Segmente gebildet werden. Segment 1 enthält alle Nutzer:innen, die parallel in der Control-Gruppe des zweiten Tests waren und Segment 2 umfasst alle Nutzer:innen aus der Variante des zweiten Tests (siehe Abbildung unten). Unterscheiden sich die Effekte in beiden Segmenten deutlich, kann es sich um eine Interferenz der beiden Tests handeln, die ggf. weiter untersucht wird oder mit einem Folgetest evaluiert werden kann.

Würden wir die Tests unabhängig voneinander durchführen, also durch serielles oder isoliertes Testing, haben wir keine Möglichkeit, diesen Vergleich anzustellen.
Grundsätzlich sei jedoch erwähnt, dass sich bei erwarteten Interferenzen ein MVT-Setup (Multivariates Testing) besser eignet als unabhängige Tests, die post hoc in einzelne Kombinationen segmentiert werden.

(Vermeintliche) Nachteile von parallelem Testing

Wie zu Beginn erwähnt, gibt es in der A/B-Testing-Community einige Stimmen, die vor einer erhöhten Fehlerwahrscheinlichkeit durch paralleles Testing warnen.

Aber was ist denn überhaupt der Grundgedanke des Experimentierens?

Wir setzen in einer Gruppe von Nutzer:innen einen Stimulus (Variante) und in der anderen nicht (Control). Abgesehen von dieser Änderung sollen sich Nutzer:innen aus beiden Gruppen identisch zusammensetzen, was in der Regel durch eine randomisierte Zuteilung in die Testgruppen sichergestellt wird. Dadurch leiten wir mit einer gewissen Konfidenz ab, dass alle “signifikanten” Unterschiede im Nutzerverhalten der Testgruppen ursächlich mit dem gesetzten Stimulus zusammenhängen.

1. Parallele Tests verwässern die Stichprobe und machen diese unbrauchbar

Kritisiert wird, dass diese Grundprinzip beim parallelen Testing nicht mehr eingehalten wird. Die Befürchtung ist, dass Nutzer:innen durch gleichzeitig laufende Tests eine Website unterschiedlich erleben und somit die Ergebnisse des einzelnen Experiments verwässern, bei dem wir ja eigentlich versuchen, die Auswirkungen auf das Nutzerverhalten durch die Veränderung(en) in einer Variante isoliert zu bewerten.

Dem würden wir entgegnen, dass es sich bei kontrollierten Online-Experimenten grundsätzlich nicht um Experimente unter Laborbedingungen handelt, sondern um sogenannte Feldexperimente, die von einer Vielzahl an externen Einflussfaktoren “gestört” werden können. Auch ohne einen zusätzlichen parallelen Test können wir nicht sicherstellen, dass alle Nutzer:innen in den Varianten dieselbe User Experience machen und derselben User Journey folgen.

Manche Nutzer:innen gehen direkt zum Check-out, nachdem sie alle Produkte in den Warenkorb gelegt haben, andere sehen sich den Warenkorb zunächst nochmal an. Einige Nutzer:innen lesen die sorgsam erstellte und mit allerlei konsumpsychologischen Triggern optimierte Produktbeschreibung, während andere nur am Preis interessiert sind und anhand dessen entscheiden, ob sie ein Produkt kaufen oder nicht.

Die Varianz in den Daten eines Online Experiments ist also ohnehin groß. Der Einfluss durch eine (oder auch mehrere) zusätzliche Varianten aus parallelen Tests ist nur ein weiterer Faktor von vielen. Durch eine randomisierte Aufteilung der Nutzer:innen in die einzelnen Testsegmente und einer ausreichend großen Stichprobe können wir dennoch sicherstellen, dass sich die beobachtbaren Veränderungen in der User-Experience gleichmäßig über alle Testvarianten verteilen und somit eine Vergleichbarkeit gegeben ist.

Das gilt auch bei parallelen Tests, da die Varianten-Zuteilung in beiden Tests unabhängig voneinander geschieht. Heißt: Wenn ein:e Nutzer:in bereits in einem Test ist und nun an einem zweiten Test teilnimmt, hat die Variante des ersten Tests keinen Einfluss darauf, welche Variante diese:r Nutzer:in im zweiten Test erlebt (siehe Abbildung unten). Control und Variante bleiben vergleichbar.

Ausnahmen bestimmen die Regel: Zum Beispiel, wenn in einem Test untersucht wird, ob der Besuch des Warenkorbs vor dem Check-out verpflichtend sein soll, und in einem zweiten Test der Inhalt der Warenkorb-Seite optimiert wird (siehe Abbildung unten).

Die Variante, in der der Warenkorb verpflichtend ist, werden alle 50.000 Nutzer:innen auch am zweiten Test teilnehmen und sich zu jeweils 25.000 auf die beiden Varianten des zweiten Tests verteilen.

Gleichzeitig werden die Nutzer:innen aus der Control des ersten Tests, welche sich dafür entscheiden, den Warenkorb zu überspringen und direkt zum Check-out zu gehen (hier: 30.000 Nutzer:innen), gar nicht am zweiten Test teilnehmen. Lediglich die 20.000 Nutzer:innen, welche freiwillig zum Warenkorb gehen, werden auch in den zweiten Test gelangen und sich dort zu jeweils 10.000 auf die beiden Varianten verteilen.

Wenn die Variante des verpflichtenden Warenkorbs nun besser (oder schlechter) abschneidet, muss dies nicht am verpflichtenden Besuch des Warenkorbs liegen, sondern kann auch dadurch getrieben sein, dass in dieser Variante viel mehr (hier: 15.000) Nutzer:innen den optimierten Warenkorb gesehen haben.

Das sind jedoch Edge Cases, die wir in der Regel antizipieren und durch ein alternatives Testing-Modell (seriell oder isoliert) umgehen können.

2. Die Validität der Ergebnisse wird beeinträchtigt

Weitere Kritik zu einer vermeintlich erhöhten Fehlerquote bei parallelen Tests bezieht sich auf die möglichen Interferenzen zwischen den Testvarianten (siehe oben).

Die Befürchtung ist, dass wenn parallel durchgeführte Experimente unabhängig voneinander ausgewertet werden und für jeden Test ein Gewinner bestimmt wird, Interferenzen nicht berücksichtigt werden. Das könnte dazu führen, dass eine unterlegene Kombination von Varianten ausgerollt wird.

Im untenstehenden Diagramm haben wir beispielhafte Daten für so einen Fall skizziert (erste und zweite Spalte). In Test 1 erzielt die Control eine Conversion Rate (CR) von 6 %, die Variante eine CR von 5,5 %. In Test 2 erzielt die Variante eine höhere Conversion Rate als die Control (6,2 % > 5 %) und würde dementsprechend ausgerollt werden – zur Vereinfachung nehmen wir einen signifikanten Effekt an.

Sowohl die Unterlegenheit der V1 als auch die Überlegenheit der V2 kommen jedoch möglicherweise nur durch die Kombination der beiden Tests zustande, so die Bedenken aus der Community. Oder anders formuliert: Bei einem isolierten Test 1 hätte die Variante gewonnen, weil nur die Interferenz mit Test 2 zu einem Downcast führte.

Diese These können wir allerdings leicht überprüfen, indem wir die Tests segmentiert auswerten, sprich alle Varianten-Kombinationen einzeln bewerten:

1. Segment: User aus Test 1 Control und Test 2 Control (C-C)
2. Segment: C-V
3. Segment: V-C
4. Segment: V-V

Wie im Beispiel oben (dritte Spalte) kann dabei tatsächlich herauskommen, dass unsere ursprüngliche Entscheidung für Kombination C-V suboptimal war. Die insgesamt höchste Conversion Rate ergab sich nämlich aus der Kombination V-V.

Wir können nicht ausschließen, dass ein solcher Fall tatsächlich auftreten kann. Aber ohne paralleles Testing (oder MVT) wüssten wir davon ja auch gar nichts.

Unsere Erfahrung bestätigt zudem, dass solche Effekte extrem selten auftreten und auch nie mit dem Ergebnis, dass die “falsche” Kombination zu einem Downcast führt. In der Praxis ergibt Plus mal Plus sozusagen niemals Minus.

Und ganz abgesehen davon gilt: Wenn in deiner Organisation bereits seriell oder isoliert getestet wird, dann wurden daraus bestimmt schon einige Varianten in den Live-Betrieb ausgerollt; und andere wurden verworfen. Dadurch fehlt uns schlichtweg die Möglichkeit zu vergleichen, ob ebendiese verworfenen Varianten in Kombination mit Varianten aus zukünftigen Tests nicht vielleicht doch Gewinner geworden wären.

Genau genommen gibt es durch vergangene Tests also unzählige mögliche Kombinationen mit der aktuellen Variante, die wir überhaupt nicht testen. Wieso sollten dann die möglichen Interferenzen aus “heute” parallel laufenden Tests überhaupt relevant sein?

3. Die Komplexität wird erhöht

Der Anspruch, wirklich alle parallel laufenden Tests immer segmentiert auszuwerten, um Interferenzen zu bemerken und stets die optimale Kombination von Varianten zu finden, würde sicherlich einen erheblichen Mehraufwand bedeuten und die Komplexität eines Testing-Programms erhöhen. Dieser Aufwand lohnt sich unserer Erfahrung nach aber nur selten (nämlich dann, wenn solche Interferenzen vorab als sehr wahrscheinlich eingeschätzt wurden).

Vernachlässigen wir diesen Aspekt, reduziert eine parallele Testing-Strategie also sogar die Komplexität des ganzen Programms, denn hinzukommt, dass es letztlich keine klassische Roadmap-Planung mehr braucht, um zu definieren, wann welcher Test durchgeführt werden kann. Auch auf ein Scoring oder die Priorisierung von Testideen könnten wir dann verzichten, wenn sowieso jede Idee jederzeit getestet werden kann. Vergesst aber deshalb bitte niemals die Qualitätssicherung und die Prüfung von Test-Konzepten auf Sinnhaftigkeit. 😉

Fazit: Beim parallelen Testen überwiegen die Vorteile!

Die Vorteile von parallelem Testing in der Praxis überwiegen die – vorwiegend theoretischen oder irrelevanten – Gegenargumente unserer Meinung nach deutlich.

Kann es passieren, dass ein Testergebnis durch einen anderen parallelen Test beeinflusst wird? Ja, sicher.

Kann es sein, dass dadurch ein tatsächlicher Verlierer fälschlicherweise als Gewinner erscheint? Sehr unwahrscheinlich.

Wenn es solche Effekte gibt und sie erwartet werden, möchten wir dann nicht die Möglichkeit haben, diese auch zu analysieren? Wenn ja, dann sind parallele Tests neben MVT die einzige Möglichkeit dazu.

Paralleles Testing bietet die Möglichkeit, das eigene Testing-Programm beinahe nach Belieben zu skalieren. Das Potenzial, das die enorme Geschwindigkeit, mit der wir dadurch Ideen testen und umsetzen können, darstellt, überwiegt sämtliche Risiken.

Sogar kleine und mittlere Unternehmen, die nicht mit sieben- bis achtstelligem Traffic arbeiten können, haben durch paralleles Testing die Möglichkeit zu optimieren wie die Großen!