Products
Solutions
Resources
Un guide rapide sur la disparité du ratio d'échantillonnage (SRM)
Note : Ceci est une traduction française d'un article de blog initialement publié en anglais, que vous pouvez trouver ici : https://statsig.com/blog/sample-ratio-mismatch
« Utilisons un tirage à pile ou face pour décider — le premier à 50 gagne. »
Imaginons que nous lancions une pièce équilibrée plusieurs fois et obtenions 8 faces et 2 piles. (Une pièce équilibrée est une pièce équitable, qui n'a jamais été utilisée dans un tour de magie.)
Bien que nous nous attendions à obtenir moitié faces et moitié piles, nous pourrions simplement avoir obtenu des résultats étranges. Si nous continuons à lancer la pièce pendant 100 essais et obtenons 80 faces et 20 piles, nous serons beaucoup plus méfiants quant à l'« équité » de cette pièce.
Si nous utilisons ce tirage à pile ou face pour assigner aléatoirement des utilisateurs au groupe test ou contrôle d'une expérience, ce manque d'« équité » est appelé déséquilibre du ratio d'échantillonnage ou SRM (sample ratio mismatch).
Nous évaluons ce manque d'équité avec un test du chi carré comparant les résultats 80/20 que nous observons aux résultats 50/50 que nous attendrions d'une pièce équitable. La valeur p de ce test du chi carré est le taux de résultats aussi extrêmes ou plus extrêmes que ce que nous avons observé que nous nous attendrions à voir dans des essais répétés avec une pièce vraiment équitable.
L'intuition correspond à la valeur p du SRM
L'intuition de nos expériences de tirage à pile ou face se reflète dans la valeur p des tests du chi carré pour chacun de ces cas. Observer des résultats de 80 % de faces dans une expérience de 10 lancers a une valeur p de 0,058, tandis qu'obtenir 80 % de faces dans une expérience de 100 lancers a une valeur p essentiellement de 0.
Pourquoi le SRM est-il mauvais ?
Le déséquilibre du ratio d'échantillonnage est une preuve de biais de sélection
L'une des hypothèses fondamentales des expériences aléatoires est qu'il y a une assignation aléatoire des individus au groupe contrôle ou test. Sinon, il pourrait y avoir d'autres variables qui ne sont pas indépendantes de l'assignation et qui pourraient être la véritable cause de toute différence entre traitement et contrôle que nous observons.
Indique un problème d'implémentation
Le fait qu'il y ait un SRM signifie probablement qu'il y a un problème dans l'implémentation de l'expérimentation, mais cela pourrait se produire soit dans la façon dont les utilisateurs sont assignés à leur groupe de traitement, soit dans la façon dont les données sont mesurées ou traitées après coup. Si vous utilisez Statsig, il y a aussi beaucoup de ces causes potentielles que nous pouvons probablement exclure !
Quelques causes à investiguer :
Certains utilisateurs ne sont pas éligibles pour certaines variantes : peut-être que le code de votre nouvelle fonctionnalité super cool force aussi par inadvertance un certain segment d'utilisateurs dans un groupe de traitement spécifique.
Cela n'arrivera pas si vous utilisez Statsig car notre SDK filtre les utilisateurs non éligibles de manière égale dans tous les groupes d'expérience
L'inscription est découplée de l'exposition : Peut-être que les utilisateurs sont inscrits dans une expérience sur une certaine page web mais ne sont exposés à leur groupe de traitement que s'ils atteignent l'expérience pertinente. Cependant, si l'exposition du groupe contrôle se produit en haut de la page mais que le groupe test doit faire défiler, c'est un mécanisme qui pourrait causer un SRM.
Le SDK Statsig couple automatiquement l'assignation et l'exposition en enregistrant automatiquement les expositions pour vous par défaut, mais cela peut aussi être découplé si nécessaire.
La procédure de randomisation ne randomise pas : la fonction que vous utilisez pour assigner « aléatoirement » les utilisateurs à un traitement n'est pas réellement aléatoire et introduit potentiellement un biais.
Cela n'arrivera pas si vous utilisez Statsig - nous utilisons l'algorithme de hachage SHA256 pour assigner de manière déterministe les groupes de traitement étant donné un ID d'unité et un ID d'expérience
Différences de taux de crash entre les groupes Test et Contrôle : Si le nouveau code introduit ou résout des crashs, cela pourrait entraîner un SRM. Si le groupe test a plus de crashs, cela entraînerait plus d'utilisateurs dans le groupe test incapables d'envoyer des expositions, causant un SRM.
Problèmes de traitement des données : il peut y avoir un processus par lequel ces données sont supprimées ou dupliquées uniquement pour la variante contrôle ou test.
Si vous envoyez toutes vos données via Statsig, nous effectuons le traitement des données et il ne devrait pas y avoir de SRM provenant du traitement des données
Avez-vous juste été super malchanceux ?
Probablement pas.
C'est ce que quantifie la valeur p : le taux de résultats où les groupes sont divisés au moins aussi extrêmement que ce que nous avons observé que nous nous attendrions à voir dans des essais répétés menés de la même manière. C'est vraiment peu probable mais cela pourrait être ce qui se passe.
SRM dans la console Statsig
Dans Statsig, nous vérifions automatiquement le SRM pour chaque expérience. Dans Diagnostics, sous Contrôles de santé de l'expérience, si vous voyez que les Expositions sont équilibrées est vert, cela signifie que nous n'avons détecté aucun SRM.
Nous considérons que les expositions sont déséquilibrées si la valeur p du SRM est inférieure à 0,01.
Si vous n'utilisez pas Statsig et que vous voulez vérifier si votre expérience a un SRM, vous ne voulez probablement pas faire un test du chi carré à la main. J'ai utilisé ce calculateur de SRM auparavant et l'ai utilisé pour calculer les valeurs p pour nos exemples (8, 2) et (80, 20) ci-dessus.
Statsig suit automatiquement votre valeur p de SRM au fil du temps, ce qui vous permet d'identifier si/quand vous voyez des preuves de SRM. Toute valeur p de SRM inférieure à 0,01 signifiera que l'expérience échoue au contrôle de santé Expositions équilibrées.
Cela signifie qu'il y a aussi un point de départ pour déboguer les problèmes qui peuvent avoir causé le SRM.
Si un SRM est détecté et que la cause racine est trouvée, vous pouvez facilement abandonner l'expérience et réallouer. Cette nouvelle expérience avec le même design aura aussi un « sel » différent utilisé pour randomiser le groupe d'un utilisateur, ce qui signifie que les utilisateurs sont assignés aléatoirement à un groupe indépendamment de leur groupe dans l'itération précédente de cette expérience. C'est important, car cela garantit que le nouveau résultat n'est pas impacté par une expérience négative ou positive dans l'exécution précédente.
Dois-je jeter mes résultats parce que j'ai un SRM ?
Nous ne voulons pas prendre à la légère l'existence d'un SRM dans une expérience. Cela indique qu'il y a très probablement quelque chose de méthodologiquement incorrect dans votre expérience. Cependant, nous ne voulons peut-être pas complètement ignorer l'expérience que nous venons de mener.
Il est important que je connaisse la cause racine du SRM pour prendre ces décisions. Sans cette connaissance cruciale, il est impossible de considérer les sources potentielles de biais expérimental et de quelle manière nous nous sentons à l'aise d'utiliser les résultats.
Il y a quelques facteurs que je considère quand je regarde une expérience avec SRM pour déterminer si je peux ou non glaner une quelconque idée directionnelle de l'expérience :
À quel point le groupe d'utilisateurs causant le SRM est-il différent des autres utilisateurs ?
par exemple, dans notre expérience, les nouveaux utilisateurs sont tous dans le groupe test, et les nouveaux utilisateurs se comportent très différemment des utilisateurs établis, donc j'ignore complètement les résultats de l'expérience et je redémarre l'expérience.
La différence entre les utilisateurs qui cause le SRM pourrait-elle aussi impacter le traitement ?
par exemple, dans notre expérience, j'ai des entrées dupliquées pour tous les utilisateurs d'Internet Explorer pour lesquels ma nouvelle fonctionnalité cause une latence plus élevée. Cela semble conduire les résultats négatifs que je vois globalement, tandis que les utilisateurs avec d'autres navigateurs semblent avoir un petit impact positif de la nouvelle fonctionnalité. Cela peut me conduire à itérer sur mon produit pour réduire la latence sur tous les navigateurs web avant de lancer une autre expérience.
Au final, c'est une question de jugement.
Bien qu'il puisse y avoir des inconvénients à redémarrer une expérience et à ne tirer aucun enseignement de la version précédente où le SRM était présent (prise de décision retardée, servir une expérience inférieure aux utilisateurs), l'approche la plus scientifiquement rigoureuse serait de toujours relancer ces expériences telles qu'elles ont été conçues une fois que le problème causant le SRM est trouvé.
Si vous voulez considérer les résultats d'une expérience malgré l'existence d'un SRM, contrôler le biais pré-expérimental en utilisant CUPED peut aider à traiter le biais.