+80 XP

Playbook CMO & tactiques avancées d'A/B testing

Un faux positif mis en production ne s'annonce jamais. Il part dans le code, dans le deck trimestriel sous forme d'un lift de 3 %, et dans la roadmap de l'année suivante comme un pattern prouvé. Personne ne le retire jamais. L'équipe d'expérimentation de Microsoft a rapporté qu'environ un tiers seulement des idées qu'elle teste font bouger la métrique visée dans la direction visée ; le reste est plat ou négatif. Passez une telle population par une barre à 5 % avec une puissance de 80 % et environ un gagnant déclaré sur dix est du bruit en costume. Laissez les équipes arrêter les tests quand la courbe a bonne allure et cette part grimpe vite. Le symptôme visible, c'est un P&L qui ne se réconcilie jamais avec la somme des lifts revendiqués par votre équipe, sans qu'aucun test en particulier puisse en porter la responsabilité.

Ce qui échoue à ce stade, ce ne sont pas les maths. Ce qui échoue, c'est qui possède la plateforme, à quelle vitesse un test peut partir en production, et qui a qualité pour mettre un veto sur un readout positif.

Concept clé : l'expérimentation comme institution, pas comme activité

Prenez pour acquis le vocabulaire de significativité, de puissance et de taille d'échantillon vu dans la leçon de fondamentaux. Ce que ce vocabulaire ne vous dit pas, c'est qui paie la plomberie. Une institution a quatre choses qu'une habitude de test n'a pas : un service d'assignation unique appelé par toutes les surfaces, une bibliothèque unique de définitions de métriques, un readout automatisé qui applique des contrôles identiques à chaque test, et un journal de décisions consignant ce qui a été livré et pourquoi.

Les travaux publiés de Microsoft sur la maturité en expérimentation (Kohavi, Fabijan, Dmitriev et leurs collègues) décrivent une organisation passant de tests artisanaux au coup par coup à une expérimentation servie par une plateforme sur Bing, Office, Windows et Xbox. Ce qui compte pour un CMO, c'est ce qui change entre ces étapes. Au bas de l'échelle, un analyste est la plateforme, et la qualité de l'analyse dépend de l'analyste qui a pris le ticket. Au sommet, un ingénieur livre un test sans analyste dans la boucle, parce que les contrôles sont du code et que les métriques sont déjà définies.

Cette capacité est un coût permanent d'ingénierie et de data science, pas une ligne dans un budget de campagne. Elle a aussi une conséquence politique : si l'expérimentation vit entièrement dans le budget marketing, elle est coupée au premier mauvais trimestre, et les définitions de vos propres métriques de conversion partent avec elle. La copropriété avec le produit et l'ingénierie est l'arbitrage qui vaut la peine d'être mené tôt.

Sous-concept 1 : build, buy, ou rester petit volontairement

Amazon a construit Weblab. Microsoft a construit ExP. Les deux l'ont fait parce que l'expérimentation touche au ranking, au pricing et aux services backend, là où un script de vendor côté client ne peut pas aller. Les vendors (Optimizely, VWO, Statsig, Eppo, GrowthBook, qui tous vendent précisément ce dont on parle) feront tourner une plateforme compétente pour une fraction de ce coût, et pour la plupart des organisations marketing c'est la bonne réponse. Ce que vous achetez, c'est le moteur statistique et la logique d'assignation de quelqu'un d'autre, ce qui signifie que vous héritez de ses réglages par défaut.

La troisième option est ignorée. Prenez une marque dont la meilleure page fait 50 000 sessions par mois à un taux de conversion de 3 %. Détecter une amélioration relative de 5 % demande environ 200 000 sessions par bras, soit à peu près huit mois de trafic pour un seul test. Aucun achat de plateforme ne change cette arithmétique. Sous un certain niveau de trafic, la décision honnête est de mener peu de tests, larges et structurels, d'accepter la recherche qualitative et le jugement pour le reste, et d'arrêter de prétendre que quinze jours de données sur un bouton constituent une preuve. Acheter une plateforme pour faire tourner plus vite des tests sous-dimensionnés ne fait qu'industrialiser le bruit.

Sous-concept 2 : vélocité contre qualité de revue

Deux modes de défaillance se situent aux extrémités opposées d'un même curseur. Un comité hebdomadaire de revue des expérimentations composé de seniors transforme trois tests par semaine en trois par mois, et la file d'attente devient la contrainte sur l'apprentissage. Aucune revue du tout, et une part significative de vos readouts sont cassés avant que quiconque les lise : répartitions de trafic non conformes, une métrique changée en cours de route, des bots dans un bras.

La lettre aux actionnaires d'Amazon de 2013 rapportait 1 976 expérimentations Weblab menées cette année-là, contre 1 092 l'année précédente et 546 en 2011. Une vélocité de cette forme ne s'obtient pas en durcissant la revue. Elle vient du fait de rendre les contrôles automatiques et peu coûteux : une alarme de sample ratio mismatch sur chaque test, une métrique primaire et une durée préenregistrées avant le lancement du trafic, des guardrail metrics permanentes qui font échouer un test quoi que dise la métrique primaire.

La question du peeking a aussi sa place ici, comme sujet de gouvernance plutôt que de statistique. Les tests à horizon fixe lus trop tôt gonflent lourdement les faux positifs ; Optimizely, qui vend une plateforme d'expérimentation, a publié des simulations montrant qu'un monitoring continu à un seuil nominal de 5 % pousse les taux d'erreur réels bien au-delà de 20 %. Un dirigeant a deux positions cohérentes : horizon fixe avec la lecture anticipée traitée comme une violation de protocole, ou une méthode always-valid pour que lire tôt soit légitime. N'en choisir aucune, ce qui est le réglage par défaut dans la plupart des organisations, signifie que le chiffre dans le deck n'a aucun taux d'erreur défini.

Sous-concept 3 : concurrence et effets d'interaction

Dès que des dizaines de tests tournent en même temps, ils se chevauchent sur les mêmes utilisateurs. Microsoft fait tourner un grand nombre d'expérimentations concurrentes et vérifie automatiquement les interactions entre elles plutôt que de sérialiser la file, ce qui est la seule réponse abordable à grande échelle. Le risque est réel : sur une page de retail, un changement de titre et un changement d'image qui gagnent chacun séparément peuvent perdre ensemble, parce qu'un visiteur lit la page comme un objet unique, pas comme des emplacements indépendants.

Le test multivarié factoriel complet, c'est là que ça devient coûteux. Trois variables à deux niveaux chacune font huit cellules, et huit cellules demandent beaucoup plus de trafic que deux. Aux volumes d'Amazon, c'est une erreur d'arrondi. Pour la plupart des marques, cela veut dire que le test se termine après la saison qu'il devait éclairer. Des designs factoriels fractionnaires ou des tests séquentiels à variable unique sur les pages qui portent du vrai chiffre sont la voie praticable. La décision de leadership n'est pas d'autoriser ou non la concurrence, c'est de savoir si votre plateforme peut détecter une interaction quand elle se produit, et si les tests touchant à la même surface sont isolés par défaut.

How Booking.com Runs 1000+ Experiments

Watch on YouTube

SOUS-CONCEPT 4 : CE QUI COMPTE COMME UNE VICTOIRE, ET QUI PEUT LE DIRE

Tout programme mature converge vers un critère de décision unique convenu à l'avance, plus des guardrails qui peuvent opposer un veto. Le taux de conversion seul est un mauvais critère parce qu'il est facile de le faire monter en empruntant ailleurs : des interstitiels agressifs qui augmentent les inscriptions et le churn, un checkout qui augmente les commandes et les retours. Une expérimentation Amazon rapportée par Greg Linden a établi que chaque 100 ms de latence ajoutée coûtait environ 1 % des ventes, et c'est pourquoi le poids de page appartient à la liste des guardrails pour tout ce qu'une équipe marketing met en production.

Le contrôle le plus solide sur un portefeuille de victoires revendiquées est un holdout de long terme : gardez une petite tranche d'utilisateurs, 1 % à 5 %, en dehors de tout ce que vous livrez pendant un trimestre ou plus, puis comparez leur comportement au lift cumulé que revendique votre journal de tests. Quand les deux divergent largement, vous avez un problème de taux de fausses découvertes, et vous l'avez trouvé avant votre CFO.

Cas réels

Cas 1 : les titres d'annonces de Microsoft Bing

En 2012, un ingénieur de Bing a proposé un petit changement dans la façon d'afficher les titres d'annonces. L'idée est restée des mois dans le backlog parce qu'elle paraissait triviale. Quand elle a enfin tourné, elle a produit une hausse d'environ 12 % du revenu américain de Bing, soit plus de 100 millions de dollars par an. Le récit de Stefan Thomke dans la Harvard Business Review en tire la leçon organisationnelle : préfiltrer les idées selon leur importance perçue est en soi une décision coûteuse, prise par des gens qui n'ont aucun moyen de savoir. Le corollaire est inconfortable pour un CMO. Si votre processus d'entrée classe les idées selon la séniorité du sponsor, vous payez ce classement avec les idées que vous ne testez jamais.

Cas 2 : la vélocité d'Amazon comme objectif

Bezos a présenté le succès d'Amazon comme une fonction du nombre d'expérimentations menées par an, par mois, par semaine, par jour, et les comptages Weblab dans les lettres aux actionnaires montrent ce cadrage piloté comme un chiffre qui a à peu près doublé d'année en année. La vélocité comme métrique exécutive explicite change les comportements plus bas : les équipes cessent de regrouper cinq changements dans une seule release pour économiser du temps de revue, parce que la revue n'est plus le goulot d'étranglement.

Cas 3 : l'effet cumulé de Duolingo

Le récit de Jorge Mazal en 2022 sur le travail de growth de Duolingo décrit une longue série de petits changements sur les mécaniques de streak, la réparation de streak et le timing des notifications, valant pour la plupart quelques pourcents au mieux. Duolingo a rapporté plus de 16 millions d'actifs quotidiens fin 2022, en croissance de plus de 50 % sur un an. Aucun test isolé de ce programme ne survivrait à une revue exécutive demandant un business case. Le programme, lui, a survécu. Cette asymétrie est l'argument pour financer une capacité de test plutôt que d'approuver les tests un par un.

A/B Testing at Scale: Lessons from Netflix

Watch on YouTube

Actions pour le CMO

  • Établissez la propriété par écrit ce trimestre : nommez l'équipe qui possède l'assignation, les définitions de métriques et l'outillage de readout, et faites co-signer la ligne budgétaire avec le produit ou l'ingénierie plutôt que de la laisser seule dans le marketing.
  • Choisissez votre régime de peeking et publiez-le. Soit horizon fixe avec durée verrouillée, soit méthode always-valid. Puis demandez à votre équipe laquelle des deux l'outil actuel implémente réellement ; la réponse n'est souvent pas celle qu'elle suppose.
  • Instrumentez le programme, pas seulement les tests : expérimentations lancées par mois, part échouant au contrôle de répartition du trafic, part des readouts plats ou négatifs, et délai entre readout et décision. Un programme où 90 % des tests gagnent mesure mal, il ne performe pas bien.
  • Faites tourner un holdout de long terme sur votre surface à plus fort trafic pendant un trimestre et réconciliez-le avec le lift que votre journal de tests revendique pour la même période.
  • Exigez deux découpages de segments sur chaque readout présenté au leadership, nouveaux contre récurrents et mobile contre desktop, pour qu'une moyenne plate ne tue pas silencieusement un changement qui fonctionne pour une large minorité.

Erreurs courantes qui tuent les résultats

Erreur 1 : faire de l'arrêt anticipé un acte valorisant pour la carrière. Les équipes font du peeking parce qu'un senior demande où en est le test au quatrième jour, et répondre avec un gros chiffre est récompensé. Le correctif est structurel plutôt qu'éducatif : durée verrouillée et consignée avant le lancement, et un template de readout qui affiche la date de fin préenregistrée à côté du résultat courant. Si l'arrêt anticipé est traité comme de l'initiative, aucune formation en statistiques n'y changera quoi que ce soit.

Erreur 2 : remplir la roadmap de retouches de surface. Couleurs, espacements et tailles de police sont faciles à tester, faciles à expliquer et rarement d'une grande valeur. L'architecture de pricing, la séquence d'onboarding, la structure d'offre et le copy de proposition de valeur, c'est là qu'est l'argent, et ce sont des sujets plus difficiles à concevoir et plus risqués à mener, ce qui explique qu'ils glissent. Une roadmap qui se lit comme une liste d'ajustements visuels est un signal sur votre processus de revue, pas sur vos designers.

Erreur 3 : traiter une victoire mise en production comme définitive. Les effets se dégradent à mesure que le marché, le mix de trafic et l'environnement concurrentiel bougent, et la littérature d'expérimentation de Microsoft traite la mesure des effets de long terme comme un exercice distinct du readout à deux semaines, précisément pour cette raison. Mettez un calendrier de re-test sur la poignée de décisions qui portent le plus de revenu, et acceptez que certaines ne se reproduiront pas. L'apprendre volontairement coûte bien moins cher que de le découvrir par un trimestre inexpliqué.

Ressources

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

  • Verrouillez la durée du test et la taille d'échantillon avant le lancement ; interdisez les coups d'œil précoces
  • Testez en priorité les éléments structurels à fort enjeu plutôt que les retouches cosmétiques à faible trafic
Voir le plan d'action complet →

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.