Diagnostiquez une incohérence du ratio d'échantillonnage dans cinq branches avant de jeter le test.

Environ 6 % des expériences menées chez Microsoft présentent une inadéquation du ratio d'échantillonnage, ce qui, pour un produit exécutant 10 000 expériences par an, correspond à environ une détection par jour (Fabijan et al., KDD 2019Les équipes effectuant beaucoup moins de tests voient rarement ce chiffre, car le contrôle effectué par leur plateforme ne peut pas atteindre une significativité statistique compte tenu de leur volume de trafic. Le test semble correct, signale une augmentation de 4 %, et est de toute façon erroné.

Ce guide s'adresse à la personne chargée d'interpréter les résultats d'expérience et de décider de l'opportunité de procéder à l'expédition. À la fin de ce guide, vous serez capable de déterminer si votre test est suffisamment vaste pour que la vérification des discordances soit pertinente, d'exécuter cinq branches de diagnostic dans l'ordre d'identification de la cause le plus rapide, et de distinguer un déséquilibre invalidant les résultats d'un déséquilibre pouvant être isolé et conservé.

Que vous indique réellement une alarme SRM ?

Un écart dans le ratio d'échantillonnage correspond à une différence entre la répartition que vous avez configurée et celle que vous avez observée : vous avez défini 50/50 et obtenu 50.8/49.2. La vérification standard consiste en un test d'adéquation du chi carré de Pearson sur les nombres d'exposition, avec un degré de liberté pour un test à deux bras.

C'est important car le mécanisme de perte d'utilisateurs est presque toujours influencé par votre indicateur. Si une redirection supprime les connexions lentes de la variante, les utilisateurs restants bénéficient de meilleures connexions et convertissent mieux. L'amélioration est visible dans les données, mais inexistante dans la réalité.

Voici la première erreur que la plupart des équipes commettent : il n’existe pas de seuil standardisé pour l’ensemble du secteur. Les différences entre les plateformes sont considérables.

Deux conséquences. Un test signalé sur une plateforme est validé sur une autre avec des données identiques ; par conséquent, l’absence d’alerte de notre outil ne constitue pas une preuve de séparation nette. De plus, un seuil de 0.01 signale un test valide sur cent. Si l’on évalue visuellement la p-valeur quotidiennement sur une période de trois semaines, la limite supérieure d’une fausse alerte, calculée par une approche indépendante, est de 19 %. Le chiffre réel est inférieur en raison de la forte corrélation entre les jours consécutifs, mais il n’est pas de 1 %. C’est pourquoi AB Tasty utilise une procédure séquentielle. Si votre plateforme effectue un test du chi carré à horizon fixe, examinez les résultats cumulés une seule fois, à la fin.

Vérifiez si votre test peut détecter un déséquilibre.

Pour une répartition 50/50, la statistique du chi carré se simplifie à 4n(p̂−0.5)², où n représente le nombre total d'expositions. En l'inversant, on obtient le plus petit déséquilibre que votre contrôle peut détecter :

Il faut le considérer comme une limite, et non comme une autorisation. Avec 10 000 expositions, tout déséquilibre inférieur à 1.3 point est imperceptible au contrôle, et un effet de sélection de 1.3 point suffit amplement à générer une légère hausse du taux de conversion. C’est là le problème structurel qui touche la majeure partie de la région. La Turquie a enregistré environ 6 milliards de transactions de commerce électronique, réparties entre quelque 634 000 entreprises, en 2025 (Ministère du Commerce, 12 mai 2026), soit en moyenne près de 9 500 par an, et cette moyenne est fortement influencée par quelques plateformes de vente en ligne. Une boutique de taille moyenne qui teste une étape de paiement effectue des tests avec des dizaines de milliers d'expositions, et non des millions ; son contrôle SRM détecte donc les erreurs grossières, mais rien de plus subtil.

À ce volume, ne vous fiez pas à l'alarme. Extrayez vous-même les données brutes d'exposition par jour et par segment, et considérez toute dérive persistante dans la même direction comme suspecte, même si la valeur p est normale. Si vous ne savez pas où votre plateforme expose ces données, Documentation du vérificateur SRM les cartographie par outil.

Les cinq branches, dans l'ordre qui trouve la cause le plus rapidement

La taxonomie KDD classe les causes SRM par étape de leur cycle de vie : affectation, exécution, traitement des journaux, analyse, interférence. Il est préférable de les diagnostiquer dans un ordre différent, en commençant par les moins coûteuses et les plus fréquentes.

1. Analyse et déclenchement. Symptôme : la séparation est nette dans le journal d’exposition brut, mais erronée dans le tableau de bord. Vérification : recalculez le ratio sans votre condition de déclenchement, votre filtre de date ni les jointures au niveau des métriques. Confirmez le résultat si le ratio revient à la valeur attendue. Solution : évaluez le déclenchement de manière identique dans les deux bras, avant que tout comportement spécifique à une variante ne puisse modifier l’éligibilité. Fausse alerte très fréquente ; dix minutes suffisent pour l’éliminer.
2. Traitement des journaux. Symptôme : le nombre d’expositions diffère entre deux pipelines, ou l’écart apparaît après l’étape ETL. Vérification : comparer le nombre côté SDK, le nombre dans l’entrepôt de données et le nombre généré par le rapport pour la même période, puis comparer les taux d’exclusion du filtre anti-bots par bras. Confirmer le problème si les bras sont égaux en amont et inégaux en aval. Solution : filtrer de manière déterministe et identique. Le trafic automatisé a atteint 53 % du trafic web en 2026, contre 51 % en 2024 (Rapport Imperva sur les bots malveillants, 29 avril 2026Ainsi, un filtre heuristique basé sur le temps de chargement ou le comportement de l'agent utilisateur peut exclure à des taux différents selon la variante. La perte liée au consentement se situe également ici : lorsque ad_storage si le refus est refusé, la plateforme de balises de Google cesse de déposer des cookies publicitaires (Documents de consentement de la plateforme Google Tag), donc si les taux de refus diffèrent selon les zones géographiques dans un test, toute attribution s'appuyant sur ces identifiants perd des utilisateurs de manière inégale.
3. Exécution. Symptôme : le déséquilibre s’accentue avec le poids de la page, est plus marqué sur mobile ou apparaît dès le déploiement. Vérification : segmentez le ratio par appareil, navigateur, type de connexion et jour ; comparez le temps d’exposition entre les différentes versions. Confirmez le problème si le déficit se concentre sur les segments lents ou sur un navigateur en particulier. Solution : c’est là que les tests de redirection échouent. Une redirection ajoute une navigation complète à une seule version, et chaque utilisateur qui abandonne sa page pendant cette redirection représente une perte sélective. Affichez les deux versions côté serveur sur une seule URL, ou acceptez que les versions ne soient pas comparables.
4. Affectation. Symptôme : le ratio est déséquilibré dès la première heure et l’écart reste constant. Vérification : effectuez une analyse A/A sur la même allocation et vérifiez que le sel de hachage n’a pas été réutilisé d’une expérience précédente sur cette population. Cela confirme le problème si l’analyse A/A révèle également le déséquilibre. Solution : réaffectez avec un sel neuf et redémarrez. La version silencieuse de ce problème, héritée d’un test précédent, est mise en évidence uniquement par l’analyse A/A.
5. Ingérence. Symptôme : le déséquilibre est concentré sur un petit nombre d’identifiants à forte activité ou sur des plages d’adresses IP internes. Vérification : la distribution du nombre d’expositions par utilisateur et le 1 % des identifiants présentant le plus grand volume d’événements. Confirmer le diagnostic en vérifiant si leur suppression rétablit le ratio. Solution : exclure le trafic interne et le trafic scripté à l’aide d’une règle documentée, et non manuellement, afin que l’exclusion soit identique la prochaine fois.

Une visite guidée fonctionnelle

Les chiffres ci-dessous sont donnés à titre indicatif et ne représentent pas des données client. Un test de validation indique 61 480 expositions pour le contrôle et 58 520 pour la variante : 51.2/48.8 sur 120 000 utilisateurs, p du test du χ² inférieur à 0.001. Branche 1 : la suppression de la condition de déclenchement donne 60 020/59 980, l’attribution est donc correcte et la perte survient après l’exposition. Branche 2 : les comptages du pipeline concordent, avec exclusions de bots de 0.9 % dans les deux branches. Branche 3 : sur ordinateur, on observe 50.1/49.9, sur mobile, 52.4/47.6, et le temps médian d’exposition de la variante est supérieur de 900 ms sur mobile. Diagnostic : la variante génère une requête supplémentaire bloquant le rendu ; les utilisateurs mobiles abandonnent la partie pendant ce temps, tandis que les utilisateurs restants bénéficient d’une meilleure connexion. Le résultat est invalide. La correction vise à améliorer les performances, et le test est relancé, mais non réinterprété.

Ce que vous pouvez sauver et ce que vous ne pouvez pas

• Annuler la lecture lorsque le mécanisme de perte pourrait plausiblement être corrélé à la métrique. Toute cause d'exécution et d'affectation remplit les conditions par défaut.
• Récupération par segment Ce n'est valable que si le déséquilibre est limité à un segment que vous pouvez exclure sans difficulté, que ce segment a été défini avant que vous ne consultiez la métrique, et que le reste réussit son propre contrôle SRM. Deux de ces trois conditions ne suffisent pas.
• Conservez le test Lorsque le problème résidait uniquement dans l'analyse et que le tableau de bord corrigé est validé, vous relisez les mêmes données avec un filtre fixe, vous ne faites pas de pêche aux données.
• Consignez-le dans les deux cas. Consignez la catégorie de cause de l'expérience. La taxonomie porte ses fruits de manière cumulative : si trois de vos dix derniers tests ont échoué dans la branche 3, le problème ne vient pas de l'expérimentation, mais du déploiement front-end. [DONNÉES INTERNES NÉCESSAIRES : part des expériences exécutées par Switas au cours des 24 derniers mois ayant échoué à un contrôle SRM, ventilée par branche de taxonomie, afin de remplacer le seuil de 6 % de Microsoft par un chiffre issu de ce marché.]

Là où cela dysfonctionne

Cet arbre de décision suppose un essai à deux bras avec une répartition fixe et connue et une randomisation au niveau de l'utilisateur. Il ne couvre pas les essais à plusieurs bras, qui nécessitent un test du χ² complet sur tous les bras, ainsi qu'un suivi pour identifier la paire défaillante, ni les répartitions progressives, où le ratio attendu évolue au cours de l'essai et où un test du χ² cumulatif est tout simplement inapproprié. Il ne s'applique pas aux plans d'étude randomisés par grappes ou géographiquement, où l'unité n'est pas l'utilisateur et où le déséquilibre pertinent réside dans les caractéristiques des grappes. Il ne se prononce pas sur la pertinence de votre définition de la métrique. Enfin, il est inutile lorsque les expositions ne sont pas enregistrées et que vous inférez l'affectation à partir d'un événement de la métrique, ce qui constitue une supposition et non une vérification par division.

QFP

Une répartition 51/49 pose-t-elle toujours problème ? Cela dépend entièrement de n. À 5 000 expositions, il s'agit d'un bruit ordinaire ; à 500 000, c'est un défaut quasi certain. Évaluez le rapport à l'aide du tableau de détectabilité, et non selon une règle empirique de pourcentage fixe.

Puis-je simplement repondérer les bras statistiquement au lieu de relancer l'exécution ? Non. La pondération corrige les comptages sans modifier la sélection. Les utilisateurs perdus sont définitivement supprimés, et ils ne constituaient pas un échantillon aléatoire du groupe.

À quelle fréquence dois-je consulter la valeur p du SRM ? Une seule fois, à la fin, sur les décomptes cumulés, sauf si votre plateforme exécute une procédure séquentielle. Consulter quotidiennement un test du chi carré à horizon fixe augmente considérablement le nombre de fausses alertes.

Est-ce que SRM invalide également les indicateurs de sécurité ? Oui, pour la même raison. Si les zones concernées regroupent des populations différentes, une ligne de défense fixe n'est pas plus fiable qu'une mesure primaire mobile.

Que se passe-t-il si un test A/A révèle également une incompatibilité ? Le problème se situe donc au niveau de l'affectation des tâches ou du processus de journalisation, et non dans votre traitement. Corrigez-le avant toute autre exécution, car il affecte tous les tests sur cette plateforme.

Les tests de redirection provoquent-ils toujours des SRM ? Pas toujours, mais elles présentent un risque structurel unique, car la navigation supplémentaire est concentrée sur un seul bras. Si vous devez absolument en utiliser une, vérifiez le rapport entre la vitesse de connexion et l'appareil avant d'interpréter les données.

Mon trafic est trop faible pour que le chèque ait une quelconque importance. Que faire alors ? Surveillez les données brutes d'exposition quotidienne pour détecter toute dérive persistante, effectuez une analyse d'autorisation périodique sur la couche d'attribution et préenregistrez une liste plus exhaustive de contrôles de cohérence. Vous privilégiez la méthode à la puissance statistique.

Le filtrage des bots doit-il avoir lieu avant ou après l'attribution des tâches ? Après l'enregistrement de l'exposition, avant l'analyse, des règles déterministes sont appliquées de manière identique aux deux bras. Le filtrage heuristique au sein du SDK est à l'origine de l'inadéquation du filtre lui-même.

Effectuez la vérification sur votre propre programme expérimental

Si vous souhaitez un second avis sur l'état de santé des tests que vous exécutez actuellement, ou une analyse de la couche d'affectation et de journalisation dont ils dépendent, c'est précisément ce que notre CRO et service d'expérimentation t.

Références

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, « Diagnostic des inadéquations de ratio d'échantillons dans les expériences contrôlées en ligne : une taxonomie et des règles empiriques pour les praticiens », KDD 2019
• Documentation AB Tasty, inadéquation du ratio d'échantillons (S-SRM séquentiel, seuil 0.01)
• Statsig, « Guide rapide sur les différences de proportion d'échantillons », 31 août 2023 (chi-carré, seuil 0.01)
• Documentation GrowthBook, Expérimentation (chi-carré, avertissement en dessous de 0.001)
• Imperva, « Rapport sur les mauvais bots 2026 : Les bots à l’ère de l’agentique », 29 avril 2026
• République de Turquie, Ministère du Commerce, Statistiques du commerce électronique 2025, 12 mai 2026
• Plateforme de balises Google, mode de consentement et comportement de stockage
• Documentation et FAQ de SRM Checker, Lukas Vermeer