SRM en test A/B : diagnostiquer un trafic mal réparti

Quand la répartition du trafic devient le premier test à analyser

Dans un test A/B, le problème le plus dangereux n’est pas toujours une variante médiocre, une hypothèse faible ou une métrique mal choisie. Il peut être beaucoup plus basique : les utilisateurs n’ont pas été répartis comme prévu entre les variantes. Le SRM, sample ratio mismatch, désigne précisément un écart anormal entre la répartition attendue et la répartition observée des utilisateurs dans les groupes expérimentaux. Un test configuré en 50/50 qui reçoit 52,8 % du trafic en A et 47,2 % en B n’est pas seulement imparfait ; il peut être invalide si cet écart ne s’explique pas par le hasard.

Pour des équipes CRO, conversion rate optimization, discipline qui vise à améliorer la capacité d’un parcours digital à transformer son trafic en valeur business, le SRM est un signal critique. Il indique souvent que la randomisation, l’éligibilité, le tracking, le consentement, le routage, le cache ou l’implémentation technique ont introduit un biais. Si ce biais est corrélé au comportement de conversion, la lecture du test peut devenir trompeuse. Une variante peut apparaître gagnante parce qu’elle a reçu davantage de trafic qualifié, ou perdante parce qu’elle a été sous-exposée à certains segments à forte intention.

L’enjeu dépasse la statistique. Une décision CRO erronée peut modifier le CPA, coût par acquisition, soit le coût marketing nécessaire pour générer un client ou une conversion qualifiée. Elle peut aussi affecter le ROAS, return on ad spend, ratio entre chiffre d’affaires attribué et dépenses publicitaires, en faisant remonter aux plateformes média un signal de conversion artificiellement amélioré ou dégradé. Dans un funnel, parcours allant de la première exposition marketing à la conversion puis à la fidélisation, un SRM non détecté peut contaminer toute la chaîne de décision : allocation budgétaire, priorisation produit, messages de landing page, campagnes CRM et modèles d’attribution.

Le SRM doit donc être traité comme un contrôle qualité de premier niveau. Avant de discuter uplift, intervalle de confiance, p-value, probabilité de supériorité ou impact économique, il faut vérifier que les groupes comparés sont comparables. Une expérience avec trafic mal réparti ressemble à un thermomètre mal calibré : elle produit des chiffres, parfois très précis, mais pas nécessairement une mesure fiable.

Ce que mesure réellement un SRM, et pourquoi il invalide souvent la preuve

Un test A/B suppose que les unités expérimentales, utilisateurs, sessions, comptes ou foyers selon le protocole, sont assignées aux variantes selon une règle connue. Si la règle prévoit 50 % en contrôle et 50 % en variante, les écarts observés doivent rester compatibles avec la variabilité aléatoire. Sur 1 000 visiteurs, obtenir 520 en A et 480 en B peut arriver. Sur 1 000 000 de visiteurs, le même écart relatif devient beaucoup moins plausible. Le SRM est donc une anomalie de distribution, pas une anomalie de performance.

La méthode classique consiste à utiliser un test du chi carré d’adéquation. On compare les effectifs observés aux effectifs attendus. Pour un split 50/50 avec 100 000 utilisateurs, l’attendu est 50 000 en A et 50 000 en B. Si l’observé est 51 200 en A et 48 800 en B, l’écart paraît faible en pourcentage, mais il est statistiquement massif. Le calcul du chi carré additionne, pour chaque cellule, le carré de l’écart entre observé et attendu divisé par l’attendu. Le résultat est ensuite comparé à une distribution théorique pour obtenir une p-value. Si cette p-value est très faible, par exemple inférieure à 0,001, l’hypothèse d’une simple fluctuation aléatoire devient peu crédible.

Il est important de ne pas confondre SRM et non-significativité du test business. Un test peut n’avoir aucun effet sur le taux de conversion et présenter malgré tout un SRM critique. À l’inverse, un test peut montrer un effet très significatif et être inutilisable parce que les groupes ne sont pas correctement répartis. Le SRM porte sur la mécanique d’assignation ; l’uplift porte sur la performance. La première question est : avons-nous bien constitué les groupes ? La deuxième seulement est : les groupes se comportent-ils différemment ?

Le seuil de détection doit être plus strict que celui des métriques business. Dans beaucoup d’organisations, un seuil de p-value à 0,001 est utilisé pour alerter sur un SRM, car les tests à fort volume détectent facilement de très petits écarts. Mais le seuil ne suffit pas. Un écart statistiquement significatif peut être opérationnellement bénin si son origine est comprise et indépendante du comportement, par exemple une exclusion technique identique sur un segment sans impact business. À l’inverse, un écart modéré peut être grave s’il touche un segment stratégique, comme le trafic paid search non-marque, les utilisateurs mobile iOS ou les nouveaux visiteurs.

La gravité d’un SRM dépend de trois dimensions : l’amplitude de l’écart, le volume concerné et la corrélation probable avec la métrique de décision. Si les utilisateurs manquants dans une variante sont surtout des visiteurs desktop fidélisés, l’effet sur un test de checkout e-commerce peut être considérable. Si l’écart provient uniquement d’une population de bots déjà filtrée dans les métriques business, le risque est plus faible. Diagnostiquer un SRM, c’est donc passer d’un signal statistique à une enquête causale.

Les causes fréquentes : randomisation, éligibilité, tracking et exécution

Le SRM a rarement une cause unique. Il apparaît souvent à l’intersection de la configuration de l’outil d’expérimentation, du tag management, des règles d’audience, des contraintes de performance et des systèmes de mesure. Une équipe mature doit disposer d’une taxonomie de causes pour ne pas diagnostiquer à l’aveugle.

La première famille concerne la randomisation. Un algorithme d’assignation peut être mal paramétré, une règle de persistance peut échouer, ou l’unité de randomisation peut être incohérente avec le parcours. Randomiser à la session alors que l’utilisateur revient plusieurs fois expose à des contaminations. Randomiser au cookie dans un environnement avec consentement partiel peut exclure différemment certains navigateurs. Randomiser au compte dans un SaaS peut être nécessaire si plusieurs utilisateurs d’une même entreprise partagent une décision d’achat. Le choix de l’unité n’est pas un détail technique ; il conditionne la validité de la comparaison.

La deuxième famille touche l’éligibilité. Un test peut être configuré pour s’appliquer uniquement à certains pays, devices, sources ou statuts clients. Si ces règles sont évaluées différemment avant et après l’assignation, le split observé peut dériver. Exemple : un utilisateur est assigné à B, mais la variante B charge un composant incompatible avec Safari, provoquant une sortie avant l’enregistrement de l’exposition. Dans les logs d’exposition, B semble recevoir moins de trafic. Dans les logs serveur, l’utilisateur existait pourtant. La définition exacte de l’exposition devient alors déterminante.

La troisième famille concerne le tracking. Un événement de page vue, d’impression de test ou de conversion peut ne pas se déclencher de façon symétrique. Un tag analytics peut être bloqué par consentement, adblocker ou latence. Une variante plus lourde peut retarder le déclenchement d’un événement, et les utilisateurs quittant rapidement la page ne sont alors pas comptés. Dans ce cas, le SRM est aussi un signal UX : la variante n’est peut-être pas seulement moins mesurée, elle est moins chargée, moins visible ou moins stable.

La quatrième famille relève du cache, du CDN et du routage. Un CDN, content delivery network, infrastructure qui distribue les contenus web depuis des serveurs proches des utilisateurs, peut servir une version mise en cache à un groupe non prévu. Un système de feature flag peut être évalué côté serveur alors que l’outil d’A/B testing est évalué côté client. Une application mobile peut conserver une ancienne configuration. Ces décalages créent des populations hybrides, parfois exposées à une variante mais mesurées comme contrôle.

La cinquième famille vient des plateformes média et de l’optimisation algorithmique. En RTB, real-time bidding, mécanisme d’enchères en temps réel permettant d’acheter une impression publicitaire disponible, et via une DSP, demand-side platform, plateforme utilisée par les annonceurs pour acheter des impressions programmatiques, les flux de trafic peuvent changer rapidement. Si un test de landing page renvoie des signaux de conversion différents aux plateformes pendant l’expérience, les algorithmes d’acquisition peuvent réallouer les impressions entre segments, devices ou audiences. Ce phénomène ne crée pas toujours un SRM au sens strict, mais il peut amplifier des déséquilibres d’audience et compliquer l’interprétation.

Diagnostiquer méthodiquement : du test global aux segments incriminés

Un SRM détecté au niveau global ne dit pas encore où se situe le problème. La démarche efficace consiste à descendre progressivement dans les couches de mesure, sans transformer l’analyse en chasse opportuniste aux segments. L’objectif n’est pas de trouver un segment qui raconte une histoire, mais d’identifier le point où la mécanique de répartition diverge.

La première étape est de vérifier les effectifs bruts d’assignation et d’exposition. L’assignation correspond au moment où l’unité expérimentale reçoit une variante. L’exposition correspond au moment où l’utilisateur voit réellement l’expérience ou déclenche l’événement de test. Si l’assignation est équilibrée mais l’exposition ne l’est pas, le problème se situe probablement entre la décision d’assignation et le rendu effectif : chargement, ciblage, compatibilité, consentement, timeout, redirection ou instrumentation. Si l’assignation elle-même est déséquilibrée, il faut inspecter la logique de randomisation et les règles d’éligibilité en amont.

La deuxième étape est de comparer les sources de vérité. Les logs serveur, les logs de l’outil d’expérimentation, l’analytics web, le tag manager et la base de conversion ne racontent pas toujours la même chose. Une bonne enquête SRM aligne ces niveaux : combien d’utilisateurs ont été éligibles, combien ont été assignés, combien ont été exposés, combien ont déclenché une page vue mesurée, combien ont été inclus dans l’analyse finale. Chaque taux de perte entre deux étapes doit être comparé par variante.

La troisième étape est la segmentation diagnostique. Les découpes prioritaires sont généralement le device, le navigateur, le système d’exploitation, le pays, la source de trafic, le statut nouveau ou existant, la page d’entrée, le consentement analytics, l’heure et la version applicative. En e-commerce, il faut souvent ajouter le statut connecté ou anonyme, le type de panier et la présence de promotion. En B2B, il peut être utile de distinguer paid search marque, paid search non-marque, paid social, direct, SEO et emailing, car l’intention et le cycle de conversion varient fortement.

La quatrième étape consiste à analyser la temporalité. Un SRM constant dès le début suggère une erreur de configuration. Un SRM qui apparaît après un déploiement indique un changement de code, de tag ou de ciblage. Un SRM intermittent peut provenir d’un incident de cache, d’un problème de performance, d’une campagne média ou d’une montée de version mobile. Tracer l’écart heure par heure ou jour par jour permet souvent d’isoler le moment exact où la répartition s’est dégradée.

La cinquième étape est de vérifier les exclusions analytiques. Beaucoup de SRM apparaissent après filtrage : suppression des bots, exclusion des utilisateurs sans consentement, retrait des sessions avec erreur, déduplication cross-device, filtrage par pays ou par canal. Si les exclusions ne sont pas symétriques entre variantes, le dataset final peut être biaisé même si l’assignation initiale était saine. Toute règle d’exclusion appliquée après randomisation doit être justifiée et testée par variante.

Exemple chiffré : un faux gain de conversion créé par un problème de consentement

Imaginons un retailer qui teste une nouvelle page produit. Le test est configuré en 50/50 sur 400 000 utilisateurs éligibles. La métrique primaire est l’achat validé par session utilisateur, et les métriques secondaires sont l’ajout panier, le revenu par visiteur et la marge brute par visiteur. Après dix jours, le dashboard affiche 203 600 utilisateurs en contrôle et 196 400 en variante. L’écart paraît modeste : 50,9 % contre 49,1 %. Pourtant, avec un volume de 400 000, il est statistiquement très improbable sous une allocation réellement équilibrée.

Le test business semble favorable. La variante affiche un taux d’achat de 3,08 % contre 2,94 % pour le contrôle, soit un uplift relatif de 4,8 %. Le revenu par visiteur progresse aussi légèrement. L’équipe acquisition envisage de déployer la page et d’augmenter les budgets paid social. Paid social désigne les campagnes publicitaires diffusées sur les plateformes sociales, souvent optimisées par enchères automatiques selon un objectif de conversion. À ce stade, la décision paraît cohérente si l’on ignore le SRM.

L’enquête montre pourtant que l’écart provient principalement des utilisateurs Safari mobile avec consentement analytics refusé. Dans la variante, un composant de preuve sociale charge un script tiers avant le tag d’exposition. Chez certains utilisateurs, le chargement dépasse le seuil de timeout, et l’exposition n’est pas enregistrée. Ces utilisateurs sortent plus vite de la page et sont sous-représentés dans les logs de la variante. Le test ne compare donc plus deux populations équivalentes : il a exclu davantage d’utilisateurs à faible engagement de B que de A.

En réanalysant les logs serveur, l’équipe estime que 7 200 utilisateurs exposés à B n’ont pas été correctement enregistrés. Une fois l’exposition reconstruite et les sessions réintégrées, le taux d’achat de la variante tombe à 2,96 %. L’uplift disparaît. Le revenu par visiteur redevient équivalent, et la marge brute par visiteur baisse légèrement en raison d’un mix produit moins favorable. Le SRM n’était pas une alerte secondaire ; il était le signal qui empêchait de déployer une illusion.

Ce cas illustre une règle essentielle : plus la variante modifie le chargement, le tracking ou la structure de page, plus le SRM doit être surveillé tôt. Les tests de copy légère présentent moins de risque technique. Les tests de checkout, de personnalisation, de recommandation produit, de prix, de disponibilité stock ou de scripts tiers exposent davantage la mesure à des divergences d’exécution. Le niveau de QA, quality assurance, processus de vérification avant mise en ligne, doit être proportionné au risque de biais.

Que faire lorsqu’un SRM est détecté : suspendre, corriger ou interpréter avec restrictions

La réaction à un SRM ne doit pas être automatique, mais elle doit être disciplinée. La pire réponse consiste à l’ignorer parce que le résultat business est attractif. Une organisation qui accepte un gagnant avec SRM crée une dette de confiance : les prochains arbitrages seront discutés sur des bases fragiles, et les effets post-déploiement risquent de ne pas se matérialiser.

La première option est la suspension immédiate. Elle est recommandée lorsque l’écart est important, inexpliqué, présent tôt dans l’expérience ou susceptible d’être corrélé à la conversion. Suspendre ne signifie pas abandonner l’hypothèse. Cela signifie arrêter de collecter des données potentiellement contaminées. L’équipe peut ensuite corriger l’implémentation, relancer un test propre et documenter l’incident.

La deuxième option est la correction technique suivie d’un redémarrage. Dans la plupart des cas, il faut redémarrer plutôt que poursuivre. Les données collectées avant correction appartiennent à un régime expérimental différent. Les mélanger avec les données post-correction peut masquer le problème. Si l’on conserve les deux périodes, elles doivent être analysées séparément, avec une justification explicite. Pour un test à fort enjeu, comme une modification de pricing ou de checkout, le redémarrage est généralement la décision la plus robuste.

La troisième option est l’interprétation restreinte. Elle peut être acceptable si la cause du SRM est identifiée, isolée et indépendante de la métrique primaire. Exemple : un déséquilibre vient d’un ancien navigateur représentant 0,4 % du trafic, non éligible au parcours de conversion analysé, et correctement exclu des deux groupes après diagnostic. Dans ce cas, l’équipe peut documenter l’exclusion et poursuivre l’analyse sur le périmètre sain. Mais cette approche exige une preuve solide, pas une hypothèse confortable.

La quatrième option est la reconstruction analytique. Elle consiste à utiliser des logs plus fiables pour reconstituer l’assignation ou l’exposition. Cette méthode peut sauver certaines analyses, mais elle est risquée. Elle suppose que la source alternative soit exhaustive, que les règles de déduplication soient maîtrisées et que la reconstruction ne crée pas de nouveaux biais. En pratique, elle est surtout utile pour comprendre l’incident, moins pour déclarer un gagnant définitif.

Dans tous les cas, la décision doit être consignée dans un registre d’expérimentation. Le registre doit indiquer le niveau de SRM, la date d’apparition, les segments touchés, la cause probable, les actions prises, le statut des données et la décision finale. Un SRM non documenté se reproduit. Un SRM documenté devient un apprentissage technique et organisationnel.

Prévenir le SRM : intégrer le contrôle dans la gouvernance d’expérimentation

La prévention commence avant le lancement. Une fiche de test sérieuse doit préciser l’unité de randomisation, le split attendu, les règles d’éligibilité, le moment d’assignation, le moment d’exposition, les événements de tracking, les exclusions prévues, les segments critiques et les seuils d’alerte SRM. Sans cette définition, l’équipe découvre trop tard qu’elle ne sait pas quelle population elle était censée comparer.

Le contrôle SRM doit être automatisé. Pour les tests à fort volume, une alerte peut être déclenchée après un minimum d’observations, par exemple 5 000 ou 10 000 utilisateurs, puis réévaluée régulièrement. Lire le SRM trop tôt peut produire du bruit ; le lire trop tard gaspille du trafic. La bonne fréquence dépend du risque technique et du volume. Sur un checkout avec plusieurs centaines de milliers de sessions hebdomadaires, un contrôle quotidien est justifié. Sur une landing page B2B à faible volume, un contrôle après paliers peut suffire.

La QA doit couvrir les cas qui génèrent le plus souvent des déséquilibres : navigateurs majeurs, mobile et desktop, utilisateurs connectés et anonymes, consentement accepté et refusé, sources paid et organiques, pages d’entrée principales, états de panier, devises, pays et versions applicatives. Il faut vérifier non seulement que la variante s’affiche, mais aussi que l’assignation persiste, que l’événement d’exposition se déclenche, que les conversions remontent et que les exclusions analytiques sont identiques.

La gouvernance doit aussi clarifier les responsabilités. L’équipe CRO définit le protocole et les critères d’arrêt. L’équipe data valide les contrôles statistiques et la cohérence des logs. L’équipe produit ou tech garantit l’exécution. L’acquisition informe des changements de budget, de campagne ou de ciblage susceptibles de modifier le mix trafic. La finance peut être impliquée lorsque la métrique primaire touche à la marge, à la LTV, lifetime value, valeur économique attendue d’un client sur toute sa relation avec l’entreprise, ou au revenu net.

Enfin, le SRM doit être intégré aux post-mortems, y compris lorsque le test est concluant. Une expérience peut réussir statistiquement et révéler un léger déséquilibre explicable. L’analyser permet d’améliorer les prochains protocoles. Les organisations qui ne regardent le SRM qu’en cas de crise se privent d’un indicateur de santé de leur stack d’expérimentation.

Conclusion : aucun uplift ne compense une comparaison mal construite

Le SRM est l’un des diagnostics les plus simples à calculer et l’un des plus souvent sous-estimés. Il ne dit pas quelle variante gagne. Il dit si l’expérience mérite d’être interprétée. Pour des professionnels du marketing habitués à arbitrer entre CPA, ROAS, taux de conversion, marge et vélocité de testing, cette distinction est essentielle. Un uplift calculé sur des groupes biaisés n’est pas un signal de performance ; c’est une mesure contaminée.

Une méthode actionnable peut tenir en huit étapes. Premièrement, définir avant le lancement le split attendu, l’unité de randomisation et les règles d’éligibilité. Deuxièmement, mesurer séparément assignation, exposition et inclusion analytique. Troisièmement, automatiser un test SRM avec un seuil d’alerte adapté au volume, souvent plus strict que les seuils business. Quatrièmement, diagnostiquer les écarts par source de vérité : outil d’expérimentation, logs serveur, analytics, tag manager et base de conversion. Cinquièmement, segmenter l’enquête par device, navigateur, source, pays, statut client, consentement, page d’entrée et temporalité. Sixièmement, suspendre ou redémarrer le test lorsque la cause est inconnue ou corrélée au comportement. Septièmement, ne restreindre l’analyse que si le périmètre sain est clairement établi et documenté. Huitièmement, consigner chaque incident dans un registre pour renforcer la gouvernance expérimentale.

Le principe stratégique est simple : avant d’optimiser la conversion, il faut protéger la comparaison. Les tests A/B ne créent de valeur que s’ils produisent des décisions fiables. Dans un environnement où le trafic coûte plus cher, où les plateformes média optimisent en temps réel et où l’attribution devient plus fragile, ignorer un SRM revient à piloter avec une donnée dont la structure même est suspecte. La discipline n’est pas de rejeter tous les tests imparfaits, mais de savoir quand l’imperfection invalide la preuve. Sur ce point, le SRM est un garde-fou indispensable : il rappelle que la qualité d’un résultat commence par la qualité de la répartition qui l’a rendu possible.