Un plan de taggage n’est pas un inventaire de ce qui est mesurable. C’est un arbitrage sous contrainte, et la contrainte est chiffrée.
Aucun des contenus français consacrés au sujet ne cite les limites de l’outil. C’est pourtant ce qui décide de la forme du plan : on ne conçoit pas une nomenclature de la même façon selon qu’on dispose de cinquante dimensions personnalisées ou de mille.
Cette page pose donc la question dans l’autre sens. Non pas ce que vous pouvez mesurer, mais ce que vous devez refuser de mesurer, et pourquoi ce refus est ce qui rend le reste exploitable.
Ce qu’elle ne traite pas, parce que c’est traité ailleurs : la déduplication entre navigateur et serveur, dans pixel publicitaire ; le moment de passer au suivi côté serveur, dans tracking côté serveur ; les écarts entre outils, dans divergences d’attribution ; le consentement, dans consentement sur une landing page.
Ressource à télécharger
Le plan de taggage, ligne par ligne
Le classeur où chaque événement porte la décision qu'il sert, sa nomenclature, ses paramètres et son propriétaire, avec le contrôle des limites de la plateforme.
- La trame du plan, un événement par ligne avec sa décision
- La nomenclature, et les noms réservés à ne pas employer
- Le compteur de dimensions personnalisées, pour ne pas saturer
- Le test de refus, à appliquer avant tout ajout
- La recette après mise en ligne, cas par cas
- La gouvernance : propriétaire, version, date de revue
Format Classeur XLSX, 6 onglets. Aucune inscription à une liste de diffusion.
Qu’est-ce qu’un plan de taggage, et à quoi sert-il vraiment
Un plan de taggage est le document qui définit ce que votre site mesure : quels événements partent, sous quel nom, avec quels paramètres, vers quelles destinations. On l’appelle aussi plan de marquage, les deux termes désignent la même chose.
Sa fonction déclarée est de coordonner le travail : l’agence sait quoi poser, le développeur sait quoi déclencher, l’analyste sait quoi attendre.
Sa fonction réelle est ailleurs. C’est le seul document qui explique ce que vos chiffres veulent dire. Sans lui, un tableau de bord affiche des nombres dont plus personne ne connaît la définition exacte, et cette ignorance ne se voit pas : les chiffres continuent de s’afficher, l’air parfaitement fiables.
Deux conséquences qui décident de tout ce qui suit.
Il vous appartient, pas à votre prestataire. Un plan qui vit uniquement dans l’espace de travail d’une agence disparaît avec elle, et vous laisse des données ininterprétables.
Il vaut par ce qu’il exclut. Un plan qui liste tout ce que le site sait produire est un inventaire, pas un plan.
Les limites que personne ne cite, et qui décident de tout
Voici les chiffres absents de tous les contenus français sur le sujet. Ils viennent de la documentation de l’éditeur, et ils sont la vraie contrainte de conception.
Sur les noms et les valeurs. D’après les limites de collecte et de configuration publiées par Google, un nom d’événement est limité à 40 caractères, un nom de paramètre également, et la valeur d’un paramètre à 100 caractères, avec des exceptions documentées pour certains paramètres de page.
Sur le nombre de paramètres. Un événement ne peut porter que 25 paramètres, et une propriété que 25 propriétés utilisateur.
Sur le nombre d’événements. Et c’est là que se joue le malentendu : la documentation indique qu’il n’y a aucune limite au nombre d’événements portant des noms distincts pour un flux web. On en conclut qu’on peut tout mesurer.
Sur les dimensions personnalisées. C’est le vrai goulot d’étranglement. Une propriété standard dispose de 50 dimensions personnalisées de portée événement, 25 de portée utilisateur et 10 de portée article, d’après la documentation dédiée. Or un paramètre que vous envoyez n’apparaît dans les rapports que si vous l’enregistrez comme dimension personnalisée.
La conséquence, énoncée simplement. Vous pouvez envoyer autant d’événements que vous voulez, mais vous ne pourrez exploiter les paramètres que de quelques dizaines d’entre eux. Un plan qui ignore ce plafond le découvre au bout d’un an, quand la case suivante n’est plus disponible et qu’il faut arbitrer dans l’urgence entre deux mesures dont l’une est déjà utilisée dans un rapport de direction.
Le test de refus, avant toute ligne ajoutée
Une seule question, posée avant d’inscrire un événement au plan : quelle décision change si ce chiffre bouge ?
Si personne ne peut nommer la décision, l’événement ne rentre pas. Ce n’est pas une position d’austérité, c’est une conséquence directe du plafond de dimensions : chaque mesure décorative consomme une case que vous n’aurez plus pour une mesure utile.
Trois façons d’échouer à ce test, et elles reviennent toutes.
« C’est intéressant à savoir. » Probablement, mais l’intérêt n’est pas un critère. La question porte sur ce que vous ferez différemment.
« On ne sait jamais, ça servira peut-être. » C’est l’argument qui remplit les plans. Il faut lui opposer le coût : la case consommée, la maintenance à chaque refonte, et la charge de relecture pour ceux qui ouvriront le document.
« Le prestataire l’a proposé. » Un prestataire propose ce qu’il sait poser, ce qui est légitime. L’arbitrage vous revient, parce que c’est vous qui vivrez avec le plan.
Ce que le refus permet. Un plan de vingt événements dont chacun sert une décision se relit en cinq minutes, se recette entièrement, et survit à un changement d’agence. Un plan de cent trente événements ne se relit jamais et devient, en pratique, un document de confiance : on suppose qu’il est juste parce que personne ne peut vérifier.
Le même raisonnement appliqué aux indicateurs de reporting est développé dans tableau de bord marketing B2B.
Que contient une ligne du plan
Sept colonnes suffisent, et chacune répond à une question qui se posera tôt ou tard. Les plans qui en comptent quinze contiennent surtout des colonnes que personne ne remplit.
Le nom de l’événement. Tel qu’il partira, à la casse près. C’est ce que verra l’analyste, et c’est ce qui devra correspondre exactement à ce que posera le développeur.
La décision qu’il sert. Une phrase, pas un thème. « Arbitrer le budget entre les deux régies » est une décision. « Suivre l’engagement » n’en est pas une. Cette colonne est la seule qui justifie l’existence de la ligne, et c’est la première qu’on supprime quand on copie un modèle trouvé en ligne.
Le déclencheur. L’action précise et l’endroit : quel bouton, quelle page, quelle condition. Formulé pour un développeur qui ne connaît pas votre marketing.
Les paramètres. Leur nom et ce qu’ils portent. C’est ici que se voit la discipline de nommage, et ici que se compte la consommation de dimensions personnalisées.
Les destinations. Quel outil reçoit quoi. Un même événement part rarement vers un seul endroit, et les écarts entre destinations sont la première cause de chiffres qui ne se recoupent pas.
Le statut de consentement. Ce qui part avant, ce qui part après. Une colonne, deux valeurs, et un problème de conformité en moins.
Le propriétaire et la date. Qui a demandé cette ligne, et quand. Sans cela, personne ne saura à qui poser la question au moment de la retirer.
Ce qu’on ne met pas dans le plan. Les valeurs attendues, les objectifs chiffrés et les commentaires de performance. Ce sont des sujets de tableau de bord, et les mélanger transforme un document technique en document de pilotage que plus personne ne met à jour.
Comment nommer, et ce qu’il faut éviter
La nomenclature est la partie la plus discutée et la plus mal traitée. Voici ce que la documentation impose, et ce qu’elle n’impose pas.
Ce qui est imposé
D’après les règles de nommage publiées par l’éditeur, les noms d’événements sont sensibles à la casse, doivent commencer par une lettre, et n’acceptent que des lettres, des chiffres et des tirets bas, à l’exclusion des espaces.
La sensibilité à la casse mérite qu’on s’y arrête : un événement écrit avec une majuscule et le même écrit en minuscules sont deux événements différents, comptés séparément. C’est l’une des causes les plus fréquentes de chiffres qui ne se recoupent pas.
Certains noms et préfixes sont réservés. Des préfixes comme le tiret bas initial ou ceux qui désignent les produits de l’éditeur ne peuvent pas être employés, et une série de noms d’événements est réservée côté web, notamment ceux qui correspondent aux mesures automatiques. Reprendre l’un de ces noms pour un usage différent produit des données mélangées, sans avertissement.
Ce qui n’est pas imposé, et qu’on répète pourtant
La convention la plus citée dans les contenus français consiste à concaténer une catégorie, une action et un libellé. C’est un héritage de la génération précédente de l’outil, dont le modèle reposait effectivement sur ces trois champs.
Le modèle actuel repose sur un événement et ses paramètres. Reproduire l’ancienne convention produit trois défauts : des noms longs qui butent contre la limite de quarante caractères, des filtres pénibles à écrire, et surtout la perte du bénéfice des paramètres, qui existent précisément pour porter le contexte.
La règle à retenir tient en une ligne : un nom d’action court en minuscules, et le contexte dans les paramètres. Le formulaire de contact envoyé devient un événement d’envoi de formulaire, avec un paramètre qui dit lequel, plutôt qu’un nom différent par formulaire.
La cardinalité, le piège technique le plus coûteux
Une dimension à forte cardinalité est une dimension dont les valeurs sont presque toutes différentes : un identifiant de session, une adresse électronique, un horodatage précis.
La documentation prévient que ces dimensions dégradent les rapports, les valeurs excédentaires étant regroupées sous une ligne résiduelle. En pratique, vos rapports se composent majoritairement de cette ligne, et l’information que vous vouliez conserver devient inaccessible pour tout le monde.
C’est contre-intuitif, parce que la donnée a bien été collectée. Elle est simplement inexploitable dans l’interface, ce qui revient au même pour celui qui doit décider.
Par quoi commencer quand il n’y a rien
La situation la plus fréquente en PME B2B n’est pas un plan trop gros, c’est l’absence de plan. Voici de quoi démarrer, et l’ordre compte.
Commencez par la conversion réelle, pas par les micro-conversions. Une ou deux lignes : la demande de contact envoyée, et le rendez-vous pris si vous avez un outil de prise de rendez-vous. Ce sont les seules mesures qui parleront à votre direction.
Ajoutez ce qui distingue les demandes entre elles. Un paramètre sur l’origine du formulaire, un autre sur l’offre concernée. Deux paramètres bien choisis valent dix événements distincts, et ils consomment moins de dimensions.
Ajoutez les étapes qui précèdent, si et seulement si vous savez qu’en faire. L’ouverture d’une page tarifaire ou le téléchargement d’un document ne méritent une ligne que si quelqu’un s’en sert pour relancer ou pour arbitrer un budget.
Ne touchez pas aux mesures automatiques. L’outil collecte déjà un ensemble d’interactions sans configuration. Les redéclarer manuellement produit des doublons, et reprendre l’un de leurs noms réservés mélange vos données aux siennes.
Arrêtez-vous là pendant un trimestre. Vivez avec cinq à huit lignes, regardez ce qui vous manque réellement au moment de décider, et n’ajoutez qu’à ce moment. Un plan construit par ce qui a manqué est toujours plus juste qu’un plan construit par anticipation.
Un repère de dimensionnement. Une PME B2B qui pilote correctement son acquisition n’a pas besoin de plus d’une quinzaine d’événements. Au-delà de trente, il y a presque toujours de la mesure décorative, et le moment est venu de rouvrir le test du refus sur les lignes existantes.
La gouvernance, ou ce qui se passe au changement d’agence
C’est la partie qu’aucune méthode ne traite, et celle qui décide de la survie du plan.
Qui possède le document. Il doit vivre dans un espace que vous contrôlez, pas dans celui de votre prestataire. La question n’est pas de méfiance : une agence qui ferme, un consultant qui change de métier, une équipe qui se réorganise suffisent à rendre un document inaccessible.
Qui arbitre un ajout. Une personne nommée, pas un comité. Son rôle n’est pas technique, il est de poser la question du refus à chaque demande. Sans arbitre, le plan grossit par accumulation, chaque partie prenante ajoutant ce qui l’intéresse.
Comment il est versionné. Un numéro et une date, et la liste de ce qui a changé. Sans cet historique, un chiffre qui bouge en mars devient inexplicable : personne ne saura si le marché a changé ou si quelqu’un a modifié un déclencheur.
Qui a les accès. Faites l’inventaire des comptes ayant un accès administrateur à vos outils de mesure, y compris ceux d’anciens prestataires. C’est un contrôle de dix minutes qui réserve souvent des surprises, et il rejoint la question de la propriété des comptes publicitaires traitée dans auditer un compte publicitaire.
Le cas des propriétés à plusieurs mains. Dès que deux prestataires travaillent sur la même propriété, l’un pour l’acquisition et l’autre pour le site par exemple, le plan devient le seul point de rencontre. Sans lui, chacun pose ce dont il a besoin, les noms divergent, et les deux mesurent la même chose deux fois sous deux libellés. Ce n’est pas une faute de leur part : personne ne leur a donné de référence commune.
Ce qu’il faut exiger d’un prestataire, dès le départ. Le plan livré dans un format modifiable, à jour à la fin de la mission, et une session de passation pendant laquelle on ouvre le document ensemble. C’est le genre d’exigence qui ne coûte rien si elle est posée au début, et qui devient impossible à obtenir à la fin.
Et Google Tag Manager, dans tout ça
Le gestionnaire de balises est l’outil qui pose les événements décrits par le plan. C’est un exécutant, pas un plan : la confusion entre les deux est la cause d’une bonne partie des dispositifs illisibles.
Ce qu’il apporte réellement. La possibilité de modifier ce qui est mesuré sans passer par une mise en production du site, et un endroit unique où voir ce qui se déclenche. Sur un site dont les évolutions techniques sont lentes, c’est un gain de plusieurs semaines par changement.
Ce qu’il n’apporte pas. Aucune discipline. Un conteneur se remplit exactement comme un plan, par accumulation, et il est plus facile d’y ajouter une balise que de justifier son retrait. Les conteneurs les plus encombrés que nous ouvrons sont ceux où trois prestataires se sont succédé sans document commun.
Trois règles qui suffisent. Nommez les balises et les déclencheurs comme les événements du plan, de sorte qu’on retrouve une ligne du document dans l’interface en une recherche. Supprimez les balises inactives au lieu de les mettre en pause, sinon personne n’osera y toucher dans deux ans. Et notez dans le plan quelle ligne est posée dans le conteneur et laquelle est codée en dur dans le site, parce que les secondes sont invisibles depuis l’interface.
Le cas du code en dur. Il n’est pas fautif : certains événements se posent mieux dans le code, en particulier ceux qui dépendent d’une donnée serveur. Ce qui est fautif, c’est qu’il ne figure nulle part. Une balise posée en dur et non documentée devient une mesure orpheline dès le départ de celui qui l’a écrite.
La recette, et les erreurs qu’elle rattrape
Un plan non recetté est une intention. La vérification prend une heure et évite des mois de données inutilisables.
Testez chaque événement dans les conditions réelles, pas dans un environnement de démonstration : le formulaire réellement rempli, le bouton réellement cliqué, sur mobile comme sur ordinateur.
Vérifiez que l’événement ne part qu’une fois. Le double envoi est l’erreur la plus fréquente, et la plus discrète : les chiffres paraissent simplement meilleurs.
Vérifiez les paramètres, pas seulement le déclenchement. Un événement qui part sans son paramètre de contexte est un événement à moitié perdu.
Vérifiez le comportement avant consentement. Un déclenchement qui survient malgré un refus est un problème de conformité, pas un problème de mesure.
Testez aussi ce qui ne doit pas se déclencher. Un événement de conversion qui part sur une page de remerciement rechargée, ou sur un clic de retour arrière, gonfle vos chiffres sans que rien ne le signale. Une recette sérieuse vérifie autant les faux positifs que les absences.
Refaites la recette après chaque refonte. Une modification de formulaire suffit à casser un déclencheur, et rien ne vous en avertira : la ligne cessera simplement de monter, ce qui ressemble à une baisse d’activité.
Par où continuer, selon votre situation
Vous branchez plusieurs canaux. Les conditions de déduplication et ce que dépose un pixel : pixel publicitaire.
Vos chiffres ne concordent pas entre outils. L’explication est structurelle : divergences entre GA4, Meta et le CRM.
Vous vous demandez s’il faut passer au serveur. Le coût réel et le bon moment : tracking côté serveur.
Vous construisez le reporting par-dessus. Ce qu’un tableau de bord ne peut pas voir : tableau de bord marketing B2B.
Une conséquence en aval, qu’il faut connaître avant de bâtir un rapport : un filtre appliqué à un tableau ne lit pas dans la ligne résiduelle, puisqu’il intervient après agrégation. Vous filtrez donc sur un ensemble déjà amputé, sans avertissement. Ce mécanisme et les trois autres plafonds de l’outil sont traités dans Google Analytics 4, ce qu’il ne vous montre pas.
En bref
- Un plan de taggage est un arbitrage, pas un inventaire. Sa question fondatrice porte sur ce qu’il faut refuser de mesurer.
- Les limites de l’outil décident de la conception : 40 caractères pour un nom, 25 paramètres par événement, 100 caractères pour une valeur.
- Le nombre d’événements est illimité sur un flux web, et c’est ce qui trompe. Le vrai plafond est celui des dimensions personnalisées, 50 de portée événement sur une propriété standard.
- Une dimension à forte cardinalité dégrade les rapports, les valeurs excédentaires étant regroupées sous une ligne résiduelle.
- Le test avant tout ajout : quelle décision change si ce chiffre bouge. Sans réponse, l’événement ne rentre pas.
- La convention en trois champs est périmée. Un nom d’action court, et le contexte dans les paramètres.
- Le plan vous appartient. Un document qui vit chez le prestataire disparaît avec lui, et vos chiffres deviennent ininterprétables.
Si personne chez vous ne sait dire ce que compte exactement une ligne de votre tableau de bord, le problème n’est pas l’outil. Parlons de votre projet, ou découvrez notre approche du suivi et de la mesure.