+75 XP

A/B-Testing in der Praxis

Das interne Experiment-Tool von Booking.com hat einen Screen, den die meisten Marketing-Teams nie bauen: alles, was gerade läuft, in der Größenordnung von tausend Experimenten gleichzeitig, jedes mit einem namentlichen Owner, einem vorab festgelegten Stop-Datum und Guardrail-Metriken, die den Test beenden können, ohne dass jemand um Erlaubnis fragt. Die veröffentlichte Position des Unternehmens, dargelegt im Paper „Democratizing online controlled experiments at Booking.com" von 2017, lautet: praktisch jede Änderung geht hinter einem Flag als Experiment live. Diese Lektion bleibt innerhalb dieses einen Programms und liest seinen Output so, wie es die Leute dort tun. Das bedeutet, die meiste Zeit mit den Readouts zu verbringen, die gestoppt wurden, flach ausfielen oder bei der Metrik richtig und beim Geschäft falsch lagen.

Anatomie eines readouts

Ein Readout bei Booking.com ist keine einzelne Zahl. Signifikanz, Power und die erforderliche Stichprobe werden vor dem Start festgelegt, nach den Regeln, die die Grundlagenlektion beschreibt, und der Split läuft über das dort beschriebene persistente Besucherprofil. Was am Ende ankommt, ist eine Tabelle: die primäre Metrik mit ihrem Intervall, eine Reihe von Guardrails (Page Latency, Fehlerrate, Stornierungen, Kontakte beim Kundenservice), die vorab deklarierten Segmente und ein Entscheidungsfeld mit drei echten Optionen: ship, kill, iterate.

Das Entscheidungsfeld ist der interessante Teil. Etwa eine von zehn getesteten Ideen bringt die Verbesserung, für die sie entworfen wurde. Lukas Vermeer, der die Experimentation bei Booking.com verantwortete, hat diese Größenordnung über Jahre öffentlich wiederholt, und sie deckt sich mit dem, was Microsoft und andere aus ihren eigenen Programmen berichten. Wenn neun von zehn Readouts in kill oder iterate enden, ist die Fähigkeit, die Sie einkaufen, nicht die Fähigkeit, einen Gewinner zu erkennen. Es ist die Fähigkeit, einen Test schnell, günstig und ohne Meeting zu schließen und dabei trotzdem eine Sache aufzuschreiben, die Sie vorher nicht wussten.

Vier dinge, die ein readout überstehen muss

  1. Die Guardrail-Zeile, gelesen vor der primären Metrik

Die primäre Metrik beantwortet die Frage, die Sie gestellt haben. Die Guardrails fangen die Frage, die Sie nicht gestellt haben. Eine Variante, die Buchungen hebt und dabei die Kundenservice-Kontakte nach oben treibt, hat Kosten verschoben, nicht Wert, und die Conversion-Zeile allein wird das nie zeigen. In der Größenordnung von Booking.com löst ein Guardrail-Verstoß einen Stop aus und keine Debatte, und genau deshalb lässt sich das Stop-Datum überhaupt vorab festlegen.

  1. Die Ökonomie einer Fehlerquote von 90%

Wenn neun von zehn Tests scheitern, rechnet sich das Programm nur, wenn ein Test etwa so viel kostet wie das einmalige Schreiben des Codes. Sobald jedes Experiment eine Woche Engineering-Setup, ein eigenes Dashboard und ein Review-Panel mitbringt, bricht die Rechnung zusammen, und die Organisation fängt an, Ideen zu schützen statt sie zu killen. Früh zu killen setzt außerdem den knappsten Input frei: Traffic.

  1. Was Ihr Volumen tatsächlich sehen kann

Booking Holdings berichtet in der Größenordnung von einer Milliarde Übernachtungen pro Jahr, und selbst das macht kleine Effekte nicht kostenlos. Eine relative Bewegung von einem halben Prozent bei der Conversion braucht in einem einzelnen Markt immer noch Wochen, und tausend gleichzeitige Experimente ziehen alle aus denselben Besuchern. Priorisierung ist ein Traffic-Budget, keine Wunschliste. Die Entscheidung, die Suchergebnisseite zu testen, ist die Entscheidung, in diesem Monat etwas anderes nicht zu testen.

  1. Der Abstand zwischen Exposure und Wahrheit

Reisen hat einen langen Schwanz: Exposure heute, Buchung nächste Woche, Aufenthalt in drei Monaten, Stornierung jederzeit dazwischen möglich. Eine Variante, die Leute in Buchungen drängt, die sie später aufgeben, wird die primäre Metrik bewegen und Wert zerstören. Das fängt nichts außer einem Stornierungs-Guardrail und einem Messfenster, das lang genug ist, um das Ergebnis einzuschließen, plus mindestens zwei vollen Wochenzyklen, um Wochentagsmuster und Neuheitseffekte abzufedern.

How Booking.com Uses A/B Testing at Scale

Watch on YouTube

Drei readouts: gestoppt, flach und falsch

Fall 1: das Experiment, das verlieren sollte

Booking.com-Engineers haben absichtlich Latenz in die Website injiziert, um zu bepreisen, was Geschwindigkeit wert ist. In den Ergebnissen, die in ihrem KDD-Paper von 2019 veröffentlicht wurden, kostete eine Latenzerhöhung von rund 30% etwa 0,5% Conversion. Der Test wurde durchgeführt, um gestoppt zu werden; sein Wert ist der Umtauschkurs, den er erzeugt. Jedes späteres Feature, das 0,3% Conversion gewinnt und dabei die Seite deutlich schwerer macht, ist jetzt ein bekannter Nettoverlust, und die Diskussion darüber, ob es sich schneller „anfühlt", ist beendet. Die meisten Unternehmen führen nie ein negatives Experiment durch und haben deshalb keinen Preis für das, was sie in jedem Sprint weggeben.

Fall 2: 150 Modelle und die Metrik, die gelogen hat

Dasselbe Paper behandelt 150 Machine-Learning-Modelle, die in Live-Experimente gegeben wurden. Ein Befund ist unangenehm: Gewinne in der Offline-Modellperformance ließen sich nicht zuverlässig in Geschäftswert übersetzen, und in einer Reihe von Fällen schnitten Modelle, die offline besser abschnitten, im Experiment schlechter ab. Die Readouts kamen flach oder negativ zurück, auf der Metrik, die bezahlt. Der Offline-Score war ein Proxy, der Proxy driftete vom Ergebnis weg, und nur der kontrollierte Test legte die Lücke offen. Wenn Ihre Agentur Modellgenauigkeit, Engagement-Scores oder Brand Lift als Wertnachweis berichtet, ist das der Fall, an dem Sie sie messen.

Fall 3: richtig bei der Conversion, falsch bei allem anderen

Die Urgency- und Scarcity-Botschaften von Booking.com (noch X Zimmer frei, andere Leute schauen gerade, Rabatt-Framing) sind das am häufigsten kopierte Muster im Online-Reisemarkt, und es wird kopiert, weil es bei der Conversion-Metrik gewinnt. Im Februar 2019 erhielt die britische Competition and Markets Authority formelle Zusicherungen von Booking.com und fünf weiteren Reise-Websites zu Pressure Selling, Rabattbehauptungen, versteckten Gebühren und der Offenlegung des Such-Rankings. Die Website änderte sich. Kein Readout hätte das zeigen können, denn keine primäre Metrik und kein Guardrail im Tool misst eine Regulierungsbehörde, einen Journalisten oder einen Kunden, der einmal bucht und der Marke nie wieder vertraut. Experimentation optimiert innerhalb der Grenze, die Sie ziehen; das Ziehen der Grenze ist eine menschliche Entscheidung, und sie gehört vor den Test, schriftlich.

A/B Testing Statistics Explained Clearly

Watch on YouTube

Action items für cmos

  • Fragen Sie nach der Kill Rate, nicht nach der Win Rate. Ein Team, das berichtet, die meisten seiner Tests hätten gewonnen, testet entweder Trivialitäten oder liest die Daten falsch. Wenn die Zahl nicht irgendwo bei neun von zehn liegt, die nicht ausgerollt werden, finden Sie heraus warum, bevor Sie feiern.
  • Verlangen Sie eine Guardrail-Zeile bei jedem Readout, das Ihnen gezeigt wird, mit Latency und einer nachgelagerten Qualitätsmetrik (Stornierungen, Rückerstattungen, Retouren, Support-Kontakte). Ein Readout mit einer einzigen Zeile ist ein Sales Pitch.
  • Schreiben Sie die Entscheidungsregel vor dem Start ins Testdokument: welches Ergebnis ausgerollt wird, welches Ergebnis killt, welches Ergebnis einen Rerun auslöst, und das Datum. Und dann halten Sie das Datum.
  • Behalten Sie die Verluste. Eine Ergebnisbibliothek, die Hypothese, Readout und den geschätzten Wert der gescheiterten Tests festhält, verhindert, dass Ihre Organisation alle achtzehn Monate dieselbe tote Idee erneut testet, wenn Personal wechselt.

Häufige fehler, die ergebnisse zerstören

  • Peeking und Stoppen am ersten guten Tag. Einen laufenden Test zu beobachten und ihn in dem Moment abzubrechen, in dem die Linie grün wird, treibt False Positives stark nach oben. Entweder Sie verpflichten sich auf das Enddatum oder Sie nutzen eine sequenzielle Methode, die für kontinuierliches Monitoring gebaut ist, und sagen vor dem Start, welche der beiden Sie verwenden.
  • Nachträgliches Jagen nach einem Segment. Schneiden Sie ein flaches Ergebnis nach Device, Markt, Traffic-Quelle und neu versus wiederkehrend, und Sie finden allein durch Zufall einen „Gewinner"; zwanzig Slices beim üblichen Schwellenwert erzeugen im Durchschnitt ein False Positive. Deklarieren Sie die Segmente, die Ihnen wichtig sind, im Voraus, und behandeln Sie alles andere als Hypothese für den nächsten Test statt als Ergebnis.
  • Annehmen, dass Ihre parallelen Tests unabhängig sind. Wenn hundert Experimente denselben Funnel berühren, können zwei Varianten interagieren, und ein gemeinsamer Traffic-Pool bedeutet, dass jedes Experiment die anderen zusätzlich verwässert. Große Programme handhaben das mit Isolationsgruppen und Interaktions-Checks. Ein Team, das zwölf Tests auf einer Landing Page fährt, ohne all das, produziert Rauschen.
  • Den Gewinner von jemand anderem importieren. Die Ergebnisse von Booking.com gelten für den Traffic, die Preispunkte und die Intent-Lage von Booking.com. Ein Muster, das die Conversion für einen Kunden hebt, der ein Hotel für nächsten Freitag auswählt, sagt Ihnen so gut wie nichts über einen sechsmonatigen Enterprise-Sales-Cycle. Leihen Sie sich die Hypothese, nie die Schlussfolgerung.

Ressourcen

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Testdauer und Stichprobengröße vor dem Start festlegen; frühes Reinschauen verbieten
  • Testen Sie strukturelle Elemente mit hohem Hebel statt kosmetischer Änderungen bei geringem Traffic
  • Eine gemeinsame Testergebnis-Bibliothek pflegen, die jeden Win und jeden Loss dokumentiert
Vollständiges Action Playbook ansehen →

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.