Comment concevriez-vous un test A/B pour un nouveau tunnel de paiement ?

Définissez un seul indicateur principal et l'effet minimal qui vaut la peine d'être détecté, puis calculez la taille d'échantillon et la durée nécessaires avant le lancement. Randomisez au niveau de l'utilisateur, pas de la session, pour qu'un visiteur qui revient voie toujours la même variante. Faites tourner par semaines entières pour couvrir les cycles hebdomadaires, vérifiez que la randomisation a tenu, et décidez à l'avance quel résultat déclenche un lancement. Suivez des indicateurs garde-fous à côté du principal.

Je commencerais par arrêter un indicateur principal, qui pour un tunnel de paiement est le nombre d'achats finalisés par utilisateur entré dans le tunnel, pas les clics, puis je demanderais quelle ampleur d'amélioration justifierait vraiment un déploiement. Cet effet minimal détectable pilote la taille d'échantillon, et la taille d'échantillon plus notre trafic quotidien donnent la durée. Si ça tombe à onze semaines, la réponse honnête est que ce test ne vaut pas la peine d'être lancé et qu'il faut trancher autrement. La randomisation se fait au niveau de l'utilisateur avec un identifiant persistant, puisqu'une affectation par session fait voir deux tunnels différents à un client qui revient, ce qui pollue les données et l'agace. Je fais tourner en multiples de semaines entières parce que les comportements de semaine et de week-end diffèrent beaucoup. Je fixe aussi les garde-fous à l'avance, donc taux de remboursement et contacts au support, ainsi que la règle de lancement. Et je ne m'arrête pas tôt un jour favorable : regarder de façon répétée un test en cours gonfle sérieusement les faux positifs, je l'ai vu se produire.