Automatiser le contrôle qualité des données Google Analytics dans Data Studio – partie 1 : e-commerce

English version here

Gagner du temps et de l’efficacité pour finaliser ou maintenir une implémentation GA de qualité à travers différents checks et rapports personnalisés directement dans Google Data Studio.

L’objectif de cet outil est de gagner du temps en ayant une vue d’ensemble et rapide avec des rapports pré configurés. Sur des environnements multisites ou avec beaucoup de propriétés dans GA, l’idée était de pouvoir identifier & corriger, précisément & rapidement des problèmes de tracking.

Sommaire

  1. Ecarts de revenu
  2. Duplication des transactions
  3. Perte de données des interactions e-commerce
  4. Persistance des valeurs ecommerce

Lorsque vous réalisez une implémentation Analytics, l’étape de contrôle de la qualité des données dans GA est primordiale. C’est cette étape qui vient généralement valider la fin de l’implémentation quand l’ensemble des données remontent exhaustivement et au bon format. Il est aussi d’usage d’auditer ponctuellement la qualité des données remontées dans GA afin de maintenir un suivi cohérent au long terme.

Il arrive que cette étape soit malheureusement non-priorisée car beaucoup d’effort auront été préalablement concentrés sur le check du Data Layer lors d’un projet d’implémentation. Dans la majorité des cas de figures et surtout pour des projets avec des Data Layer volumineux, il est presque impossible de tester toutes les combinaisons clé/valeur possibles. Il est donc d’usage de laisser aussi tourner un peu la machine grâce à nos utilisateurs avant d’aller compléter son check via un état des lieux dans GA.

Ce type de rapport peut faire du sens pour de petites comme de grosses implémentation, pour un seul environnement ou pour contrôler plusieurs sites/applications.


Rapport Data Studio de contrôle qualité des données E-commerce

Ecarts de revenu

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-revenue.png.
Exemple de calcul de différence de revenu

La première section du rapport affiche les revenus. Cette étape peut être assez variable en fonction de la politique de collecte des données. En soit, une différence de chiffre d’affaires entre les deux ne veut pas expliquer forcément un problème de tracking ou de calcul. Il se peut que le prix remisé au niveau de la transaction ne soit pas appliqué aux prix des produits dans une transaction. C’est un autre sujet qu’il est possible d’explorer sur le blog d’InfoTrust .

Ici l’idée est de savoir si on a bien des données cohérentes entre notre chiffre d’affaires/chiffre d’affaires par produit & éventuellement le total des remises appliquées aux commandes (préalablement remontées dans GA). Le calcul nous permet d’évaluer rapidement, si on a une déperdition de chiffre d’affaire ou de montant de remise lors d’une commande. Il arrive souvent par exemple que le calcul du revenu au niveau de la transaction selon une remise ne soit pas correctement calculé. Dans le Framework Data Studio ci-dessus, il faut que notre revenu au niveau produit – le revenu au niveau transaction soit = au total de la remise


Transactions dupliquées

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-transaction-duplication.png.

La deuxième section du rapport se penche sur la duplication des transactions. Il se peut dans différents cas de figure qu’une même transaction soit comptée en double dans Google Analytics. Exemple : lorsque lors d’un rechargement de la page de confirmation de paiement, les informations de transaction avec le mêmes ID de transaction sont envoyées. Il est souvent conseillé d’éviter ce genre de situation en demandant à vos développeurs de ne pas renvoyer deux fois la même information de transaction lors d’un rechargement de page de confirmation. Si c’est un fix que vous souhaitez régler rapidement sans l’aide de vos développeurs, j’ai créé un custom tag dans Google Tag Manager qui permet entre autre d’éviter la duplication des transactions en passant par le Local Storage Le lien de l’article ici.

Ici le tableau est une combinaison entre les identifiants de transaction en dimension + transaction en métrique. Je vous conseille d’appliquer un filtre qui permet de prendre le nombre de transactions > 1. Il permet d’identifier rapidement si des transactions font l’objet d’une duplication et dans quelle proportion.

L’attribut alt de cette image est vide, son nom de fichier est image-14.png.

Perte de données des interactions e-commerce

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-transaction-checkout.png.

La troisième section est consacrée au suivi des événements d’interaction e-commerce purchase/checkouts/detail views/list views/list clicks/add to & remove from cart/promotion views… L’idée dans cette section est d’obtenir une vue rapide pour identifier la déperdition ou le ralentissement d’un événement e-commerce. Exemple : dans la capture d’écran du checkout on voit qu’à date on perd des données de manière importante sur l’étape 1 alors que les étapes suivantes sont collectées. Même comportement pour la déperdition des Removes From Cart ci-dessous. Il se peut qu’un événement ne soit plus correctement envoyé dans le Data Layer ou dans GTM. Cette visualisation nous permet d’identifier le problème rapidement et d’aller de l’avant vers un fix.

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-ecommerce-interaction-1024x173.png.

Persistance des valeurs ecommerce

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-persistence-data.png.

La quatrième et dernière section se penche sur la persistance des valeurs e-Commerce telles que le nom des produits, la catégorie de produit, les listes, les promotions etc…

Exemple :

  • Mon “produit 1” est vu 0 fois dans le checkout
  • Mais mon “PRODUIT 1” est acheté 15 fois

Ces deux produits sont les mêmes mais sont séparés dans GA car les valeurs sont sensibles à la casse. Il est très fréquent de rencontrer des inconsistances de valeur à travers différentes interactions E-commerce rendant certains rapport complétement incohérents. C’est pour cette raison qu’il est important de donner des indications précises à vos développeurs au préalable ou mettre en place des solutions pour réduire les risques d’écarts à travers GTM.

L’attribut alt de cette image est vide, son nom de fichier est image-15-1024x192.png.

Ici la formule du rapport est simple, dans le tableau du bas on veut identifier les produits achetés mais non-identifiés dans le checkout ou d’autres interactions e-commerce. Le tableau du haut et la commande de filtrage sert à retrouver un produit parmi l’ensemble des produits (non-filtrés) et comprendre quel a été le facteur d’inconsistance.

L’attribut alt de cette image est vide, son nom de fichier est ecommerce-data-studio-filter-2.png.

Merci !


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *