Notes GA4 et GTM

GA4 et Google Tag Manager restent maintenables quand les noms d’événements, les paramètres, les déclencheurs, le consentement et les notes de mise en production suivent une convention commune. Ces notes rassemblent les mécanismes côté outil : les limites exactes, les formats de nommage, le push de couche de données à normaliser et les vérifications de débogage qui attrapent les échecs silencieux. Le processus autour — quoi définir d’abord, quoi vérifier, qui valide — relève de la liste de vérification d’implémentation analytique liée ci-dessous.

Conception des événements et paramètres

• Modéliser les événements autour des actions utilisateurs, pas de la mécanique des pages. form_submit survit à une refonte, click_blue_button non. Un événement nommé d’après l’interface casse dès que l’interface change, et l’historique devient ininterprétable.
• Réutiliser un petit ensemble cohérent de noms de paramètres. Un seul item_id employé partout vaut mieux que cinq quasi-synonymes. Chaque nom redondant consomme l’un des rares emplacements de dimensions personnalisées — et les plafonds ci-dessous sont plus bas que la plupart des taxonomies ne le supposent.
• Enregistrer les dimensions personnalisées de façon délibérée, pas réactive. L’enregistrement n’est pas rétroactif : un paramètre ne devient exploitable qu’à partir de son enregistrement, et les données antérieures ne sont pas récupérables via l’interface. Décidez avant le début de la collecte.
• Conserver les noms d’événements recommandés là où GA4 les attend. Les rapports intégrés et l’entonnoir de commerce ne s’alimentent qu’à partir des noms réservés et de leurs paramètres attendus. Renommer purchase oblige à reconstruire chaque rapport qu’il aurait rempli automatiquement.

Les limites qui dictent la conception

La ressource limitée n’a rien de figuré. Voici les plafonds d’enregistrement dans lesquels une taxonomie doit tenir :

La collecte a aussi ses bornes : 40 caractères pour les noms d’événements et de paramètres, 100 pour une valeur de paramètre, et 25 paramètres au plus par événement. Archiver une dimension finit par libérer son emplacement, mais rien de ce qui a été collecté sous un emplacement gaspillé n’est réparé rétroactivement — d’où l’intérêt de budgéter les emplacements avant la première balise.

Conventions de nomenclature

• Utiliser des noms d’événements en minuscules, avec tirets bas et prévisibles. Les noms GA4 sont sensibles à la casse : sign_up, Sign_Up et SIGN_UP collectent trois événements parallèles, et personne ne le remarque avant qu’un rapport se scinde. Les minuscules avec tirets bas correspondent aussi au format des événements recommandés, ce qui garde les rapports visuellement cohérents.
• Documenter la convention pour que les nouvelles balises restent cohérentes. Une convention n’est utile que si la prochaine personne la trouve. Gardez-la là où le travail se fait : une note dans le conteneur vaut mieux qu’un document que personne n’ouvre.
• Éviter les synonymes pour la même action entre gabarits. signup, sign_up et registration pour une même action produisent trois vues partielles et aucune complète. Fixez la liste des verbes dès le départ.

La convention elle-même tient dans un tableau :

Le contrat de la couche de données

Les balises doivent lire des valeurs poussées délibérément par le site, jamais des valeurs extraites du DOM rendu. Les valeurs extraites dépendent d’un balisage que personne n’a promis de conserver : le suivi casse silencieusement le jour où un développeur renomme une classe CSS, et l’échec silencieux est pire que l’échec bruyant. Le push ci-dessous est le contrat à normaliser :

window.dataLayer = window.dataLayer || []

// Poussé par le gabarit du site, avant que le déclencheur n’écoute.
window.dataLayer.push({
  event: 'form_submit', // correspond au déclencheur Custom Event, casse comprise
  form_id: 'newsletter', // enregistré comme dimension de portée événement
  form_destination: '/api/subscribe',
  form_length: 2, // un vrai nombre — GA4 ne convertira pas la chaîne "2"
})

La clé event est ce que le déclencheur Custom Event de GTM compare, casse comprise — c’est là que naissent la plupart des événements parallèles. Les types voyagent tels quels : GTM transmet les valeurs sans les toucher, donc un champ numérique envoyé en chaîne reste une chaîne jusque dans les rapports.

Hygiène du conteneur

• Préférer moins de déclencheurs bien nommés à de nombreux déclencheurs ad hoc. Des déclencheurs dupliqués aux conditions légèrement différentes sont la cause habituelle des événements comptés deux fois. Un déclencheur réutilisé se raisonne mieux que cinq qui se ressemblent.
• Utiliser dossiers, nomenclature et notes pour garder le conteneur lisible. Un conteneur est plus souvent hérité que construit. Une convention de préfixes regroupant les balises par finalité est ce qui permet à la personne suivante de modifier quelque chose sans risque.
• Versionner et documenter les changements importants. Notez ce qui change et pourquoi dans les notes de version au moment de publier. GTM conserve l’historique : une version documentée fait la différence entre un retour arrière de trente secondes et un après-midi de suppositions.

Débogage

• Valider dans l’aperçu et le DebugView de GA4 avant publication. L’aperçu montre si la balise s’est déclenchée ; le DebugView montre ce que GA4 a réellement reçu. Les deux sont nécessaires, car une balise peut se déclencher correctement et envoyer une charge utile erronée.
• Vérifier les valeurs des paramètres, pas seulement le déclenchement. Confirmez que la valeur est présente, du bon type, et n’est pas la chaîne "undefined" — celle-ci trahit généralement une variable de couche de données mal orthographiée, résolue en undefined puis convertie en texte à l’envoi. Un paramètre numérique envoyé en chaîne paraît identique dans DebugView et refuse discrètement de s’agréger dans les rapports.
• Confirmer que les changements d’état du consentement se comportent comme prévu. Testez trois états : accordé dès la première page, refusé dès la première page, et un changement d’avis en cours de session. Pour ce dernier, chargez le site avec le consentement refusé, acceptez via la bannière de la CMP sans recharger, et confirmez que les balises en attente se déclenchent avec l’état mis à jour — puis retirez le consentement depuis le lien des préférences et confirmez qu’elles s’arrêtent. L’état refusé est celui que la plupart des implémentations ne testent jamais explicitement.
• Surveiller les événements dupliqués ou comptés deux fois. Causes courantes : une balise déclenchée à la fois sur un changement d’historique et sur une vue de page, ou la même balise déployée dans le conteneur et codée en dur dans la page. Comparez les comptes à une session de référence plutôt que de supposer.

Ces notes accompagnent la liste de vérification d’implémentation analytique ci-dessous, qui couvre le versant processus — quoi définir, quoi vérifier et qui valide — avant de construire tout cela. Une définition à consigner dès maintenant : le canal Assistants IA de GA4 comptabilise les visites référées par des produits d’assistants nommés et exclut les AI Overviews et le mode IA de Google, ce qui explique pourquoi le trafic de la recherche IA exige quatre rapports distincts plutôt qu’un seul chiffre GA4.