Comment établir un référentiel Single Source of Truth (SSOT) pour l'A/B Testing
Sans des données fiables, impossible de formuler des hypothèses valides pour améliorer l’expérience de vos utilisateurs. Leur pertinence repose entièrement sur la qualité de vos données. Vous ne pourrez pas faire confiance aux résultats de vos tests si vous n'êtes pas sûr d'avoir sous les yeux des indicateurs précis.
Pour cette raison, il est essentiel d’organiser votre programme de testing autour d'un référentiel de données unique, ou Single Source of Truth (SSOT). Voici quelques bonnes pratiques à suivre, testées et approuvées par Kameleoon sur le terrain.
1 Qu'est-ce qu'un référentiel SSOT ?
Créer un SSOT consiste à formaliser une source de données fiable et commune à l’ensemble des équipes.
Sans SSOT, vous prenez le risque d'une fragmentation de vos données en silos gardés par différentes équipes pour différentes fonctions. Il n'y a alors aucune standardisation, aucun consensus et aucun moyen de savoir si l'on prend des décisions basées sur les meilleures informations disponibles.
Avec cette pratique, la qualité des données relatives au comportement de vos clients est garantie. Vous pouvez donc baser vos hypothèses de tests et vos réflexions stratégiques pour favoriser la croissance de votre entreprise sur des données fiables.
2 Comment utiliser un SSOT pour le testing ?
Les équipes d'expérimentation sont souvent noyées de données générées par leur plateforme d'analytics, leur CRM, leurs solutions de testing... Établir un SSOT permet de prendre des décisions basées sur des données alignées avec les besoins/objectifs des autres équipes.
Chez Kameleoon, nous vous recommandons d'utiliser votre plateforme d'analytics comme SSOT. Même si vous passez vos journées à travailler sur une plateforme de testing, d'autres équipes peuvent avoir besoin d'utiliser les données analytics à d'autres fins. Choisissez l'ensemble de datas utilisé par le plus grand nombre d'équipes pour avoir un référentiel commun au sein de votre entreprise.
Il n’est pas rare d’observer des écarts entre les données des différentes plateformes. Prenons l'exemple d'un des clients de Kameleoon qui lance une campagne pour optimiser le moteur de recherche de son site web. Le client suit le trafic sur une page d'accès grâce à des tests server-side.
Il rencontre rapidement un problème fréquent dans de nombreux programmes d'expérimentation : les données Google Analytics et de son outil d’expérimentation présentent un écart supérieur à 9% sur le nombre de visites de la page.
Pour un site de e-commerce avec plus d'un million de visiteurs par mois, choisir un ensemble de données plutôt qu’un autre change considérablement les rapports de performance des KPI de l'entreprise. Si des petites ou moyennes entreprises peuvent se permettre d'ignorer des disparités allant jusqu'à 10 % dans les statistiques de visite, cet écart de 9 % remet en question la pertinence des données pour l'équipe d'expérimentation.
S’il existe un écart entre les données de certains outils, il est nécessaire de connaître les raisons de cet écart afin de les corriger. Ces écarts de données sont fréquents et peuvent avoir différentes sources :
Dans le cas de notre client, l’équipe doit vérifier le suivi des données de visite et établir un SSOT grâce à 6 étapes pour harmoniser ses données de testing et tirer le meilleur parti de son programme d'expérimentation.
3 Harmoniser les données de test et établir un SSOT en 6 étapes
1. Réalisez un test A/A
Un test A/B compare une ancienne à une nouvelle version de votre page ou produit. Lors d’un test A/A, on compare les performances de deux versions identiques afin de comparer les données générées par chaque plateforme de suivi. Le test A/A sert de méthode de calibrage avant de lancer un premier test A/B ou lors de l’intégration d’un nouvel outil.
Dans un monde idéal, votre test A/A renverra des résultats identiques. Dans la réalité, cela se produit rarement, mais vous découvrirez cependant quel est l'écart auquel vous devez vous attendre.
Dans le cas de notre client, le test A/A permet de voir quelles sont les valeurs qu'obtient Google Analytics par rapport à Kameleoon pour les mêmes sessions, utilisateurs, visites, conversions…
2. Installez vos outils sur les mêmes pages
L'emplacement du snippet est une cause fréquente de divergence des données, surtout si votre expérimentation cible le site entier. En effet, de nombreux outils d'expérimentation considèrent le « site entier » comme l'ensemble des pages qui contiennent l'extrait de code. Cela peut même inclure votre site de test si des snippets s'y trouvent et fausser vos résultats.
Dans le cas de notre client, suite au test A/A, nous lui avons conseillé de vérifier que ses outils étaient implémentés sur les mêmes pages.
Pour cela, il a affiché une répartition de ses données en fonction de l'URL des pages visitées. Cela lui a permis d’identifier toutes les principales URL où l'expérimentation a eu lieu, de manière à identifier celles où son outil de testing n'aurait pas dû charger. Voici à quoi ressemble cette option dans Kameleoon :
Après une analyse approfondie, Kameleoon a pu déterminer que le client qui présentait des écarts de données rencontrait ce problème de snippet. Google Analytics et l'outil de testing ne s'exécutaient pas sur les mêmes pages.
Là où Google Analytics suivait tout le trafic arrivant sur leur page de résultats de recherche, l'outil de testing avait été configuré avec un paramètre plus restreint : l'expérimentation comptait les visites sur la page d'accès uniquement après avoir effectué une recherche dans la barre de recherche. Les pages avaient l'air d'être les mêmes, mais les URL étaient différentes, ce qui créait un écart entre les données.
3. Suivez les visiteurs et les visites de la même manière sur tous vos outils
Le nombre de visiteurs ou de visites qu'enregistrent vos outils ne correspondra jamais exactement aux utilisateurs et sessions dans la réalité. Vous pouvez cependant vous assurer que les visites sont bien comptabilisées de la même manière sur toutes vos plateformes afin de minimiser les écarts. Contrôlez combien de visiteurs et de visites sont comptabilisés dans votre outil d'analytics et vérifiez que les valeurs sont les mêmes dans votre outil de testing ou que vous pouvez les modifier.
Dans le cas de notre client, nous savons que dans Google Universal Analytics (GA3), par défaut, une visite peut se terminer de deux manières :
- Expiration basée sur le temps : la session se termine après 30 minutes d'inactivité ou à minuit. Alors que dans Kameleoon, elle prend systématiquement fin après 30 minutes d'inactivité.
- Changement de la campagne : si le même visiteur arrive via une campagne, part après 2 minutes, puis revient via une autre campagne 2 minutes plus tard, Google Analytics comptera ceci comme deux visites. Certains outils d'A/B testing en comptent une seule.
Nous lui avons conseillé de modifier la durée au-delà de laquelle les sessions et campagnes prennent fin dans les paramètres de session de GA.
4. Créez des filtres de navigateurs et de versions dans votre outil d'analytics
Certains navigateurs (ou versions de navigateurs) sont comptabilisés différemment entre outils d’analytics et de testing.
Par exemple, de nombreuses plateformes d'A/B testing ne fonctionnent pas sur Internet Explorer, et les visites qui ont lieu sur ce navigateur sont automatiquement exclues des tests. Néanmoins, IE peut tout de même créer des divergences si vous ciblez de grandes entreprises qui continuent de s'en servir.
Un autre problème de suivi courant est que les outils d’analytics sont généralement compatibles avec toutes les versions des navigateurs, là où les outils de testing ne sont totalement compatibles qu'avec les dernières versions.
4. Créez des filtres de navigateurs et de versions dans votre outil d'analytics
Certains navigateurs (ou versions de navigateurs) sont comptabilisés différemment entre outils d’analytics et de testing.
Par exemple, de nombreuses plateformes d'A/B testing ne fonctionnent pas sur Internet Explorer, et les visites qui ont lieu sur ce navigateur sont automatiquement exclues des tests. Néanmoins, IE peut tout de même créer des divergences si vous ciblez de grandes entreprises qui continuent de s'en servir.
Un autre problème de suivi courant est que les outils d’analytics sont généralement compatibles avec toutes les versions des navigateurs, là où les outils de testing ne sont totalement compatibles qu'avec les dernières versions.
Dans le cas de notre client, nous lui avons proposé de créer dans GA des filtres personnalisés basés sur les navigateurs et les versions qui l’intéressent, pour que toutes les plateformes affichent les mêmes valeurs.
Par exemple, dans la section Vue, voici comment vous pouvez exclure une ancienne version de Google Chrome :
5. Filtrez le trafic problématique dans tous vos outils
Faites en sorte que vos données SSOT restent les plus propres possibles en collectant des données provenant uniquement de membres valides de votre audience. Vous ne voulez pas polluer vos données avec des bots, des trolls, des bugs de suivi ou toute autre anomalie de trafic.
Les outils avancés d'A/B testing proposent un certain nombre de paramètres clé en main de filtrage des bots. Ils peuvent, par exemple, éliminer le trafic provenant de statistiques collectées s'ils détectent un comportement anormal ou si la session affiche une activité suspecte.
Dans le cas de notre client, nous lui avons conseillé de filtrer le trafic dans GA pour détecter et exclure les bots via les critères suivants :
- Durée de la visite > 120 minutes
- Durée de la visite < 100 millisecondes
- Nombre d'événements (conversions, clics, ciblage, produit, vue de page, etc.) > 10 000
Nous lui avons également recommandé d'exclure le trafic interne pour ne pas comptabiliser les données issues des comportements des membres de son organisation.
Pour exclure le trafic interne dans Google Analytics, rendez-vous dans Admin > Tous les filtres puis créez un nouveau filtre. Choisissez pour type de filtre « defined ». Puis ajoutez les plages d'IP internes que vous souhaitez exclure.
6. Évitez les bloqueurs de publicités
Certains visiteurs utilisent des bloqueurs de publicités qui peuvent bloquer les trackers client-side.
Si une part importante de vos visiteurs utilisent des bloqueurs de publicités sur leur navigateur, il est fort probable que vous observiez des divergences entre le nombre de visites enregistrées par votre outil d'A/B testing et votre plateforme d'analytics, qui ne sont pas nécessairement bloqué de la même manière. Pour contourner ces écueils, commencez par mettre en évidence le pourcentage de personnes dont l’adblocker empêche l’exécution du script de votre solution de testing ou d’analytics puis choisissez de filtrer votre trafic pour ignorer ces visiteurs ou de contourner le blocage.
Dans le cas de notre client, nous lui avons proposé d’identifier le volume de personnes concernées en paramétrant l’envoi d’un évènement à la plateforme analytics au démarrage de Kameleoon. Une fois ce pourcentage définit, nous avons expliqué à notre client comment s’affranchir de ce blocage en 2 étapes :
- En pratiquant leself hosting du script : Le script ne sera plus exécuté sous le nom de Kameleoon mais via une URL hébergée sur le site de notre client.
- En envoyant les datas à Kameleoon via un “proxy” pour faciliter les échanges et éviter l’interception des données par l’adblock.
Attention : Ces recommandations concernent exclusivement les tests en client-side. Le testing server-side n’est pas impacté car les tests et le tracking sont exécutés sur vos serveurs.
Conclusion
En enquêtant sur les paramètres de votre outil de testing qui ne correspondent pas à votre suivi d'analytics, vous pouvez identifier comment modifier vos paramètres pour réduire les écarts et choisir quel nombre de visiteurs enregistrer.
