Un guide pratique de A/B testing pour sites web

Ce guide explique A/B testing pour sites web de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

Les tests A/B sont utiles car ils transforment une modification de site Web en une expérience contrôlée au lieu d'un débat sur les goûts. La discipline est simple : décidez quel résultat commercial vous souhaitez améliorer, exposez des visiteurs comparables à différentes versions et mesurez si le changement a produit un réel impact. Le plus difficile est d’éviter les fausses confiances.

Une configuration d'analyse axée sur la confidentialité peut prendre en charge de bonnes expériences sans transformer chaque visiteur en un profil publicitaire à long terme. Vous avez généralement besoin de pages vues, de référents, de paramètres de campagne, d'attribution de variantes et d'un événement de conversion. Vous n'avez pas besoin d'un suivi intersites, d'attributs sensibles ou d'un graphique d'identité pour la plupart des expériences de sites Web.

Ce qui compte comme une bonne expérience de site Web

Un test A/B utile comprend quatre parties : une hypothèse, une métrique principale, une méthode d'affectation aléatoire et une règle d'arrêt. Par exemple : "Si nous rapprochons la preuve de tarification du bouton d'inscription, le nombre d'essais démarrés à partir de la page de tarification augmentera car les visiteurs verront une réduction des risques avant de prendre une décision." C'est mieux que de « tester une nouvelle page de tarification », car cela indique ce qui devrait changer et pourquoi.

Choisissez une métrique principale avant le lancement. Les mesures secondaires sont toujours utiles, mais elles ne doivent pas devenir une liste de courses pour un résultat positif après coup. Un test de page de tarification SaaS peut utiliser le taux d'inscription à l'essai comme mesure principale et surveiller les erreurs de paiement, les clics d'assistance, la profondeur de défilement et les demandes de remboursement comme garde-fous.

L’assignation aléatoire est importante. Si les visiteurs connus voient toujours le contrôle et les nouveaux visiteurs voient la variante, le résultat mélangera votre modification de conception avec les différences d'audience. Commencez par une attribution côté serveur pour la session en cours ou pour les utilisateurs authentifiés où le compte interne ID reste dans vos propres systèmes. Si vous stockez la variante attribuée dans un cookie propriétaire, un stockage local ou un stockage similaire dans le navigateur, traitez ce stockage comme potentiellement soumis au consentement de ePrivacy, à moins qu'une exemption locale étroite ne s'applique.

Que tester en premier

Commencez par les changements liés à un point de décision. Les couleurs des boutons constituent rarement la meilleure première expérience. Les meilleurs candidats incluent la clarté du message, la structure tarifaire, la longueur du formulaire, la preuve proche d'un CTA à haute intention, le cadrage essai contre démo, la friction à la caisse et les options de paiement.

Donnez la priorité aux tests avec suffisamment de trafic et suffisamment de contrôle des baisses. Un test de paiement peut produire un signal rapide, mais un paiement interrompu coûte également de l'argent. Utilisez les indicateurs de fonctionnalités, contrôlez la qualité des deux variantes et surveillez les taux d'erreur dès les premières minutes du lancement.

Taille de l'échantillon et calendrier

N'arrêtez pas un test la première fois qu'un tableau de bord devient vert. Regarder à plusieurs reprises augmente le risque de faux positif. Ronny Kohavi, Diane Tang et Ya Xu, chercheurs de Microsoft, soulignent dans leurs travaux d'expérimentation contrôlée en ligne que les programmes d'expérimentation nécessitent des mesures claires, une randomisation et une discipline statistique, et pas seulement une répartition du trafic (Trustworthy Online Controlled Experiments).

Pour les équipes pratiques, définissez ces règles avant le lancement :

1. Durée d'exécution minimale : au moins un cycle économique complet, généralement sept jours, afin que le comportement en semaine/week-end soit représenté.
2. Conversions minimales : suffisamment de conversions dans chaque variante pour que le résultat soit significatif. Un test avec 20 conversions totales est généralement directionnel et non décisif.
3. Effet minimum détectable : le plus petit ascenseur sur lequel vous agiriez réellement. Si une augmentation de 1 % ne modifierait pas votre feuille de route, ne concevez pas le test autour de la détection de 1 %.
4. Garde-corps : mesures qui peuvent invalider un gagnant, telles qu'un chargement de page plus lent, des remboursements plus élevés, une activation plus faible ou davantage de tickets d'assistance.

Pour les sites à faible trafic, les tests A/B peuvent ne pas être le bon outil. Si votre page de tarification reçoit 300 visites par mois et 9 inscriptions, un test statistiquement propre prendra beaucoup de temps. Utilisez d'abord la recherche qualitative, les entonnoirs au niveau de la session, les enquêtes, les notes d'appels commerciaux et les tests d'utilisabilité. Exécutez ensuite des expériences plus vastes et plus audacieuses où l’effet attendu est suffisamment important pour être détecté.

Mise en œuvre axée sur la confidentialité

Une implémentation minimale nécessite trois événements : l'exposition à l'expérience, l'achèvement de l'objectif et les événements de garde-fou. Gardez les propriétés de l'événement ennuyeuses : la page, le nom de l'expérience, la variante, l'horodatage, la source et la classe d'appareil suffisent généralement.

Évitez de collecter des adresses e-mail, des noms, des adresses IP brutes ou des URL complètes contenant des données personnelles. Si des paramètres de campagne sont nécessaires, conservez UTMs mais supprimez les identifiants inutiles. Si une URL peut contenir un jeton, une commande ID ou une adresse e-mail, nettoyez-le avant qu'il n'atteigne les analyses.

Les règles de consentement dépendent de la mise en œuvre. En vertu de la loi EU, le stockage ou l'accès aux informations sur l'appareil de l'utilisateur est généralement régi par les lois nationales mettant en œuvre la loi ePrivacy Directive, tandis que le traitement ultérieur des données personnelles relève de la loi GDPR. Les lignes directrices relatives à l'article 5(3) du EDPB et les lignes directrices sur le stockage et l'accès du ICO soulignent toutes deux que ces règles couvrent plus que les cookies, y compris le stockage local, les pixels, le SDKs et d'autres accès aux équipements terminaux (EDPB Article 5(3) guidance, ICO technologies de stockage et d'accès conseils). Le rapport du groupe de travail sur les bannières de cookies de EDPB note la répartition entre les règles d'accès aux cookies et les règles de traitement de GDPR (EDPB Cookie Banner Taskforce).

Si votre test utilise des cookies non essentiels, un stockage local, un suivi tiers ou des destinations publicitaires, vous aurez peut-être besoin d'un consentement. Si vous exécutez une expérience côté serveur strictement nécessaire sans profilage personnel, l'analyse est différente, mais documentez votre raisonnement et évitez que l'affectation ne devienne un identifiant caché.

Lire le résultat

Une variante gagnante devrait répondre à trois questions : la mesure principale s'est-elle améliorée, les garde-corps sont-ils restés sains et l'effet est-il suffisamment important pour avoir de l'importance ? Soyez prudent avec l'analyse des segments. Si vous divisez les résultats en dix segments après le test, l'un d'entre eux peut paraître dramatique par hasard. Utilisez des segments pour générer des hypothèses de suivi, et non pour récupérer un résultat faible.

Décidez également de ce qui se passe après une perte. Un test échoué est utile lorsqu’il supprime une mauvaise idée de la feuille de route ou révèle que l’hypothèse était fausse. Notez le résultat, l’interprétation et l’action suivante. Au fil du temps, vos archives d’expériences deviennent une base de connaissances sur les produits.

Les tests A/B ne sont pas magiques. C’est un moyen de rendre les décisions en matière de site Web moins fragiles. Les meilleures équipes l’utilisent avec parcimonie, mesurent uniquement ce dont elles ont besoin et traitent les contraintes de confidentialité comme une exigence de conception plutôt que comme un obstacle.

Liste de contrôle de conformité des expériences

Avant d'envoyer un test, confirmez la méthode d'affectation, le comportement de stockage, le déclencheur de consentement, la charge utile de l'événement, la période de conservation et les destinations des fournisseurs. Dans un navigateur propre, testez le chargement de la première page avant le choix, après le rejet et après l'acceptation. Une expérience conforme n’est pas seulement statistiquement valable ; cela prouve également que le stockage optionnel et les tags respectent le choix de l'utilisateur.

Liez chaque mesure à une décision. Les pages vues doivent guider le contenu et le travail de navigation, les référents doivent guider l'investissement dans les canaux, les balises de campagne doivent guider les dépenses et les événements de conversion doivent être rapprochés des enregistrements backend. Si une métrique ne peut pas modifier une décision, archivez-la depuis le tableau de bord principal.