Lorsque vous développez un produit, chaque nouvelle itération présente un risque de perte de métriques et de perte d'utilisateurs. Néanmoins, parfois, en particulier aux stades initiaux, les entreprises prennent inconsciemment ce risque - elles changent le produit, en ne s'appuyant que sur leurs instincts et leurs hypothèses.Chez Badoo, nous ne faisons pas confiance aux sentiments, mais nous croyons aux chiffres. Au total, nos services comptent plus de 500 millions d'utilisateurs, et nous avons rédigé notre framework de test depuis longtemps. En six ans, 2962 tests l'ont traversé et les tests A / B ont prouvé son importance, sa fiabilité et son efficacité.
Mais dans cet article, je ne parlerai pas du fonctionnement de notre système. Un article ne suffit pas pour cela. De plus, beaucoup de choses sont spécifiques à notre entreprise et ne conviendront pas à d'autres. Aujourd'hui, je vais parler de l'évolution de nos idées sur les tests A / B: quel type de râteau nous avons mis en place dans le processus et comment nous avons vérifié l'exactitude des tests. Cet article s'adresse à ceux qui n'ont pas encore commencé les tests, mais pensez-y, ainsi qu'à ceux qui ne sont pas sûrs de leur système de test.Qu'est-ce qu'un test A / B?
Imaginez une situation: une nouvelle fonctionnalité doit être lancée et notre chef de produit n'est pas prêt à risquer un revenu modeste mais stable pour le produit. Après quelques délibérations, il suggère de lancer la fonctionnalité via le test A / B et de voir si elle décollera et que les utilisateurs n'iront pas chez les concurrents. Nous n'avions pas effectué de tests A / B auparavant, donc la première chose que nous apprenons est ce qu'ils sont. Wikipédia dit: «Les tests A / B sont une méthode de recherche marketing , dont l'essence est que le groupe de contrôle des éléments est comparé à un ensemble de groupes de tests dans lesquels un ou plusieurs indicateurs ont été modifiés afin de savoir lequel Changer améliorer la cible". Il s'avère que nous devons mener une étude dans laquelle il devrait y avoir un groupe témoin, au moins un groupe test et un indicateur cible.Pour le groupe de test, nous afficherons une version alternative de la page de paiement. Sur celui-ci, nous voulons changer le texte, mettre en évidence la remise, remplacer l'image - et tout cela pour les utilisateurs d'Eurasie, afin qu'ils achètent plus. Et pour les utilisateurs d'Amérique, nous ne voulons rien changer. Nous aurons des cibles. Prenons les basiques:- ARPU (revenu moyen par utilisateur) - le profit que nous recevrons en moyenne de l'utilisateur;
- nombre de clics sur les éléments CTA (appel à l'action) - boutons et liens sur la page de paiement.
Tâche technique
Il est prévu de changer trois éléments sur la page en même temps: texte, bouton et image avec informations de remise.
Il sera assez difficile de comprendre lequel de ces changements a influencé le résultat s'il est testé simultanément. Peut-être que le nouveau texte repoussera les utilisateurs et entraînera une diminution du nombre d'achats, mais la mise en évidence de la remise l'augmentera: par conséquent, nous obtenons zéro. Les ressources de développement seront gaspillées et l'hypothèse de travail sera rejetée. Par conséquent, nous ne le ferons pas. Nous ne laisserons qu'une seule modification pour les tests: l'attribution de remises. 
Premier test
Le plan est le suivant: nous divisons les utilisateurs en deux groupes égaux et attendons le résultat. Lorsque nous le recevrons, nous comparerons les indicateurs dans les groupes de contrôle et de test. Tout semble assez simple: nous divisons les utilisateurs en pairs et impairs, puis regardons les statistiques. Nous écrivons le code:if (userId % 2 == 1) {
showNewAwesomeFeature();
}
Nous attendons avec impatience quelques semaines: les résultats sont incroyables! L'ARPU a augmenté de 100%! Les gens cliquent, paient, le chef de produit demande de déployer rapidement le changement. 
Nous l'allumons, encore deux semaines passent, mais il n'y a aucun résultat. Le bénéfice total n'a pas augmenté. Que faisons-nous de mal?Nous sélectionnons un groupe de test
Nous avons simplement divisé les utilisateurs en deux groupes égaux et exécuté le test, mais vous ne pouvez pas le faire. Après tout, quelque chose n'a changé que pour les utilisateurs d'Eurasie. Et nous en avons beaucoup moins que les utilisateurs d'Amérique. Par conséquent, il s'est avéré qu'une augmentation soudaine de l'activité des utilisateurs en provenance d'Amérique a influencé les résultats de notre test, bien qu'en réalité ils n'étaient pas les meilleurs.Conclusion: sélectionnez toujours dans le groupe de test uniquement les utilisateurs pour lesquels les modifications sont implémentées.Corrigeons notre code:if (user.continent === ‘eurasia’ && userId % 2 == 1) {
showNewAwesomeFeature();
}
Maintenant, tout devrait fonctionner comme il se doit! Exécutez le test. Nous attendons quelques semaines.
Arrivé! ARPU est en hausse de 80%! Déployez la modification à tous les utilisateurs. Et ... après la même période, les graphiques ne ressemblent pas à nouveau à ce que nous avions prévu.Calculer l'importance statistique
Le test ne peut pas être arrêté simplement «après quelques semaines»: les résultats obtenus peuvent être inexacts. Moins la métrique que nous suivons a changé et moins de personnes participent au test, plus il est probable qu'il soit aléatoire. Cette probabilité peut être calculée. La valeur qui la désigne est appelée valeur p. Je vais vous expliquer comment cela fonctionne.Lors de tout test, il est possible d'obtenir des résultats aléatoires. Par exemple, les utilisateurs qui ont visité le site peuvent être inégalement répartis - et l'ensemble du public payant appartiendra à l'un des groupes. Dans les tests réels, la différence de métriques n'est généralement pas si grande: il est difficile, voire impossible, de remarquer un problème sur les graphiques, et les tests statistiques ne peuvent pas être supprimés. En particulier, nous devons fixer la probabilitéles erreurs du premier et du deuxième type - en d'autres termes, la probabilité de trouver des changements là où ils n'existent pas et, inversement, de ne pas les trouver s'ils existent. En fonction de la valeur de la métrique et des probabilités établies, nous avons besoin d'un nombre différent d'utilisateurs.Vous pouvez le calculer à l'aide de la calculatrice en ligne : spécifiez les valeurs actuelles et cibles des mesures surveillées - vous obtenez le nombre requis d'utilisateurs pour le test, et vice versa.
Calcul de conversion à 10% et variation à 0,2% par rapport à la valeur actuelle.Maintenant nous avons reçu toutes les données nécessaires et nous savons quand arrêter le test. Il n'y a plus d'obstacles.Lançons notre test A / B et examinons les résultats.
Cette fois, les résultats ressemblent davantage à la vérité, mais restent excellents: croissance de l'ARPU de 55%. Nous arrêtons le test, appliquons le groupe de test du tout. Et ... les paramètres chutent à nouveau. Pourquoi? Vérifiez le nombre d'utilisateurs
Voyons combien d'utilisateurs ont réellement visité notre site pendant les tests. À en juger par les journaux, seulement 10% de nos groupes de test, mais nous n'avons pas pris cela en compte. Si votre DAU (le nombre d'utilisateurs uniques par jour) est de 1000 personnes, cela ne signifie pas que dans dix jours, vous aurez 10 000 utilisateurs dans le test. Enregistrez toujours les vrais résultats du test (résultats du test) et ne comptez que ceux-ci.Nous implémentons une logique simple. Pour chaque utilisateur qui visite le site, nous envoyons une requête au serveur avec les noms du groupe de test et contrôle A / B. Grâce à cela, nous saurons exactement combien d'utilisateurs nous ont visités, et nous ne nous tromperons plus.Nous lançons le test A / B.Les résultats sont excellents. Nous gagnons encore plus d'argent! Nous activons notre test pour tout le monde - et quelque chose se passe à nouveau mal: après quelques semaines, les mesures sont à nouveau plus faibles que prévu. Rappelez-vous, nous avons commencé à envoyer des hits pour tous les utilisateurs qui ont visité le site? Ne fais jamais cela. Les hits doivent être envoyés uniquement aux utilisateurs qui ont interagi avec la partie testée de la ressource. Et plus vous les définissez avec précision, mieux c'est. Heureusement, cela est facile à vérifier. Pour ce faire, vous pouvez effectuer un test A / A / B. Cela ressemble à un test A / B, mais dans ce cas, vous avez deux groupes de contrôle et un groupe de test. Pourquoi est-ce nécessaire? Si le moment d'envoi d'un hit a été mal choisi, les utilisateurs qui n'ont pas interagi avec la partie testée du site tomberont dans le test. Dans ce cas, il y aura de grandes différences dans les mesures dans les groupes A et A, et vous pouvez immédiatement comprendre que quelque chose ne va pas. Nous lançons le test A / A / B. Dans le groupe B, laissez 50% des utilisateurs et divisez également les 50% restants entre les groupes A et A (nous les appelons control et control_check). Oui, les résultats devront attendre plus longtemps, mais si les résultats des groupes A et A convergent, vous comprendrez si le hit est envoyé correctement.
Les résultats sont modestes (croissance de seulement 20%), mais réalistes. Faisons rouler le changement du tout. Tout fonctionne parfaitement! Mais après un mois, les mesures ont de nouveau chuté.Tester ce que nous pouvons contrôler
Il s'avère que notre facturation par un tiers a également effectué son test A / B, ce qui a directement affecté nos résultats. Par conséquent, suivez toujours les résultats de la production et essayez de tester entièrement ce que vous contrôlez.Total
Les tests A / B peuvent aider le produit à se développer. Mais pour faire confiance aux tests, il est important de les mener correctement et de toujours vérifier les résultats. Cette approche vous permettra de tester qualitativement votre produit et de tester les hypothèses avant de supprimer toutes les métriques.- Vérifiez toujours le groupe cible.
- Soumettre des hits.
- Envoyez les bons coups.
- Testez entièrement ce que vous contrôlez.
- /-!