Deutsch

Experimentdesign, das die Stakeholder-Prüfung übersteht

Ein Team, mit dem ich zusammengearbeitet habe, hat letztes Quartal einen Banner-Farb-Test durchgeführt. Drei Tage. Rund 200 Nutzer pro Arm. Der PM schaute auf das Dashboard, sah p = 0,07 für den Click-through, und schrieb in Slack: „Richtungsweisend positiv, lass uns shippen." Sechs Wochen später war die Topline-Kennzahl flach, das nachgelagerte ML-Personalisierungsmodell hatte sich still auf Traffic neu trainiert, der auf Session-Ebene für ein Nutzer-Level-Ziel randomisiert worden war, und als der VP fragte, was die ursprüngliche Hypothese gewesen sei, konnte sie niemand finden.

Dieses Experiment hatte vier Probleme, die sich gegenseitig verstärkten: unterdimensionierte Stichprobe, keine Berechnung des Minimum Detectable Effects, falsche Randomisierungseinheit und ein Blick auf Tag 2, der die Entscheidung beeinflusst hat. Jedes für sich allein hätte das Ergebnis ruiniert. Zusammen produzierten sie eine selbstsichere Entscheidung, die auf nichts aufbaute.

Dieser Leitfaden ist das Gegenmittel. Es ist das Design-Playbook, das diese Geschichte unmöglich macht, sich zu wiederholen. Das, bei dem ein PM, ein Engineering Lead und ein skeptischer VP das Readout-Dokument lesen und zur gleichen Schlussfolgerung gelangen wie Sie.

Das Hypothesen-Template

Die meisten Experimente scheitern, bevor überhaupt Daten erhoben werden, weil die Hypothese nicht falsifizierbar ist. „UX verbessern." „Checkout besser machen." „Engagement steigern." Nichts davon kann falsch sein, was bedeutet, dass auch keines davon richtig sein kann.

Eine Hypothese, die Sie verteidigen können, hat vier Teile:

  • Problem: die konkrete Zahl, die Sie stört, heute, mit einem Basiswert.
  • Vorhergesagte Veränderung: das, was Sie tun werden, in einem Satz.
  • Erfolgskennzahl: die einzige primäre Zahl, nach der Sie es beurteilen.
  • MDE: die kleinste Effektstärke, die Ihre Geschäftsentscheidung ändern würde.

Ausgefüllt sieht es so aus:

Die Checkout-Abschlussrate beträgt 38 Prozent (90-Tage-Basiswert, n ca. 1,2 Mio. Sessions). Das Hinzufügen einer 4-Schritte-Fortschrittsanzeige im Checkout-Flow wird den Abbruch nach dem Adressschritt reduzieren. Primärkennzahl: Abschlussrate, gemessen pro Nutzer, 14-Tage-Fenster. MDE: 1,5 Prozentpunkte absoluter Lift (4 Prozent relativ). Alles darunter rechtfertigt die Engineering-Kosten nicht.

Achten Sie darauf, wozu das Template zwingt. Sie legen sich auf eine Basiswert-Zahl fest, sodass Sie im Nachhinein nicht argumentieren können, die Kennzahl sei anders gewesen. Sie legen sich auf eine primäre Kennzahl fest, sodass Sie nicht auf eine sekundäre wechseln können, wenn die primäre enttäuscht. Sie legen sich auf einen MDE fest, sodass Sie einen 0,3-Pp-Shift nicht als „bedeutsam" deklarieren können. Und der MDE basiert auf einer Geschäftsentscheidung (dem kleinsten Lift, der tatsächlich ändern würde, was Sie als Nächstes tun), nicht auf einer statistischen Bequemlichkeit.

Weisen Sie vage Hypothesen schon beim Eingang ab. Wenn ein Stakeholder sagt: „Wir wollen ein neues Layout testen und sehen, was passiert," ist es Ihre Aufgabe, nachzuhaken: Welche Zahl ändert sich, um wie viel, und warum ist diese Zahl wichtig? „Schauen wir mal, was passiert" ist eine Forschungsfrage, kein Experiment.

MDE-Berechnung und Stichprobengröße

Dieser Abschnitt ist der, der Sie mehr als jeder andere vor dem Ausliefern von Unsinn bewahren wird. Die Mathematik ist nicht optional.

Für einen Zwei-Stichproben-Test von Anteilen mit α = 0,05 (zweiseitig) und Teststärke = 0,80 beträgt die Stichprobengröße pro Arm ungefähr:

n ≈ 16 × σ² / δ²

Dabei ist σ² die Varianz der Kennzahl und δ die absolute Effektgröße, die Sie erkennen wollen (Ihr MDE). Für eine binäre Kennzahl wie Conversion gilt σ² ca. p(1 − p), wobei p die Basisrate ist.

Gehen wir das Checkout-Beispiel vollständig durch.

  • Basis-Abschlussrate: p = 0,38
  • Varianz: σ² = 0,38 × 0,62 ca. 0,2356
  • MDE: δ = 0,015 (1,5 Prozentpunkte absolut)
  • δ² = 0,000225
n ≈ 16 × 0,2356 / 0,000225
n ≈ 16.755 pro Arm

Also ungefähr n = 17.000 Nutzer pro Arm, n = 34.000 insgesamt, um einen 1,5-Pp-Lift auf einem 38-Prozent-Basiswert bei 80 Prozent Teststärke zuverlässig zu erkennen. Wenn das tägliche qualifizierte Nutzervolumen 5.000 beträgt, entspricht das einem Test von mindestens 7 Tagen. Mit einem MDE von 1 Pp statt 1,5 Pp sinkt der Nenner um den Faktor 2,25, und Sie brauchen ca. 38.000 pro Arm, also einen Test von rund 16 Tagen.

Schauen Sie sich nun den Banner-Test aus der Einleitung an: 200 Nutzer pro Arm, Basis-Click-through rund 8 Prozent. Varianz ca. 0,074. Um einen 1-Pp-Lift bei 80 Prozent Teststärke zu erkennen: n ca. 16 × 0,074 / 0,0001 = 11.840 pro Arm. Vorhanden waren 200. Der Test war mathematisch nicht in der Lage, den erhofften Effekt zu erkennen. Das zitierte p = 0,07 war kein fast-signifikantes Signal, sondern statistisches Rauschen in einer Stichprobe, die gar nichts hätte signalisieren können.

Einige praktische Hinweise:

  • Die 16 in der Formel ergibt sich aus (z_α/2 + z_β)² × 2 für α = 0,05, Teststärke = 0,80. Bei 90 Prozent Teststärke verwenden Sie ca. 21. Für α = 0,01 (Bonferroni-korrigiert für beispielsweise 5 Kennzahlen) steigt die Konstante weiter.
  • Für kontinuierliche Kennzahlen (Revenue pro Nutzer, Session-Länge) verwenden Sie die tatsächliche Stichprobenvarianz, und achten Sie auf schwere Schwänze. Das Kappen oder Log-Transformieren der Kennzahl ist oft der richtige Schritt. Tun Sie es vor, nicht nach dem Start.
  • Die Stichprobengröße skaliert mit 1/δ². Den MDE zu halbieren vervierfacht die erforderliche Stichprobe. Deshalb ist „Wir lassen es einfach länger laufen, wenn es nicht anspringt" eine Illusion.

Wenn Ihr Stichprobengrößen-Rechner 38.000 Nutzer pro Arm ergibt und das Team nur 5.000 pro Woche hat, sind Ihre Optionen: 8 Wochen laufen lassen, einen größeren MDE akzeptieren (und zugeben, dass Sie kleinere Gewinne nicht erkennen können), oder ein anderes Experiment wählen. Eine vierte Option, bei der die Mathematik sich biegt, gibt es nicht.

Randomisierungseinheit: Nutzer vs. Session vs. Cluster

Die falsche Randomisierungseinheit zu wählen ist der stille Killer von A/B-Tests. Sie erhalten einen sauberen p-Wert für die falsche Frage.

Randomisierung auf Nutzerebene ist der Standard für die meisten Produktexperimente. Ein Nutzer wird beim ersten Kontakt mit dem Experiment einer Variante zugewiesen und bleibt für immer in dieser Variante (oder zumindest für das Testfenster). Das ist korrekt, wenn die Kennzahl pro Nutzer berechnet wird: Retention, LTV, Kaufhäufigkeit, 7-Tage-Rückkehrrate.

Randomisierung auf Session-Ebene weist jede Session unabhängig zu. Das funktioniert für zustandslose, Einzelsession-Kennzahlen wie Seitenladezeit oder Einzelsession-Conversion auf einer Landing Page, auf die Nutzer nicht zurückkehren. Es scheitert erheblich, wenn sich die Kennzahl über Sessions summiert. Wenn Sie einen Empfehlungsalgorithmus auf Session-Ebene randomisieren und die 30-Tage-Retention messen, haben Sie einem Nutzer über 30 Tage drei verschiedene Empfehlungserfahrungen gezeigt; Sie messen den Durchschnitt von A und B, nicht A gegen B.

Cluster-Randomisierung gilt für Marktplatz-, Netzwerk- und soziale Effekte. Wenn die Variante beeinflusst, wie Angebot und Nachfrage zusammentreffen (ein neuer Ranking-Algorithmus in einem Marktplatz, eine Feed-Änderung, die beeinflusst, was andere Nutzer sehen), können Sie keine einzelnen Nutzer randomisieren. Die Erfahrungen übertragen sich gegenseitig. Randomisieren Sie auf Geo-Ebene, Marktplatz-Ebene oder sozialem Cluster. Der Preis: Ihr effektives n sinkt auf die Anzahl der Cluster, nicht der Nutzer, und Ihre Stichprobengrößenberechnung muss Varianz auf Cluster-Ebene verwenden (die in der Regel viel höher ist als auf Nutzer-Ebene).

Die diagnostische Frage lautet: „Wenn ich Nutzer A der Kontrollgruppe und Nutzer B der Treatmentgruppe zuweise, kann das Ergebnis von Nutzer A durch die Erfahrung von Nutzer B beeinflusst werden?" Falls ja, liegt Interferenz vor, und Sie brauchen Cluster-Randomisierung oder ein Switchback-Design.

Der Session-Level-Fehler aus dem einleitenden Test war genau das. Click-through ist technisch eine Session-Kennzahl, weshalb die Session-Level-Randomisierung auf den ersten Blick stimmig schien. Aber das nachgelagerte Modell, das auf den Daten neu trainiert wurde, benötigte Signal auf Nutzer-Ebene. Die Randomisierungseinheit muss zur Analyseeinheit passen, und beide müssen zur Entscheidungseinheit passen.

Leitplanken-Kennzahlen

Die Primärkennzahl sagt Ihnen, ob die Änderung gewirkt hat. Leitplanken-Kennzahlen sagen Ihnen, ob Sie dabei etwas anderes kaputt gemacht haben.

Registrieren Sie zwei bis vier Leitplanken-Kennzahlen vor dem Start, die sich auch dann nicht verschlechtern dürfen, wenn die Primärkennzahl gewinnt. Standard-Leitplanken:

  • Latenz (p95-Seitenladezeit, API-Antwortzeit): Viele „Gewinne" sind Gewinne, weil die neue Variante schneller geladen hat, nicht weil die Änderung gut war.
  • Fehlerrate (5xx, clientseitige JS-Fehler): Ein Treatment, das die Fehlerrate verdoppelt, liefert einen Bug aus, unabhängig davon, was die Conversion tut.
  • Revenue pro Nutzer: Wenn Sie den Click-through optimieren und der Revenue pro Nutzer sinkt, haben Sie einen Weg gefunden, Menschen auf minderwertiger Dinge klicken zu lassen. Nicht ausliefern.
  • Support-Ticket-Rate: UX-Änderungen, die Nutzer verwirren, zeigen sich hier, nicht in der Conversion-Kennzahl.

Der Schwellenwert ist entscheidend. Ein häufiges Muster: „Leitplanke darf sich um nicht mehr als 1 Prozent relativ verschlechtern, sonst schlägt das Experiment fehl, unabhängig vom Primärergebnis." Registrieren Sie den Schwellenwert vorab. Andernfalls wird, wenn die Latenz um 2 Prozent langsamer wird, die Diskussion zu „Ist 2 Prozent wirklich bedeutsam," und Sie verhandeln mit sich selbst.

Der Zweck der Leitplanken: das Experiment aufzufangen, das die Primärkennzahl gewann, aber das Unternehmen schadete. Sie sind das am häufigsten vernachlässigte Werkzeug in der DS-Arbeit und die günstigste Absicherung, die Sie kaufen können.

Das Readout-Dokument

Immer dieselbe Form. Das Readout-Dokument, das die Prüfung übersteht, ist eine Seite, in 90 Sekunden überfliegbar, ohne Überraschungen im Anhang. Hier das Template:

  • Hypothese: ein Absatz, das viergliedrige Template von oben, vor dem Experiment geschrieben.
  • Design: Randomisierungseinheit, Stichprobengröße-Ziel, MDE, Primärkennzahl, Leitplanken, Traffic-Aufteilung.
  • Daten und Stichprobe: Startdatum, Enddatum, tatsächlich erreichte Stichprobengröße pro Arm.
  • Primärergebnis: Punktschätzung, 95-Prozent-Konfidenzintervall, p-Wert. Eine Zeile.
  • Leitplanken: Tabelle der Leitplanken-Kennzahlen mit Delta, KI und Bestanden/Nicht bestanden gegenüber vorregistriertem Schwellenwert.
  • Vorregistrierte Segment-Auswertungen: dieselbe Kennzahl, aufgeteilt nach den Segmenten, auf die Sie sich vorab festgelegt haben.
  • Entscheidung: Ausliefern / nicht ausliefern / iterieren, mit einer Begründung, die direkt an das Ergebnis geknüpft ist.
  • Rollback-Plan: Falls ausgeliefert, wie überwachen wir in der Produktion, und was löst einen Rollback aus?

Was nicht im Readout steht: nachträgliche Segment-Auswertungen als Erkenntnisse präsentiert, narrative Umformulierungen der Hypothese oder „richtungsweisende" Entscheidungen. Wenn ein Segment-Cut explorativ ist, kennzeichnen Sie ihn als explorativ in einem klar markierten Abschnitt. Prüfer sollten auf einen Blick erkennen können, welche Zahlen geplant waren und welche nachgefischt wurden.

Die Disziplin ist das Template. Wenn jedes Experiment im Unternehmen denselben Einseitenformat verwendet, müssen Prüfer aufhören, sich in den persönlichen Stil jedes DS einzuarbeiten, und können die Arbeit tatsächlich beurteilen.

Warum die meisten Experimente scheitern

Nach genügend Readouts lassen sich die Fehlermuster auf eine kurze Liste zusammenfassen:

  • Unterdimensioniert. Die MDE-Mathematik wurde nicht durchgeführt oder durchgeführt und ignoriert. Der Test hätte den behaupteten Effekt nicht erkennen können.
  • Unklare Hypothese. Keine falsifizierbare Vorhersage, keine festgelegte Primärkennzahl, kein MDE. Das Experiment „gelingt" unabhängig davon, was die Daten sagen.
  • Falsche Randomisierungseinheit. Session-Ebene für eine Nutzer-Ebene-Frage, oder Nutzer-Ebene für eine Marktplatz-Frage mit Interferenz.
  • Keine Leitplanken. Die Primärkennzahl gewann, das Team lieferte aus, die Latenz verschlechterte sich um 8 Prozent, und drei Wochen später bemerkt jemand, dass der Revenue gesunken ist.
  • Kein Rollback-Plan. Code wurde ausgeliefert, das Experiment wurde als abgeschlossen erklärt, und niemand überwachte die Produktion. Die Änderung driftet, und niemand kann den Drift auf den Launch zurückführen.
  • Mit einem anderen Release konfundiert. Das Experiment lief während einer Marketing-Aktion oder eines UI-Refreshes, der beide Arme traf. Der geschätzte Effekt ist das Experiment plus der Confounder, und Sie können sie nicht trennen.

Jedes dieser Probleme ist in der Designphase vermeidbar. Keines ist nach der Datenerhebung behebbar.

HARKing vermeiden

HARKing (Hypothesizing After Results are Known, zu Deutsch: Hypothesen nach Bekanntwerden der Ergebnisse aufstellen) ist die häufigste Form der Selbsttäuschung bei Experimenten. Das Muster: Sie haben einen Test auf der gesamten Nutzerbasis durchgeführt, die Primärkennzahl ist null, aber die Variante sieht großartig aus für „Nutzer auf iOS in den USA, die über bezahlte Suche kamen." Also wird daraus die Schlagzeile.

Das Problem ist rein statistischer Natur. Wenn Sie Ihre Daten in 20 Segmente aufteilen, würden Sie erwarten, dass eines davon per Zufall p < 0,05 erreicht. Den Gewinner nach Betrachtung aller 20 auszuwählen und ihn als bestätigtes Ergebnis zu präsentieren ist mathematisch gesehen Betrug. Sie würden denselben „Effekt" bei einem Münzwurf finden, wenn Sie fein genug schneiden.

Die Lösung ist Vorab-Registrierung. Bevor das Experiment beginnt, schreiben Sie auf:

  1. Die Primärkennzahl.
  2. Die genauen Segment-Auswertungen, die Sie berichten werden (z. B. neue vs. wiederkehrende Nutzer, Mobil vs. Desktop, die Top-3-Märkte), und nur diese.
  3. Jede Untergruppe, auf die Sie sich als bestätigende Analyse festlegen.

Alles, was Sie später finden, kommt in einen klar gekennzeichneten Abschnitt „Explorativ", mit dem Hinweis, dass die p-Werte nicht für multiples Testen korrigiert sind und dass der Befund ein Folgeexperiment zur Bestätigung benötigt. Nennen Sie ein nachträgliches Subgruppen-Ergebnis niemals „signifikant". Nennen Sie es eine Hypothese für den nächsten Test.

Die kulturelle Lösung ist schwieriger als die technische. Wenn ein Stakeholder dringend einen Erfolg braucht und die nachträgliche Auswertung ihn liefert, ist der Druck real, diesen als bestätigtes Ergebnis darzustellen. Die Disziplin der Vorab-Registrierung (das Aufschreiben vor dem Start) ist das, was Ihnen den Spielraum gibt, dagegen zu argumentieren.

Disziplin beim Beobachten des laufenden Tests

Eine Zahl, die überrascht: Wenn Sie Ihren A/B-Test zwei Wochen lang täglich auf Signifikanz prüfen, ist Ihre tatsächliche Falsch-Positiv-Rate nicht 5 Prozent. Sie liegt eher bei 14 Prozent, möglicherweise höher, je nachdem, wie aggressiv Sie früh stoppen.

Der Grund ist das sequenzielle Testproblem. Ein Standard-t-Test oder z-Test ist für einen einzigen Blick auf die Daten nach Erreichen der festgelegten Stichprobengröße kalibriert. Jeder zusätzliche Blick ist eine weitere Chance, dass zufälliges Rauschen den Schwellenwert überschreitet. Wenn Sie zwischendurch schauen und stoppen, wählen Sie den extremsten Moment eines Random Walks aus und berichten ihn als festes Ergebnis.

Sie haben zwei saubere Optionen:

  1. Auf die Stichprobengröße festlegen. n berechnen, den Test laufen lassen, bis Sie n erreichen, dann einmal das Ergebnis anschauen. Kein tägliches Dashboard als Grundlage für Stop/Ship-Entscheidungen. Leitplanken zur Sicherheit zu überwachen ist in Ordnung; die Primärkennzahl zur frühzeitigen Beendigung des Experiments zu verwenden, nicht.
  2. Eine sequenzielle Testmethode verwenden. mSPRT (mixture sequential probability ratio test), Gruppen-Sequenz-Designs mit Alpha-Spending-Funktionen oder ordentlich implementierte Bayesianische Methoden mit informativen Priors. Diese ermöglichen beliebig häufiges Hineinschauen mit valider Inferenz, zu dem Preis einer etwas höheren erforderlichen Stichprobe als Ausgleich.

Was Sie nicht tun können: einen Fixed-Horizon-Test durchführen, täglich hineinschauen und stoppen, sobald p den Wert 0,05 unterschreitet. Das ist der häufigste Falsch-Positiv-Generator in der industriellen Experimentierung, und es ist der Grund, warum „ausgelieferte Gewinne" routinemäßig scheitern, wenn sie später ordentlich gemessen werden.

Die Lösung ist verfahrenstechnischer Natur. Schreiben Sie die Stop-Regel in das Design-Dokument. „Wir werden n = 17.000 pro Arm laufen lassen, voraussichtlich 8 Tage, und einmalig auswerten." Wenn das Team dem Dashboard nicht widerstehen kann, blenden Sie die Primärkennzahl aus der Live-Ansicht aus und zeigen Sie nur die Leitplanken. Die Disziplin liegt im Design.

Fazit

Das Readout-Dokument, das die Prüfung übersteht, ist das, in dem alle Designentscheidungen vor Beginn der Datenerhebung getroffen wurden. Die Hypothese war präzise. Die Stichprobengröße wurde berechnet. Die Randomisierungseinheit wurde begründet. Die Leitplanken wurden vorab registriert. Die Segment-Auswertungen wurden im Voraus festgelegt. Die Stop-Regel wurde aufgeschrieben.

Alles andere ist Erzählung. Und Erzählung ist in Ordnung für den narrativen Teil des Readouts, aber sie kann nicht die Grundlage einer Ship-Entscheidung sein.

Den Kampf gewinnen Sie vor der Datenerhebung. Investieren Sie die Stunde in das Design-Dokument. Es ist die günstigste Stunde, die Sie das gesamte Quartal investieren werden, und sie entscheidet, ob Ihr Experiment die Prüfung besteht oder still dem Stapel „richtungsweisend positiver" Tests beigesellt wird, den sechs Monate später niemand mehr rekonstruieren kann.

Weiterführende Artikel