L’A/B testing au service de l’amélioration continue

L’A/B quoi ?

Le test A/B, ou A/B testing, est une technique de marketing qui consiste à proposer plusieurs variantes d’un même objet qui diffèrent selon un seul critère. L’objectif est de déterminer la version qui donne les meilleurs résultats auprès des utilisateurs. Cette technique est particulièrement utile sur le web en offrant la possibilité de tester auprès d’un échantillon de personnes plusieurs versions d’une même page, d’une même application mobile, d’un même email ou d’une même bannière publicitaire. Vous obtenez un évaluation objective et chiffrée de son efficacité pour en faire ensuite une évolution.

Split test ou test bandit ?

Car oui, d’autres versions de cette méthode existent (concurrentes ou complémentaires) :

• Le split testing (ou split URL testing) : ici ce n’est pas un seul critère qui change d’une version a l’autre, on met en concurrence deux versions très différentes d’une page web (le trafic est “splitté” et redirigé sur deux URL distinctes) afin de déterminer laquelle est la plus performante.
• Le test multi variantes : ici ce ne sont pas deux variantes qui sont mises en concurrence mais de multiples variantes d’un même contenu. La difficulté ici réside dans la constitution d’un panel suffisamment représentatif pour que le résultat du test soit concluant
• Le test multi pages : ce type de test porte sur un élément partagé par plusieurs pages ayant différents layouts. La version A d’un élément à travers plusieurs pages est comparée à une version B (ou plusieurs autres) de ce même élément à travers plusieurs pages.
• Le test bandit (ou multi-armed bandit) : mode de test intégrant du Machine Learning afin d’optimiser au maximum l’orientation du trafic à destination de la version la plus performante. Ici un algorithme observe en temps réel les résultats de chaque variante du test. Il réajuste le trafic automatiquement au profit de la variante la plus performante. L’objectif ici est de profiter plus rapidement des améliorations de l’hypothèse gagnante tout en menant le test.
• Le test A/A : une méthode de validation d’une hypothèse après qu’elle ait été mise en concurrence avec d’autres. Ici une version qui aurait la mieux performé lors d’un test A/B, mais sur laquelle un doute subsisterait, est dupliquée et expose à deux groupes d’utilisateurs. Si on observe des performances différentes d’un groupe à l’autre, c’est qu’un biais s’est glissé dans l’expérimentation et qu’un critère supplémentaire est venu polluer le résultat du test A/B. Il s’agit donc de l’isoler et de relancer un test.

 

 

Amélioration continue et tests A/B : l’alliance parfaite

Toutes ces méthodes de test, avec leurs cibles différentes et leurs différences de mise en place, viennent servir un même objectif : améliorer la performance de pages, d’applications mobiles ou d’emails déjà mis à disposition de leur public.

Nous parlons bien ici d’un outil d’amélioration continue : apporter de petites améliorations à un produit ou un service à intervalles réguliers. Si on prend l’exemple de la méthode Kaizen, l’application de l’A/B testing dans un contexte web ou applicatif fait parfaitement sens. Cette méthode repose sur trois principes :

• Feedback
• Efficience
• Évolution

Et si on y calque le principe d’un A/B testing ça donne l’application suivante :

• Feedback >> utilisation des retour clients pour prendre des décisions consolidées
• Efficience >> n’engager des coûts de développement qu’après un test démontrant l’amélioration de la performance apportée par le changement
• Évolution >> ne jamais se reposer sur l’existant, et continuellement remettre en question ce qui pourrait mieux fonctionner encore.

 

Les avantages de l’A/B testing pour l’amélioration continue

Mais quelles sont les alternatives à un test AB ? Comment faisait-on avant ? Eh bien, on disposait des options suivantes :

• Les tests bêta : on rendait publique (de façon restreinte ou non) une nouvelle version d’un site, d’un parcours ou d’une application. Puis on recueille les avis et suggestions des utilisateurs de cette variante. Ensuite on modifie et (idéalement) on améliore la version bêta qui viendra remplacer celle qu’on souhaite faire évoluer.
• Les études de marché et sondages : les études de marché pour percevoir les besoins et envies de consommateurs. On orientera alors les évolutions dans cette direction. Les sondages et questionnaires en ligne pour atteindre un peu plus vite les mêmes objectifs.
• L’analyse qualitative des données : des analystes utilisent les données disponibles (ex : taux de conversion, taux de rebond) pour identifier des points de friction d’un parcours. Mais pour plus de précision, l’analyse nécessitera des retours utilisateurs par email ou via des formulaires de contact.
• Les tests A/B manuels : les équipes fonctionnelles et techniques conçoivent ensemble des versions d’un parcours d’une page ou d’une fonctionnalité. Puis ils en mesurent la performance. Des sondages apportaient souvent en complément le volet qualitatif de l’étude
• Les tests utilisateurs “classiques” : un panel d’utilisateurs représentatifs est sélectionné, puis exposé aux deux variantes avant de recueillir leur avis.
• Les évolutions empiriques : un chef de produit, ou un manager estime que telle variation serait plus performante. Il impose ensuite une évolution sur la base de son expérience personnelle ou de son intuition.

Un outil à la main des équipes fonctionnelles

Mais maintenant, parlons des outils d’A/B testing ! Le premier avantage notable d’un tel outil est son orientation fonctionnelle. Les équipes qui pilotent ces outils sont rarement techniques et l’accessibilité de type WYSIWYG (What You See Is What You Get) met à la portée d’équipes fonctionnelles des modifications jusqu’à présent réservées à des développeurs.

La rapidité de paramétrage de ces tests, l’absence de développement, ou d’intégration à un planning de mise en production, représentent un gain notable de temps et d’argent. Un responsable CRO ou un chef de produit a virtuellement la possibilité d’exposer des variantes n’importe où sur un site ou application mobile. Il sera ensuite en capacité de valider des hypothèses en quelques jours ou quelques semaines, pourvu que le volume de trafic auquel sont exposées ces variantes rendent l’échantillon représentatif.

Dès qu’un test aboutit, il pourra planifier les améliorations. Mais si le test n’est pas concluant, le responsable fonctionnel doit immédiatement ajuster son test A/B et relancer une campagne pour évaluer sa nouvelle hypothèse.

La fin des évolutions “au doigt mouillé”

L’A/B testing sonne le glas des évolutions “au doigt mouillé”, motivées par l’expérience personnelle ou l’intuition. Le résultat chiffré d’un test lui donnant sa légitimité, il réduit également le risque d’erreur. Le risque principal étant de choisir une évolution qui, une fois en production, se révèle négative en termes de performance.

Le risque d’erreur ne disparait pas avec l’A/B testing ! Mais il est fortement réduit et souvent limité à la phase de test. Or une erreur identifiée en production est évidemment beaucoup plus coûteuse à corriger qu’une mauvaise hypothèse en phase de test.

La mesure de l’impact des modifications est aussi beaucoup plus rapide. Vous pourrez en faire une estimation dès l’issue du test. Et les données pourront ensuite être comparée à celles fournies par les outils d’analyse (Google Analytics ou Piano) ou par les retours clients.

Il s’agit d’un point important des tests A/B : le retour d’expérience des utilisateurs. L’attention régulière aux comportements clients participe à la connaissance client et à notre capacité à répondre à leurs besoins. Qu’on y accède grâce à des “session replay”, ou via des retours utilisateurs plus classiques (formulaires en ligne ou verbatims).

 

Les étapes de l’A/B testing

Définir l’objectif du test

Sur la base de données quantitatives, comme une analyse de trafic (taux de conversion, taux de rebond), ou de données qualitatives (commentaire client, formulaire de satisfaction), vous identifiez des points de friction et imaginez des pistes d’amélioration. Sur cette base vous affinez des tests qui porteront sur des variations précises. Plus les variations sont précises et clairement identifiables, plus les résultats seront exploitables.

Concevoir les variantes

Une fois les variantes définies, elles sont implmentées dans l’outil. En fonction de la complexité de la variation et des capacités de l’outil, certaines peuvent nécessiter l’intervention d’experts techniques. Mais il faut noter que la majorité des A/B tests sont complètement opérables à la main des responsables métiers (ex : chef de projet, CRO).

Vous devrez d’abord sélectionner la population qui sera exposée au test (le segment). Ensuite créer la (les) variante(s), généralement depuis un outil WYSIWYG (voire du développement pour les tests plus complexes).

Une fois les variantes créées, décidez des objectifs de performance (KPI), afin de permettre à l’outil d’évaluer la performance des variantes.

Enfin, choisissez la part du trafic que vous allouez aux différentes variantes. Deux choix doivent être faits :

• quelle part du trafic total de la page exposez-vous au test et quelle part exposez-vous à la version originale ?
• (dans le cas de multiples variantes) dans quelle proportion distribuez-vous le trafic entre les variantes, 1, 2, n ?

L’allocation du trafic aura un impact sur la représentativité de l’échantillon. Avec le volume total et la durée du test, son ajustement influera donc aussi la validité du test.

Collecter les données

Une fois le test A/B lancé, vérifier régulièrement des résultats restera une bonne pratique. Dans un premier temps, pour vérifier le fonctionnement du test. Dans un second temps, pour mesurer la population exposée au test. Si elle est suffisamment représentative, le planning du test sera respecté. Si elle ne l’est pas assez, il suffira d’allonger la durée du test pour atteindre une exposition représentative.

Analyser les résultats

Une fois l’échantillon représentatif atteint, il est temps d’analyser les résultats et d’observer quelle variante aura eu le plus de succès. Quatre types de résultats peuvent être rencontrés et un seul donnera lieu à une modification en production :

• Le “faux positif”, soit une variante gagnante qui s’avère être fausse. Ici la vérification de l’indice de confiance peut éviter de s’emballer pour un résultat qui s’avèrera inexact. Et en cas de doute, un test A/A et le suivi continu de la performance, même après le test, seront également de bons systèmes d’alerte dans le cas d’un faux positif.
• Le “faux négatif”, quand aucune variante n’émerge alors que l’une d’entre elles est réellement plus performante. Ici le résultat est le même que lorsqu’il n’y a réellement pas de différence entre les résultats des variantes testées. Dans chacun de ces cas de figure, un test A/A peut aussi aider à confirmer la performance réelle du test.
• Enfin le résultat souhaité pour tout test : quand une “variante gagnante” est clairement identifiée. C’est bon, vous y êtes arrivés ! Il s’agit maintenant de transformer cette hypothèse gagnante en évolution poussée en production. Mais attention à toujours garder un œil sur les performances afin de repérer un éventuel cas de “faux positif”.

 

Le dispositif à prévoir autour de l’A/B testing

Comme nous l’évoquions juste avant sur la phase d’analyse des résultats, complétez l’A/B test par l’utilisation de données analytiques. Idéalement vous devriez toujours accompagner un dispositif d’A/B testing d’outils tels que Google Analytics ou Piano.

En amont d’un test ils permettent de mettre en évidence des incidents de parcours, comme l’observation  d’un taux de rebond anormal, ou des chiffres de fréquentation qui mettent en évidence des comportement utilisateurs non souhaités. Ils peuvent être à l’origine d’une réflexion d’A/B testing et apporteront une vision “témoin” du trafic avant le test. Vous pourrez par la suite les comparer à “l’après”.

Pendant le test, la surveillance des outils analytiques permet d’observer des variations de trafic qui viendraient fausser le résultat. Il sera alors possible de modérer l’analyse en fonction des observations.

Enfin, après le test ils peuvent venir confirmer la réussite ou l’échec d’une variation en apportant une argumentation chiffrée du résultat du test en plus de l’outil d’A/B testing utilisé.

 

Les limites des outils d’A/B testing

La guerre des cookies

Sur Internet, le moyen d’identifier un utilisateur est souvent le cookie, un fichier texte stocké sur le device de l’utilisateur. Or sur Internet comme ailleurs, les utilisateurs sont de plus en plus sensibilisés à la protection de leurs données personnelles. Cela a donné lieu à une levée de boucliers face aux cookies tiers (ou “3rd party cookies”) souvent utilisés à des fins publicitaires.

Apple fût l’un des premiers acteurs majeurs à protéger les utilisateurs de ses produits et notamment de son navigateur Safari :

• en 2017 avec l’introduction de l’ITP, une fonctionnalité empêchant les annonceurs de collecter les données des internautes
• puis en 2020 avec le blocage par défaut des cookies tiers

Aujourd’hui, tous les navigateurs offrent la possibilité de bloquer tous les cookies tiers. Les solutions d’A/B testing utilisant principalement ces cookies, elles se sont retrouvées dans une impasse.  Car sans identification des utilisateurs, les mesures de performance des tests risquent d’être faussées et les résultats du test non-exploitables.

La fin des cookies tiers a poussé les solutions d’A/B testing à l’utilisation des cookies internes (ou 1st party cookies). Ceux-ci sont associés au nom de domaine de la page visitée et permettent un tracking anonymisé des utilisateurs. Ils ne sont donc pas concernés par les blocages de navigateurs et sont respectueux des obligations RGPD.

Et quid des visiteurs qui refusent les cookies à l’arrivée sur votre site ? Pas de panique, leur refus ou leur absence de choix (l’option “continuer sans accepter”) n’impactera pas négativement votre test. L’outil d’A/B test observera normalement leur parcours utilisateur à travers la variante proposé. Il ne récoltera simplement pas les métadonnées utilisateur comme le type de device ou la résolution utilisée.

Alors attention à vos tests dont les déclencheurs sont dépendants des métadonnées (ex : ciblage d’une résolution de 1920×1080 pixels). Les internautes ne seront exposé à la variante qu’à condition d’avoir accepté les cookies.

En France, 39% des internautes refusent les cookies
-source CNIL 2022-

Le risque du “tout personnalisation” et le mirage du no-code

Un autre atout des outils d’A/B testing est la fonctionnalité de personnalisation. De même que l’on peut exposer les visiteurs à plusieurs variantes afin de choisir la plus performantes (test A/B), il est possible d’exposer 100% du trafic à une ou plusieurs modifications d’une page ou d’un parcours. On parle dans ce cas là d’une personnalisation.

Très accessible, car l’outil WYSIWYG est à la main des métiers, il est aussi très rapide en leur permettant de modifier le site sans avoir à passer par un cycle de développement – recette – mise en production. Certaines équipes métier seront ainsi tentées de passer tous leurs besoins de modification par ce biais. Et ça va venir poser plusieurs problèmes :

• La performance de la page risque d’être pénalisée : la personnalisation étant une surcouche de la page existante, le temps de chargement sera plus long qu’avec du développement pur.
• Le sujet de l’acceptation des cookies : car contrairement au test A/B, la personnalisation est entièrement dépendante de leur acceptation par l’internaute et un refus signifie qu’il passera complètement à côté de la modification à laquelle on souhaite l’exposer.
• La difficulté de dépannage : lorsque qu’un problème survient avec une personnalisation, le dépannage peut être plus complexe car il s’agit d’une surcouche d’un outil tiers alors qu’il est souvent plus facile pour les équipes techniques de résoudre les problèmes en accédant directement au code source.

La personnalisation est donc un très bon moyen d’apporter une modification temporaire rapidement et sans sollicitation des équipes techniques. Mais gardez à l’esprit que certains utilisateurs ne la verront pas et qu’elle ne remplacera pas une vraie modification de la page dans le cas d’un besoin plus pérenne.