L’erreur SRM survient lorsqu’il existe un écart statistiquement significatif entre la répartition prévue du trafic (ex. 50 % / 50 %) et la répartition observée des utilisateurs dans les groupes d’un test A/B. Cet écart indique un problème de randomisation ou de collecte des données, susceptible de biaiser toutes les conclusions.
1. Définition formelle
- Allocation attendue : pour un total N d’utilisateurs et une proportion théorique p (ex. 0,5), on s’attend à N·p observations dans chaque groupe.
- Allocation observée : si les comptes réels diffèrent au‑delà de la variation aléatoire, on parle de Sample Ratio Mismatch.
- Test statistique : on applique le χ² (Chi‑carré) à 1 degré de liberté ou un test exact de Fisher pour vérifier si l’écart est dû au hasard (α typique : 0,001 pour SRM, plus strict qu’un test d’effet). Si la p‑value < α, on déclare un SRM.
2. Causes courantes
| Catégorie | Exemple |
| Bug de bucketing | Id utilisateur tronqué, hash non uniforme |
| Filtrage asymétrique | Bloqueurs d’annonces affectant seulement le groupe B |
| Sessions multiples | Même user_id mappé à plusieurs cookies |
| Ciblage post‑randomisation | Exclusions ou redirections appliquées après l’attribution |
| Période de warm‑up | Collecte démarrée avant que le routage soit stabilisé |
| Bot / trafic interne | Robots envoyés majoritairement sur une variante |
3. Conséquences
- Biais statistique : la variance et la taille d’échantillon effectives sont faussées.
- Risque d’erreurs Type I / II : conclusions du test (gagnant / perdant) deviennent invalides.
- Perte de confiance : crédibilité des expérimentations compromise auprès des parties prenantes.
4. Détection et réactions
- Monitorer en temps réel : tableau SRM qui calcule p‑value du χ² après chaque batch de trafic.
- Seuil stricte : α = 0,001 limite les faux positifs tout en détectant tôt un problème sérieux.
- Arrêt immédiat : si SRM confirmé, suspendre le test ; ne pas interpréter les KPI.
- Audit technique : revoir la logique de routing, les exclusions et le tracking des identifiants.
- Correctif & relance : redémarrer le test après résolution, avec un nouvel identifiant d’expérimentation.
5. Bonnes pratiques CRO
- Design upfront : valider le mécanisme de split sur un environnement de staging avec des logs complets.
- Idempotence user_id : garantir un identifiant unique et stable pour la randomisation.
- Exclusions symétriques : appliquer les mêmes filtres avant la randomisation pour tous les groupes.
- Logging exhaustif : stocker attribution, timestamp, user_id, groupe et motif d’exclusion pour diagnostic.
En bref : l’erreur SRM est le « check santé » incontournable d’un test A/B. Sans randomisation fiable, même la meilleure analyse statistique ne vaut rien. Un monitoring SRM rigoureux protège la validité scientifique et la crédibilité de votre programme d’expérimentation.