Les tests A / B sont souvent facturés comme un moyen scientifique de valider les décisions de conception. Parfois appelé test fractionné, le test A / B est un processus simple qui, en surface, semble promettre des résultats concrets:
Créez deux variantes sur un élément de conception, échangez-les de manière aléatoire sur votre site et enregistrez la réaction de vos utilisateurs, comparez les résultats et implémentez la variation la plus performante. Ca a du sens.
L'exemple classique est le suivant: un bouton rouge ou un bouton vert, qui sera exploité davantage? Cependant, la question la plus intéressante est la suivante: un bouton vert contre le même bouton vert, qui sera exploité davantage?
Que se passe-t-il lorsque nous testons deux variantes identiques? Un test A / A, si vous voulez.
Afin de tester la validité de tout test A / B, nous avons besoin d'un test qui a une réponse «correcte». Nous avons besoin d'une réponse correcte parce que nous voulons savoir, toutes choses égales par ailleurs, à quel point le test A / B produira probablement le résultat escompté et pour cela, nous devons savoir à quel résultat nous pouvons nous attendre.
Si nous testons deux boutons identiques, le résultat devrait être une chaleur morte
Alors, supposons que nous testons un bouton vert par rapport au même bouton vert, et que le bouton est si attrayant que 100% des utilisateurs vont le toucher.
(Le pourcentage n’a pas d’importance, il pourrait être de 14,872%. Ce qui compte, c’est que parce que les boutons sont identiques, le taux de prise devrait également être identique.)
Si nous testons deux boutons identiques, le résultat devrait être une chaleur morte.
Un tirage au sort. De quel côté viendront les têtes ou les queues? Nous savons qu'il y a deux côtés, tous deux identiques, donc il y a une chance de 50-50.
Si nous jetons notre pièce deux fois, nous savons qu'il y a trois résultats possibles: 2 têtes, 2 queues ou 1 tête et 1 queue. Etc…
Disons que le tirage au sort est notre test A / A; les chances de voir la face des queues sont identiques à celles des queues, tout comme la probabilité que l'un de nos boutons verts soit utilisé.
Donc, écrivons un script rapide dans le navigateur (parce que la plupart des tests A / B ont lieu dans le navigateur) pour simuler les utilisateurs en appuyant sur un bouton ou sur l'autre, selon celui auquel ils sont présentés.
Rappelez-vous: nous testons deux variantes identiques d'un bouton, et la manière dont nous savons qu'ils sont identiques est que nous traitons la probabilité qu'ils soient exploités comme étant identiques. Tout ce que nous recherchons est un résultat cohérent (et donc correct).
Tout d'abord, nous avons besoin d'un tableau HTML pour enregistrer nos résultats, la table ressemblera à ceci:
# Heads Tails Difference Margin of Error
Dans la première colonne, nous enregistrerons le numéro du test (tous les bons tests A / B sont répétés pour vérifier les résultats, nous répéterons donc le test plusieurs fois). Ensuite, nous enregistrerons le nombre de résultats de Heads , puis le nombre de résultats de Tails . La colonne après sera la différence entre les deux résultats (qui devrait être zéro). Ensuite, nous enregistrerons la marge d'erreur (qui, encore une fois, devrait être de 0%). Sous la table, nous allons imprimer un résumé, la moyenne de tous les résultats et le pire des résultats.
Voici le script:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}Le code est commenté, voici donc les faits saillants:
Nous définissons tout d'abord certaines variables, notamment le nombre de fois que nous voulons lancer la pièce (bestOf) et le nombre de fois que nous voulons répéter le test (testRepeat).
Alerte de spoiler: nous allons entrer dans des boucles assez élevées, donc pour éviter de casser le navigateur de quelqu'un, nous effectuons le test à intervalles de 100 ms.
A l'intérieur de la fonction performCoinToss , nous bouclons le nombre de fois requis, chaque itération de la boucle, nous utilisons la fonction aléatoire de JavaScript pour générer un 1 ou un 0, ce qui incrémente soit le headsCounter , soit le tailsCounter .
Ensuite, nous écrivons le résultat de ce test sur la table.
Enfin, si le test a été répété le nombre de fois que nous aimerions, nous trouvons les moyennes, et le pire des cas, les écrivez dans le résumé et effacez l'intervalle.
Voici le résultat . Comme vous pouvez le constater, la différence moyenne est que ce sera différent pour vous, mais comme je vous écris, la différence moyenne est de 2,8333333333333335, l'erreur moyenne est donc de 23,611111111111114%.
Une erreur de plus de 23% n'inspire pas confiance, d'autant plus que nous savons que la différence devrait être de 0%. Ce qui est pire, c’est que mon pire résultat est 8, c’est 10-2 en faveur de la tête.
Ok, donc ce test n'était pas juste. Un test A / B réel ne prétendrait jamais trouver un résultat probant avec seulement 12 utilisateurs.
Le test A / B utilise quelque chose appelé "signification statistique", ce qui signifie que le test doit être suffisamment long pour obtenir un résultat exploitable.
Donc, doublons la variable BestOf et voyons jusqu'où nous devons aller pour atteindre une marge d'erreur de moins de 1%, soit l'équivalent de 99% de confiance.
À un meilleur de 24 (au moment de la rédaction du présent document), la différence moyenne est de 3.1666666666666665, ce qui correspond à 13.1444444444444445%. Un pas dans la bonne direction! Essayez vous-même (vos résultats varieront).
Faisons le double encore. Cette fois, ma différence moyenne de 6.666666666666667, avec une marge d'erreur de 13,88888888888889%. Pire encore, le pire des cas est 16, c'est une erreur de 33,33333333333333%! Vous pouvez essayez celui-là pour vous aussi.
En fait, pas de prix pour deviner que nous pouvons continuer: meilleur de 96 , meilleur de 192 , meilleur de 384 , meilleur de 768 , meilleur de 1536 , meilleur de 3072 , meilleur de 6144 , meilleur de 12288 , meilleur de 24576 , meilleur de 49152 , meilleur de 98304 .
Enfin, au meilleur de 98304, le pire scénario tombe sous la barre des 1%. En d'autres termes, nous pouvons être convaincus à 99% que le test est correct.
Ainsi, dans un test A / A dont nous savions le résultat à l’avance, la taille de l’échantillon était de 98 304 pour obtenir une marge d’erreur acceptable.
Chaque fois que l'on discute des tests A / B, quelqu'un se souvient d'un ami d'un ami, qui a testé un seul bouton sur son site, et a rapidement réalisé un profit improbable (la valeur réelle du bouton augmente chaque fois que j'entends le récit).
Dans ces contes, les boutons sont généralement testés pour la micro-copie, "Télécharger mon ebook" vs "Télécharger mon ebook gratuit". Il ne devrait pas être une surprise que ce dernier gagne. C'est une amélioration que ferait tout bon rédacteur publicitaire. Un test A / B plus approprié serait "Télécharger mon ebook" vs "Télécharger l'ebook" (mon argent sur ce dernier).
Si vous vous retrouvez avec un résultat fortement pondéré par l'une des options, cela suggère que quelque chose ne va pas avec l'une de vos variantes. Plus souvent, un bon résultat sera une amélioration de moins de 5%, ce qui pose un problème si vous testez avec environ 1000 utilisateurs (la marge d'erreur est d'environ 5%).
Plus un test est utile, plus la marge de victoire est serrée pour l'une ou l'autre variante. Toutefois, plus la marge de victoire est étroite, plus la taille de l’échantillon est importante pour vous donner une marge d’erreur acceptable.
Mark Twain, citant peut-être Disraeli, a déjà utilisé l'expression: mensonges, mensonges et statistiques. Par ce qu'il voulait dire que quelque chose prouvé par des statistiques, n'est pas nécessairement vrai. Les statistiques peuvent être utilisées pour prouver ce que vous voulez.
Les tests A / B vous donneront un résultat, mais c'est un résultat qui en dit plus sur vous et sur ce que vous attendiez, que sur vos clients.
La chose la plus dangereuse concernant les tests A / B est qu’elle peut prouver tout ce que vous voulez. Cela peut produire des faux positifs et nous permet de discerner les modèles qui ne sont pas correctement pris en charge.
De plus, un test A / B peut indiquer qu'un bouton vert surpasse un bouton rouge, mais qu'en est-il d'un bouton bleu? Même les tests A / B réussis nous permettent uniquement de valider nos décisions de conception dans le contexte du test lui-même.
Pour qu'un test A / B fonctionne comme prévu, deux conditions opposées doivent être remplies:
Malheureusement, la plupart des sites n'ont pas une taille d'échantillon suffisante pour atteindre une marge d'erreur suffisamment faible. Et comme nous ne pouvons pas augmenter la taille de notre échantillon (nous le pourrions si nous le pouvions), notre seul choix est d'augmenter la variation des options afin de produire un résultat clair, en faussant le test par nos préférences.
Les tests A / B vous donneront un résultat, mais c'est un résultat qui en dit plus sur vous et sur ce que vous attendiez, que sur vos clients. Quand il s’agit de prendre des décisions de conception sur un site autre que ceux ayant un volume de trafic très élevé, nous pourrions aussi bien lancer une pièce que le test A / B.
L'image sélectionnée, tirage au sort image via Shutterstock.