Construire un plan de marquage qui tient dans le temps

Sommaire

La plupart des dispositifs de mesure ne sont pas conçus : ils sont accumulés. Une balise pour la campagne du printemps, un événement ajouté pour un rapport ponctuel, une conversion créée en urgence avant un comité. Deux ans plus tard, personne ne sait ce que form_submit compte exactement, et deux services citent deux chiffres différents pour la même question.

Un plan de marquage est le document qui empêche ça. Il nomme, avant toute implémentation, chaque événement à mesurer, ce qu’il veut dire pour l’entreprise, et où il part. Ce n’est pas un livrable technique : c’est une décision métier écrite dans un format que la technique peut exécuter.

Ce que c’est, et ce que ce n’est pas

Un plan de marquage n’est pas la liste des balises présentes dans Tag Manager. Cette liste décrit l’état actuel ; le plan décrit l’état voulu et la raison de chaque ligne. L’un est un inventaire, l’autre un contrat.

Ce n’est pas non plus un export de l’interface de Google Analytics. Un export dit « voici les événements reçus » ; il ne dit ni pourquoi ils existent, ni qui s’en sert, ni ce qui doit se passer quand ils disparaissent.

Partir de la question, jamais de l’outil

La bonne première ligne d’un plan de marquage n’est pas un nom d’événement. C’est une question à laquelle l’entreprise n’a pas de réponse fiable.

« Combien de demandes de devis viennent du référencement naturel ? » « Quelle proportion des visiteurs qui téléchargent le livre blanc reviennent dans les trente jours ? » « Le nouveau tunnel perd-il moins de monde que l’ancien ? » Chacune de ces questions se traduit en un ou deux événements, et seulement ceux-là.

Cette contrainte est délibérée. Elle élimine d’office la moitié de ce qu’on mesure d’habitude : les événements sans question derrière eux, ajoutés parce qu’ils étaient disponibles.

La matrice

Un plan de marquage tient dans un tableau. Sept colonnes suffisent, et chacune règle une question qui, laissée implicite, finit en réunion.

La colonne « déclencheur » est celle qu’on remplit le plus vite et qu’on regrette le plus. Un clic sur un bouton d’envoi compte les intentions, y compris celles qui échouent sur une erreur de validation ; l’affichage d’un message de confirmation compte les succès. L’écart entre les deux chiffres peut atteindre un tiers, et il ne se voit pas dans les rapports.

La colonne « consentement requis » est celle qu’on oublie le plus souvent. Elle se remplit en même temps que le reste, pas après : un événement dont on découvre au moment de la recette qu’il ne peut pas partir sans consentement publicitaire change parfois de destination, donc de raison d’être.

Nommer les événements

Un nom d’événement est une décision définitive. Le renommer plus tard coupe la série en deux : les données d’avant restent sous l’ancien nom, celles d’après sous le nouveau, et aucun rapport ne les réunit spontanément.

Trois règles suffisent.

• Un format unique, tenu partout. Le snake_case est la convention de Google Analytics 4 ; suivre la convention de l’outil de destination évite une classe entière de surprises.
• Verbe puis objet : devis_demande, livre_blanc_telecharge. On lit ce qui s’est passé, pas où ça s’est passé.
• Aucune référence à l’implémentation. clic_bouton_bleu devient faux le jour où le bouton change de couleur — et il changera.

Les limites de l’outil s’invitent ici : Google Analytics 4 accepte 40 caractères pour un nom d’événement, 25 paramètres par événement, 40 caractères pour un nom de paramètre et 100 pour une valeur (limites documentées par Google, consultées en septembre 2026). Au-delà, la troncature est silencieuse.

Événements clés : le sous-ensemble qui décide

Tous les événements ne se valent pas. Google Analytics 4 permet de marquer certains d’entre eux comme événements clés — le terme a remplacé « conversions » dans l’interface en 2024, Google Ads conservant de son côté le mot « conversion ».

Ce marquage n’est pas cosmétique : il détermine ce qui remonte dans les rapports d’acquisition et, si l’import est configuré, ce que Google Ads utilisera pour optimiser les enchères. Un événement clé mal choisi n’altère pas seulement un tableau de bord : il oriente une dépense.

La règle de sélection est stricte : un événement clé correspond à une étape que l’entreprise cherche réellement à produire. Trois à six suffisent pour la plupart des sites. Au-delà, la notion perd son sens et l’optimisation publicitaire poursuit des signaux faibles.

Déclarer les paramètres, sinon ils n’existent pas

C’est l’angle mort le plus coûteux du sujet, parce qu’il ne produit aucune erreur : un paramètre envoyé avec un événement n’apparaît pas spontanément dans les rapports de Google Analytics 4. Il faut l’y enregistrer comme dimension personnalisée.

Tant que cet enregistrement n’est pas fait, la donnée arrive, elle est bien reçue, et elle reste invisible. Pire : l’enregistrement n’est pas rétroactif. Les événements collectés avant la déclaration ne récupèrent jamais leur paramètre, même une fois la dimension créée.

Le plan de marquage doit donc porter une colonne de plus, ou une mention dans la colonne des destinations : ce paramètre doit-il être exploitable dans les rapports, et sous quel nom d’affichage ? La réponse conditionne une action à faire avant la première collecte, pas après le premier rapport décevant.

Le nombre de dimensions personnalisées disponibles est par ailleurs limité par propriété. C’est une ressource rare, à attribuer aux paramètres qui servent réellement à segmenter — pas à tous ceux que l’on collecte.

La source de vérité

Chaque paramètre du plan doit indiquer d’où vient sa valeur. Deux origines possibles, et elles n’ont pas la même espérance de vie.

La couche de données est une déclaration du site : il dépose le montant réel, la catégorie réelle, l’identifiant réel. La lecture de la page est une déduction : on va chercher un texte affiché à un endroit donné. La première survit à une refonte, la seconde non.

Un plan de marquage sérieux note cette origine colonne par colonne, et traite toute lecture de page comme une dette : acceptable pour aller vite, à rembourser avant qu’elle ne casse.

Prioriser

Sur une boutique, cette priorisation obéit à des contraintes propres, décrites dans l’article sur le tracking e-commerce. Ailleurs, un plan complet du premier coup ne s’implémente jamais. Trois vagues fonctionnent mieux.

1. Ce qui décide d’un budget — les événements clés, ceux qui alimentent les campagnes. S’ils sont faux, l’argent part au mauvais endroit.
2. Ce qui explique un écart — les étapes intermédiaires du parcours, qui permettent de dire où ça coince quand le premier niveau baisse.
3. Ce qui documente — le reste, utile à l’analyse fine, sans urgence.

Livrer la première vague proprement vaut mieux que livrer les trois approximativement : une mesure partielle et juste permet de décider, une mesure complète et douteuse ne permet rien.

La recette, avant la publication

Un plan de marquage se vérifie ligne à ligne, sur le site réel, avant toute publication. Le mode aperçu de Tag Manager montre l’événement reçu, la balise déclenchée et les valeurs transmises ; l’outil de destination confirme la réception.

Quatre contrôles par ligne :

• l’événement part-il, et une seule fois ?
• les paramètres arrivent-ils complets, au bon format ?
• l’événement ne part-il pas quand le consentement est refusé ?
• l’outil de destination le reçoit-il sous le nom attendu ?

Le troisième contrôle est le plus souvent sauté, et c’est celui qui expose. Tester le refus demande le même effort que tester l’acceptation.

Propriété et maintenance

Un plan sans propriétaire redevient un inventaire en six mois. Deux pratiques suffisent à le tenir vivant.

Une personne par ligne. Pas une équipe : une personne nommée, qui reçoit la question quand le chiffre paraît faux. C’est la colonne la plus efficace du tableau, et la plus souvent laissée vide.

Une revue trimestrielle. Trois questions : quelles lignes n’ont produit aucune décision depuis la dernière revue, quelles questions nouvelles ne sont couvertes par aucune ligne, et quelles lignes reposent encore sur une lecture de page. La revue supprime autant qu’elle ajoute — c’est le signe qu’elle fonctionne.

Enfin, le plan doit être versionné au même titre que le code, avec une date et un auteur. Quand une série de données change d’allure, la première question utile est « qu’a-t-on modifié dans la mesure ce jour-là », et seule une histoire écrite y répond.

Les erreurs fréquentes

Commencer par l’outil. Ouvrir Tag Manager avant d’avoir écrit les questions, c’est mesurer ce que l’interface propose.

Confondre volume et valeur. Trois cents événements décrivent un site ; six événements clés décrivent une activité.

Traiter le consentement en dernier. Il change ce qui peut partir, donc parfois la conception même du plan. Il se traite dans la matrice, pas après la recette — le sujet relève de la plateforme de consentement autant que de la mesure.

Ne rien supprimer. Un plan qui ne fait que grossir a cessé d’être un plan.