Sample Ratio Mismatch (SRM) : un guide complet avec des solutions aux cas des clients

Quoi de pire qu'un test raté ?

Problèmes de qualité des données de test qui rendent les résultats des tests peu fiables.

Mais comment éviter les mauvaises données ?

La vérification de l'inadéquation du rapport d'échantillonnage (SRM) est un moyen simple de détecter rapidement les problèmes potentiels. Si quelque chose est louche, plus tôt vous le découvrirez, mieux ce sera.

Poursuivez votre lecture pour en savoir plus sur l'inadéquation du ratio d'échantillonnage, comment la repérer, comment elle affecte vos tests et quelles plates-formes de test A/B sont livrées avec des vérifications SRM intégrées (vous n'avez donc pas besoin de garder une feuille de calcul sur le côté) .

Qu'est-ce que l'inadéquation du rapport d'échantillonnage (SRM) ?

L'inadéquation du ratio d'échantillons, ou SRM, se produit dans les tests A/B lorsque le nombre réel d'échantillons (ou de visiteurs dans un groupe de traitement) ne correspond pas à ce qui était attendu.

Illustrons cela par un exemple.

Disons qu'un site Web reçoit environ 15 000 visiteurs par semaine. Nous avons 3 variantes, l'original (qui est la page inchangée), et 2 variantes. Quelle quantité de trafic attendez-vous que chacun reçoive si le trafic est réparti de manière égale ? Dans un monde idéal, la réponse serait que chaque variation devrait recevoir 15 000 / 3 = 5 000 visiteurs.

Maintenant, il est très peu probable que chaque variation reçoive réellement 5000 visiteurs, mais un nombre très proche, comme 4982, ou 5021. Cette légère variation est normale et est due au simple hasard ! Mais si l'une des variantes devait recevoir 3500 visiteurs et les autres environ 5000, alors quelque chose ne va pas avec celle-là !

Plutôt que de se fier à notre propre intuition pour repérer ces problèmes, nous pouvons plutôt opter pour le test SRM. Il utilise le test d'adéquation du chi carré pour nous dire, par exemple, si 4850 ou 4750 visiteurs, par rapport à l'autre nombre de visiteurs reçus, sont « normaux » ou non !

En termes statistiques, le test d'adéquation du chi carré compare le nombre d'échantillons observés à ceux attendus. Et s'il y a une réelle différence, la p-value sera inférieure au seuil de signification fixé à 0,01, ce qui correspond à une confiance de 99 %.

Votre test A/B a-t-il un SRM ? Comment calculer l'inadéquation du rapport d'échantillonnage ?

Dans les tests A/B, SRM peut être un véritable boogeyman, provoquant des résultats inexacts et des conclusions erronées. La bonne nouvelle est qu'il existe des outils qui peuvent vous aider à éviter les maux de tête.

Utiliser des feuilles de calcul

Les feuilles de calcul sont la méthode la plus simple pour calculer le SRM en raison de la large disponibilité de Microsoft Excel et/ou des produits Google.

Montrons un autre exemple.

Nous calculerons le SRM pour un test A/B avec une répartition du trafic 50/50 et des nombres observés de visiteurs de 214 598 et 241 156 pour l'original et la variation, respectivement.

Nous utiliserons le test du chi carré pour voir si la répartition du trafic observée correspond à la répartition du trafic attendue. Dans le cas contraire, vous voudrez savoir si les valeurs observées diffèrent suffisamment des valeurs attendues pour susciter des inquiétudes et justifier l'abandon des résultats.

Vous devrez utiliser la fonction CHISQ.TEST dans votre feuille de calcul pour calculer la valeur p, comme illustré dans la feuille de calcul ci-dessous.

Dans notre exemple, la valeur p est 0. Avec une valeur p inférieure à 0,05, vous avez un SRM entre les mains et suffisamment de preuves pour rejeter les résultats du test dans la plupart des cas.

Utilisation des calculateurs en ligne d'inadéquation des taux d'échantillonnage

1. La calculatrice de Convert peut vous aider à diagnostiquer l'inadéquation du rapport d'échantillonnage et vous indique également combien de temps vous devez attendre pour que votre expérience soit terminée !
   

   

2. Un autre calculateur en ligne spécifique au SRM est celui conçu par Lukas Vermeer. Cette méthode calcule le SRM de la même manière que la technique précédente, donc si vous avez suivi et compris le processus, vous devriez pouvoir utiliser ce calculateur SRM en ligne. Remplissez simplement les chiffres de vos échantillons et le résultat apparaîtra comme ceci
   

   

Comment SRM affecte-t-il les tests A/B ?

Il est probable que vous ayez examiné la répartition du trafic entre les variantes au cours d'un test et que vous vous soyez interrogé sur sa précision.

Peut-être un ressemblant au rapport ci-dessous. Vous pourriez le regarder et vous demander s'il est normal que l'Original ait eu 1330 visiteurs mais que la Variation 1713.

Un court calcul statistique du ratio SRM (utilisant l'une des deux méthodes ci-dessus) vous dira si le ratio de variation est acceptable ou non.

La répartition réelle entre les deux variations (Original et Variation 1) correspond-elle aux valeurs attendues ? Si ce n'est pas le cas, vous devez rejeter les données et relancer le test lorsque vous avez résolu le problème.

Le SRM affecte-t-il à la fois les modèles statistiques fréquentistes et bayésiens ?

Oui.

Les causes de SRM ont un impact identique sur la validité des résultats d'une expérience que les données soient analysées avec des approches bayésiennes (Google Optimize, Optimizely, VWO, A/B Tasty) ou fréquentistes (Convert Experiences, Dynamic Yield).

Ainsi, les calculateurs SRM ci-dessus peuvent également être utilisés pour vérifier le SRM sur les plates-formes qui utilisent des statistiques bayésiennes.

Quand devez-vous prendre en compte le SRM ?

Trouver une non-concordance de ratio d'échantillon dans vos tests ne signifie pas nécessairement que vous devez rejeter les résultats.

Alors, quand est-il vraiment nécessaire de prendre au sérieux le calcul SRM ?

Découvrons-le avec quelques exemples.

Exemple 1

Vous exécutez un test dans lequel 50 % des utilisateurs sont attribués à l'original et à la variante. Vous vous attendez donc à voir un nombre à peu près égal d'utilisateurs dans chacun.

Les résultats reviennent comme

• Contrôle : 21 588 utilisateurs
• Traitement : 15 482 utilisateurs

Passons-les au vérificateur SRM :

Est-ce une source d'inquiétude ?

La valeur de p pour le ratio d'échantillon ci-dessus est < 0,0001, donc la probabilité de voir ce ratio ou un ratio plus extrême, sous un plan qui exigeait des proportions égales, est < 0,0001 !

Vous devez absolument vous inquiéter que quelque chose ne va pas , car vous venez d'observer un événement extrêmement improbable. Il est donc plus probable qu'il y ait un bogue dans la mise en œuvre de l'expérience et vous ne devez faire confiance à aucun des résultats.

Exemple #2

Vous exécutez un autre test, où l'original et la variante se voient attribuer un pourcentage égal d'utilisateurs. Vous calculez la valeur p, et elle est <0,002, donc un événement très improbable.

Dans quelle mesure les mesures pourraient-elles être différentes ? Devez-vous vraiment rejeter les résultats ?

En utilisant une plate-forme d'expérimentation comme Convert Experiences, vous pouvez appliquer une segmentation post-test aux résultats et découvrir que si vous excluez les utilisateurs d'Internet Explorer, le SRM a disparu.

Dans ce cas, les utilisateurs exclus utilisent très probablement un ancien navigateur IE, qui était à l'origine du SRM ; un bot n'a pas été correctement classé en raison de certains changements dans la variation, ce qui a entraîné une inadéquation du ratio.

Sans le segment, le pourcentage d'utilisateurs restant est correctement équilibré et les statistiques semblent normales.

Si le SRM n'avait pas été découvert, toute l'expérience aurait été considérée comme un échec majeur.

Mais une fois que le SRM a été repéré, un petit segment a pu être retiré et l'expérience utilisée pour une analyse appropriée.

Dans un scénario similaire, vous pouvez ignorer en toute sécurité les utilisateurs exclus et le test peut être utilisé .

Exemple #3

Vous exécutez une expérience et vous découvrez qu'il y a SRM étiqueté sur votre test.

Cependant, si vous faites attention à vos graphiques, vous remarquerez que les courbes de taux de conversion restent parallèles et que la confiance calculée est de 99,99 %. Ce modèle devrait vous fournir une certitude suffisante que les tests sont valides.

Dans ce cas, vous pouvez ignorer le SRM en toute sécurité et continuer à faire confiance à vos données .

Où devriez-vous vérifier si SRM existe ?

Il y a quelques domaines où le SRM peut se produire. Jetons un coup d'œil à la taxonomie des causes de Lukas Vermeer :

1. Affectation d'expérience – Il peut y avoir un cas de regroupement incorrect (les utilisateurs sont placés dans des clusters incorrects), une fonction de randomisation défectueuse ou des ID utilisateur corrompus.
2. Exécution de l'expérience - Les variations peuvent avoir commencé à des moments différents (provoquant des écarts), ou il peut y avoir des retards d'exécution du filtre (déterminant quels groupes sont soumis à l'expérience).
3. Traitement du journal d'expérimentation - Des bots automatiques supprimant les utilisateurs réels, un retard dans l'arrivée des informations dans les journaux.
4. Analyse expérimentale - Mauvais déclenchement de la variation ou démarrage incorrect.
5. Interférence de l'expérience – L'expérience peut faire l'objet d'attaques et de piratages, ou les impacts d'une autre expérience en cours peuvent interférer avec l'expérience en cours.

Si vous avez un SRM et que vous ne savez pas où chercher une réponse, la taxonomie ci-dessus est un bon point de départ.

Et pour clarifier les choses, nous allons maintenant vous donner un exemple concret pour chacun de ces cas.

Affectation d'expérience

C'est là que l'une des choses les plus intéressantes à surveiller est la fonction de randomisation utilisée par votre plateforme de test A/B.

Dans l'exemple ci-dessous, les scientifiques des données de Wish ont découvert des problèmes de SRM lors d'un test A/A et, après une longue enquête, ont conclu que le SRM était dû au fait que leur randomisation n'était pas complètement aléatoire.

Pour obtenir des résultats d'expérience valides, la procédure de randomisation est cruciale.

Une hypothèse cruciale des tests statistiques utilisés dans les tests A/B est l'utilisation d'échantillons aléatoires. Entre les compartiments d'expérience, la randomisation équilibre les attributs utilisateur observés et non observés, établissant une relation causale entre la fonctionnalité du produit testé et toute différence de résultat dans les résultats de l'essai.

Exécution de l'expérience

En ce qui concerne l'exécution des expériences, deux raisons principales peuvent entraîner la SRM dans vos expériences.

1. Le script n'est pas installé correctement sur l'une des variantes

Vérifiez toujours si le script de votre plateforme de test A/B est correctement installé sur l'Original et les Variations.

Notre équipe de support client a récemment résolu un cas où le script Convert n'a pas été ajouté sur l'une des variantes, provoquant un SRM sur le test.

Assurez-vous d'ajouter le script sur toutes les pages où vous souhaitez que l'expérience s'exécute, comme indiqué ci-dessous :

2. Le ciblage de la page est mal configuré

Dans ce cas, l'incompatibilité SRM est due au fait que le ciblage du test a été configuré de manière incorrecte.

Avec la mauvaise configuration, certains visiteurs sont sélectionnés pour être redirigés vers la variante, mais la redirection échoue, probablement parce que l'expression d'URL d'origine ne correspond pas à toutes les URL de tous les visiteurs inclus dans le test et redirigés.

Pour éviter cela, reconfigurez les expressions d'URL de variation du test et relancez le test.

Voici deux autres scénarios vous montrant comment configurer le ciblage de votre page avec Convert Experiences pour éviter le SRM sur les tests d'URL fractionnée.

Scénario 1 : ciblez uniquement la page d'accueil (https://www.convert.com) avec l'URL fractionnée et transmettez tous les paramètres de requête que les visiteurs pourraient avoir

Ici, dans la zone du site, l'URL de la page doit correspondre exactement à https://www.convert.com. Dans la section d'exclusion, la chaîne de requête doit contenir v1=true afin d'éviter toute redirection (car les conditions de l'expérience correspondront toujours si vous vous retrouvez sur https://www.convert.com ?v1=true et que le trafic la distribution pourrait finir par être inégale).

Ensuite, lorsque vous définissez vos variantes, conservez-les comme ceci :

Scénario 2 : Cibler toutes les pages, pas seulement la page d'accueil (https://www.convert.com), avec les paramètres d'URL fractionnée et de requête de transmission

Ici, vous devez définir votre zone de site avec une "URL de page" contenant https://www.convert.com . Dans la section d'exclusion, la requête doit contenir v1=true.

Lors de la définition des variantes, utilisez la recette regex ci-dessous pour attraper tous les pag :

Traitement du journal des expériences

Ici, comme raison principale des SRM, nous identifions les bots qui peuvent cibler votre expérience. Vous pouvez nous contacter pour vérifier les journaux supplémentaires que nous conservons si nous pouvons trouver des modèles inhabituels sur les agents utilisateurs.

Par exemple, notre équipe de support a aidé un client dont le test avait SRM.

Dans leur cas, lorsque nous avons filtré le rapport par Browser=Other , nous avons constaté une répartition et un SRM inégaux. Mais lorsque nous avons filtré le même rapport par Browser=Chrome+Safari , aucun SRM n'a été détecté, et aucune distribution inégale.

Nous avons donc vérifié quelques événements pour lesquels le navigateur était défini sur Autre, et tous affichaient un agent utilisateur de "site24x7". Nous avons immédiatement su qu'il s'agissait d'une sorte de logiciel de surveillance, ce qui est une chance puisqu'il s'agit de publicité et qu'il utilise un agent utilisateur distinct. Si cela avait été caché derrière un agent utilisateur habituel, il aurait été impossible de le trouver.

Pour résoudre le problème, nous sommes allés de l'avant et avons ajouté cet agent utilisateur à la liste des bots que nous excluons du trafic. Malheureusement, ce changement peut avoir un impact sur les données futures, après le moment où nous ajoutons le bot à la liste, mais au moins il a été trouvé et corrigé.

Analyse de l'expérience

Cette catégorie concerne principalement les expériences définies avec un déclenchement manuel.

Cela se produit par exemple sur les applications à page unique où vous devez vous occuper vous-même du déclenchement.

Ainsi, chaque fois que vous devez le faire manuellement en utilisant un code similaire à celui ci-dessous, portez une attention particulière aux SRM potentiels de votre test.

 fenêtre._conv_q = _conv_q || [] ;
window._conv_q.push(["run","true"]);

Expérimenter l'interférence

Il s'agit d'une intervention de l'utilisateur où l'une des variantes est mise en pause pendant l'expérience. Imaginez que vous ayez un test d'URL fractionnée en cours d'exécution pendant quelques semaines et que, par erreur ou exprès, vous suspendiez la variante et ne laissiez que l'original en cours d'exécution.

Immédiatement après, et en fonction du trafic de votre site Web, vous remarquerez le SRM calculé pour votre test.

Dans ce cas, vous pouvez soit exclure la plage de dates où la variation a été mise en pause, soit réinitialiser les données d'expérience.

Raisons non expérimentales

Si aucune des catégories ci-dessus ne révèle la cause profonde de votre SRM, nous vous suggérons d'ajouter un logiciel de suivi des erreurs sur votre site Web (comme Sentry) pour identifier les problèmes plus profonds avec votre site.

Plateformes de test A/B prenant en charge les alertes SRM

Vous vous demandez peut-être quelles plateformes de test A/B prennent en charge cette fonctionnalité SRM et vous donnent des alertes sans que vous ayez à la calculer par vous-même.

Nous avons fait la recherche et compilé une liste d'outils.

Convertir les expériences

Depuis décembre 2021, nous avons introduit notre propre méthode SRM.

Si vous êtes un utilisateur, vous pouvez activer les vérifications SRM à partir de Configuration du projet > Plus de paramètres.

Ensuite, vous pourrez voir les balises SRM dans les rapports :

De façon optimale

A ouvert de manière optimale une solution de test séquentiel en septembre 2021 que tout le monde peut mettre en œuvre pour détecter les SRM.

Optimizely a transformé le test ssrm en un microservice backend prêt pour la production qui peut s'exécuter sur toutes les expériences en cours en même temps.

Sur la page de résultats d'Optimizely, vous pouvez configurer des alertes et obtenir les résultats en temps réel du test ssrm :

Michael Lindon, statisticien du personnel d'Optimizely, déclare que le SRM est un problème typique qui survient lorsque les tests sont mal effectués.

Pour exécuter une expérience de produit, une quantité importante d'infrastructure est nécessaire, il peut donc y avoir des erreurs. Par exemple, si les visiteurs du site Web ne sont pas systématiquement répartis dans une variante de test et convertis à la fois dans les conditions d'origine et de variation, les données obtenues pour cet utilisateur ne sont pas valides pour évaluer l'impact du test.

La principale préoccupation est lorsque SRM produit des données inexactes qui pourraient affecter vos métriques et passer inaperçues.

Adobe Target via MiaProva

En avril 2021, Adobe Target s'est associé à MiaProva pour fournir des alertes SRM sur les activités A/B.

Ces alertes avertissent les clients MiaProva qui utilisent Adobe Target lorsqu'une non-concordance est détectée. Cette approche applique automatiquement un test du chi carré à chaque test A/B en direct.

CroissanceBook

GrowthBook est une plateforme de test A/B open source avec un moteur de statistiques bayésien et des vérifications SRM automatiques pour chaque expérience.

Chaque expérience recherche un SRM et avertit les utilisateurs si un est identifié.

Lorsque vous prédisez une certaine répartition du trafic (par exemple 50/50), mais que vous voyez à la place quelque chose de radicalement différent (par exemple 40/60), vous recevez un avertissement. Cela ne s'affiche que si la valeur p est inférieure à 0,001, ce qui indique qu'il est extrêmement peu probable que cela se produise par coïncidence.

Les résultats d'un tel test ne doivent pas être fiables car ils sont potentiellement trompeurs, d'où l'avertissement. Au lieu de cela, les utilisateurs doivent localiser et corriger la source du bogue avant de redémarrer l'expérience.

Split.io

Split est une plate-forme de livraison de fonctionnalités qui alimente la gestion des indicateurs de fonctionnalités, l'expérimentation logicielle et la livraison continue.

À chaque mise à jour de calcul, la plate-forme Split vérifie le rapport d'échantillonnage pour voir s'il existe une différence substantielle entre les rapports d'échantillonnage ciblés et actuels. Cette vérification du ratio d'échantillon peut être trouvée sous le résumé des mesures clés et de l'organisation, ainsi que d'autres détails importants tels que la durée et la dernière mise à jour.

Démystification du rapport de taille d'échantillon

Vous vous demandez peut-être à quelle fréquence est-il « normal » de voir un SRM ?

Lukas Vermeer l'a dit le mieux. Même les grandes entreprises technologiques observent une fréquence naturelle des SRM de 6 % à 10 % dans leurs expériences contrôlées en ligne.

Maintenant, si le SRM se répète plus fréquemment, cela justifie une enquête plus approfondie sur la conception de l'expérience ou sur le site Web.

Notre équipe est toujours disponible pour vous aider si vous rencontrez des problèmes comme ceux ci-dessus ! Cliquez ici pour contacter notre équipe.