Application concrète de l'A/B testing

L'outil d'expérimentation interne de Booking.com comporte un écran que la plupart des équipes marketing ne construisent jamais : tout ce qui tourne à cet instant, de l'ordre du millier d'expériences en parallèle, chacune avec un propriétaire nommé, une date d'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt fixée à l'avance et des guardrailguardrailRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → metrics capables de stopper le test sans que personne ait à demander l'autorisation. La position publiée de l'entreprise, exposée dans son article de 2017 « Democratizing online controlled experiments at Booking.com », est que pratiquement chaque changement part en production derrière un flag, sous forme d'expérience. Cette leçon reste à l'intérieur de ce seul programme et lit ses résultats comme le font les gens sur place, c'est-à-dire en passant l'essentiel du temps sur les readouts qui ont été arrêtés, plats, ou justes sur la métrique et faux sur le business.

Anatomie d'un readout

Un readout chez Booking.com n'est pas un chiffre unique. La significativité, la puissance et la taille d'échantillon requise sont fixées avant le lancement, selon les termes posés dans la leçon sur les fondamentaux, et le split s'appuie sur le profil visiteur persistant qui y est décrit. Ce qui arrive à la fin est un tableau : la métrique primaire avec son intervalle, une ligne de guardrails (latence des pages, taux d'erreur, annulations, contacts service client), les segmentssegmentsDécouper un marché en groupes distincts de clients partageant des besoins, des caractéristiques ou des comportements similaires, afin de traiter chaque groupe avec une approche dédiée.Voir la définition complète → déclarés à l'avance, et un champ décision avec trois options réelles : ship, kill, iterate.

Le champ décision est la partie intéressante. Environ une idée testée sur dix produit l'amélioration pour laquelle elle a été conçue. Lukas Vermeer, qui a dirigé l'expérimentation chez Booking.com, répète publiquement cet ordre de grandeur depuis des années, et il correspond à ce que Microsoft et d'autres rapportent de leurs propres programmes. Si neuf readouts sur dix se terminent en kill ou iterate, la capacité que vous achetez n'est pas celle de reconnaître un gagnant. C'est celle de clore un test vite, à moindre coût, sans réunion, et de noter quand même une chose que vous ne saviez pas avant.

Quatre choses qu'un readout doit passer

1. La ligne de guardrails, lue avant la métrique primaire

La métrique primaire répond à la question que vous avez posée. Les guardrails attrapent celle que vous n'avez pas posée. Une variante qui augmente les réservations tout en poussant les contacts service client à la hausse a déplacé du coût, pas de la valeur, et la seule ligne de conversion ne le montrera jamais. À l'échelle de Booking.com, une violation de guardrail déclenche un arrêt plutôt qu'un débat, et c'est précisément pour cela que la date d'arrêt peut être fixée à l'avance.

1. L'économie d'un taux d'échec de 90 %

Si neuf tests sur dix échouent, le programme n'est rentable que si un test coûte à peu près ce que coûte l'écriture du code une fois. Dès que chaque expérience embarque une semaine de setup engineering, un dashboard sur mesure et un comité de revue, l'arithmétique s'effondre et l'organisation se met à protéger les idées au lieu de les tuer. Tuer tôt libère aussi la ressource la plus rare : le trafic.

1. Ce que votre volume permet réellement de voir

Booking Holdings déclare de l'ordre d'un milliard de nuitées par an, et même cela ne rend pas les petits effets gratuits. Un mouvement relatif d'un demi-point sur la conversion prend encore des semaines sur un seul marché, et mille expériences simultanées puisent toutes dans les mêmes visiteurs. La priorisation est un budget de trafic, pas une liste de souhaits. Décider de tester la page de résultats de recherche, c'est décider de ne pas tester autre chose ce mois-ci.

1. Le décalage entre l'exposition et la vérité

Le voyage a une longue traîne : exposition aujourd'hui, réservation la semaine prochaine, séjour dans trois mois, annulation possible à n'importe quel moment entre les deux. Une variante qui pousse les gens vers des réservations qu'ils abandonnent ensuite fera bouger la métrique primaire et détruira de la valeur. Rien ne détecte cela, sauf un guardrail sur les annulations et une fenêtre de mesure assez longue pour inclure le résultat, plus au moins deux cycles hebdomadaires complets pour absorber les effets jour de la semaine et l'effet de nouveauté.

Trois readouts : arrêté, plat, et faux

Cas 1 : l'expérience conçue pour perdre

Les ingénieurs de Booking.com ont délibérément injecté de la latence dans le site pour chiffrer ce que vaut la vitesse. Dans les résultats publiés dans leur article KDD de 2019, une hausse de latence d'environ 30 % coûtait à peu près 0,5 % de conversion. Le test a été mené pour être arrêté ; sa valeur est le taux de change qu'il produit. Toute fonctionnalité ultérieure qui gagne 0,3 % de conversion tout en alourdissant sensiblement la page est désormais une perte nette connue, et le débat sur le fait qu'elle « semble » plus rapide est clos. La plupart des entreprises ne mènent jamais d'expérience négative et n'ont donc aucun prix pour ce qu'elles sacrifient à chaque sprint.

Cas 2 : 150 modèles, et la métrique qui a menti

Le même article couvre 150 modèles de machine learning mis en expérience live. Un constat dérange : les gains de performance offline des modèles ne se traduisaient pas de façon fiable en valeur business, et dans un certain nombre de cas, des modèles mieux notés offline performaient moins bien dans l'expérience. Les readouts revenaient plats ou négatifs sur la métrique qui paie. Le score offline était un proxy, le proxy a dérivé par rapport au résultat, et seul le test contrôlé a exposé l'écart. Si votre agence présente la précision d'un modèle, des scores d'engagement ou un brand lift comme preuve de valeur, c'est le cas à leur opposer.

Cas 3 : juste sur la conversion, faux sur tout le reste

Les messages d'urgence et de rareté de Booking.com (chambres restantes, autres personnes qui consultent, cadrage des remises) constituent le pattern le plus copié du voyage en ligne, et il est copié parce qu'il gagne sur la métrique de conversion. En février 2019, la Competition and Markets Authority britannique a obtenu des engagements formels de Booking.com et de cinq autres sites de voyage portant sur la vente sous pression, les allégations de remise, les frais cachés et la façon dont le classement des résultats est explicité. Le site a changé. Aucun readout n'aurait pu montrer cela, parce qu'aucune métrique primaire et aucun guardrail de l'outil ne mesure un régulateur, un journaliste ou un client qui réserve une fois et ne fait plus jamais confiance à la marque. L'expérimentation optimise à l'intérieur de la frontière que vous tracez ; tracer la frontière est une décision humaine et elle se prend avant le test, par écrit.

Actions pour le CMO

• Demandez le kill rate, pas le win rate. Une équipe qui rapporte que la plupart de ses tests ont gagné teste des trivialités ou lit mal les données. Si le chiffre n'est pas proche de neuf sur dix non déployés, cherchez pourquoi avant de célébrer.
• Exigez une ligne de guardrails sur chaque readout qu'on vous présente, avec la latence et une métrique de qualité en aval (annulations, remboursements, retours, contacts support). Un readout à une seule ligne est un argumentaire de vente.
• Écrivez la règle de décision dans le document de test avant le lancement : quel résultat déclenche le ship, quel résultat déclenche le kill, quel résultat déclenche un rerun, et la date. Puis tenez la date.
• Gardez les pertes. Une bibliothèque de résultats qui consigne l'hypothèse, le readout et la valeur estimée de ceux qui ont échoué empêche votre organisation de retester la même idée morte tous les dix-huit mois au gré du turnover.

Erreurs courantes qui ruinent les résultats

• Regarder en cours de route et s'arrêter au premier bon jour. Surveiller un test en direct et l'arrêter dès que la courbe passe au vert gonfle fortement les faux positifs. Soit vous vous engagez sur la date de fin, soit vous utilisez une méthode séquentielle conçue pour le monitoring continu, et vous dites laquelle avant le lancement.
• Chercher un segment après coup. Découpez un résultat plat par device, marché, source de trafic et nouveaux versus récurrents et vous trouverez un « gagnant » par pur hasard ; vingt découpages au seuil habituel produisent en moyenne un faux positif. Déclarez à l'avance les segments qui vous intéressent, et traitez tout le reste comme une hypothèse pour le prochain test, pas comme un résultat.
• Supposer que vos tests simultanés sont indépendants. Quand cent expériences touchent le même funnelfunnelLe parcours client de la découverte à l'achat, généralement Awareness, Interest, Consideration, Decision, Action, avec des prospects de moins en moins nombreux à chaque étape.Voir la définition complète →, deux variantes peuvent interagir, et un pool de trafic partagé signifie que chacune dilue aussi les autres. Les grands programmes gèrent cela avec des groupes d'isolation et des contrôles d'interaction. Une équipe qui fait tourner douze tests sur une seule landing pagelanding pagePage web autonome construite pour un seul objectif de campagne, conçue pour maximiser les conversions en supprimant les distractions et en concentrant le visiteur sur une action unique.Voir la définition complète → sans rien de tout cela produit du bruit.
• Importer le gagnant de quelqu'un d'autre. Les résultats de Booking.com valent pour le trafic, les niveaux de prix et l'intention de Booking.com. Un pattern qui augmente la conversion pour un client choisissant un hôtel pour vendredi prochain ne vous apprend presque rien sur un cycle de vente entreprise de six mois. Empruntez l'hypothèse, jamais la conclusion.