Als Booking.com zu einem der größten Reisemarktplätze heranwuchs, drohten Produktteams, Features nach Meinung zu entscheiden. Das Unternehmen führte seit mehr als einem Jahrzehnt online kontrollierte Experimente durch und wollte, dass jeder – nicht nur Produktmanager – Ideen kostengünstig, sicher und mit vertrauenswürdigen Daten validieren kann.

Experimentieren zum Standard-Entscheidungssystem machen: Jede Änderung, selbst Bugfixes, wird in einen A/B-Test verpackt ausgeliefert, und jeder kann Tests starten, die Historie einsehen und schädliche Tests stoppen.

Ingenieure bauten eine unternehmenseigene Experimentierplattform mit einem durchsuchbaren Repository jedes vergangenen Erfolgs und Fehlschlags, generischen APIs für Rekrutierung, Tracking und Metriken, zwei unabhängigen Überwachungspipelines, A/A-Test-Pools und Schutzmaßnahmen wie Vorabregistrierung und Peer-Review von Erfolgen. Jede Abteilung erhielt ihr eigenes dediziertes Support-Team, sodass jeder ein Experiment von Anfang bis Ende verantworten konnte.

Mehr als 1.000 Experimente laufen gleichzeitig über mobile Apps, Hotelier-Tools, Kundendienst-Telefonleitungen und interne Systeme; jede Neugestaltung, jede Infrastrukturänderung und jeder Bugfix wird in einen Test verpackt, sodass Produktentscheidungen von Meinungen zu Belegen wanderten und Erkenntnisse abteilungsübergreifend wiederverwendet werden.

Bei Booking.com ist Experimentieren kein Werkzeug, das einige Teams nutzen – es ist die Art, wie das Unternehmen entscheidet. Seit mehr als zehn Jahren betreibt die Reiseplattform evidenzbasierte Produktentwicklung, und bis 2017 führten und analysierten ihre Abteilungen an einem beliebigen Tag mehr als tausend gleichzeitige Experimente, über mobile Apps, Hotelier-Tools, Kundendienst-Telefonleitungen und interne Systeme hinweg.

Die bewusste Entscheidung war Demokratisierung. Die Experimentierplattform fungiert als durchsuchbares Repository jedes Erfolgs und Fehlschlags seit dem allerersten Experiment, sodass jeder die Historie einsehen und neue Hypothesen bilden kann. Generische APIs abstrahieren Rekrutierung, Randomisierung und Reporting, und jede Abteilung hat ihr eigenes dediziertes Support-Team, sodass das Durchführen eines Tests keine Genehmigung des Produktmanagements erfordert.

Vertrauen entstand durch Engineering-Disziplin: Zwei getrennt gepflegte Pipelines berechnen dieselben Metriken und werden gegeneinander überwacht, ein Pool von A/A-Experimenten validiert die Statistik, und Schutzmaßnahmen wie Vorabregistrierung und Peer-Review von Erfolgen zügeln p-Hacking. Jeder im Unternehmen ist befugt, ein schädliches Experiment selbst zu stoppen.

Das Ergebnis war ein Unternehmen, in dem „jede Änderung, von kompletten Neugestaltungen und Infrastrukturänderungen bis hin zu Bugfixes, in ein Experiment verpackt wird“, wie die Ingenieure in einem Papier von 2017 schrieben – was die Produktentwicklung in einen Strom gemessener Wetten statt einer Reihe von Meinungen verwandelte.

Die Dezentralisierung von Experimenten ermöglichte es Tausenden von Menschen, Ideen zu testen, statt darauf zu warten, dass Produktmanager sie priorisieren.

Eine durchsuchbare Historie von Erfolgen und Fehlschlägen lässt Teams die Erkenntnisse der jeweils anderen erneut aufgreifen und darauf aufbauen.

Vertrauenswürdige Infrastruktur (doppelte Pipelines, A/A-Pools, Vorabregistrierung) machte Belege als Schiedsrichter von Entscheidungen akzeptabel.

Die lose Kopplung der Experimentierplattform an die Geschäftslogik machte das Ausliefern einer gewinnenden Änderung so einfach wie das Entfernen eines API-Aufrufs.

Die Befugnis für jeden, ein schädliches Experiment zu stoppen, hielt Sicherheit mit Geschwindigkeit vereinbar.

Man braucht keinen Konsens über eine Meinung, wenn jeder ein kostengünstiges, sicheres Experiment durchführen kann: Infrastruktur plus eine Evidenzkultur verwandelt Entscheidungen in Tests und Fehlschläge in gemeinsames, durchsuchbares Lernen.

Das unternehmenseigene Framework, das Amsterdamer Ingenieure Mitte der 2000er Jahre schrieben, wurde erweitert, aber nie neu geschrieben; im Jahr 2026 berichtete Silicon Canals, dass Booking.com auf der Live-Produktionsbuchungsseite weiterhin mehr als 1.000 gleichzeitige Tests und jährlich Zehntausende kumulative Experimente durchführt, wobei eine Konversionsverschiebung von 0,1 % eine achtstellige Summe bedeutet. Das Muster verbreitete sich in der gesamten Branche als „Experimentierkultur“ – Anbieterplattformen, öffentliche Playbooks und andere Technologieunternehmen übernahmen dasselbe Default-to-Test-Modell, das Booking.com pionierhaft entwickelt hatte.

DEN BELEGEN FOLGEN

Die Quellen

  1. Democratizing online controlled experiments at Booking.com arXiv · arxiv.org ·
  2. Booking.com still runs on the internal A/B testing framework its engineers wrote in Amsterdam in the mid-2000s, with no major rewrite since, and at any given moment it is running more than 1,000 live experiments Silicon Canals · siliconcanals.com ·