Offizieller Skill · Produkt
Plan für einen A/B-Test
Schreibt ein Briefing für einen A/B-Test: Hypothese, primäre und Guardrail-Metriken, MDE, Stichprobengröße und Laufzeit mit Rechnung, Abbruchregeln und eine vorab festgelegte Entscheidungsregel.
Funktioniert in Claude, ChatGPT und Coding-Agents. In Team und Business aktualisiert sich der offizielle Skill in deinem Pod von selbst, wenn wir ihn verbessern.
Wann du ihn nutzt
- Bevor ein A/B-Test auf einer Seite, in einem Ablauf, einer E-Mail oder beim Preis startet
- Jemand fragt, wie lange ein Test laufen muss oder wie viele Nutzer er braucht
Was du ihm gibst
- Die zu testende Änderung und der Grund
- Basiswert der primären Metrik
- Traffic pro Woche im Test
Was du bekommst
Ein einseitiger Experimentplan mit Hypothese, Metriktabelle, Rechnung zur Stichprobengröße, Laufzeit, Abbruchregeln, einer Regel für Ausrollen oder Nicht-Ausrollen und Risiken.
So funktioniert er
- Schreib eine falsifizierbare Hypothese „Weil [Beleg], glauben wir, dass [Änderung] für [Zielgruppe] [primäre Metrik] erhöht. Wir wissen, dass es stimmt, wenn [Metrik] um mindestens [MDE] steigt.“ Gibt es keinen Beleg, sag das; dann ist der Test explorativ.
- Wähl eine primäre Metrik und 1 bis 3 Guardrails Die primäre Metrik entscheidet den Test. Guardrails sind Metriken, die nicht schlechter werden dürfen, etwa Erstattungen, Abmeldungen, Ladezeit oder Support-Tickets. Nimm als primäre Metrik die, die dem Ergebnis am nächsten liegt, das die Änderung im Testzeitraum bewegen kann.
- Leg den minimal nachweisbaren Effekt fest Der MDE (Minimum Detectable Effect) ist die kleinste Veränderung, die der Test zuverlässig erkennen kann. Wähl ihn aus geschäftlicher Sicht: der kleinste Anstieg, für den sich das Ausrollen lohnt. Ein kleinerer MDE braucht eine viel größere Stichprobe.
- Schätz Stichprobengröße und Laufzeit und zeig den Rechenweg Standardwerte: 5 % Signifikanzniveau (α) und 80 % Teststärke (Power), die üblichen Einstellungen in Tools wie Statsig. Für eine Conversion Rate lautet Evan Millers Faustregel n = 16 × p(1 − p) ÷ δ² pro Variante, wobei p die Basisrate und δ der absolute MDE ist. Laufzeit = (n × Anzahl der Varianten) ÷ Nutzer pro Woche im Test, aufgerundet auf ganze Wochen, damit jeder Wochentag abgedeckt ist. Bestätige das Ergebnis vor dem Start mit einem Rechner und nenn ihn.
- Schreib die Abbruchregeln Brich nicht früher ab, weil das Ergebnis signifikant aussieht: Evan Miller zeigt, dass wiederholtes Hineinschauen die Zahl falsch positiver Ergebnisse erhöht. Brich nur bei Schaden früher ab: wenn ein Guardrail eine Schwelle reißt, die du jetzt festlegst, oder wenn das Erlebnis kaputt ist. Prüf vor dem Auswerten mit einem Chi-Quadrat-Test auf Sample Ratio Mismatch (die beobachtete Aufteilung weicht von der geplanten ab); das Experimentation-Team von Microsoft verlangt, dass jeder Test diese Prüfung zuerst besteht.
- Schreib die Entscheidungsregel vor dem Start Leg fest, was du bei jedem Ergebnis tust: ausrollen, wenn die primäre Metrik den MDE übertrifft und kein Guardrail reißt; nicht ausrollen, wenn ein Guardrail reißt; ist das Ergebnis nicht eindeutig, die Kontrollversion behalten und festhalten, was ihr gelernt habt. Nenn, wer entscheidet.
- Liste Risiken und den Auswertungstermin auf Neuheitseffekte, Saisonalität, Überschneidung mit anderen Tests und Lücken im Tracking. Leg den Auswertungstermin anhand der Laufzeit fest, nicht anhand eines Meetings.
Teile ihn mit deinem Team
Füge ihn einem AI Skill Pod hinzu, und alle im Team, auch Freelancer, nutzen dieselbe Version aus ihrer eigenen KI. Lies, wie Teams KI-Skills am besten teilen
Zum Pod meines Teams hinzufügen
Änderungen
- v1.0.0 · · First release.
Quellen
- How Not To Run an A/B Test - Evan Miller (gelesen am 2026-11-04)
- Power Analysis - Statsig Docs (gelesen am 2026-11-04)
- Diagnosing Sample Ratio Mismatch in A/B Testing - Microsoft Research (gelesen am 2026-11-04)