Un dashboard peut continuer à avoir l’air parfaitement normal
Une anomalie de Tracking ne casse pas forcément votre site.
Et c’est justement ce qui la rend difficile à repérer.
Un événement ne remonte plus sur une partie du tunnel. Un paramètre disparaît après une mise en production. Un nouveau parcours est déployé mais n’est pas collecté comme prévu.
Pour autant, GA4, Piano ou votre dashboard maison continue d’afficher quelque chose.
Le chiffre est là.
La question, c’est ce qu’il vaut encore.
Derrière un taux de conversion, un chiffre d’affaires ou un coût d’acquisition, il y a une chaîne de collecte.
Et dès qu’un maillon de cette chaîne change, le KPI peut changer avec lui sans que l’anomalie saute immédiatement aux yeux.
C’est là que, pour nous, le Tracking cesse d’être uniquement un sujet technique.
Parce qu’à partir du moment où cette donnée sert à couper une campagne, déplacer un budget ou prioriser une évolution produit, la qualité du Tracking devient une condition de la décision.
Une petite anomalie technique peut avoir une portée beaucoup plus large
Prenons un cas très simple.
Le paramètre value ne remonte plus correctement sur l’événement purchase.
Pour la personne qui travaille sur le plan de marquage, le problème est clair : un paramètre manque.
Mais ce paramètre peut alimenter derrière :
- le chiffre d’affaires e-commerce
- le panier moyen
- le taux de conversion
- un modèle d’attribution
- un reporting présenté à la Direction
C’est précisément pour cette raison qu’une alerte purement technique nous paraît incomplète.
Dire :
“Le paramètre value est absent.”
c’est utile.
Mais ce n’est que le début de la réponse.
Ce qu’on veut réellement savoir, c’est :
Qu’est-ce que ça change ?
Passer de “qu’est-ce qui a cassé ?” à “qu’est-ce que ça met en risque ?”
Pendant longtemps, les outils de Tracking ont surtout répondu à une question technique :
quel tag, quel événement ou quel paramètre ne fonctionne plus ?
C’est indispensable.
Mais après des années à travailler sur ces sujets, on sait aussi que ce n’est pas la question qui aide le plus à prioriser.
Deux anomalies peuvent être techniquement très proches et avoir des conséquences complètement différentes.
Un paramètre absent sur une page secondaire.
Et le même paramètre absent au moment de l’achat.
Sur le papier : deux erreurs de collecte.
Dans la réalité : pas du tout la même urgence.
C’est pour ça qu’on a choisi de relier les éléments du plan de marquage aux KPI qu’ils alimentent.
Un même incident peut alors se lire à deux niveaux.
Côté technique : quel événement, paramètre ou contrôle est en échec ?
Côté métier : quel KPI dépend de cet élément, sur quel périmètre et depuis quand ?
Le KPI devient l’autre bout de la chaîne : il permet de savoir ce que vous perdez lorsqu’un élément du plan casse.
C’est exactement cette logique qui structure Netvigie Tracking.
Ce que ça donne vraiment au quotidien
Une campagne affiche soudainement une baisse de conversion.
Le premier réflexe peut être de regarder les enchères, les créas, l’audience ou le parcours.
Puis quelqu’un finit par vérifier la collecte.
L’événement d’achat remonte toujours.
Mais pas partout.
Sur une partie du tunnel, un paramètre a disparu après la dernière mise en production.
Le problème n’est donc pas forcément que la campagne performe moins.
Le problème peut être que vous ne mesurez plus toute sa performance.
Et à partir de là, le sujet n’est plus simplement de corriger un tag.
Il faut savoir depuis quand la donnée est touchée, quelle partie du parcours est concernée et quels KPI reposent dessus.
C’est ce genre de situation qu’on rencontre depuis des années dans les problématiques de Data Quality.
Et c’est aussi ce qui nous a poussés à faire évoluer notre propre manière de présenter les anomalies.
Détecter n’a jamais été la partie la plus difficile
Après dix ans de Data Quality, on retrouve toujours la même limite :
détecter un écart ne suffit pas.
Remonter cinquante erreurs n’aide pas beaucoup si l’équipe doit ensuite passer une heure à comprendre laquelle mérite réellement son attention.
Sur la Data Quality, il faut pouvoir répondre rapidement à quatre questions :
- Quoi ? Quel événement, paramètre ou contrôle est concerné ?
- Où ? Sur quel site, quelle page, quel gabarit ou quel parcours ?
- Depuis quand ? À partir de quand la collecte a-t-elle commencé à diverger ?
- Quel KPI ? Quel indicateur dépend de l’élément concerné ?
Cette dernière information change complètement la manière de prioriser.
Une anomalie qui menace le taux de conversion du tunnel principal ne se traite pas comme une erreur sur un élément secondaire.
Même si, techniquement, les deux sont des anomalies de Tracking.
Savoir depuis quand la donnée n’est plus fiable
C’est une autre question qui revient presque systématiquement lorsqu’une anomalie est découverte : depuis quand ?
Parce que découvrir aujourd’hui qu’un KPI est affecté ne dit pas encore quelle période de reporting remettre en question.
Chez Netvigie, chaque alerte conserve notamment sa première observation, sa dernière observation en échec et sa résolution.
Vous savez donc sur quelle période et sur quel périmètre précis la collecte a été affectée.
C’est ce qui permet de répondre à des questions très concrètes :
- Faut-il retraiter les données des dernières heures ?
- Remettre en question une semaine de reporting ?
- Corriger un modèle d’attribution ?
- Prévenir une équipe qui s’est appuyée sur ces chiffres pour décider ?
Sans cette information, le doute finit souvent par s’étendre à beaucoup plus de données que nécessaire.
Une lecture commune pour des équipes qui n’ont pas les mêmes besoins
Une même anomalie ne raconte pas la même chose selon la personne qui la regarde.
Le développeur cherche la cause.
La Data cherche la fiabilité.
Le Marketing regarde l’impact sur ses indicateurs.
Notre rôle, c’est de faire tenir ces lectures dans le même incident, sans obliger chaque équipe à le retraduire de son côté.
Parce qu’un incident doit pouvoir être compris par la personne qui va le corriger mais aussi par celle qui doit décider s’il mérite de passer en priorité.
Relier le Tracking à ce qu’il sert réellement à piloter
C’est cette logique qu’on a intégrée dans Netvigie Tracking : une anomalie ne doit jamais être isolée de ce qu’elle met réellement en risque.
Les KPI sont directement reliés aux événements, paramètres et règles dont ils dépendent.
Quand un écart apparaît, vous ne voyez donc pas uniquement ce qui a cassé.
Vous pouvez aussi identifier :
- les KPI concernés
- le périmètre touché
- le moment où l’écart a commencé
- les éléments techniques à l’origine du problème
Le Tracking reste un sujet technique.
Mais dès qu’une donnée collectée sert à arbitrer une campagne, un produit ou un investissement, sa qualité devient un sujet de pilotage.
C’est probablement l’un des constats les plus importants qu’on tire de ces années passées à travailler sur la Data Quality :
Détecter le problème est nécessaire. Comprendre ce qu’il met réellement en risque, c’est ce qui permet d’agir.
Et maintenant ?
Netvigie Tracking permet de relier votre plan de marquage aux KPI qui pilotent votre activité puis d’identifier les indicateurs concernés lorsqu’un écart apparaît.
Découvrez comment la Data Quality permet de passer de l’anomalie technique à son impact réel sur vos données.
