Meilleures pratiques pour établir une source unique de vérité (SSOT) pour les tests A/B

Vos tests CX vivent ou meurent en fonction de la qualité de vos données. Vous ne pouvez pas formuler d'hypothèses valides et vérifiables à l'aide de données douteuses. Et vous ne pouvez pas faire confiance aux résultats de vos tests si vous ne savez pas que vous recherchez des mesures précises.

C'est pourquoi vous devez construire votre programme de test autour d'un ensemble de données de source unique de vérité (SSOT). Si vous ne le pouvez pas, même le test A/B le plus simple manquera de valeur. Cet article explore pourquoi l'établissement d'un SSOT est si important et partage certaines des meilleures pratiques testées sur le terrain que nous avons développées pour le faire ici chez Kameleoon.

Qu'est-ce qu'un SSOT

La prise de décision commerciale moderne doit être basée sur les données. Le maintien d'un SSOT signifie que pour l'expérimentation CX, ou toute autre fonction, vous standardisez sur une source de données comme la «vérité» définitive autour de laquelle vous menez le travail de cette équipe et informez les décisions de votre entreprise.

Sans SSOT, vous risquez de fragmenter vos données en silos gardés par différentes équipes pour différentes fonctions. Il n'y a pas de normalisation, pas de consensus et aucun moyen de savoir si quelqu'un prend des décisions basées sur les meilleures informations disponibles.

Un SSOT n'est pas une technologie ou un système particulier. Il s'agit d'une pratique commerciale conçue pour obtenir des résultats optimaux des activités de votre équipe. Certaines entreprises ont économisé des millions en passant à une stratégie de données SSOT sans même toucher au travail sous-jacent.

Des études ont montré que les mesures de haute qualité du comportement des clients restent les données les plus recherchées pour éclairer les décisions stratégiques. Depuis plusieurs années consécutives, dans l'enquête annuelle auprès des PDG de PricewaterhouseCoopers, les PDG considèrent qu'il s'agit de la mesure la plus importante qu'ils souhaitent pour la planification stratégique.

Qu'est-ce qu'un test A/B ?

Le test A/B est une méthode permettant d'expérimenter des sites Web, des applications mobiles ou des publicités en comparant les performances d'une version originale (la version A ou de contrôle) à une version B modifiée. L'objectif est de collecter des données de performance pour chacun, d'effectuer des analyses statistiques et de déterminer, sur la base des données, quelle version a le mieux fonctionné.
Les tests A/B fonctionnent pour tester plus que de simples éléments de page Web. Par exemple, vous pouvez l'utiliser pour optimiser les prix, valider les fonctionnalités du produit et personnaliser les sites Web en fonction des différents segments de visiteurs. En outre, les tests A/B sont à la base de nombreuses autres techniques d'optimisation CX, notamment les tests multivariés, la recommandation de produits et le ciblage basé sur les profils.

Qui a besoin d'un SSOT pour ses tests ?

Les équipes d'expérimentation parcourent les données générées dans leurs plateformes d'analyse, leur CRM, leurs plateformes de test, etc. Ils doivent établir un SSOT pour les tests afin de clarifier ce que leurs équipes veulent faire. Prenons un exemple.

L'un des clients de Kameleoon a lancé une campagne pour optimiser la fonction de recherche de son site Web. Ils ont effectué des tests côté serveur impliquant le suivi du trafic vers une page d'accès.

Mais ils ont rencontré un problème auquel sont confrontés de nombreux programmes d'expérimentation : les données de Google Analytics indiquaient un certain nombre de visites de pages, et leur outil d'expérimentation en indiquait un autre. La différence était de plus de 9 %.

Étant un site Web de commerce électronique avec plus d'un million de visiteurs par mois, le choix de l'ensemble de données auquel faire confiance a fait une grande différence dans les rapports KPI de l'entreprise. Alors que certaines marques moyennes et grandes entreprises peuvent ignorer des disparités allant jusqu'à 10 % dans les statistiques des visiteurs, une disparité de 9 % dans les données a rendu nerveuse l'équipe d'expérimentation de cette société.

Cette équipe n'avait que récemment obtenu l'adhésion à son programme d'expérimentation, y compris un budget pour investir dans des outils comme Kameleoon. Ils espéraient des tests avec des conclusions claires. Au lieu de cela, l'exactitude de leurs données était mise en doute. Ils avaient besoin d'établir un SSOT.

Nous avons aidé cette entreprise à nettoyer son suivi des données des visiteurs, à établir un SSOT et à obtenir les résultats des tests dont elle avait besoin pour se développer. Pour ce faire, nous les avons aidés à adopter sept bonnes pratiques SSOT. Nous partageons ces meilleures pratiques ici, car toute équipe CX cherchant à gérer ses données de test et à tirer le meilleur parti de son programme d'expérimentation peut les utiliser pour se développer.

Meilleures pratiques pour éliminer les écarts de données de test et établir un SSOT

1. Avant de faire quoi que ce soit d'autre, effectuez un test A/A

Alors qu'un test A/B compare une ancienne à une nouvelle version de votre produit ou de votre page, un test A/A compare ce qui est comparable. Pourquoi voudriez-vous faire cela ? Vous pouvez ainsi comparer les données générées par chaque plateforme de monitoring.

Dans le test A/A, les deux variantes sont identiques, mais les utilisateurs qui les verront seront différents :

Comment agir

Avant d'effectuer des tests A/B sérieux ou de déployer une nouvelle implémentation dans laquelle vous souhaitez collecter des données, exécutez un test A/A pour calibrer. Dans un monde parfait, votre test A/A renverra des résultats identiques. En réalité, cela arrive rarement, mais vous saurez quand même à quel point vous avez affaire à un écart.

Par exemple, l'exécution d'un test A/A vous permet de voir quelles mesures Google Analytics obtient par rapport à votre outil de test sur les mêmes sessions, utilisateurs, visites, conversions ou toute autre mesure que vous souhaitez mesurer.

2. Suivez les visiteurs et les visites de la même manière dans tous vos outils

Le nombre de visiteurs ou de visites suivis par vos outils d'analyse ne correspondra jamais précisément aux utilisateurs et aux sessions. Cependant, vous pouvez vous assurer que les visites sont comptées de la même manière dans vos plateformes d'analyse et A/B pour réduire l'écart.

Dans Google Analytics, une visite se termine de deux manières :

• Expiration basée sur le temps : Ici, la session expire après 30 minutes d'inactivité ou à minuit. Alors que, par exemple, dans Kameleoon, c'est après 30 minutes d'inactivité.

• Changement de campagne : Si le même visiteur arrive via une campagne, repart au bout de 2 minutes, puis revient via une autre campagne 2 minutes plus tard, Google Analytics comptera deux visites. Certains outils de test A/B verront cela comme tel.

Comment agir

Vérifiez comment les visiteurs et les visites sont comptés dans votre outil d'analyse et assurez-vous qu'il en est de même pour votre outil de test. Ou que vous pouvez le changer. Chez Kameleoon, nous vous recommandons d'utiliser votre plateforme d'analyse comme unique source de vérité.

Dans GA, vous pouvez modifier le délai d'expiration des sessions et des campagnes dans les paramètres de session.

Pourquoi? Les SSOT doivent être définis au niveau organisationnel. Ainsi, même si votre équipe de test passe toute sa journée à travailler avec les données de votre plate-forme de test, d'autres équipes peuvent toujours avoir besoin de référencer les données de GA à d'autres fins. Définissez le SSOT comme étant l'ensemble de données référencé par le plus large éventail d'équipes de votre organisation.

3. Créez des filtres de navigateur et de version dans votre outil d'analyse

De nombreuses plates-formes de test A/B ne fonctionnent pas sur Internet Explorer, de sorte que toutes les visites dans ce navigateur sont automatiquement exclues des rapports d'expérience. Mais IE peut toujours entraîner une divergence de données si vous ciblez de grandes organisations héritées qui l'utilisent.

Un autre problème de suivi potentiel est que Google Analytics est compatible avec toutes les versions de navigateur, tandis que les outils de test A/B ne conservent généralement une compatibilité totale qu'avec les dernières versions.

Comment agir

Dans Google Analytics, créez des filtres personnalisés basés sur les navigateurs et les versions de navigateur qui vous intéressent afin que toutes les plates-formes correspondent. Vous faites cela dans

Par exemple, sous Afficher, voici comment exclure une ancienne version de Google Chrome :

4. Filtrez le trafic problématique dans tous vos outils

Gardez votre ensemble de données SSOT aussi propre que possible en collectant uniquement les données des membres légitimes de l'audience. Vous ne voulez pas brouiller vos données avec des robots, des trolls, des bugs de suivi ou tout autre trafic aberrant. Ne vous inquiétez pas des baisses de volume, la qualité de vos résultats augmentera.

Comment agir

Les outils de test A/B avancés offrent plusieurs paramètres de filtrage de bot prêts à l'emploi. Par exemple, ils peuvent supprimer automatiquement le trafic des statistiques collectées s'ils détectent un comportement aberrant ou si la session tombe dans une condition d'activité suspecte.

D'autre part, si vous utilisez GA, c'est à vous de décider comment détecter et exclure le trafic de bot de vos données d'analyse à l'aide de filtres. Pour référence, voici quelques conditions que vous voudrez peut-être exclure.

• Durée de la visite > 120 minutes
• Durée de la visite < 100 millisecondes
• Nombre d'événements (conversions, clics, ciblage, produit, page vue, etc.) > 10K

Vous souhaitez également exclure le trafic interne au sein de votre organisation. N'oubliez pas que l'objectif de la création de cet ensemble de données SSOT est d'avoir une source définitive de données sur vos clients réels, et non sur vos collègues.

Pour filtrer le trafic interne dans GA, accédez au panneau d'administration > Tous les filtres et créez un nouveau filtre. Définissez le type de filtre sur "indéfini". Ajoutez ensuite les plages d'adresses IP internes que vous souhaitez exclure.

5. Évitez les bloqueurs de publicités

De nombreux visiteurs utilisent des bloqueurs de publicités tels que Adblock, Ghostery et uBlock. Certains adblockers peuvent également bloquer les trackers côté client, y compris les événements d'analyse des outils d'expérimentation.

Si une partie importante de vos visiteurs ont des bloqueurs de publicités activés dans leur navigateur, il y a de fortes chances que le nombre de visites enregistrées varie entre votre outil de test A/B et votre plateforme d'analyse.

Comment agir

Certaines plateformes peuvent fournir des URL de demande de suivi "sur site" qui leur permettent d'éviter d'être bloquées par des bloqueurs de publicités. Ici, le suivi se produit côté serveur, de sorte que le blocage du code côté client, comme celui d'un bloqueur de publicités, n'arrête pas le suivi légitime. Activez-le sur toutes les plateformes possibles.

Une autre façon de mieux comprendre l'écart entre vos plateformes d'analyse et de test consiste à envoyer un événement à votre plateforme d'analyse après le chargement de votre outil de test. Cela devrait vous donner une idée précise du pourcentage de visiteurs utilisant des bloqueurs de publicités qui bloquent votre outil de test A/B. Ensuite, vous devrez filtrer votre trafic pour exclure les visiteurs utilisant des bloqueurs de publicités.

6. Installez vos outils sur toutes les mêmes pages

Le placement d'extraits de code est une cause première courante d'écarts de données, en particulier si vous souhaitez exécuter un test ciblant un site entier. La raison en est que de nombreux outils d'expérimentation traitent le "site entier" comme toutes les pages contenant son extrait de code. Malheureusement, cela pourrait même inclure votre site de développement si vous y avez copié des extraits.

Comment agir

Si vous ne l'avez pas déjà fait, c'est le moment idéal pour exécuter ce test A/A pour calibrer vos plates-formes. Ensuite, assurez-vous que tous vos outils sont implémentés sur les mêmes pages.

Une façon de déterminer si ce n'est pas le cas consiste à ventiler vos données en fonction des URL des pages visitées. Cela vous montrera toutes les URL principales où l'expérience s'est déroulée afin que vous puissiez identifier celles où votre outil de test n'aurait pas dû se charger. Voici à quoi ressemble cette option dans Kameleoon :

Dernières pensées

Après une analyse minutieuse, Kameleoon a déterminé que le client avec une divergence de données rencontrait ce dernier problème. Google Analytics et son outil de test ne fonctionnaient pas sur les mêmes pages.

Alors que GA suivait tout le trafic vers leur page de résultats de recherche, ils ont configuré leur outil de test avec un paramètre plus étroit : l'expérience a compté les visites sur la page d'accès uniquement après une recherche dans la barre de recherche.

Alors que les deux pages se ressemblaient, les URL étaient différentes, créant une divergence de données. Cependant, une fois résolus, ils disposaient d'un SSOT fiable pour tester les données et devaient générer de nombreuses informations précieuses.

En identifiant où les paramètres prêts à l'emploi de votre outil de test ne correspondent pas à votre suivi analytique, vous pouvez décider du nombre de visiteurs à signaler ou de la manière d'utiliser vos paramètres pour minimiser la différence.

Éliminez les écarts, établissez une source unique de vérité et rassemblez vos équipes autour d'un ensemble de données commun. L'établissement d'un SSOT est la première étape vers des tests meilleurs, plus fiables et plus perspicaces.