Je suis un développeur de logiciels travaillant sur des systèmes de test A / B. Je n'ai pas une solide expérience en statistiques, mais j'ai acquis des connaissances au cours des derniers mois.
Un scénario de test typique consiste à comparer deux URL sur un site Web. Un visiteur visite LANDING_URL
et est ensuite envoyé au hasard vers URL_CONTROL
ou URL_EXPERIMENTAL
. Un visiteur constitue un échantillon et une condition de victoire est atteinte lorsque le visiteur effectue une action souhaitable sur ce site. Cela constitue une conversion et le taux de conversion est le taux de conversion (généralement exprimé en pourcentage). Un taux de conversion typique pour une URL donnée se situe entre 0,01% et 0,08%. Nous effectuons des tests pour déterminer comment les nouvelles URL se comparent aux anciennes URL. S'il URL_EXPERIMENTAL
s'avère supérieur URL_CONTROL
, nous le remplaçons URL_CONTROL
par URL_EXPERIMENTAL
.
Nous avons développé un système utilisant des techniques de test d'hypothèse simples. J'ai utilisé les réponses à une autre question CrossValidated ici pour développer ce système.
Un test est mis en place comme suit:
- L'estimation
CRE_CONTROL
du taux de conversion deURL_CONTROL
est calculée à l'aide de données historiques. - Le taux
CRE_EXPERIMENTAL
de conversion cible souhaité deURL_EXPERIMENTAL
est défini. - Un niveau de signification de 0,95 est généralement utilisé.
- Une puissance de 0,8 est généralement utilisée.
Ensemble, toutes ces valeurs sont utilisées pour calculer la taille d'échantillon souhaitée. J'utilise la fonction R power.prop.test
pour obtenir cette taille d'échantillon.
Un test sera exécuté jusqu'à ce que tous les échantillons soient collectés. À ce stade, les intervalles de confiance pour CR_CONTROL
et CR_EXPERIMENTAL
sont calculés. S'ils ne se chevauchent pas, un gagnant peut être déclaré avec un niveau de signification de 0,95 et une puissance de 0,8.
Les utilisateurs de nos tests ont cependant deux préoccupations majeures:
1. Si, à un moment donné du test, suffisamment d'échantillons sont collectés pour montrer un gagnant clair, le test ne peut-il pas être arrêté?
2. Si aucun gagnant n'est déclaré à la fin du test, pouvons-nous exécuter le test plus longtemps pour voir si nous pouvons collecter suffisamment d'échantillons pour trouver un gagnant?
Il convient de noter qu'il existe de nombreux outils commerciaux qui permettent à leurs utilisateurs de faire exactement ce que souhaitent nos propres utilisateurs. J'ai lu qu'il y a beaucoup d'erreurs avec ce qui précède, mais j'ai également rencontré l'idée d'une règle d'arrêt et j'aimerais explorer la possibilité d'utiliser une telle règle dans nos propres systèmes.
Voici deux approches que nous aimerions considérer:
1. À l'aide de power.prop.test
, comparez les taux de conversion mesurés actuels au nombre actuel d'échantillons et voyez si suffisamment d'échantillons ont été collectés pour déclarer un gagnant.
Exemple: Un test a été mis en place pour voir si le comportement suivant existe dans notre système:
CRE_CONTROL
: 0,1CRE_EXPERIMENTAL
: 0,1 * 1,3- Avec ces paramètres, la taille de l'échantillon
N
est de 1774.
Cependant, à mesure que le test avance et atteint 325 échantillons, CRM_CONTROL
(le taux de conversion mesuré pour le contrôle) est de 0,08 et de CRM_EXPERIMENTAL
0,15. power.prop.test
est exécuté sur ces taux de conversion et N
se trouve être 325. Exactement le nombre d'échantillons nécessaires pour déclarer CRM_EXPERIMENTAL
être le gagnant! À ce stade, nous espérons que le test pourra être terminé. De même, si le test atteint 1774 échantillons mais qu'aucun gagnant n'est trouvé, mais qu'il atteint 2122 échantillons, ce qui est suffisant pour montrer que CRM_CONTROL
0,1 et CRM_EXPERIMENTAL
0,128 est un résultat où un gagnant peut être déclaré.
Dans une question connexe, les utilisateurs ont indiqué qu'un tel test est moins crédible car il encourage les arrêts précoces à avoir moins d'échantillons et est également vulnérable aux biais d'estimation et à un nombre accru d'erreurs de type I et de type II. Existe-t-il un moyen de faire fonctionner cette règle d'arrêt? C'est notre approche préférée car cela signifie moins de temps de programmation pour nous. Peut-être que cette règle d'arrêt pourrait fonctionner en offrant une sorte de score numérique ou des scores qui mesurent la crédibilité du test s'il devait être arrêté tôt?
2. Utilisation de l'analyse séquentielle ou SPRT .
Ces méthodes de test sont conçues exactement pour la situation dans laquelle nous nous trouvons: comment nos utilisateurs peuvent-ils commencer un test et le terminer de telle manière qu'ils ne perdent pas trop de temps dans les tests? Soit exécuter un test trop longtemps, soit recommencer un test avec des paramètres différents.
Des deux méthodes ci-dessus, je préfère SPRT parce que les mathématiques sont un peu plus faciles à comprendre et parce qu'il semble que ce soit plus facile à programmer. Cependant, je ne comprends pas comment utiliser la fonction de vraisemblance dans ce contexte. Si quelqu'un pouvait construire un exemple de la façon de calculer le rapport de vraisemblance, la somme cumulée du rapport de vraisemblance, et continuer à travers un exemple illustrant une situation où l'on continuerait à surveiller, quand on accepterait l'hypothèse nulle et l'hypothèse alternative, cela nous aiderait à déterminer si SPRT est la bonne voie à suivre.