BlastOptimize – Häufige Fehler beim A/B-Testing

Die Methode des A/B-Testings lässt sich einfach beschreiben: Man teilt den Traffic auf, vergleicht die Ergebnisse und wartet auf statistische Signifikanz. Allerdings ist sie leicht falsch anzuwenden, und einige Fehler treten regelmäßig auf, selbst bei erfahrenen Teams. Dieser Artikel erläutert die häufigsten Fehler beim A/B-Testing, warum sie die Ergebnisse verfälschen und wie man sie am einfachsten vermeidet.

Fehler Nr. 1: Testen ohne klare Hypothese

Einen Test durchzuführen, weil ein Wettbewerber eine ähnliche Änderung vorgenommen hat oder weil ein Designtrend online kursiert, führt selten zu verwertbaren Ergebnissen. Ohne eine klare Hypothese, die eine Beobachtung, eine Änderung und eine erwartete Kennzahl miteinander verknüpft, wird die Interpretation des Ergebnisses schwierig: Ein erfolgreicher Test gibt keine Auskunft über das „Warum“, und ein erfolgloser Test liefert keine Erkenntnisse, die auf den nächsten Test übertragbar sind.

Die Korrektur ist einfach anzuwenden: Formulieren Sie vor jedem Test die Hypothese in der Form: „Weil [Beobachtung], gehen wir davon aus, dass [Änderung] [Wirkung] zur Folge haben wird, gemessen durch [Kennzahl].“ Lässt sich dieser Satz nicht eindeutig vervollständigen, ist der Test wahrscheinlich noch nicht bereit zur Durchführung.

Fehler Nr. 2: Den Test abbrechen, sobald ein Ergebnis signifikant erscheint.

Dies ist vermutlich der häufigste Fehler, selbst bei Teams mit Kenntnissen in Statistik. Die meisten Tools zeigen ein Konfidenzniveau in Echtzeit an, das bei jedem neuen Besuch neu berechnet wird. Diesen Wert täglich zu überprüfen und den Test abzubrechen, sobald er 95 % übersteigt – manchmal schon nach zwei oder drei Tagen –, erhöht die Wahrscheinlichkeit, auf eine zufällige Schwankung zu stoßen, die im jeweiligen Moment einem realen Effekt ähnelt.

Dieses Phänomen, in der Literatur zu kontrollierten Tests als „Spähen“ dokumentiert, kann die Rate falsch positiver Ergebnisse im Vergleich zum angegebenen Konfidenzniveau deutlich erhöhen. Die Lösung besteht darin, vor Testbeginn eine Mindeststichprobengröße und -dauer festzulegen (siehe den Artikel in diesem Blog zur Berechnung der Stichprobengröße) und das Ergebnis erst dann als endgültig zu betrachten, wenn beide Bedingungen erfüllt sind – niemals vorher, selbst wenn das Dashboard bereits vielversprechend erscheint.

Fehler Nr. 3: Zu viele Änderungen gleichzeitig testen

Die gleichzeitige Änderung von Titel, Bild, Schaltfläche und Layout einer Seite in einer einzigen Variante mag effizient erscheinen – ein Test statt vier. Das Problem ist jedoch, dass ein positives Ergebnis weder Aufschluss darüber gibt, welche der vier Änderungen den Effekt hervorgerufen hat, noch ob einige davon ein Ergebnis sogar verschlechtert haben, das ohne sie noch besser hätte ausfallen können.

Die Isolierung einer Variable pro Test ermöglicht es, das Ergebnis eindeutig einer bestimmten Änderung zuzuordnen und diese Erkenntnisse für nachfolgende Tests zu nutzen. Das bedeutet nicht, dass Sie sich auf Mikroanpassungen beschränken sollten: Eine komplette Seitenüberarbeitung kann durchaus als einzelne „Überarbeitungsvariante“ gegen die Kontrollgruppe getestet werden, solange das Testziel darin besteht, die Überarbeitung als Ganzes zu validieren und nicht die Wirkung jeder einzelnen Komponente zu isolieren.

Fehler Nr. 4: Die erforderliche Stichprobengröße wird ignoriert.

Wenn man einen Test startet, ohne vorher die benötigte Besucherzahl abzuschätzen, führt das häufig zu einer von zwei problematischen Situationen: Entweder wird der Test aufgrund von Ungeduld zu früh abgebrochen, was dem Peeking-Fehler ähnelt, oder er läuft unbegrenzt weiter, ohne dass jemals eine klare Entscheidung getroffen wird, wodurch ein Teil des Datenverkehrs monatelang auf einer nicht validierten Variante blockiert wird.

Die Berechnung der Stichprobengröße vor dem Start, basierend auf der aktuellen Konversionsrate und dem minimalen Effekt, den wir nachweisen möchten, ermöglicht es uns, von Anfang an zu wissen, ob der Test innerhalb eines angemessenen Zeitraums durchführbar ist, und unsere Ambitionen entsprechend anzupassen, anstatt dies erst im Nachhinein festzustellen.

Fehler Nr. 5: Unterschiede zwischen Segmenten werden ignoriert

Ein aggregiertes Ergebnis kann sehr unterschiedliche Verhaltensweisen in verschiedenen Traffic-Segmenten verschleiern. Eine Änderung kann die Conversion-Rate auf Mobilgeräten verbessern, sie aber auf Desktop-Computern leicht verschlechtern, oder sie wirkt sich positiv auf neue Besucher aus, ohne wiederkehrende Besucher zu beeinträchtigen. Die alleinige Fokussierung auf die Gesamtzahl birgt das Risiko, ein Ergebnis zu verallgemeinern, das in Wirklichkeit nur einem Teil der Zielgruppe zugutekommt – oder sogar eine Änderung einzuführen, deren insgesamt positiver Effekt einen Rückgang in einem strategisch wichtigen Segment verschleiert.

Es ist nicht notwendig, für jeden Test jedes denkbare Segment zu analysieren, aber die Überprüfung der Konsistenz des Ergebnisses auf den für Ihr Unternehmen relevantesten Achsen (Gerätetyp, neue Besucher versus wiederkehrende Besucher, Hauptverkehrsquellen) vor der Verallgemeinerung einer Schlussfolgerung ist eine einfache Maßnahme, die unangenehme Überraschungen nach der Implementierung vermeidet.

Fehler Nr. 6: Verwechslung von Korrelation, Kausalität und Neuheitseffekt

Ein gut durchgeführter A/B-Test mit randomisierter Traffic-Verteilung stellt in der Regel einen recht zuverlässigen Kausalzusammenhang zwischen der getesteten Änderung und dem gemessenen Effekt her. Allerdings ist eine Verzerrung nicht auszuschließen: der Neuheitseffekt. Ein neues Layout kann allein aufgrund seiner Andersartigkeit mehr Aufmerksamkeit erregen – ein Effekt, der nachlässt, sobald sich wiederkehrende Besucher daran gewöhnt haben. Dieses Phänomen sollte besonders bei gut sichtbaren Änderungen beobachtet werden, die mit einer Zielgruppe getestet werden, die einen hohen Anteil an wiederkehrenden Besuchern aufweist.

Der einfachste Ansatz besteht darin, die Testdauer über das strikte statistische Minimum hinaus zu verlängern, wenn ein Neuheitseffekt vermutet wird, und, sofern das Volumen es zulässt, die Entwicklung der Konversionsrate der Variante zwischen dem ersten und dem letzten Testtag zu vergleichen: Ein Effekt, der im Laufe der Zeit deutlich nachlässt, ist eher ein Zeichen für einen Neuheitseffekt als für eine dauerhafte Verbesserung.

Fehler Nr. 7: Versäumnis, Ergebnisse zu dokumentieren

Ein Test, dessen Ergebnisse nicht strukturiert dokumentiert werden – Hypothese, erfasste Kennzahlen, Dauer, Stichprobengröße und Ergebnis – verliert langfristig viel von seinem Wert. Ohne diese Dokumentation wird dieselbe Idee aufgrund fehlenden kollektiven Gedächtnisses manchmal erst ein Jahr später erneut getestet, und individuelle Erkenntnisse tragen nicht zu einem differenzierteren und umfassenderen Verständnis des Besucherverhaltens bei.

Das Führen einer strukturierten Testhistorie, selbst in einfacher Form, ist eine der kostengünstigsten und lohnendsten Investitionen, die ein Team in sein Experimentierprogramm tätigen kann. Sie ermöglicht es Ihnen außerdem, im Laufe der Zeit wiederkehrende Themen zu identifizieren (z. B. funktionieren Änderungen, die die Benutzerführung vereinfachen, fast immer besser als solche, die sie erweitern), die speziell auf Ihre Zielgruppe zugeschnitten sind.

Fehler Nr. 8: Verallgemeinerung eines Ergebnisses über seinen Kontext hinaus.

Ein Test, der ausschließlich während einer atypischen Verkaufsperiode (Sonderangebot, saisonaler Besucheransturm, einmalige Werbekampagne) durchgeführt wird, kann ein Ergebnis liefern, das sich nicht auf den Rest des Jahres übertragen lässt, da sich das Besucherprofil in diesem Zeitraum vom üblichen Profil unterscheidet. Ebenso lassen sich Ergebnisse, die auf einer einzelnen Traffic-Quelle (z. B. einer spezifischen Werbekampagne) basieren, nicht unbedingt auf den gesamten Website-Traffic verallgemeinern.

Die Berücksichtigung des Kontextes, in dem ein Test durchgeführt wurde – Zeitraum, vorherrschende Verkehrsquellen, außergewöhnliche Ereignisse während des Testzeitraums – ermöglicht eine genauere Einschätzung des tatsächlichen Umfangs eines Ergebnisses, bevor es breitflächig eingesetzt wird, oder die Entscheidung, es in einem repräsentativeren Kontext erneut zu testen, falls Zweifel bestehen.

Fehler Nr. 9: Die technische Prüfung vor dem Start wird übersprungen.

Ein Test kann methodisch einwandfrei sein – gute Hypothese, gute Stichprobe, nur eine Variable wird getestet – und dennoch ein unbrauchbares Ergebnis liefern, wenn ein technisches Problem bei der Markteinführung unbemerkt bleibt: ein schlecht konfigurierter Conversion-Tracker, der bestimmte Ereignisse nicht zählt, eine Variante, die auf einem bestimmten Browser oder einer bestimmten Bildschirmgröße schlecht angezeigt wird, oder ein Element der Variante, das eine andere Komponente der Seite beeinträchtigt, ohne dass dies sofort ersichtlich ist.

Eine systematische Prüfung vor dem Teststart vermeidet diese Fallstricke: Visualisieren Sie die Variante auf den gängigsten Browsern und Bildschirmgrößen Ihrer Zielgruppe, lösen Sie das getrackte Conversion-Ereignis manuell aus, um die korrekte Erfassung zu bestätigen, und lassen Sie den Test einige Stunden mit reduzierter Last laufen, bevor Sie auf die endgültige Last umschalten. So erkennen Sie offensichtliche Anomalien, bevor diese eine größere Stichprobe beeinträchtigen. Diese Prüfung dauert selten länger als zehn Minuten und verhindert, dass Sie nach mehrtägiger Datenerfassung feststellen, dass ein Teil der Ergebnisse unbrauchbar ist.

Eine kurze Checkliste vor dem Start eines Tests

Um all diese Fehler in einer direkt nutzbaren Form zusammenzufassen, hier die Punkte, die vor dem Start eines A/B-Tests überprüft werden sollten:

  • Die Hypothese ist klar formuliert, mit einer Beobachtung, einer Veränderung und einem Erfolgsmaßstab.
  • Pro Variante wird nur eine Variable verändert, es sei denn, dies geschieht bewusst, um eine globale Neugestaltung als kohärentes Ganzes zu testen.
  • Die erforderliche Stichprobengröße wurde auf Basis der aktuellen Konversionsrate und des minimal gewünschten Effekts berechnet.
  • Eine Mindestdauer (mindestens ein bis zwei Wochen) wird im Voraus festgelegt und wird auch dann eingehalten, wenn sich bereits nach wenigen Tagen ein Ergebnis abzeichnet.
  • Das Conversion-Tracking wurde vor dem endgültigen Launch manuell getestet.
  • Die Variante wurde visuell auf den wichtigsten Geräten und Browsern des Publikums verifiziert.
  • Es gibt einen Plan, um das Endergebnis zu dokumentieren, wie auch immer es aussehen mag.

Das Durchgehen dieser Liste dauert vor jedem Start nur wenige Minuten und deckt die überwiegende Mehrheit der Fehler ab, die einen Test im Nachhinein ungültig machen – ein Zeitaufwand für die Überprüfung, der durch die gewonnene Zuverlässigkeit der endgültigen Entscheidung weitgehend kompensiert wird.

Wichtigste Erkenntnisse

Keiner dieser Fehler lässt sich durch ausgefeilte Werkzeuge vermeiden – sie werden durch Methodik und Disziplin korrigiert: eine vor jedem Test formulierte Hypothese, die Prüfung jeweils nur einer Variable, eine im Voraus berechnete Stichprobengröße, die Einhaltung der Testdauer, die Beachtung von Unterschieden zwischen Segmenten und die systematische Dokumentation der Ergebnisse. Es sind diese Vorgehensweisen, mehr als die Wahl eines bestimmten Werkzeugs, die darüber entscheiden, ob ein A/B-Testprogramm langfristig verlässliche Entscheidungen liefert.

BlastOptimize wurde entwickelt, um die technischen Hürden dieses Prozesses zu beseitigen – Variantenerstellung ohne Code, integrierte Stichprobenberechnung, Echtzeit-Überwachung der statistischen Signifikanz –, sodass sich das Team auf das Wesentliche konzentrieren kann: die Qualität der Hypothese und die Strenge der Methode. Sollten Sie in Ihren bisherigen Tests Fehler dieser Art festgestellt haben, bietet sich hier eine gute Gelegenheit, das Thema in Ihrem nächsten Test mit einer robusteren Methode erneut aufzugreifen.

Nachricht Bewährte Verfahren Neuigkeiten AB-Test und CRO

Die Kommentarfunktion ist deaktiviert.