A/B testing : quand ça vaut le coup, ce que ça coûte et ce qu'il faut avant

L'A/B testing est une méthode qui consiste à diffuser deux versions d'une page en même temps, à répartir le trafic entre elles et à garder celle qui produit davantage du résultat qui compte.

La mécanique est simple et abondamment expliquée. Ce qui décide de la réussite n'est pas la mécanique, c'est de savoir si vous avez assez de trafic pour que la réponse veuille dire quelque chose. La plupart des articles sur le sujet sont écrits par ceux qui vendent les outils, et sautent donc la question de savoir si vous devriez tester. Celui-ci commence par là, car pour une grande part des sites la réponse honnête est : pas encore.

Le seuil est fixé par l'arithmétique, pas par l'enthousiasme. Pour détecter une amélioration réaliste, disons un cinquième de conversions en plus, il faut environ 100 conversions par variante avant que le résultat se sépare du hasard. Cela fait 200 conversions par test, et à un taux de 2 % cela représente près de 10 000 sessions sur la page testée.

En dessous, les tests n'échouent pas bruyamment. Ils produisent un gagnant qui est du bruit, vous le déployez, et l'effet n'apparaît jamais dans les chiffres du mois. Deux tours comme ça et l'équipe conclut que le test ne marche pas, alors que c'est le test à ce volume qui ne marchait pas.

Le calculateur de taille d'échantillon d'Evan Miller prend votre taux de départ et le plus petit gain sur lequel vous agiriez, et vous donne le nombre de visiteurs nécessaire par variante.

Trois choses, chacune affaire d'heures et non de semaines. S'il en manque une, vous obtenez des résultats inexploitables, ce qui coûte plus cher que de ne pas tester, car les conclusions seront citées pendant un an. Le chiffre dans l'hypothèse est ce qui empêche un résultat plat d'être réinterprété plus tard en petite victoire.

Un suivi des conversions qui se déclenche une fois depuis chaque parcours, vérifié à la main. Une base d'au moins huit semaines pour savoir à quoi ressemble la variation normale. Et une hypothèse écrite avec un chiffre dedans : pas «un formulaire plus court marchera mieux» mais «passer le formulaire de neuf à quatre champs augmentera les envois d'au moins 15 %».

Personne n'a le trafic pour tout tester, donc l'ordre compte plus que la liste. Le tableau ci-dessous montre par quoi nous commençons selon le type de page, tiré d'audits et non de la théorie, avec le trafic approximatif nécessaire pour une réponse propre en un mois. Les volumes valent pour un taux autour de 2 % : à 5 %, comptez presque moitié moins. Une remarque sur l'ordre : commencez par la page qui reçoit le plus de sessions, pas par celle qui vous agace le plus. Ce sont rarement les mêmes, et la seconde consomme un mois pour un résultat que personne ne remarquera.

Le motif derrière : le premier test sur une page devrait être un retrait, pas un ajout. Les retraits sont plus rapides à construire, plus faciles à lire et gagnent plus souvent, car la plupart des pages portent plus que nécessaire.

Divisez les sessions nécessaires par vos sessions hebdomadaires sur cette page, puis arrondissez à la semaine entière. À la semaine, car le trafic ne se comporte pas pareil en semaine et le week-end, et s'arrêter en milieu de semaine penche le résultat vers les jours qui s'y trouvent. Fixez aussi la date de fin avant de démarrer : un test sans fin définie tourne jusqu'à ce que quelqu'un veuille un résultat.

Deux règles gardent un test honnête. Ne regardez pas avant la fin prévue, car vous vous arrêterez sur un pic. Et ne faites pas tourner deux tests sur le même parcours en même temps si votre outil ne gère pas l'interaction.

Le split testing SEO répond à une autre question et fonctionne autrement. Au lieu de répartir les utilisateurs, vous répartissez les pages : la moitié d'un ensemble de gabarits similaires reçoit la modification, l'autre non, et vous comparez le trafic organique entre les groupes sur plusieurs semaines. En pratique, cela veut dire aussi que les deux types de test ne doivent pas tourner ensemble sur le même gabarit.

La raison est qu'un moteur voit une version d'une URL et non deux, donc une répartition par utilisateur ne peut pas mesurer un effet de classement. Cela règle aussi l'inquiétude habituelle. La documentation de Google sur les tests de site dit explicitement qu'un test A/B correctement implémenté n'entraîne pas de pénalité.

Les tests SEO demandent plus de patience : quatre à six semaines au minimum, et au moins vingt pages comparables.

Les exemples qui circulent le plus sont les plus photogéniques, et la couleur du bouton est le pire d'entre eux. Il survit grâce à une étude de cas célèbre de 2009 et parce que c'est la chose la plus facile à changer. Dans nos audits, cela n'a jamais été le levier principal d'une page.

La règle qui fait gagner le plus de temps : ne testez rien que vous déploieriez de toute façon. Si la version actuelle est cassée, illisible ou contredit l'annonce qui a amené le visiteur, réparez-la. Un test sur une page cassée mesure laquelle des versions cassées est la moins mauvaise.

Écartez aussi tout ce qui ne peut pas déplacer le chiffre d'un cinquième à votre volume. Tester des couleurs avec peu de trafic, c'est en réalité tester la patience de l'équipe.

Un test a trois issues possibles et la plupart des équipes n'en prévoient qu'une. Un gagnant net est le cas rare. Un perdant net est réellement utile, car il montre que l'hypothèse derrière la page est fausse. Et un résultat plat, le plus fréquent, signifie que la modification était trop petite pour votre volume, pas que l'idée était mauvaise.

Écrivez la règle d'interprétation avant de commencer : quel chiffre compte comme victoire, lequel comme plat, et ce que vous ferez dans chaque cas. Notez aussi qui décide : un résultat sans décideur désigné reste en attente.

Les travaux du Nielsen Norman Group sur les études quantitatives traitent la question de l'échantillon plus en détail.

Les échecs que nous voyons se répètent, et aucun n'est de nature statistique. Ils concernent le processus, ce qui explique qu'un meilleur outil les corrige rarement.

• S'arrêter tôt un bon jour, ce qui transforme un tirage à pile ou face en décision
• Tester quelque chose de si petit qu'un effet réel resterait invisible à votre volume
• Changer deux choses à la fois et apprendre quelle paire a gagné plutôt que quelle modification
• Ne jamais écrire le résultat attendu, si bien que chaque issue est rapportée comme un succès
• Tester pendant un pic saisonnier et appliquer la conclusion au reste de l'année

«Les tests dont nous apprenons quelque chose sont ceux où nous avions écrit ce que nous attendions et où nous nous étions trompés.» - responsable conversion chez Vezert

Aucune de ces erreurs ne se corrige en changeant d'outil. Elles se corrigent en écrivant trois lignes avant de lancer : ce que vous attendez, quand vous vous arrêtez, et qui décide.

L'outil est le plus petit poste. Un outil de test correct coûte de 0 € à 200 € par mois aux volumes qu'ont la plupart des sites B2B, et l'offre gratuite de plusieurs suffit pour un test à la fois. Le vrai coût est dans la construction et l'analyse. Comptez enfin le coût d'opportunité : le mois qu'un test occupe est un mois pendant lequel la page ne reçoit pas d'autre amélioration. À faible trafic, ce coût dépasse souvent la valeur de la réponse obtenue.

Comptez trois à huit heures par test pour l'implémentation sur une page normale, plus une heure pour lire le résultat correctement. Aux tarifs agence, cela fait 400 € à 1 200 € par test, et un programme d'un test par mois se situe autour de 1 000 € à 2 500 € outil et reporting compris.

Un poste n'apparaît jamais dans le devis : le temps de décision. Les programmes meurent bien plus souvent de résultats non lus que d'outils médiocres.

Si votre page principale dépasse 10 000 sessions par mois, commencez par le test de retrait du tableau et écrivez d'abord le chiffre attendu. Sinon, mettez le même budget dans le trafic et servez-vous d'un audit CRO pour trouver les problèmes qui n'ont pas besoin d'un test pour être évidents.

L'essentiel de ce qu'un premier audit trouve n'est de toute façon pas testable. C'est cassé, et on répare ce qui est cassé au lieu de le tester. Notre travail d'optimisation des conversions sépare les deux avant de construire quoi que ce soit.