Testdauer

Definition: Die Testdauer eines A/B-Tests oder multivariaten Tests bezeichnet den Zeitraum vom Start der Traffic-Aufteilung bis zum planmäßigen Ende der Datenerhebung und Ergebnisauswertung. Berechnung: Laufzeit (Tage) = (2 × erforderliche Stichprobengröße pro Variante) ÷ Tages-Traffic der Testseite (Unique Users); anschließend auf vollständige Kalenderwochen aufrunden. Drei kritische Mindestanforderungen an die Testdauer: (1) Stichproben-Anforderung erfüllt: genug Conversions für die erforderliche statistische Teststärke (Power ≥ 80%); (2) Wochentags-Coverage: mindestens 2 vollständige Kalenderwochen um Montag-bis-Freitag-Verhalten und Wochenend-Verhalten in beiden Varianten gleich zu gewichten; (3) Novelty-Effect-Abklingen: bei starken Design-Änderungen mindestens 3–4 Wochen damit der anfängliche Neuheitseffekt (bessere Performance der Variante allein durch Neuheit) abklingt und das reale langfristige Verhalten messbar wird. Maximale Testdauer: über 8 Wochen ist keine sinnvolle Untergrenze; wenn 8 Wochen für die Stichprobe nicht ausreichen, ist der Test aufgrund zu kleinen MDE oder zu geringen Traffics nicht valide durchführbar.

Erläuterung

Die Testdauer-Problematik ist eines der am meisten unterschätzten Qualitätsprobleme in der CRO-Praxis. Ron Kohavi, Diane Tang und Ya Xu («Trustworthy Online Controlled Experiments», Cambridge University Press, 2020) identifizierten in einer Auswertung von Tausenden Experimenten bei Microsoft, Amazon und Airbnb drei systematische Fehlerquellen bei der Testdauer-Planung: erstens vorzeitiger Test-Stop (Peeking), der Typ-I-Fehler-Raten von bis zu 30% erzeugt; zweitens zu kurze Tests ohne vollständige Wochentags-Abdeckung, die Wochentag-Bias erzeugen (CVR unterscheidet sich bei vielen E-Commerce-Sites Montag bis Freitag um 15–40% vom Wochenend-Wert); drittens der Novelty Effect der von Robert Calder und Brian Sternthal (Journal of Marketing Research, 1980) im Kontext von Werbemitteleffekten beschrieben wurde und im CRO zu systematischer Überschätzung von Varianten-Uplifts in kurzen Tests führt: wenn Nutzer eine neue Seiten-Version sehen, erzeugt die Neuheit selbst kurzfristig erhöhtes Engagement das innerhalb von 2–4 Wochen auf das reale Niveau zurückfällt. Evan Miller («How Not To Run An A/B Test», 2010) quantifizierte den Wochentags-Effekt durch Simulation: ein Test der nur Montag bis Mittwoch läuft kann allein durch Wochentags-Bias einen scheinbaren CVR-Unterschied von 8% erzeugen ohne jede echte Varianten-Wirkung. Craig Sullivan (CRO-Experte, «The Web Analytics Bible»; Gründer Optimal Visit, UK) prägte die Praxis-Regel «Mindestens zwei Business-Cycles» – wobei ein Business-Cycle für B2C E-Commerce eine Woche, für B2B SaaS ein Monat (inklusive Monatsend-Buchungs-Peak) und für saisonale Geschäfte eine volle Saisonperiode bedeutet.

Wochentags-Effekt, Saisonalität und Test-Timing

• Wochentags-CVR-Varianz quantifiziert: typische Wochentags-CVR-Muster (E-Commerce, Desktop): Montag: CVR 110% des Wochenschnitts (Post-Weekend-Recherche-Phase); Dienstag–Donnerstag: CVR 95–105% (stabiles Kaufverhalten); Freitag: CVR 90–95% (Pre-Weekend-Ablenkung); Samstag–Sonntag: CVR 80–95% (je nach Kategorie stark variabel; Mode und Einrichtung: höher; B2B-Produkte: deutlich niedriger); Implikation: ein Test der am Donnerstag startet hat in Woche 1 überproportional Montag–Donnerstag-Daten; in Woche 2 ab Donnerstag komplettiert er eine vollständige Woche; Lösung: immer auf Montag als Starttag normieren; Kalenderwochen-Vollständigkeit sicherstellen; GA4-Check: vor Teststart wöchentliche CVR-Varianz der letzten 8 Wochen ansehen; wenn Schwankungsbreite ≥20%: 3 Wochen Mindestlaufzeit; wenn ≥40%: 4 Wochen; Mobile vs. Desktop Wochentags-Muster: Mobile-Traffic oft Wochenend-lastig; wenn Testseite Mobile-dominant: Wochentags-Bias noch ausgeprägter; separate Device-Segment-Analyse nach Test
• Saisonalitätsprobleme und Perioden die Tests ungültig machen: Tests die während Sonderperioden laufen produzieren nicht-generalisierbare Ergebnisse: Black Friday / Cyber Monday Woche: CVR und AOV atypisch hoch; Nutzer-Intent fundamental anders als Normalbetrieb; Weihnachtsgeschäft November–Dezember: SEO und Paid-Traffic-Mix verändert; neuer Nutzeranteil höher als üblich; Sommerloch Juli–August: für B2B deutlich niedrigerer Traffic und anderes Nutzerverhalten; Ostern/Feiertags-Wochen: 1–2 Tage fehlen; Wochenstruktur unvollständig; Marketing-Aktionen (Flash Sales, Newsletter-Kampagnen): wenn eine Variante disproportional von Kampagnen-Traffic profitiert: SRM-ähnliche Verzerrung; Empfehlung: Testplan mit Marketing-Kalender abgleichen; wenn Test unvermeidlich über saisonale Periode läuft: Segment-Analyse «Pre-Saison» vs. «Saison» separat auswerten; Testergebnis als «konditional valide» behandeln
• Novelty Effect und Minimum Observational Period: Definition Novelty Effect: Nutzer reagieren auf eine neue Seiten-Version anfänglich positiv allein durch Neuheit (erhöhte Aufmerksamkeit, Neugier) unabhängig von deren tatsächlichem Wert; CVR der Variante ist in Woche 1 systematisch 5–20% höher als in Woche 3+; wann Novelty Effect besonders stark: komplette Design-Überarbeitungen (neue Farben, Layouts); neue CTA-Texte («Neu!» Framing); interaktive Elemente (Animation, Hover-Effekte); wann schwach: kleine Text-Änderungen; Preisdarstellungs-Varianten; Trust-Signals; Novelty Effect erkennen: Zeit-Segmentierung: Test-CVR von Woche 1 vs. Woche 2 vs. Woche 3 vergleichen; wenn Variante in Woche 1 deutlich besser ist aber in Woche 3 angleicht: Novelty Effect; Lösung: Test mindestens 3–4 Wochen laufen lassen; Woche 1 mit erhöhter Skepsis bewerten; Returning-User-Segment: Wiederkehrende Nutzer haben keinen Novelty Effect; ihr Verhaltensmuster ist belastbarer; wenn Returning-User-Segment kein signifikantes Ergebnis zeigt: Novelty Effect wahrscheinlich

Testdauer-Kalkulator, Verlängerung und Abbruch

• Testdauer-Kalkulation Schritt-für-Schritt: Eingaben: Baseline-CVR aus GA4 (letzte 4 Wochen; Unique User Sessions mit Conversion Event auf Testseite); MDE (Minimum Detectable Effect): relativer Uplift der betriebswirtschaftlich relevant ist; Tages-Traffic der Testseite (Unique Users; Durchschnitt letzte 4 Wochen); Berechnung: Schritt 1: Stichprobengröße n berechnen (Evan Miller Calculator oder Formel mit z_α/2 = 1,96; z_β = 0,84); Schritt 2: Gesamt-Stichprobe = 2 × n (eine pro Variante bei 50/50 Split); Schritt 3: Rohe Laufzeit (Tage) = 2n / Tages-Traffic; Schritt 4: Auf vollständige Wochen aufrunden (immer nach oben); Schritt 5: Prüfen: Laufzeit ≥ 14 Tage; wenn nein: auf 14 Tage setzen; Schritt 6: Mit Marketing-Kalender abgleichen; saisonale Perioden ausschließen; Beispiel: Baseline-CVR 2,5%; MDE 15% rel. (Variante = 2,875%); n = ~17.000; 2n = 34.000; Tages-Traffic 1.500; Laufzeit = 34.000 / 1.500 = 22,7 Tage → aufrunden auf 28 Tage (4 Wochen)
• Wann Test verlängert werden sollte: Verlängerungsregel 1 – Stichprobe nicht erreicht: wenn nach geplanter Laufzeit die kalkulierte Stichprobengröße noch nicht erreicht ist (z. B. wegen Traffic-Einbruch durch Ferien): Verlängerung um fehlende Stichprobe; Verlängerungsregel 2 – Saisonale Unterbrechung: wenn Test planmäßig über Black-Friday-Woche gelaufen ist: diese Woche aus Auswertung ausschließen und Test entsprechend verlängern bis gleichwertiger Normalbetrieb-Traffic gesammelt ist; Verlängerungsregel 3 – SRM festgestellt und behoben: wenn SRM in Woche 1 erkannt und Implementierungsfehler behoben wurde: Daten von Woche 1 verwerfen; Test mit bereinigtem Traffic von vorne werten (effektiver Neubeginn); Verlängerungsregel 4 – Ergebnis knapp unter Signifikanzgrenze: NICHT verlängern allein weil p = 0,06 und «fast signifikant»; das ist Post-Hoc-Peeking; Verlängerung nur wenn ursprüngliche Stichprobenplanung fehlerhaft war (z. B. MDE falsch geschätzt)
• Wann Test vorzeitig abgebrochen werden sollte: Abbruch-Kriterium 1 – Starker negativer Effekt auf Guardrail-Metrik: wenn Variante die primäre CVR nicht verbessert UND gleichzeitig Bounce Rate signifikant steigt oder Revenue per Visitor signifikant sinkt: Test stoppen; keine schädliche Variante länger laufen lassen als nötig; Abbruch-Kriterium 2 – SRM nicht behebbar: wenn Traffic-Split trotz Debuggen persistent und stark asymmetrisch ist (z. B. 65/35 bei geplant 50/50): Ergebnis nicht valide; Test stoppen und neu implementieren; Abbruch-Kriterium 3 – Technischer Defekt auf Variante: wenn Variante einen kritischen Rendering-Fehler hat der Conversions technisch verhindert: sofortiger Stopp; Abbruch-Kriterium 4 – Externe Markt-Events die Test invalidieren: außergewöhnliche Nachrichtenereignisse; Competitor-Aktionen; Lieferproblem für Testprodukte: wenn Test-externe Faktoren eine der Varianten disproportional betreffen: pausieren oder abbrechen; kein statistisches Test-Ergebnis ist in einem invalidierten Kontext verwertbar