A/B Testing im Marketing verspricht etwas Verführerisches: Du musst nicht mehr diskutieren, wer im Meeting recht hat, sondern lässt die Nutzer abstimmen. Das ist im Kern richtig – und es ist der Grund, warum aus einer Methode der Agrarstatistik das wichtigste Werkzeug der Conversion-Optimierung wurde.
Der Haken steht selten im Tutorial: Ein A/B-Test, der falsch ausgewertet wird, ist nicht neutral. Er ist schlechter als gar kein Test, weil er einer Bauchentscheidung den Anstrich von Wissenschaft gibt. Du triffst dieselbe willkürliche Wahl wie vorher, aber jetzt mit einem Dashboard, das „95 % Konfidenz” darunterschreibt.
Dieser Artikel behandelt deshalb drei Dinge. Erstens die Mechanik: Wie ein sauberer Test aufgebaut ist. Zweitens die Statistik in der Form, die du tatsächlich brauchst – ohne Formelwüste, aber auch ohne die üblichen Halbwahrheiten. Und drittens die Fehler, die Ergebnisse nicht ungenau, sondern wertlos machen.
Die Zahlen zu diesen Fehlern haben wir nicht abgeschrieben. Wir haben sie selbst simuliert: Millionen künstlicher Nutzer, bei denen wir vorher wussten, was wahr ist – und dann gemessen, wie oft die übliche Auswertungspraxis das Falsche behauptet.
Die kurze Version für Eilige
- „Signifikant” heißt nicht „richtig”. Ein p-Wert unter 0,05 sagt: Wenn es keinen Unterschied gäbe, wären Daten wie diese selten. Er sagt nichts darüber, wie wahrscheinlich deine Variante besser ist.
- Zwischenblicke zerstören genau diese Aussage. In unserer Simulation ohne jeden echten Unterschied: 1× auswerten → 5,1 % Fehlalarm. 10× zwischendurch schauen und beim ersten grünen Ergebnis stoppen → 22,0 %. 50× → 32,0 %.
- Die Stichprobengröße ist keine Formalie, sondern die Testfrage. Bei 5 % Ausgangs-Conversion und dem Wunsch, eine relative Verbesserung von 5 % zu erkennen, brauchst du rund 244.000 Besucher. Für 20 % Verbesserung nur noch 16.316.
- Zu kleine Tests lügen nicht nur häufiger, sie lügen auch nach oben. Bei einem wahren Effekt von +5 % meldeten die signifikanten Durchläufe in unserer Simulation im Schnitt +22,6 % (n = 5.000 je Variante). Das ist der Winner’s Curse – und der Grund, warum sich Testerfolge selten in der Bilanz wiederfinden.
- Prüfe zuerst die Verteilung, dann das Ergebnis. Wenn Variante A 51,4 % und B 48,6 % des Traffics bekommen hat, ist der Test kaputt, egal wie schön die Kurve aussieht (Sample Ratio Mismatch).
- Die meisten Ideen funktionieren nicht. Bei Microsoft verbesserte nur etwa ein Drittel der getesteten Ideen die Zielmetrik. Das ist keine schlechte Nachricht, sondern der eigentliche Wert der Methode.
- Für kleine Websites ist A/B-Testing oft das falsche Werkzeug. Bei 200 Besuchern am Tag dauert ein sauberer Test auf 10 % Verbesserung über zwei Jahre. Was du stattdessen tun kannst, steht weiter unten.
Bevor du Buttonfarben testest: miss die Ladezeit Eine Seite, die drei Sekunden zum Rendern braucht, verliert mehr Conversions, als jeder Text-Test je zurückholt. Unser Core Web Vitals Test zeigt dir in wenigen Sekunden, ob dein Problem überhaupt auf der Ebene liegt, die du gerade testen willst.
Was ein A/B-Test ist – und was er nicht ist
Ein A/B-Test teilt deinen Traffic zufällig in zwei Gruppen. Gruppe A sieht die bestehende Version (Kontrolle), Gruppe B eine Variante mit genau einer geänderten Sache. Nach einer vorher festgelegten Menge an Besuchern vergleichst du eine vorher festgelegte Kennzahl.
Die drei Wörter, die den ganzen Unterschied machen, sind zufällig, genau eine und vorher festgelegt. Fällt eines davon weg, bekommst du zwar immer noch Zahlen, aber sie tragen keine Aussage mehr.
- Zufällig heißt: Die Zuteilung darf nichts mit dem Nutzer zu tun haben. Wenn Variante B nur an Desktop-Nutzer ausgespielt wird, misst du das Endgerät, nicht deine Idee.
- Genau eine Sache heißt: Wenn du Überschrift und Button und Bild änderst, weißt du hinterher, dass etwas gewirkt hat – aber nicht was. Für viele Änderungen auf einmal gibt es multivariate Tests, die deutlich mehr Traffic brauchen.
- Vorher festgelegt ist die Bedingung, an der die meisten Tests scheitern, und sie hat einen eigenen Abschnitt weiter unten verdient.
Der Unterschied zum Vorher-Nachher-Vergleich
Der häufigste Ersatz für einen echten Test ist: „Wir haben die Seite am Montag umgestellt, und diese Woche ist die Conversion um 12 % besser.” Das ist kein Test, sondern eine Erzählung. In dieser Woche war das Wetter anders, eine Kampagne lief an, es war Monatsanfang, ein Wettbewerber hatte einen Ausfall. Ein A/B-Test entfernt diese Störgrößen nicht dadurch, dass er sie misst, sondern dadurch, dass beide Gruppen sie gleichzeitig erleben.
Genau deshalb ist die Parallelität nicht verhandelbar. Ein “A/B-Test”, bei dem Variante A im März und Variante B im April läuft, ist ein Vorher-Nachher-Vergleich mit besserem Namen.
Was A/B-Tests nicht können
- Sie erklären nichts. Ein Test sagt dir, dass B besser konvertiert, nie warum. Das Warum liefern Nutzerinterviews, Session Recordings und Umfragen – und die gehören vor den Test, weil sie die Hypothese liefern.
- Sie messen kurzfristig. Ein aggressiveres Pop-up steigert die Newsletter-Anmeldungen und kostet dir über Monate Wiederkehrer. Der Test läuft zwei Wochen und sieht davon nichts.
- Sie taugen nicht für seltene Ereignisse. Wenn du zwölf Verkäufe im Monat hast, kannst du mit A/B-Testing nichts messen. Dazu unten mehr.
Statistische Signifikanz: was sie wirklich sagt
Fast jedes Dashboard zeigt eine Zahl wie „96 % Konfidenz” oder „p = 0,04”. Die verbreitetste Übersetzung ist: „Wir sind zu 96 % sicher, dass B besser ist.” Diese Übersetzung ist falsch, und aus diesem einen Missverständnis folgen die meisten schlechten Entscheidungen.
Was der p-Wert tatsächlich beantwortet, ist eine hypothetische Frage:
Angenommen, A und B wären in Wahrheit exakt gleich gut – wie oft würden wir dann einen Unterschied sehen, der mindestens so groß ist wie der gemessene?
Ein p-Wert von 0,04 heißt: in 4 % der Fälle. Mehr nicht. Es ist eine Aussage über die Daten unter einer Annahme, nicht über die Wahrheit der Annahme. Die Wahrscheinlichkeit, dass deine Variante besser ist, kann man daraus nicht ablesen – dafür bräuchte man zusätzlich, wie plausibel die Idee vorher war. Genau das leistet die bayessche Auswertung, die viele moderne Tools deshalb anbieten.
Für die Praxis reicht eine strengere, aber ehrlichere Faustregel:
Signifikanz ist ein Filter gegen Zufall, kein Beweis für Wirkung. Sie sagt: „Das ist wahrscheinlich nicht nur Rauschen.” Sie sagt nicht: „Das wird sich in deiner Bilanz zeigen.”
Die zwei Fehlerarten, und warum nur über eine geredet wird
| In Wahrheit kein Unterschied | In Wahrheit ein Unterschied | |
|---|---|---|
| Test sagt „Gewinner” | Fehler 1. Art (Fehlalarm) | richtig |
| Test sagt „nichts” | richtig | Fehler 2. Art (übersehener Effekt) |
Das Signifikanzniveau (üblich: 5 %) begrenzt die erste Fehlerart. Die zweite regelt die Teststärke (Power), üblich sind 80 %. Sie bedeutet: Wenn der Effekt, den du erkennen wolltest, wirklich existiert, findest du ihn in 80 % der Fälle – und übersiehst ihn in 20 %.
Über die zweite Fehlerart redet fast niemand, obwohl sie im Marketing teurer ist. Ein übersehener Gewinner erzeugt keinen Ärger, keine Krisensitzung, keine Notiz. Er verschwindet einfach in einem „hat nichts gebracht”, und die Idee kommt nie wieder auf den Tisch. Die erste Fehlerart bemerkt man irgendwann. Die zweite nie.
Die Stichprobengröße ist die eigentliche Testfrage
Die wichtigste Zahl legst du fest, bevor der Test startet: Wie groß muss der Unterschied mindestens sein, damit er dich interessiert? Dieser Wert heißt MDE (Minimum Detectable Effect), und er entscheidet über alles Weitere.
Die Beziehung ist unbarmherzig: Halbierst du den Effekt, den du erkennen willst, vervierfacht sich der benötigte Traffic. Hier die Werte, gerechnet für ein Signifikanzniveau von 5 % (zweiseitig) und eine Teststärke von 80 %:
| Ausgangs-Conversion | Erkennbare relative Verbesserung | Besucher je Variante | Gesamt |
|---|---|---|---|
| 1 % | 5 % | 637.010 | 1.274.020 |
| 1 % | 10 % | 163.095 | 326.190 |
| 1 % | 20 % | 42.693 | 85.386 |
| 2 % | 10 % | 80.682 | 161.364 |
| 2 % | 20 % | 21.109 | 42.218 |
| 3 % | 10 % | 53.211 | 106.422 |
| 5 % | 5 % | 122.124 | 244.248 |
| 5 % | 10 % | 31.234 | 62.468 |
| 5 % | 20 % | 8.158 | 16.316 |
| 10 % | 20 % | 3.841 | 7.682 |
Übersetzt in Kalendertage wird die Zahl erst richtig unangenehm. Bei 5 % Ausgangs-Conversion und dem Ziel, 10 % Verbesserung zu erkennen:
- 5.000 Besucher am Tag: 12 Tage – machbar.
- 1.000 Besucher am Tag: 62 Tage – schwierig, aber möglich.
- 200 Besucher am Tag: 312 Tage. In dieser Zeit ändert sich dein Produkt, deine Zielgruppe und dein Wettbewerb. Das Ergebnis wäre veraltet, bevor es fertig ist.
Die praktische Konsequenz wird selten ausgesprochen: Wenn deine Rechnung 300 Tage ergibt, ist das kein Grund, den Test trotzdem zu starten und nach zwei Wochen zu schauen. Es ist die Antwort, dass A/B-Testing für diese Fragestellung das falsche Werkzeug ist. Was dann hilft, steht im Abschnitt „Wenn dein Traffic nicht reicht”.
Fehler 1: Peeking – der teuerste Fehler, den kaum jemand für einen hält
Das Muster ist überall gleich. Der Test läuft, das Dashboard ist offen, am dritten Tag steht Variante B auf „97 % Konfidenz”. Der Test wird gestoppt, B ausgerollt, alle sind zufrieden.
Dieses Vorgehen zerstört exakt die Grundlage, auf der die 97 % berechnet wurden. Die Signifikanzberechnung setzt voraus, dass die Stichprobengröße vorher feststand. Wenn du stattdessen so lange schaust, bis das Ergebnis gefällt, testest du nicht mehr die Hypothese – du testest, ob das Rauschen irgendwann zufällig groß genug wird. Und das wird es.
Evan Miller hat das 2010 in „How Not To Run an A/B Test” durchgerechnet und kommt für den Extremfall (Auswertung nach jedem einzelnen Besucher, Abbruch bei 5 % Signifikanz) auf eine tatsächliche Fehlerrate von 26,1 % statt der angenommenen 5 %.
Weil das theoretisch klingt, haben wir es selbst nachgestellt – mit einer Situation, in der wir sicher wissen, dass es keinen Unterschied gibt. Beide Varianten haben exakt 5 % Conversion. Wir simulieren jeweils 4.000 komplette Testläufe mit 10.000 Besuchern je Variante und zählen, wie oft ein „Gewinner” gemeldet wird:
| Auswertungsverhalten | Gemeldete Gewinner (Wahrheit: keiner) |
|---|---|
| 1× am Ende auswerten (korrekt) | 5,1 % |
| 2 Zwischenblicke | 8,8 % |
| 5 Zwischenblicke | 13,4 % |
| 10 Zwischenblicke | 22,0 % |
| 20 Zwischenblicke (etwa täglich) | 23,7 % |
| 50 Zwischenblicke | 32,0 % |
Lies die letzte Zeile noch einmal: Bei etwa jedem dritten Test findest du einen Gewinner, der nicht existiert. Nicht weil deine Idee schlecht wäre – sondern weil du hingeschaut hast, bis die Zahlen zufällig gut standen.
Und jetzt der Teil, der im Alltag wirklich weh tut: Diese Fehlalarme kommen nicht gleichmäßig. Sie tauchen bevorzugt früh auf, wenn die Kurven noch am stärksten schwanken. Der Test, der schon nach zwei Tagen „gewinnt”, ist genau der, dem du am wenigsten trauen darfst. Im Alltag ist es aber der, der am meisten Begeisterung auslöst.
Die Gegenmittel, in dieser Reihenfolge:
- Stichprobengröße vorher berechnen und aufschreiben. Nicht im Kopf – in das Ticket, in dem der Test beschrieben ist. Ein Zielwert, den nur du kennst, wird im Erfolgsfall nachträglich angepasst.
- Volle Wochen laufen lassen, mindestens eine, besser zwei. Dienstagnutzer verhalten sich anders als Sonntagnutzer. Wer nach 9 Tagen stoppt, hat einen Wochentag doppelt drin.
- Hinschauen ist erlaubt, stoppen nicht. Zwischenstände sind nützlich, um technische Fehler zu finden (siehe Sample Ratio Mismatch). Sie sind kein Entscheidungsgrund.
- Wenn du wirklich früh stoppen musst, brauchst du dafür gebaute Verfahren – Sequenzanalyse, Alpha-Spending, Always-Valid-Inference. Mehrere moderne Tools bieten das an. Was nicht geht: normale Auswertung plus früher Abbruch.
Fehler 2: Sample Ratio Mismatch – der Test, der nie stattgefunden hat
Du willst 50/50 aufteilen. Am Ende steht in Variante A 51.400 Besucher und in B 48.600. Klingt nach normaler Schwankung, ist es aber nicht: Bei rund 100.000 Zuweisungen sollte die Abweichung deutlich unter einem Prozentpunkt liegen. Eine Verteilung von 51,4 zu 48,6 ist so unwahrscheinlich, dass es fast sicher einen technischen Grund gibt.
Das nennt sich Sample Ratio Mismatch (SRM). Microsoft Research nutzt dafür einen bewusst strengen Schwellenwert: Ein χ²-Test auf die Verteilung mit p < 0,0005 löst Alarm aus. In der Praxis liegt der Wert bei echten SRM-Fällen weit darunter.
Die Ursachen sind fast immer banal und fast immer verzerrend:
- Das Skript der Variante lädt langsamer, ein Teil der Nutzer bricht vor der Zuteilung ab – und zwar die mit der schlechtesten Verbindung.
- Ein Bot-Filter greift auf einer Variante anders.
- Ein Redirect verliert Nutzer auf dem Weg.
- Der Test wurde mittendrin neu gestartet, ein Teil der Nutzer kannte die Variante schon.
Warum das schlimmer ist als ein ungenaues Ergebnis: Wenn Nutzer systematisch aus einer Gruppe herausfallen, ist die Zufälligkeit dahin. Die verbleibenden Gruppen sind nicht mehr vergleichbar, und kein statistisches Verfahren kann das reparieren. Ein Test mit SRM liefert kein schwaches Ergebnis, sondern gar keines.
Deshalb gehört die Prüfung an den Anfang der Auswertung, nicht ans Ende. Erst die Verteilung, dann die Kennzahl. Wer zuerst auf das Ergebnis schaut, findet Gründe, den SRM nicht so ernst zu nehmen.
Fehler 3: Der Winner’s Curse – warum Testerfolge in der Bilanz verschwinden
Dieser Fehler ist der subtilste, und er erklärt eine Beobachtung, die fast jedes Marketingteam kennt: Über das Jahr wurden zwölf Tests „gewonnen”, jeder mit zweistelliger Verbesserung – aber die Gesamtconversion steht ungefähr da, wo sie vorher stand.
Der Grund ist eine Auswahlverzerrung. Ein zu kleiner Test kann einen echten, kleinen Effekt gar nicht erkennen. Er wird nur dann signifikant, wenn das Rauschen zufällig in dieselbe Richtung zeigt wie der echte Effekt. Damit sind die Gewinner systematisch die überschätzten Durchläufe.
Auch das haben wir simuliert. Wir bauen einen wahren Effekt von +5 % ein (5 % gegen 5,25 % Conversion) und schauen, was die Tests melden, die signifikant werden:
| Besucher je Variante | Teststärke (gefundene echte Effekte) | Gemessener Lift der „Gewinner” |
|---|---|---|
| 5.000 | 8,7 % | +22,6 % |
| 20.000 | 20,1 % | +11,2 % |
| 100.000 | 69,0 % | +5,9 % |
Die erste Zeile ist der Normalfall in kleinen und mittleren Shops. Der wahre Effekt beträgt 5 %, das Dashboard meldet 22,6 %, und in der Präsentation steht „+22 % Conversion”. Ausgerollt wird eine Änderung, die real ein Zwanzigstel davon bringt. Niemand lügt – die Zahl steht wirklich so im Tool.
Beachte auch die mittlere Spalte: Bei n = 5.000 findet der Test den echten Effekt in 8,7 % der Fälle. In über 90 % der Durchläufe passiert – nichts. Ein Team, das so testet, erlebt A/B-Testing als „bringt meistens nichts, aber wenn, dann richtig”. Beide Hälften dieses Satzes sind Artefakte der zu kleinen Stichprobe.
Konsequenzen für die Praxis:
- Rechne mit dem unteren Rand des Konfidenzintervalls, nicht mit dem Punktschätzer. Wenn das Intervall von +2 % bis +40 % reicht, plane mit +2 %.
- Wiederhole große Gewinner. Ein Effekt, der in einem zweiten, unabhängigen Test bestätigt wird, ist real. Der Winner’s Curse überlebt keine Wiederholung.
- Miss die Summe deiner Tests an der Gesamtkennzahl. Wenn zwölf Gewinner mit je 15 % keine sichtbare Veränderung im Jahresverlauf erzeugen, sind die 15 % nicht echt gewesen.
Fehler 4: Zu viele Metriken gleichzeitig
Wenn du eine Variante gegen 20 Kennzahlen prüfst – Conversion, Warenkorbwert, Absprungrate, Verweildauer, Klicks auf fünf Buttons, Newsletter, Scrolltiefe … – dann wird bei einem Signifikanzniveau von 5 % im Schnitt eine davon zufällig signifikant, selbst wenn die Variante wirkungslos ist. Die Wahrscheinlichkeit, mindestens einen Fehlalarm zu bekommen, liegt bei 20 unabhängigen Kennzahlen bei rund 64 %.
Der Fehler passiert selten absichtlich. Er passiert so: Der Test zeigt bei der Hauptkennzahl nichts. Man schaut in die Nebenkennzahlen, findet dort etwas Grünes und erzählt den Test um. Aus „B verbessert die Conversion” wird „B verbessert die Verweildauer, das zahlt langfristig ein”.
Das Gegenmittel ist organisatorisch, nicht statistisch: Lege eine Erfolgskennzahl vorher fest (Kohavi nennt das Overall Evaluation Criterion). Alles andere sind Beobachtungen für die nächste Hypothese – nie die Entscheidungsgrundlage für diesen Test. Wer mehrere Kennzahlen gleichberechtigt prüfen will, muss das Niveau korrigieren (Bonferroni und Verwandte) und braucht entsprechend mehr Traffic.
Dazu gehört ein zweites Paar: Guardrail-Metriken. Das sind Kennzahlen, die sich nicht verschlechtern dürfen – Ladezeit, Fehlerrate, Retouren, Abmeldungen. Sie entscheiden nicht über den Gewinner, aber sie können ihn disqualifizieren.
Ronny Kohavi hat die Experimentierplattformen von Amazon, Microsoft und Airbnb aufgebaut; in diesem Gespräch (englisch) ordnet er Teststärke, Winner’s Curse und die Ein-Drittel-Regel aus erster Hand ein.Was die Großen wissen: Die meisten Ideen funktionieren nicht
Die vielleicht wichtigste Zahl im ganzen Feld stammt aus Microsofts Experimentierplattform: Nur etwa ein Drittel der getesteten Ideen verbessert die Zielmetrik. Ein Drittel bewirkt nichts, ein Drittel macht es schlechter. Von Google wird ein noch strengerer Wert berichtet – rund 10 % der kontrollierten Experimente führen zu einer Umstellung.
Diese Zahl wird meistens als deprimierend gelesen. Sie ist das Gegenteil. Sie bedeutet: Zwei Drittel der Änderungen, die ein erfahrenes Team für gut hält, sind es nicht. Ohne Tests würden sie alle ausgerollt. Der Wert des Testens liegt also weniger in den Gewinnern als in den verhinderten Verschlechterungen – und die sieht niemand, weil sie nie live gehen.
Daraus folgt eine ehrliche Erwartungshaltung: Wenn dein Team behauptet, 80 % seiner Tests zu gewinnen, misst es entweder Selbstverständlichkeiten (kaputter Checkout gegen funktionierenden) – oder es wertet falsch aus. Die dritte Möglichkeit ist selten.
Wenn dein Traffic nicht reicht
Für viele Websites lautet das ehrliche Ergebnis der Stichprobenrechnung: A/B-Testing ist hier nicht das richtige Werkzeug. Bei 200 Besuchern am Tag und 2 % Conversion sind es vier Verkäufe täglich; ein Test auf 20 % Verbesserung bräuchte gut sieben Monate.
Das ist kein Grund aufzugeben – es ist ein Grund, die Methode zu wechseln:
- Teste weiter oben im Trichter. Klicks auf den „In den Warenkorb”-Button sind zehn- bis fünfzigmal häufiger als abgeschlossene Käufe. Die Kennzahl ist ungenauer, aber sie ist überhaupt messbar. Achtung: Ein Gewinn dort ist erst dann echt, wenn er unten ankommt – prüfe die Kaufabschlüsse als Guardrail.
- Teste große Änderungen statt kleiner. Ein komplett neues Seitenkonzept kann 30 % bewegen; eine Buttonfarbe bewegt vielleicht 2 %. Die Rechnung oben zeigt, dass genau das den Unterschied zwischen 3 Tagen und 300 macht. Der Preis: Du weißt hinterher nicht, welche der zwanzig Änderungen gewirkt hat.
- Nutze qualitative Methoden. Fünf Nutzertests decken die groben Usability-Probleme auf. Dafür brauchst du keine Statistik, und die Probleme, die du dort findest, sind meist größer als alles, was ein A/B-Test je auflösen könnte.
- Repariere zuerst das Messbare ohne Test. Ladezeit, kaputte Formulare auf dem Handy, fehlende Versandkosten-Angabe, Pflichtregistrierung vor dem Kauf. Das sind keine Hypothesen – das sind Fehler.
- Nimm Vorher-Nachher bewusst und mit Vorbehalt. Wenn ein sauberer Test unmöglich ist, ist ein dokumentierter Vorher-Nachher-Vergleich über mehrere Wochen besser als gar nichts – solange du ihn nicht als Beweis verkaufst.
Der wichtigste Satz dieses Abschnitts: Ein Test, der zu klein ist, um die Wahrheit zu finden, findet trotzdem etwas. Und dieses Etwas ist Rauschen mit einem Konfidenzwert daneben. Kein Test ist besser als ein Test, dessen Ergebnis du nicht interpretieren kannst.
Der Ablauf, der Fehler unwahrscheinlich macht
1. Hypothese schreiben, nicht Idee. Eine Hypothese hat die Form: „Weil [Beobachtung], erwarten wir, dass [Änderung] die [Kennzahl] um [Größenordnung] verbessert.” Die Beobachtung ist der wichtigste Teil – sie kommt aus Analytics, Nutzerinterviews oder Support-Anfragen. Ohne sie testest du Meinungen.
2. Kennzahl und MDE festlegen, Stichprobe berechnen. Eine Erfolgskennzahl, ein bis drei Guardrails, ein Mindesteffekt. Daraus folgt die Stichprobengröße, daraus die Laufzeit. Wenn die Laufzeit unrealistisch ist, wird der Test hier abgesagt, nicht in Woche drei.
3. Sauber implementieren und vorher prüfen. Ein A/A-Test (beide Gruppen sehen dasselbe) über ein paar Tage deckt die meisten technischen Fehler auf: Wenn dabei ein „Gewinner” herauskommt, ist dein Aufbau kaputt und nicht deine Idee. Zusätzlich prüfen: Zählt das Tracking doppelt? Ist die Zuteilung über Sessions hinweg stabil? Flackert die Seite (Flicker-Effekt), weil die Variante erst nach dem Rendern eingesetzt wird?
4. Laufen lassen und nicht anfassen. Volle Wochen. Kein Stopp bei grünem Zwischenstand. Zwischenblicke ausschließlich für SRM- und Fehlerprüfung.
5. In fester Reihenfolge auswerten. Erst die Verteilung (SRM), dann die Hauptkennzahl, dann die Guardrails, erst danach alles Übrige – und das Übrige nur als Quelle für die nächste Hypothese.
6. Dokumentieren, auch die Verlierer. Ein Testarchiv mit Hypothese, Ergebnis und Konfidenzintervall verhindert, dass dieselbe Idee alle acht Monate neu getestet wird. Und es ist die einzige Möglichkeit, später zu prüfen, ob eure Gewinner sich in der Gesamtkennzahl niederschlagen.
Testprotokolle als Markdown Ein Testarchiv wirkt nur, wenn es sich schneller schreiben lässt, als man es vergisst. Für Tabellen und Checklisten in lesbarem Format hilft unser Markdown-Generator – Textformat, versionierbar, kein Tool-Lock-in.
Werkzeuge: die Lage nach Google Optimize
Google Optimize wurde am 30. September 2023 eingestellt, und es gibt bis heute keinen kostenlosen Nachfolger von Google. GA4 selbst kann keine A/B-Tests durchführen – es kann Ergebnisse anderer Tools auswerten, wenn du die Variante als Parameter mitschickst.
Grob sortiert nach Ansatz:
- Client-seitige Tools (VWO, AB Tasty, Convert, Optimizely Web) verändern die Seite per JavaScript im Browser. Schnell einzurichten, ohne Entwickler nutzbar – aber sie bringen den Flicker-Effekt mit und kosten Ladezeit. Für Seiten, bei denen Core Web Vitals zählen, ist das ein realer Nachteil.
- Server-seitige Tools und Feature-Flags (GrowthBook, Unleash, Optimizely Feature Experimentation, LaunchDarkly) entscheiden die Variante, bevor die Seite ausgeliefert wird. Kein Flackern, keine zusätzliche Ladezeit, funktioniert auch für APIs und Apps – erfordert aber Entwicklungsarbeit.
- Open Source und selbst gehostet: GrowthBook lässt sich selbst betreiben. Das ist relevant, wenn die Zuordnungsdaten das Haus nicht verlassen sollen – ein Datenschutzargument, das seit dem Optimize-Aus häufiger den Ausschlag gibt.
- Plattformeigene Tests: Shopify, Shopware und die großen Shopsysteme haben Apps und Plugins dafür. Bequem, aber prüfe vorher, welches statistische Verfahren dahintersteckt und ob Zwischenstände zum Abbruch verleiten.
Die Auswahlfrage, die wichtiger ist als der Funktionsumfang: Zeigt das Tool nur „96 % Konfidenz”, oder zeigt es auch das Konfidenzintervall und die zugrunde gelegte Stichprobengröße? Werkzeuge, die nur eine grüne Zahl anzeigen, erziehen zum Peeking. Werkzeuge, die den Zielwert und den Fortschritt dorthin anzeigen, erziehen zum Warten.
Häufige Fragen
Wie lange sollte ein A/B-Test laufen?
Mindestens eine volle Woche, besser zwei, und immer bis zur vorher berechneten Stichprobengröße – je nachdem, was später eintritt. Volle Wochen sind wichtig, weil sich das Verhalten zwischen Werktagen und Wochenende unterscheidet. Ein Test, der nach 9 oder 11 Tagen endet, gewichtet einzelne Wochentage doppelt.
Wie viele Besucher brauche ich für einen A/B-Test?
Das hängt von deiner Ausgangs-Conversion und dem Effekt ab, den du erkennen willst. Bei 5 % Conversion und 10 % gewünschter relativer Verbesserung sind es rund 62.500 Besucher insgesamt; für 20 % Verbesserung nur 16.300, für 5 % Verbesserung dagegen 244.000. Die Faustregel: Halber Effekt, vierfacher Traffic.
Was bedeutet 95 % statistische Signifikanz genau?
Sie bedeutet: Wenn es in Wahrheit keinen Unterschied zwischen den Varianten gäbe, würde man ein Ergebnis wie das gemessene in höchstens 5 % der Fälle sehen. Sie bedeutet nicht, dass die Variante mit 95 % Wahrscheinlichkeit besser ist – diese Aussage lässt sich aus dem p-Wert nicht ableiten.
Darf ich einen A/B-Test vorzeitig beenden, wenn er signifikant ist?
Nein, nicht bei einer normalen Auswertung. Unsere Simulation mit zwei identischen Varianten zeigt: Bei zehn Zwischenblicken mit Abbruch beim ersten grünen Ergebnis meldet der Test in 22 % der Fälle einen Gewinner, der nicht existiert – statt in 5 %. Wer früh stoppen können muss, braucht dafür gebaute Verfahren wie Sequenzanalyse oder Always-Valid-Inference.
Was ist ein Sample Ratio Mismatch?
Eine Abweichung zwischen der geplanten und der tatsächlichen Traffic-Verteilung, zum Beispiel 51,4 % zu 48,6 % statt 50/50. Das deutet auf einen technischen Fehler bei der Zuteilung hin. Weil dabei Nutzer systematisch aus einer Gruppe herausfallen, ist die Zufälligkeit zerstört und das Ergebnis nicht mehr auswertbar. Microsoft Research prüft dafür mit einem strengen Schwellenwert von p < 0,0005.
Kann ich mit GA4 A/B-Tests machen?
Nicht direkt. GA4 hat keine eigene Experimentierfunktion, seit Google Optimize am 30. September 2023 abgeschaltet wurde. Du brauchst ein separates Tool für die Ausspielung; GA4 kann die Ergebnisse dann auswerten, wenn die Variante als Event-Parameter mitgesendet wird.
Warum zeigen meine gewonnenen Tests keine Wirkung in der Bilanz?
Das ist typisch für den Winner’s Curse. Zu kleine Tests werden nur dann signifikant, wenn das Zufallsrauschen den echten Effekt verstärkt – die Gewinner sind daher systematisch überschätzt. In unserer Simulation meldeten signifikante Tests bei einem wahren Effekt von +5 % im Schnitt +22,6 % (5.000 Besucher je Variante). Gegenmittel: mit dem unteren Rand des Konfidenzintervalls planen und große Gewinner in einem zweiten Test bestätigen.
Wie viele Metriken darf ich auswerten?
Eine als Entscheidungsgrundlage, dazu ein paar Guardrail-Metriken, die sich nicht verschlechtern dürfen. Prüfst du 20 Kennzahlen gleichberechtigt, liegt die Wahrscheinlichkeit für mindestens einen zufälligen Treffer bei rund 64 % – auch wenn deine Variante wirkungslos ist.
Lohnt sich A/B-Testing für kleine Websites?
Meistens nicht in der klassischen Form. Bei 200 Besuchern am Tag dauert ein Test auf 10 % Verbesserung über 300 Tage. Sinnvoller sind größere Änderungen statt kleiner Details, Kennzahlen weiter oben im Trichter, qualitative Nutzertests und das Beheben klarer technischer Mängel.
Fazit
A/B-Testing im Marketing funktioniert – aber nicht als Dashboard, das man anschaut, bis es grün wird. Es funktioniert als Verfahren mit einer unbequemen Eigenschaft: Die wichtigsten Entscheidungen fallen, bevor der Test startet. Welche Kennzahl zählt, wie groß der Effekt sein muss, wie viele Besucher nötig sind, wann Schluss ist. Danach ist der Test nur noch Ausführung.
Die drei Zahlen, die aus unseren eigenen Simulationen hängen bleiben sollten: Zehn Zwischenblicke machen aus 5 % Fehlalarm 22 %. Ein wahrer Effekt von 5 % erscheint bei zu kleiner Stichprobe als +22,6 %. Und bei den Großen funktioniert nur rund ein Drittel der Ideen – was bedeutet, dass die zwei verhinderten Verschlechterungen genauso wertvoll sind wie der eine Gewinner.
Wer daraus nur eine Sache mitnimmt, sollte es diese sein: Rechne die Stichprobengröße aus, bevor du testest. Ergibt sie eine Zahl, die du in vertretbarer Zeit erreichst, hast du ein Werkzeug. Ergibt sie 300 Tage, hast du eine Antwort – nämlich die, dass diese Frage anders beantwortet werden muss.
Wenn du an der Stelle weiterlesen willst: Ladezeit ist der eine Faktor, der sich fast immer lohnt und keinen Test braucht – dafür gibt es unseren Core Web Vitals Test. Wie du überhaupt an belastbare Zahlen zu deiner Sichtbarkeit kommst, klärt der Vergleich SISTRIX vs. Ahrefs. Und warum Durchschnittswerte aus Studien für deine Seite oft nichts aussagen, steht ausführlicher in Google KI SEO – dasselbe Problem, anderes Thema.
