+75 XP

A/B-Testing in der Praxis

Das interne Experimentier-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 namentlich benannten Owner, einem vorab festgelegten Stoppdatum 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 in diesem einen Programm und liest dessen Output so, wie es die Leute dort tun. Das heißt: Die meiste Zeit geht an die Readouts, die gestoppt wurden, flach blieben 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 aus der Grundlagenlektion, und der Split läuft über das dort beschriebene persistente Besucherprofil. Am Ende steht eine Tabelle: die primäre Metrik mit ihrem Intervall, eine Zeile mit Guardrails (Page Latency, Fehlerrate, Stornierungen, Kontakte beim Kundenservice), die vorab deklarierten Segmente und ein Entscheidungsfeld mit drei realen Optionen: ship, kill, iterate.

Das Entscheidungsfeld ist der interessante Teil. Etwa eine von zehn getesteten Ideen liefert die Verbesserung, für die sie entworfen wurde. Lukas Vermeer, der Experimentation bei Booking.com verantwortet hat, wiederholt diese Größenordnung seit Jahren öffentlich, 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, dann ist die Fähigkeit, die Sie einkaufen, nicht das Erkennen eines Gewinners. Es ist die Fähigkeit, einen Test schnell, günstig und ohne Meeting zu schließen und 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 ab, die Sie nicht gestellt haben. Eine Variante, die Buchungen hebt und gleichzeitig die Kundenservice-Kontakte nach oben treibt, hat Kosten verschoben, nicht Wert erzeugt, und die Conversion-Zeile allein wird das nie zeigen. In der Größenordnung von Booking.com löst ein Guardrail-Verstoß einen Stopp aus, keine Debatte. Genau deshalb lässt sich das Stoppdatum überhaupt vorab festlegen.

2. Die Ökonomie einer Ausfallrate von 90%

Wenn neun von zehn Tests scheitern, zahlt sich das Programm nur aus, wenn ein Test ungefähr so viel kostet wie das einmalige Schreiben des Codes. In dem Moment, in dem jedes Experiment eine Woche Engineering-Setup, ein maßgeschneidertes Dashboard und ein Review-Gremium mitschleppt, bricht die Rechnung zusammen, und die Organisation fängt an, Ideen zu schützen statt sie zu killen. Frühes Killen setzt außerdem den knappsten Input frei: Traffic.

3. Was Ihr Volumen tatsächlich sehen kann

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

4. Der Verzug 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, bewegt die primäre Metrik und zerstört Wert. Nichts fängt das ab 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 aufzufangen.

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 eingebaut, um zu bepreisen, was Geschwindigkeit wert ist. In den Ergebnissen ihres KDD-Papers von 2019 kostete eine Erhöhung der Latenz um rund 30% etwa 0,5% Conversion. Der Test wurde durchgeführt, um gestoppt zu werden; sein Wert ist der Wechselkurs, den er erzeugt. Jedes spätere Feature, das 0,3% bei der Conversion gewinnt und die Seite dabei spürbar schwerer macht, ist jetzt ein bekannter Nettoverlust, und die Diskussion darüber, ob sich etwas 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 eintauschen.

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: Verbesserungen der Offline-Modellperformance haben sich nicht zuverlässig in Geschäftswert übersetzt, 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, gemessen an der Metrik, die zahlt. 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

Booking.coms Urgency- und Scarcity-Messaging (verbleibende Zimmer, andere Personen sehen sich das gerade an, Rabatt-Framing) ist das meistkopierte Muster im Online-Reisegeschäft, und es wird kopiert, weil es bei der Conversion-Metrik gewinnt. Im Februar 2019 erwirkte die britische Competition and Markets Authority förmliche Zusagen von Booking.com und fünf weiteren Reiseportalen zu Druckverkauf, Rabattbehauptungen, versteckten Gebühren und der Offenlegung des Such-Rankings. Die Website änderte sich. Kein Readout hätte das zeigen können, weil keine primäre Metrik und kein Guardrail im Tool eine Regulierungsbehörde misst, 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

CMO ACTION ITEMS

  • Fragen Sie nach der Kill Rate, nicht nach der Win Rate. Ein Team, das berichtet, die meisten seiner Tests hätten gewonnen, testet entweder Belanglosigkeiten oder liest die Daten schlecht. Wenn die Zahl nicht irgendwo bei neun von zehn nicht-ausgerollten Tests liegt, finden Sie heraus warum, bevor Sie feiern.
  • Verlangen Sie in jedem Readout, das man Ihnen zeigt, eine Guardrail-Zeile mit Latenz und einer nachgelagerten Qualitätsmetrik (Stornierungen, Rückerstattungen, Retouren, Support-Kontakte). Ein Readout mit nur einer Zeile ist ein Verkaufsgespräch.
  • Schreiben Sie die Entscheidungsregel vor dem Start ins Testdokument: welches Ergebnis ausgerollt wird, welches Ergebnis killt, welches Ergebnis einen erneuten Durchlauf auslöst, und das Datum. Und halten Sie das Datum ein.
  • 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, weil Personal wechselt.

HÄUFIGE FEHLER, DIE ERGEBNISSE ZERSTÖREN

  • Zwischendurch reinschauen und am ersten guten Tag stoppen. Einen laufenden Test zu beobachten und ihn in dem Moment abzubrechen, in dem die Linie grün wird, treibt die Rate falsch positiver Ergebnisse massiv hoch. Entweder Sie verpflichten sich auf das Enddatum oder Sie nutzen ein sequenzielles Verfahren, das für kontinuierliches Monitoring gebaut ist, und sagen vor dem Start, welches von beiden.
  • Nachträglich nach einem Segment jagen. Zerlegen Sie ein flaches Ergebnis nach Gerät, Markt, Traffic-Quelle und Neu- versus Bestandskunden, und Sie finden allein durch Zufall einen "Gewinner"; zwanzig Slices beim üblichen Schwellenwert erzeugen im Schnitt ein falsch positives Ergebnis. Deklarieren Sie die Segmente, die Sie interessieren, vorab, und behandeln Sie alles andere als Hypothese für den nächsten Test, nicht als Ergebnis.
  • Annehmen, Ihre parallelen Tests seien unabhängig. Wenn hundert Experimente denselben Funnel berühren, können zwei Varianten interagieren, und ein gemeinsamer Traffic-Pool bedeutet, dass jede die anderen zusätzlich verwässert. Große Programme lösen das mit Isolationsgruppen und Interaktions-Checks. Ein Team, das zwölf Tests auf einer Landingpage laufen lässt, ohne all das, produziert Rauschen.
  • Den Gewinner eines anderen importieren. Booking.coms Ergebnisse gelten für Booking.coms Traffic, Preispunkte und Intent. Ein Muster, das die Conversion für einen Kunden hebt, der ein Hotel für nächsten Freitag auswählt, sagt Ihnen fast nichts über einen sechsmonatigen Enterprise-Sales-Zyklus. Borgen 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.