SYS/DEF
Plan de marquage
Le contrat : quels événements, quelles propriétés, quelle déduplication, quel outil les reçoit. Sans lui, l’analytics est du folklore.
Définition
Un plan de marquage est le spécification des événements produit : nom, déclencheur, paramètres, identifiant utilisateur vs cookie, destinations (analytics, ads, A/B). Il dit aussi ce qu’on ne mesure pas. Le dataLayer n’est qu’un tuyau ; le plan est la loi.
Sans version, sans responsable, le plan pourrit : un dev renomme purchase en purchase_v2, le test A/B continue de lire l’ancien, le CRO célèbre un flatten de conversions.
Quand ça compte
Avant le premier test, avant une refonte, avant de brancher un pixel ads. C’est le prérequis de toute hypothèse testable et de toute attribution crédible.
Il compte à l’audit d’intégrité : un SRM côté outil A/B et des conversions qui ne matchent pas l’analytics, c’est souvent un plan non respecté, pas « le hasard ».
Pièges
Documenter après coup dans un Notion que plus personne n’ouvre. Tracker « tout » (bruit, RGPD, budget tag). Dupliquer le même événement GTM + in-app. Changer le nom d’événement au milieu d’un test. Oublier les consent modes : le plan doit dire le comportement cookieless, pas seulement le cas idéal.
Termes liés
Outil associé
SRM, peeking, marquage : savoir repérer un test invalide avant d’en lire le résultat : Ouvrir quiz intégrité d’expérience.