Was vorher fertig sein muss
Eine testbare Hypothese liegt schriftlich vor mit erwarteter Wirkung, Erfolgsmetrik und plausibler Effektgroesse.
Die betroffene Conversion-Stelle ist im Funnel identifiziert und die Baseline-Rate bekannt.
Mindestens eine Gegenmetrik ist definiert, die Schaden durch Manipulation oder Nebenwirkungen sichtbar macht.
Was vor Start vorliegen muss
Experimentier-Tool mit Bucketing und statistischer Auswertung; Vorlage fuer Experiment-Brief (Hypothese, Varianten, Metriken, Sample, Dauer, Stop-Regel); Sample-Size-Rechner.
Ein Experiment-Owner (Product oder Growth); Engineer fuer Implementierung; Datenanalyst fuer Auswertung; Reviewer fuer Brief-Freigabe; Stakeholder fuer Go-Live-Entscheidung.
Baseline-Conversion und Varianz; bekannte saisonale Effekte; minimum detectable effect (MDE) als Ziel; Tracking-Plan fuer Erfolgs- und Counter-Metriken; bereits laufende Tests, um Interferenz zu pruefen.
1-2 Wochen Setup, plus 1-4 Wochen Laufzeit
Experiment-Brief schreiben, von Reviewer freigeben lassen. Sample-Size-Berechnung mit MDE, Alpha (0.05) und Power (0.8). Variant-Implementierung hinter Feature-Flag. Dry-Run mit interner Gruppe vor Rollout.
Die eine Frage, die diese Methode beantwortet
Liefert die Variante einen statistisch signifikanten Effekt auf die Erfolgsmetrik ohne Counter-Metrik zu verschlechtern?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Brief und Sample-Size | 2-4 h | Experiment-Brief schreiben: Hypothese (wenn-dann-weil), Varianten A/B (oder mehr), Erfolgsmetrik, Counter-Metriken, MDE, Sample pro Variante, Laufzeit, Stop-Regeln, Decision-Rule. | MDE realistisch waehlen. Wenn MDE 1% absolute Conversion ist, aber Baseline 5%, braucht es zehntausende Nutzer. Sample-Berechnung explizit dokumentieren. |
2Phase 2: Implementierung und QA | 1-5 Tage | Variante hinter Feature-Flag. Random Bucketing pruefen (50/50-Verteilung). Tracking-Events fuer Erfolg und Counter pruefen. QA in Staging plus internes Dogfooding. | Bucketing-Fehler ruinieren das Experiment unsichtbar. Sample Ratio Mismatch (SRM) ist die haeufigste Fehlerquelle. Pre-Test-Health-Check mit Chi-Quadrat-Test. |
3Phase 3: Rollout und Monitoring | 1-4 Wochen | Stufenweiser Rollout (1% -> 10% -> 50%) zur Stabilitaetspruefung. Taegliches Monitoring auf Crashes, Latenz, Beschwerden. Keine Zwischeninterpretation der Erfolgsmetrik vor Sample-Erreichung. | Peeking (vorzeitiges Schauen) erhoeht False-Positive-Rate massiv. Wenn ein Tool sequenzielle Tests anbietet, nutzen. Sonst: nicht reinschauen. |
4Phase 4: Auswertung | 1-2 Tage | Nach Sample-Erreichung Auswertung pro Variante: Punktschaetzer, Konfidenzintervall, p-Wert, praktische Effektgroesse. Counter-Metriken pruefen. Segment-Analyse fuer Heterogenitaet. | p<0.05 allein reicht nicht. Effektgroesse muss praktisch relevant sein und Counter-Metriken duerfen sich nicht signifikant verschlechtern. Sonst Decision-Rule explizit. |
5Phase 5: Entscheidung und Rollout | 1 Tag | Decision: Ship, Iterate, Kill. Bei Ship: 100%-Rollout planen, Test-Code aufraeumen. Bei Iterate: naechste Hypothese formulieren. Bei Kill: Variante entfernen, Lessons Learned notieren. | Jedes Experiment liefert Wissen, auch ein „Kill“. Lessons Learned in Knowledge Base ablegen, sonst wird der naechste Test denselben Effekt suchen. |
Was am Ende rauskommt
Experiment-Report mit Brief, Sample-Size-Begruendung, finalen Werten (Punkt, KI, p), Counter-Metriken, Segment-Analyse, Decision und Followup. Ergaenzt um Tracking-Plan und Brief-Aenderungslog.
Pro Experiment eindeutige ID und Ordner mit Brief, Code-Referenzen, Auswertung und Decision. Briefe versionieren, Aenderungen waehrend Laufzeit dokumentieren. Archiv fuer abgeschlossene Tests durchsuchbar halten.
Kompakte Arbeitsvorlage für A/B Testing mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# A/B Testing Arbeitsvorlage
## Ziel
Vergleicht zwei oder mehr Varianten anhand definierter Erfolgsmetriken.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Experiment Result:
- Decision Log:
- Learning Summary:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## A/B-Test EXP-2026-042 - Buchungs-CTA-Position Mobil
**Hypothese**: Wenn der Buchungs-CTA auf Mobil oberhalb des Folds erscheint, steigt Conv-to-Booking-Start von 33% auf mindestens 38%, weil weniger Nutzer den Button verfehlen.
**Varianten**: A (Kontrolle, CTA unter Beschreibung), B (CTA fixed top, sticky).
**Metriken**
- Erfolg: Conv Detail -> Booking-Start.
- Counter: Stornoquote nach Buchung, Beschwerden im Support.
**Sample**: 12.800 Nutzer pro Variante (MDE 5pp, Power 0.8, Alpha 0.05). Sample Window 18 Tage.
**Ergebnis (Laufzeit 18 Tage, n=25.840)**
| Metrik | A | B | Delta | p |
|---|---|---|---|---|
| Conv-to-Start | 33.1% | 39.4% | +6.3pp | <0.001 |
| Stornoquote | 4.2% | 4.4% | +0.2pp | 0.31 |
| Support-Tickets | 12 | 14 | +2 | 0.62 |
**Segment**: iOS +7.1pp, Android +5.4pp. Beide signifikant.
**Decision**: Ship. Rollout 100% am 27.05. Folge-Hypothese: Sticky CTA auf Desktop fuer Tablet-Layout pruefen.Symptome erkennen, gegensteuern
Variant A und B haben deutlich ungleich viele Nutzer trotz 50/50-Zuteilung.
Test abbrechen, Bucketing-Code reviewen. Haeufige Ursache: Variante laedt langsamer und Nutzer brechen ab, oder Cookie-Logik wirft Nutzer raus. Chi-Quadrat-Test bei jedem Experiment automatisch.
Nach 3 Tagen wirkt Variante besser, Team beendet den Test fruehzeitig.
Vor Start fixierte Laufzeit oder sequenziellen Test verwenden. Frueh-Stop ohne Korrektur erzeugt False-Positives. Decision erst nach Sample-Erreichung.
Mehrere Metriken werden parallel ausgewertet, mindestens eine wird signifikant „durch Zufall“.
Vorab eine primaere Erfolgsmetrik benennen. Sekundaere Metriken explorativ kennzeichnen. Bei mehreren Primaerzielen Bonferroni- oder Benjamini-Hochberg-Korrektur.
Effekt ist signifikant, aber 0.1pp; Aufwand der Implementierung uebersteigt den Nutzen.
Decision-Rule erweitert: nicht nur Signifikanz, sondern Mindest-Effektgroesse. Wenn praktische Schwelle nicht erreicht, kein Ship.
Click-Rate steigt, aber Aktivierung oder Retention faellt unter Variant B.
Counter-Metriken bewusst breiter waehlen, mindestens eine Lagging Metric (Aktivierung, Retention). Bei signifikanter Verschlechterung kein Ship trotz positivem Primaerziel.
Mehrere Experimente teilen sich Nutzer und Erfolgsmetrik, Ergebnisse widersprechen sich.
Vor Start Interferenz-Check: betreffen Experimente dieselbe Metrik oder denselben UI-Bereich? Bei Konflikt orthogonal aufteilen (verschiedene Layer) oder seriell.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.