Comment surveiller la qualité des données — un guide détaillé

Il est plus facile de prévenir une erreur dans la collecte de données que de gérer ses conséquences. La sagacité de vos décisions commerciales dépend de la qualité de vos données. Dans cet article, nous vous expliquons comment vérifier la qualité des données à toutes les étapes de la collecte, de l'énoncé des travaux aux rapports complétés.

Malheureusement, de nombreuses entreprises qui dépensent des ressources considérables pour stocker et traiter des données prennent encore des décisions importantes basées sur l'intuition et leurs propres attentes plutôt que sur les données.

Pourquoi cela arrive-t-il ? La méfiance à l'égard des données est exacerbée par les situations où les données apportent une réponse en contradiction avec les attentes du décideur. De plus, si quelqu'un a rencontré des erreurs dans les données ou les rapports dans le passé, il est enclin à privilégier l'intuition. Cela est compréhensible, car une décision prise sur la base de données incorrectes peut vous faire reculer plutôt que vous faire avancer.

Imaginez que vous avez un projet multi-devises. Votre analyste a configuré Google Analytics dans une devise et le responsable marketing en charge de la publicité contextuelle a configuré l'importation des coûts dans Google Analytics dans une autre devise. Par conséquent, vous obtenez un retour sur les dépenses publicitaires (ROAS) irréaliste dans vos rapports de campagne publicitaire. Si vous ne remarquez pas cette erreur à temps, vous pouvez soit désactiver les campagnes rentables, soit augmenter le budget des campagnes déficitaires.

De plus, les développeurs sont généralement très occupés et la mise en œuvre de l'analyse Web est une tâche secondaire pour eux. Lors de la mise en œuvre de nouvelles fonctionnalités - par exemple, un nouveau design pour une unité avec des accessoires - les développeurs peuvent oublier de vérifier que les données sont collectées dans Google Analytics. En conséquence, lorsque vient le temps d'évaluer l'efficacité du nouveau design, il s'avère que la collecte de données a été interrompue il y a deux semaines. Surprise.

Imaginez que vous avez fait une erreur lors de la phase de spécification. Si vous le trouvez et le corrigez immédiatement, le correctif sera relativement bon marché. Si l'erreur est révélée après la mise en œuvre, lors de la création de rapports ou même lors de la prise de décisions, le coût de sa correction sera très élevé.

La collecte de données comprend généralement cinq étapes clés :

1. Formuler un défi commercial. Supposons que vous ayez besoin d'évaluer l'efficacité d'un algorithme de sélection de biens dans un bloc de recommandations.
2. L'analyste ou la personne responsable de la collecte des données conçoit un système de mesures à suivre sur le site.
3. La personne configure Google Analytics et Google Tag Manager.
4. Celui envoie des termes de référence pour les développeurs à mettre en œuvre.
5. Une fois que le développeur a implémenté les métriques et configuré la collecte de données, l'analyste travaille avec les rapports.

À presque toutes ces étapes, il est très important de vérifier vos données. Il est nécessaire de tester la documentation technique, les paramètres de Google Analytics et de Google Tag Manager et bien sûr la qualité des données collectées sur votre site ou dans votre application mobile.

Avant de passer à chaque étape, examinons quelques exigences pour les tests de données :

• Vous ne pouvez pas tester sans outils. Au minimum, vous devrez travailler avec la console développeur dans un navigateur.
• Il n'y a pas de résultat attendu abstrait. Vous devez savoir exactement avec quoi vous devriez vous retrouver. Nous avons toujours un certain ensemble de paramètres que nous devons collecter pour toute interaction de l'utilisateur avec un site. Et nous connaissons les valeurs que ces paramètres doivent prendre.
• Des connaissances particulières sont nécessaires. Au minimum, vous devez être familiarisé avec la documentation des outils d'analyse Web que vous utilisez, la pratique et l'expérience des acteurs du marché.

Comme nous l'avons mentionné, il est beaucoup plus facile de corriger une erreur si vous l'attrapez dans les spécifications. Par conséquent, la vérification de la documentation commence bien avant la collecte des données. Voyons pourquoi nous devons vérifier votre documentation.

Objectifs de la documentation des tests :

• Corrigez les erreurs avec peu d'effort. Une erreur dans la documentation est juste une erreur dans le texte écrit, donc tout ce que vous avez à faire est de faire une modification rapide.
• Empêcher le besoin de modifications futures qui pourraient affecter l'architecture du site/de l'application.
• Protégez la réputation de l'analyste. Un instrument comportant des erreurs de développement pourrait remettre en cause la compétence de celui qui l'a rédigé.

Erreurs les plus courantes dans les spécifications :

1. Fautes de frappe. Un développeur peut copier le nom des paramètres sans les lire. Il ne s'agit pas de fautes de grammaire ou d'orthographe, mais plutôt de noms incorrects de paramètres ou de valeurs que ces paramètres contiennent.
2. Ignorer les champs lors du suivi des événements. Par exemple, un message d'erreur peut être ignoré si un formulaire n'a pas été soumis avec succès.
3. Noms de champ non valides et non-concordance avec le schéma de commerce électronique amélioré. La mise en œuvre d'un commerce électronique amélioré avec une variable dataLayer nécessite une documentation claire. Il est donc préférable de vérifier deux fois tous les champs lors de la rédaction de votre cahier des charges.
4. Vous n'avez pas de prise en charge des devises pour un site multidevise. Ce problème est pertinent pour tous les rapports liés aux revenus.
5. Les limites d'accès ne sont pas prises en compte. Par exemple, disons qu'il peut y avoir jusqu'à 30 produits différents sur une page de catalogue. Si nous transférons des informations sur les vues en même temps pour tous les produits, il est probable que le hit dans Google Analytics ne sera pas transféré.

La prochaine étape après avoir vérifié votre documentation technique consiste à vérifier vos paramètres Google Analytics et Google Tag Manager.

Pourquoi tester les paramètres de Google Analytics et de Google Tag Manager ?

• Assurez-vous que les paramètres sont correctement traités par les systèmes de collecte de données. Google Analytics et Google Tag Manager peuvent être configurés en parallèle avec la mise en place des métriques sur votre site. Et tant que l'analyste n'aura pas terminé, les données n'apparaîtront pas dans Google Analytics.
• Facilitez le test des métriques intégrées sur le site. Vous n'aurez qu'à vous concentrer sur une partie du travail du développeur. À l'étape finale de X, vous devrez rechercher la cause de l'erreur directement sur le site, et non dans les paramètres de la plate-forme.
• Faible coût de réparation car il n'est pas nécessaire d'impliquer les développeurs.

Erreurs les plus courantes dans Google Analytics :

1. Une variable personnalisée n'a pas été créée. Ceci est particulièrement pertinent pour les comptes Google Analytics 360, qui peuvent avoir jusqu'à 200 métriques et 200 paramètres. Dans ce cas, il est très facile d'en manquer un.
2. L'étendue d'accès spécifiée n'est pas valide. Vous ne pourrez pas détecter cette erreur lors de la phase de révision de dataLayer ou en examinant le hit que vous envoyez, mais lorsque vous créez un rapport, vous verrez que les données ne se présentent pas comme prévu.
3. Vous obtenez un doublon d'un paramètre existant. Cette erreur n'affecte pas les données envoyées, mais elle peut entraîner des problèmes lors de la vérification et de la création de rapports.

Erreurs les plus courantes dans Google Tag Manager :

1. Aucun paramètre n'a été ajouté, comme la balise Universal Analytics ou la variable Paramètres Google Analytics.
2. L'index de la balise ne correspond pas au paramètre dans Google Analytics, ce qui crée un risque que les valeurs soient transmises aux mauvais paramètres. Par exemple, supposons que vous ayez spécifié l'indice du paramètre du nombre d'utilisateurs dans GTM pour le paramètre d'évaluation de l'élément. Cette erreur est susceptible d'être immédiatement détectée lors de la création de rapports, mais vous ne pourrez plus influencer les données collectées.
3. Nom de variable non valide spécifié dans le dataLayer. Lorsque vous créez un dataLayer, assurez-vous de spécifier sous quel nom la variable sera trouvée dans le tableau dataLayer. Si vous tapez ou écrivez une autre valeur, cette variable ne sera jamais lue à partir du dataLayer.
4. Le suivi amélioré du commerce électronique n'est pas activé.
5. Le déclencheur de démarrage n'est pas configuré correctement. Par exemple, l'expression régulière pour déclencher X est écrite de manière incorrecte ou il y a une erreur dans le nom de l'événement.

La dernière étape du test consiste à tester directement sur le site. Cette étape nécessite plus de connaissances techniques car vous devrez regarder le code, vérifier comment le conteneur est installé et lire les journaux. Il faut donc être averti et utiliser les bons outils.

Pourquoi tester les métriques embarquées ?

• Vérifiez que ce qui est implémenté est conforme aux spécifications et enregistrez les éventuelles erreurs.
• Vérifiez si les valeurs à envoyer sont adéquates. Vérifier que les paramètres transmettent les valeurs à transmettre. Par exemple, la catégorie de biens ne transmet pas son nom à la place.
• Donner des commentaires aux développeurs sur la qualité de la mise en œuvre. Sur la base de ces commentaires, les développeurs peuvent apporter des modifications au site.

Les erreurs les plus courantes :

1. Tous les scénarios ne sont pas couverts. Par exemple, supposons qu'un article puisse être ajouté au panier sur le produit, le catalogue, la promotion ou la page maître, c'est-à-dire partout où il y a un lien vers l'article. Avec autant de points d'entrée, vous pouvez manquer quelque chose.
2. La tâche n'est pas implémentée sur toutes les pages. Autrement dit, pour certaines pages ou certaines partitions/répertoires, les données ne sont pas du tout collectées ou ne sont que partiellement collectées. Pour éviter de telles situations, nous pouvons établir une liste de contrôle. Dans certains cas, nous pouvons avoir jusqu'à 100 vérifications pour une fonction.
3. Tous les paramètres ne sont pas implémentés ; c'est-à-dire que le dataLayer n'est que partiellement implémenté.
4. Le schéma dataLayer pour le commerce électronique amélioré est rompu. Cela est particulièrement vrai pour les événements tels que l'ajout d'articles au panier, le déplacement entre les étapes de paiement et le clic sur des articles. L'une des erreurs les plus courantes dans la mise en œuvre du commerce électronique amélioré est l'absence de crochets dans le tableau Produits .
5. Le dataLayer utilise une chaîne vide au lieu de null ou undefined pour mettre à zéro le paramètre. Dans ce cas, les rapports Google Analytics contiennent des lignes vides. Si vous utilisez null ou undefined, cette option ne sera même pas incluse dans le hit que vous envoyez.

Outils que nous utilisons pour tester les données :

• Extension Chrome du débogueur Google Analytics
• GTM Debugger, que vous pouvez utiliser pour activer le mode aperçu dans Google Tag Manager
• La commande dataLayer dans la console développeur
• L'onglet Réseau dans la console développeur
• Extension Chrome Google Tag Assistant

Regardons de plus près ces outils.

Pour commencer, vous devez installer cette extension dans votre navigateur et l'activer. Ouvrez ensuite l'ID de page et accédez à l'onglet Console. Les informations que vous voyez sont fournies par l'extension.

Cet écran affiche les paramètres qui sont transmis avec les hits et les valeurs qui sont transmises pour ces paramètres :

Il existe également un bloc de commerce électronique étendu. Vous pouvez le trouver dans la console comme ec :

De plus, des messages d'erreur s'affichent ici, par exemple en cas de dépassement de la limite de taille d'accès.

Si vous avez besoin de vérifier la composition du dataLayer, le moyen le plus simple consiste à taper la commande dataLayer dans la console :

Voici tous les paramètres qui sont transmis. Vous pouvez les étudier en détail et les vérifier. Chaque action sur le site est reflétée dans le dataLayer. Disons que vous avez sept objets. Si vous cliquez sur un champ vide et appelez à nouveau la commande dataLayer , un huitième objet devrait apparaître dans la console.

Pour accéder au débogueur Google Tag Manager, ouvrez votre compte Google Tag Manager et cliquez sur le bouton Aperçu :

Ouvrez ensuite votre site et actualisez la page. Dans le volet inférieur, un panneau devrait apparaître et afficher toutes les balises en cours d'exécution sur cette page.

Les événements ajoutés au dataLayer sont affichés à gauche. En cliquant dessus, vous pouvez vérifier la composition en temps réel du dataLayer.

Fonctionnalités des tests de navigateur mobile :

• Sur les smartphones et les tablettes, les sites peuvent être lancés en mode adaptatif ou il peut y avoir une version mobile distincte du site. Si vous exécutez la version mobile d'un site sur votre bureau, elle sera différente de la même version sur votre téléphone.
• En général, les extensions ne peuvent pas être installées dans les navigateurs mobiles.
• Pour compenser cela, vous devez activer le mode Debug dans la balise Universal Analytics ou dans le code de suivi Google Analytics sur le site.

Fonctionnalités des tests d'applications mobiles :

• Travailler avec le code d'application nécessite plus de connaissances techniques.
• Vous aurez besoin d'un serveur proxy local pour intercepter les hits. Afin de suivre le nombre de requêtes envoyées par un appareil, vous pouvez filtrer les requêtes par le nom de l'application ou de l'hôte auquel elles sont envoyées.
• Tous les hits sont collectés au format du protocole de mesure et nécessitent un traitement supplémentaire. Une fois les hits collectés et filtrés, ils doivent être copiés et analysés en paramètres. Vous pouvez utiliser n'importe quel outil pratique pour ce faire : Hit Builder, des formules dans Google Sheets ou une application JavaScript ou Python. Tout dépend de ce qui vous convient le mieux. De plus, vous aurez besoin de connaître les paramètres du protocole de mesure pour identifier les erreurs dans les résultats envoyés.

1. Connectez votre appareil mobile à votre ordinateur portable via USB.
2. Ouvrez Google Chrome sur votre appareil.
3. Dans la console développeur de Chrome, ouvrez le rapport sur les appareils distants :

1. Confirmez la connexion à votre appareil en cliquant sur OK dans la boîte de dialogue. Sélectionnez ensuite l'onglet que vous souhaitez inspecter et cliquez sur Inspecter .
2. Vous pouvez maintenant travailler avec la console développeur en mode standard, comme dans le navigateur. Vous aurez tous les onglets familiers : Console, Réseau et autres.

1. Pour travailler avec une application mobile, vous devez installer et exécuter un serveur proxy. Nous recommandons Charles.
2. Une fois votre serveur proxy installé, vérifiez à quelle adresse IP l'application se connecte :

3. Ensuite, prenez votre appareil et configurez la connexion Wi-Fi via le serveur proxy en utilisant le port 8888. C'est le port que Charles utilise par défaut.

4. Après cela, il est temps de collecter les hits. Notez que dans les applications, les hits ne sont pas envoyés en collecte mais en lot. Batch est une requête packagée qui vous permet d'envoyer plusieurs requêtes. Tout d'abord, il économise les ressources de l'application. Deuxièmement, s'il y a des problèmes de réseau, les requêtes seront stockées dans l'application et un pool commun sera envoyé dès que la connexion réseau sera rétablie.

5. Enfin, les données collectées doivent être analysées (désassemblées) en paramètres, vérifiées dans l'ordre et comparées aux spécifications.

Cette étape est la plus rapide et la plus facile. En même temps, il s'assure que les données collectées dans Google Analytics ont du sens. Dans vos rapports, vous pouvez vérifier des centaines de scénarios différents et consulter des indicateurs en fonction de l'appareil, du navigateur, etc. Si vous trouvez des anomalies dans les données, vous pouvez jouer le script sur un appareil spécifique et dans un navigateur spécifique.

Vous pouvez également utiliser les rapports de Google Analytics pour vérifier l'exhaustivité des données transférées au dataLayer. C'est-à-dire que selon chacun des scénarios, la variable est remplie, s'il y a tous les paramètres dedans, si les paramètres prennent les bonnes valeurs, etc.

Nous voulons partager les rapports les plus utiles (à notre avis). Vous pouvez les utiliser comme liste de contrôle pour la collecte de données :

• Rapports sur le commerce électronique :
  • Performances du produit
  • Performances de la liste de produits
  • Promotion interne
• Comportement — Événements — Top événements
• Acquisition — Campagnes — Analyse des coûts
• Rapports personnalisés — Par exemple, un qui montre les commandes en double

Voyons à quoi ressemblent ces rapports dans l'interface et auxquels de ces rapports vous devez prêter attention en premier.

L'onglet le plus précieux de ce rapport est le comportement d'achat. Il analyse l'exhaustivité de la collecte de données à chaque étape du commerce électronique amélioré. Autrement dit, nous pouvons voir si Google Analytics transfère les vues de la liste des produits, les clics, les vues des détails du produit, l'ajout/la suppression de produits vers/du panier et les achats eux-mêmes.

A quoi devons-nous faire attention ici ? Tout d'abord, c'est très étrange si vous avez des valeurs nulles dans l'une des colonnes. Deuxièmement, si vous avez plus de valeurs à un certain stade qu'au stade précédent, vous aurez probablement des problèmes pour collecter des données. Par exemple, supposons que le nombre d'achats uniques d'un article est supérieur au nombre de paiements. C'est bizarre et ça vaut le coup d'y prêter attention.

Vous pouvez également basculer entre d'autres paramètres dans ce rapport, qui doit également être envoyé à Enhanced Ecommerce. Par exemple, si vous sélectionnez Catégorie d'article comme option principale, vous pouvez voir qu'il y a des ventes pour certaines catégories d'articles mais qu'il n'y a pas de vues pour ces articles, pas d'ajouts au panier, etc.

Tout d'abord, il est nécessaire de parcourir tous les paramètres qui sont transmis à Google Analytics et de voir quelles valeurs prend chaque paramètre. Habituellement, il est immédiatement clair si tout va bien. Une analyse plus détaillée de chacun des événements peut être effectuée dans des rapports personnalisés.

Un autre rapport standard qui peut être utile pour vérifier l'importation des données de dépenses dans Google Analytics est l'analyse des coûts.

Nous voyons souvent des rapports où il y a des dépenses pour une source ou une campagne publicitaire mais il n'y a pas de sessions. Cela peut être causé par des problèmes ou des erreurs dans les balises UTM. Alternativement, les filtres de Google Analytics peuvent exclure les sessions d'une source particulière. Ces rapports doivent être vérifiés de temps à autre.

Nous aimerions souligner le rapport personnalisé qui vous permet de suivre les transactions en double. C'est très simple à configurer : le paramètre doit être un ID de transaction et la dimension clé doit être des transactions.

Notez que lorsqu'il y a plus d'une transaction dans le rapport, cela signifie que des informations sur la même commande ont été envoyées plus d'une fois.

Si vous rencontrez un problème similaire, lisez ces instructions détaillées sur la façon de le résoudre.

Google Analytics dispose d'un très bon outil d'alertes personnalisées qui vous permet de suivre les changements importants sans afficher de rapports. Par exemple, si vous arrêtez de collecter des informations sur les sessions Google Analytics, vous pouvez recevoir une notification par e-mail.

Nous vous recommandons de configurer des notifications pour au moins ces quatre statistiques :

• Nombre de séances
• Taux de rebond
• Revenu
• Nombre de transactions

D'après notre expérience, il s'agit de la tâche la plus difficile et la plus chronophage - la ligne étroite où les erreurs sont les plus courantes.

Pour éviter les problèmes d'implémentation de dataLayer, les vérifications doivent être effectuées au moins une fois par semaine. En général, la fréquence doit dépendre de la fréquence à laquelle vous implémentez des modifications sur le site. Idéalement, vous devez tester le dataLayer après chaque modification importante. Cela prend du temps de le faire manuellement, nous avons donc décidé d'automatiser le processus.

Pour automatiser les tests, nous avons créé une solution basée sur le cloud qui nous permet de :

• Vérifier si la variable dataLayer sur le site correspond à la valeur de référence
• Vérifier la disponibilité et la fonctionnalité du code Google Tag Manager
• Vérifier que les données sont envoyées à Google Analytics et OWOX BI
• Collecter des rapports d'erreurs dans Google BigQuery

Avantages de l'automatisation des tests :

• Augmenter considérablement la vitesse des tests. D'après notre expérience, vous pouvez tester des milliers de pages en quelques heures.
• Obtenez des résultats plus précis, puisque le facteur humain est exclu.
• Réduisez le coût des tests, car vous avez besoin de moins de spécialistes.
• Augmentez la fréquence des tests, car vous pouvez exécuter des tests après chaque modification du site.

Un schéma simplifié de l'algorithme que nous utilisons :

Lorsque vous vous connectez à notre application, vous devez spécifier les pages que vous souhaitez vérifier. Vous pouvez le faire en téléchargeant un fichier CSV, en spécifiant un lien vers le plan du site ou simplement en spécifiant une URL de site, auquel cas l'application trouvera le plan du site lui-même.

Ensuite, il est important de spécifier le schéma dataLayer pour chaque scénario à tester : pages, événements, scripts (une séquence d'actions, comme pour le paiement). Vous pouvez ensuite utiliser des expressions régulières pour spécifier que les types de page correspondent à l'URL.

Après avoir reçu toutes ces informations, notre application parcourt toutes les pages et tous les événements comme prévu, vérifie chaque script et télécharge les résultats des tests sur Google BigQuery. Sur la base de ces données, nous configurons les notifications par e-mail et Slack.

PS Si vous avez besoin d'un audit complet de votre site Web, vous pouvez demander des services de conseil à OWOX BI. Inscrivez-vous pour une démo et nous discuterons des possibilités.