Fallstricke beim Experimentieren mit Produkten, Beitrag #3: Sich von Statistiken täuschen lassen

Die Analyse eines A/B-Tests ist trügerisch einfach. Sie zählen, wie viele Conversions bei jeder Variante zustande gekommen sind, Sie teilen durch die Anzahl der Nutzer, die ihr ausgesetzt waren, und dann vergleichen Sie die Conversion Rates. Dann lassen Sie das Ganze durch eine Online-Statistikformel laufen und sehen, ob das Ergebnis über 95 % Wahrscheinlichkeit liegt. Wiederholen Sie diesen Vorgang für jede Variante und jede Kennzahl und schon haben Sie eine Scorecard mit den Gewinnern und Verlierern. Was kann da schon schief gehen?

Eine ganze Menge, wie sich herausstellt.

Nachdem ich diesen Prozess bei Hunderten von Experimenten selbst durchlaufen habe, habe ich zwei sehr kostspielige Lektionen gelernt, die ich gerne mit Ihnen teilen möchte:

1. Statistik ist die verwirrendste Wissenschaft der Welt
2. Ein Experiment falsch zu interpretieren ist schlimmer, als es gar nicht durchzuführen.

Hier ein Beispiel aus den Anfängen meiner Karriere als Experimentierer. Wir hatten eine umfassende Neugestaltung unserer Suchergebnisseite mit vier verschiedenen Varianten auf den Weg gebracht und erhofften uns eine Steigerung des Engagements ohne Einbußen bei den Kernkennzahlen wie Leistung oder Werbeeinnahmen. Wir arbeiteten also mit einer Datenwissenschaftlerin zusammen, um den Test zu konfigurieren, und sie riet uns, das Experiment drei Wochen lang mit unserer Standardbatterie von etwa 25 Kernmetriken wie "Homepage CTR" und "mobile Werbeeinnahmen" durchzuführen. Sie bestand auch darauf, dass wir uns die Ergebnisse erst ansehen, wenn sie fertig sind, und mich einweihen, wenn Sie bereit sind, sie zu analysieren. Im Nachhinein war das so, als würde man einem Kind sagen: "Iss nicht den leckeren Marshmallow, der vor dir liegt."

Natürlich schauten wir uns die Ergebnisse an. Ungefähr vier Tage nach Beginn des Tests hatten wir unser wöchentliches Treffen zur Besprechung der Experimente (ein Muss für jedes Team, das einen Muskel für das Experimentieren mit Produkten aufbaut). In dieser Sitzung besprachen alle PMs und Engineering Manager die von uns durchgeführten Tests und entschieden über die nächsten Schritte. Wir beschlossen, einen Blick auf diesen Test zu werfen, obwohl er noch nicht abgeschlossen war. Und...oh-oh...die Ergebnisse waren sehr schlecht.

Die Scorecard leuchtete wie ein Weihnachtsbaum, mit Metriken, die als extreme Gewinner und Verlierer auftauchten. Irgendwie hatte unser Redesign den Umsatz auf dem Handy in den Keller geschickt, aber den auf dem Desktop gesteigert... aber nur in China? Wir haben die Site-Performance auf der Startseite ruiniert, aber die Suche viel schneller gemacht. Und zwei fast identische Varianten hatten fast genau entgegengesetzte Auswirkungen auf Kennzahlen, die in keinem Zusammenhang mit der von uns vorgenommenen Änderung zu stehen schienen.

Was folgte, war die Art von FUD-Explosion, die jeder Produktmanager fürchtet.

Mein Chef entschied, dass wir den Test abbrechen mussten, bevor wir die gesamte Site abschalten konnten. Damit war das gesamte Projekt, in dem unser gesamtes Team sechs Monate lang hart gearbeitet hatte, in der Schwebe. Wir verbrachten die nächsten zwei Wochen damit, verzweifelt zu versuchen, herauszufinden, wie unser lang erwartetes Redesign so unerwartete Auswirkungen haben konnte. Unsere Ingenieure versuchten verzweifelt, ein Profil des neuen Designs zu erstellen und herauszufinden, was es verlangsamt haben könnte. Unser Analyst zerlegte die Daten auf 10 verschiedene Arten, um einen Sinn in den Änderungen zu finden. Ich ließ unseren Designer verzweifelt neue Versionen des neuen Designs entwerfen und alle unsere großen Ideen verwerfen, damit wir etwas Praktischeres veröffentlichen konnten. Und mittendrin erinnere ich mich an die verzweifelte Ungewissheit. Warum, um alles in der Welt, spielten die Zahlen verrückt?

Schließlich fand mich die Datenwissenschaftlerin, die niedergeschlagen und verzweifelt durch die Gänge lief. Sie fragte mich, was los sei, und ich erzählte ihr, was passiert war. "Aber Sie haben es nicht die vollen drei Wochen laufen lassen", sagte sie. "Und Sie haben mich nicht zur Überprüfung der Kennzahlen eingeladen!" Ups.... Also entschuldigte ich mich verlegen und rief dann die Daten auf, um ihr unsere mickrigen vier Tage zu zeigen. Und so erfuhr ich von der verheerenden Macht der falsch positiven Ergebnisse.

Es stellte sich heraus, dass die Daten, die wir sahen, ein reines Glücksspiel waren. Und außerdem waren sie aufgrund der Art und Weise, wie wir den Test durchgeführt hatten,zu erwarten. Wir hatten zwei entscheidende Fehler gemacht, die mir als Statistik-Neuling nicht bewusst waren.

Der erste Fehler war, dass wir mehrere Vergleichedurchgeführt haben , ohne sie zu korrigieren. Es stellte sich heraus, dass der standardmäßige t-Test, der grundlegende Algorithmus hinter der Signifikanzberechnung beim A/B-Testing, nur für den Test von zwei Varianten und einer einzigen Metrik konzipiert wurde. Eine Signifikanz von 95 % bedeutet, dass die Wahrscheinlichkeit 5 % beträgt, dass Sie ein signifikantes Ergebnis erhalten, obwohl es eigentlich keinen Unterschied gibt. Aber wir hatten vier Varianten und 25, was bedeutet, dass wir 100 Vergleiche anstelle von einem gemacht haben. Jeder dieser Vergleiche hatte eine 5 %ige Chance, ein falsches Positiv zu sein - was bedeutet, dass Sie erwarten sollten, dass fünf von ihnen eine Veränderung zeigen, auch wenn nichts passiert war. Wir waren die ganze Zeit auf der Jagd nach Geistern.

Das Problem der Mehrfachvergleiche, berühmt illustriert von Randall Patrick Munroe via xkcd.

Das kann sich wie Voodoo anfühlen. Wie kann das Sammeln von mehr Daten schlechter sein? Sind mehr Daten nicht immer besser? Der wichtigste Faktor, den Sie verstehen müssen, ist das Risiko eines falsch positiven Ergebnisses. Da wir es mit zufälligem Verhalten zu tun haben, können wir nie ganz sicher sein - aber es besteht die Versuchung, "95% signifikant" so zu behandeln, als ob es "100% definitiv wahr" bedeutet. Ich betrachte falsch positive Ergebnisse gerne als ein Spiel mit russischem Roulette, bei dem die "Kugel" eine irreführende Schlussfolgerung ist, die Ihr Team auf die Suche nach schlechten Daten schickt. Ein A/B-Test mit einer einzigen Kennzahl ist wie ein Revolver mit 20 Kammern und einer Wahrscheinlichkeit von 1/20, ein falsch positives Ergebnis zu erzielen. Aber das Testen vieler Kennzahlen ist so, als würden Sie diesen Revolver immer wieder drehen und jedes Mal schießen. Wenn Sie dies 100 Mal wiederholen, ist es fast sicher, dass Sie bei mindestens einigen der Messgrößen falsch liegen. Dieses Problem der Mehrfachvergleiche ist eine der größten und am wenigsten verstandenen Herausforderungen beim Experimentieren - und eine, die unser Projekt direkt torpediert hatte, weil wir sie nicht berücksichtigt hatten.

Zu allem Übel hatten wir auch noch den zweiten Fehler gemacht, nämlich einen Test mit festem Zeithorizontzu verwenden . Dieses Problem rührt daher, dass wir eine Statistik, die 1908 erfunden wurde, auf das Internet-Zeitalter angewendet haben. Spaß beiseite: Der t-Test wurde von einem Chemiker erfunden, der für die Guinness-Brauerei in Dublin arbeitete. In diesem Zusammenhang machte er Sinn: Er braute Bier mit zwei Rezepten, ließ es ein paar Wochen lang gären und testete es dann am Ende aus. In der Zwischenzeit gab es nicht viel zu tun, außer zuzusehen, wie es brodelte. Daher war die Mathematik so ausgelegt, dass sie nur am Ende des Tests ein gültiges Ergebnis lieferte , nicht währenddessen.

Bei herkömmlichen t-Tests schwankt der p-Wert im Laufe der Zeit. Wenn Sie handeln, wenn er seinen Höhepunkt erreicht, riskieren Sie, dass Sie mit falschen Informationen arbeiten.

Das ist großartig für das Brauen, aber bei Online A/B-Testing ist das nicht der Fall, weil Sie die Zahlen jederzeit aktualisieren können. In unserem Fall bedeutete diese Flexibilität, dass wir uns über Zahlen aufgeregt haben, die noch nicht ganz "fertig" waren. Bei Tests mit festem Zeithorizont kann die statistische Signifikanz stark schwanken, bis Sie das vordefinierte Enddatum eines Tests erreichen, was bedeutet, dass es gefährlich einfach ist, die Ergebnisse falsch zu interpretieren. Und das ist nicht nur ein Problem, wenn man zu früh nachschaut. Auch nachdem Sie eine bestimmte Stichprobengröße abgewartet haben, sollten Sie die Ergebnisse während der Laufzeit des Experiments nicht ansehen, da sie immer wieder nach oben und unten schwanken.

Das Frustrierende an diesen Problemen ist, dass sie sich nicht offensichtlich ankündigen. In Ihren Analysen erscheint keine Meldung, die besagt: "Keine Sorge, das ist nur ein falsches Positiv". Stattdessen sehen Sie einen scheinbar glaubwürdigen, knallroten Bericht, der Ihnen mitteilt, dass die Einnahmen einbrechen und SIE ALLE Schuld daran haben. Diese Fehlalarme sind unglaublich kostspielig. Sie schicken Ihre Designer und Entwickler zurück an das Zeichenbrett, wo sie verzweifelt eine Funktion umgestalten, um ein Problem zu beheben, das es gar nicht gibt, und Funktionen aufgeben, die eigentlich eine positive Wirkung haben könnten. Falsch positive Ergebnisse können schnell den gesamten Wert des Experimentierens zunichte machen, indem sie Unsicherheit und Angst in einen Prozess einbringen, der eigentlich für Klarheit und Vertrauen sorgen sollte.

Die gute Nachricht ist, dass diese Fallen durchaus vermeidbar sind. Es gibt zwei Möglichkeiten, falsch positive Ergebnisse zu vermeiden. Die häufigste ist der Schritt, den ich übersprungen habe: Lassen Sie jeden Test von einem erfahrenen Statistiker oder Datenwissenschaftler analysieren. So gehen Unternehmen wie Airbnb, Netflix und Booking.com beim Experimentieren vor. Sie stellen bewusst überdurchschnittlich große Data-Science-Teams ein, damit jedem Produktmanager ein unparteiischer Analyst zur Seite gestellt werden kann, der die Ergebnisse analysiert.

Diese Fachleute können Probleme wie falsch positive Ergebnisse erkennen und ein Team zu den richtigen Schlussfolgerungen führen, ohne überreagieren zu müssen.

Aber leider ist diese Art von Fachwissen nur schwer zu skalieren, vor allem weil naive Experimentierer, wie mein jüngeres Ich, einfach nicht wissen, was ihnen entgeht. Der Gedanke, dass ein Blick auf die Ergebnisse diese irgendwie ungültig machen könnte oder dass die Messung von mehr Daten dazu führen kann, dass die Daten weniger valide sind, ist so kontraintuitiv, dass die meisten Experimentierer dies einfach abtun - zumindest solange, bis sie von einem Erlebnis wie dem meinen erschüttert werden.

Angesichts dieser Herausforderung verfolgen moderne Plattformen für das Experimentieren zunehmend den entgegengesetzten Ansatz. Anstatt zu erwarten, dass der Experimentierende die Mathematik versteht, passen sie die Mathematik an die Intuition des Experimentierenden an. Sie können zum Beispiel Techniken wie die Bonferroni-Korrektur für multiple Hypothesen oder das Benjamini-Hochberg-Verfahren zur Reduzierung der Falschfindungsrateanwenden . Dies war unser Ansatz bei Optimizely. Nachdem wir jahrelang versucht hatten, unseren Nutzern die Einfürung in Statistik beizubringen, haben wir beschlossen, die ganze Mathematik über Bord zu werfen und ganz von vorne anzufangen. Wir haben uns mit einem Team von Statistikern der Stanford University zusammengetan, um ein neues Modell namens Stats Engine zu entwickeln , das den Standard-t-Test modernisiert. Stats Engine verwendet moderne Techniken wie sequentielle Tests und die Kontrolle der Falschentdeckungsrate, um Ergebnisse zu generieren, die nicht unter dem Problem des Peekings oder der Mehrfachvergleiche leiden.

Wenn Sie mehr über die Bewältigung dieser Herausforderungen in der Praxis erfahren möchten, empfehle ich Ihnen diesen großartigen Blogbeitrag des Data Science-Teams der BBC. Nachdem sie jahrelang mit falsch positiven Ergebnissen zu kämpfen hatten, beschlossen sie, zu einer Plattform für das Experimentieren mit eingebauten Korrekturen für Mehrfachvergleiche und Peeking zu wechseln. Wenn Sie eine technischere Behandlung wünschen, sehen Sie sich diese Konferenzpräsentation von KDD an .