Testplanung

Definition: Testplanung im CRO bezeichnet die strukturierte Vorbereitung eines A/B-Tests oder multivariaten Tests vor dem Implementierungsstart mit dem Ziel, valide, interpretierbare und entscheidungsrelevante Ergebnisse zu gewährleisten. Die Testplanung umfasst acht Kernelemente: (1) Hypothesen-Formulierung im Wenn-Dann-Weil-Format mit Evidenzangabe; (2) Definition der Primär-Metrik (OEC; Overall Evaluation Criterion) und Guardrail-Metriken; (3) Stichprobengrößenberechnung mit MDE und Power-Analyse; (4) Testdauer-Festlegung und Kalender-Check; (5) Traffic-Zuweisung und Split-Konfiguration; (6) Koordination mit anderen laufenden Tests (Mutual Exclusion); (7) Implementierungs-Qualitätscheck vor Go-Live; (8) Segment-Analyse-Plan und Post-Test-Workflow. Ohne vollständige Testplanung entstehen häufig: unklare Erfolgskriterien die post-hoc umdefiniert werden (HARKing: Hypothesizing After Results are Known); zu kurze Tests mit Peeking-Fehlern; nicht erkannte Implementierungsfehler (SRM) die das Ergebnis invalidieren; Tests die gleichzeitig auf derselben Nutzergruppe laufen und sich gegenseitig kontaminieren.

Erläuterung

Die systematische Testplanung als Disziplin im Web-Experimentation-Kontext wurde maßgeblich durch Ron Kohavi, Diane Tang und Ya Xu («Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing», Cambridge University Press, 2020) formalisiert. Kohavis Erfahrung aus über 10.000 Experimenten bei Microsoft (Bing; Azure; MSN) und Amazon identifizierte dass der häufigste Grund für nicht-valide Testergebnisse nicht fehlerhafte Statistik sondern fehlerhafte Implementierung und unzureichende Planung ist: 30–50% aller A/B-Tests in einer umfangreichen Microsoft-Analyse hatten mindestens einen Planungsfehler der das Ergebnis kompromittierte. Chris Goward (WiderFunnel Marketing, gegründet 2007 Vancouver; LIFT-Modell-Entwickler; «You Should Test That!», 2012) etablierte in der CRO-Community die Praxis des strukturierten Test-Briefings als Team-Dokument das Hypothese, Evidenzgrundlage, Priorisierung und Erfolgskriterien verbindlich vor Teststart festhält. Andy Young (Gründer PRWD, UK; CRO-Beratung; Sprecher auf Conversion Conference) prägte das Konzept der «Research-Led Hypothesis» als Gegenpol zur beliebigen Ideen-getriebenen Testplanung: jede Hypothese muss auf mindestens einer Forschungsquelle (Heatmap, Session Recording, Nutzerinterviews, Exit-Survey, Analytics-Analyse) basieren, die explizit im Test-Brief dokumentiert ist. Die Praxis des Pre-Registration von Hypothesen und Analyseplänen vor dem Test-Start – aus der akademischen Forschungsmethodik übernommen (Nosek et al., «The Preregistration Revolution», PNAS, 2018) – gewinnt in fortgeschrittenen CRO-Programmen (Booking.com, Etsy, Spotify) an Bedeutung als Schutz gegen HARKing und Confirmation Bias in der Ergebnisinterpretation.

Hypothesen-Formulierung und Test-Brief

• Wenn-Dann-Weil-Hypothesen-Format: Struktur: «Wenn [spezifische Änderung an Element X], dann [Veränderung der Primär-Metrik Y um mindestens Z%], weil [Forschungs-Evidenz und Kausaltheorie]»; Beispiel 1: «Wenn wir auf der Produktseite den CTA-Button ‹In den Warenkorb› von Weiß auf Orange ändern und ihn von Größe M auf Größe L vergrößern, dann steigt die Add-to-Cart-Rate um mindestens 8%, weil die Scroll-Map zeigt dass 45% der Mobile-Nutzer den aktuellen Button übersehen (Session Recordings bestätigen: nur 38% der Mobile-Nutzer klicken irgendein Element nahe dem CTA-Bereich) und weil orangefarbene CTAs in unserem Kategorie-Kontext höhere Farbekontrast-Auffälligkeit haben»; Beispiel 2: «Wenn wir im Checkout-Schritt 2 die Formularfelder von 12 auf 6 reduzieren (Zusammenführung Vor- und Nachname; Streichung Telefonnummer als Pflichtfeld), dann sinkt die Checkout-Abbruchrate um mindestens 12%, weil 3 Session Recordings zeigen dass 27% der Nutzer auf dem Telefonnummernfeld abbrechen und ein Exit-Survey (n=87) als häufigste Checkout-Abbruchursache ‹zu viele Pflichtfelder› nennt»; falsche Hypothesen: «Wir ändern den CTA-Button weil er besser aussieht» → keine Metrik; keine Evidenz; «Wir testen, ob Testimonials helfen» → kein Mechanismus erklärt
• Test-Brief-Template (8 Felder): Feld 1 – Hypothese: vollständig im Wenn-Dann-Weil-Format; Feld 2 – Forschungs-Evidenz: Quellen (Heatmap vom [Datum]; Session Recording Batch [Anzahl]; Exit-Survey [n=x]; Analytics-Analyse [Zeitraum]); Feld 3 – Priorisierungs-Score: ICE-Score oder RICE-Score mit Einzelbewertungen; Feld 4 – Primär-Metrik (OEC): eine Metrik die den Test entscheidet (z. B. Add-to-Cart-Rate; Checkout-Completion-Rate; Revenue per Visitor); Feld 5 – Guardrail-Metriken: Metriken die nicht verschlechtern dürfen (z. B. Bounce Rate ≤+5%; Session-Dauer ≥−10%); Feld 6 – Stichprobengröße und Laufzeit: Baseline-CVR, MDE, n/Variante, geplante Laufzeit; Feld 7 – Segment-Analyse-Plan: welche Segmente nach Test-Ende analysiert werden (Desktop vs. Mobile; New vs. Return; Traffic-Quelle); Feld 8 – Implementierungs-QA-Checkliste: Screenshots Kontroll und Variante; alle Geräte geprüft; Tracking-Events verifiziert; kein SRM nach 24h bestätigt
• HARKing vermeiden durch Pre-Registration: HARKing (Hypothesizing After Results are Known; Kerr, 1998): post-hoc Umformulierung der Hypothese passend zum beobachteten Ergebnis; besonders in CRO häufig: «Eigentlich wollten wir CVR testen aber da Mobile besser ist, war das Mobile-Segment das Ziel»; Schutzmaßnahmen: Test-Brief vor Start von mindestens 2 Personen unterschrieben; Hypothese und Primär-Metrik im Test-Tool als Annotation eingetragen (Datum-Stempel); Test-Brief in Confluence/Notion mit unveränderlichem Erstellungsdatum; Alternative Metrik-Analyse (Segment-Analysen) explizit als explorative Sekundär-Analyse deklariert; kein Implementierungs-Trigger aus Sekundär-Analysen ohne neue Primärtest-Validierung; Confirmation Bias: auch bei ehrlicher Hypothese neigen Analysten dazu, Ergebnisse «in die richtige Richtung» zu interpretieren; Gegenmaßnahme: blinde Auswertung (Analyst sieht keine Gruppen-Labels bis Analyse vollständig)

Paralleltest-Koordination und Pre-Test-Checks

• Mutually Exclusive Experiments und Overlapping Tests: Problem: wenn Nutzer gleichzeitig in Test A (CTA-Farbe) und Test B (Checkout-Formular) sind, können Interaktionseffekte die Ergebnisse beider Tests verzerren; Mutual Exclusion (ME): Nutzer werden entweder Test A ODER Test B zugewiesen, nie beiden; Vorteil: kein Contamination Risk; Nachteil: jeder Test benötigt eigenen Traffic → Laufzeit steigt bei niedrigem Traffic; Overlapping Experiments (OE): Nutzer können in mehreren Tests gleichzeitig sein; Annahme: wenn Testablauf zu verschiedenen Seiten/Elementen gehört: Interaktion unwahrscheinlich; nur valide wenn: Tests sich auf funktional unabhängige Seitenelemente beziehen; keine User-Journey-Überschneidung; keine gemeinsame abhängige Variable; Google-Experiment-Infrastruktur (Overlapping Experiment Framework; Tang et al., «Overlapping Experiment Infrastructure: More, Better, Faster Experiments at Google», KDD 2010): zeigt dass bei genug Tests gleichzeitige Tests ohne ME möglich sind wenn Interactions-Tests durchgeführt werden; für kleine CRO-Teams (≤3 Tests gleichzeitig): ME empfohlen; für große Plattformen (10+ Tests gleichzeitig): OE mit Interaction-Checks
• Pre-Test-QA-Checkliste: Rendering-Check: Variante auf Desktop Chrome, Firefox, Safari; Mobile iOS Safari, Android Chrome; Tablet iPad Safari; Tracking-Verifizierung: Custom Events (Add-to-Cart, Purchase, Formular-Submit) in GA4 Real-Time für Kontroll- und Variante-Nutzersession testen; kein Event-Doppel-Firing; kein fehlendes Event in Variante; A/A-Test (optional): 24 Stunden lang beide Varianten identisch ausliefern; prüfen ob CVR statistisch gleich ist (p > 0,2 erwünscht); wenn A/A-Test signifikante Unterschiede zeigt: Implementierungsfehler; SRM-Check nach 24 Stunden: tatsächlicher Split mit Chi-Quadrat-Test auf 50/50 prüfen; wenn p < 0,01: SRM; Ursachensuche; Cookie-Persistenz: Nutzerzuordnung über mehrere Sessions stabil; Cookie nicht nach Session-Ende gelöscht; Redirect-Latenz bei Split-URL-Tests: Messung der zusätzlichen Ladezeit durch Redirect (<100ms angestrebt); Consent-Manager-Integration: nur Consent-konforme User werden in den Test einbezogen; keine Tracking-Daten von Opt-out-Nutzern
• Segment-Analyse-Plan und Post-Test-Workflow: Segment-Analyse-Plan (VOR Test-Start festlegen): explizit benennen welche Segmente post-Test analysiert werden; Desktop vs. Mobile (immer); New vs. Returning Users (bei UX-Changes); Traffic-Quellen (wenn Mix inhomogen); Geo (wenn internationale Varianz erwartet); Verhaltenssegmente (z. B. High vs. Low Engagement); Post-Test-Workflow: Schritt 1: Signifikanzniveau und Primary Metric auswerten; Gewinner oder «kein Gewinner» deklarieren; Schritt 2: Guardrail-Metriken prüfen; wenn Guardrail verletzt: kein Implementierungs-Trigger selbst bei positiver Primary Metric; Schritt 3: Segment-Analysen als explorative Analysen (keine Entscheidungs-Trigger); Schritt 4: Learnings dokumentieren: Was hat der Test gezeigt? Welche Hypothesen wurden bestätigt/falsifiziert? Was sind nächste Test-Ideen?; Schritt 5: Entscheidung: Variante implementieren (Gewinner); Test wiederholen (kein Gewinner bei zu kleiner Stichprobe); Hypothese verwerfen (kein Gewinner bei ausreichend Stichprobe)