À quoi sert Google Tag Manager ?
Sans gestionnaire de balises ni intégration adaptée, l’ajout d’un code de mesure passe par le développeur. Pour poser une simple balise de conversion, il faut alors attendre la prochaine mise en ligne du site, parfois des semaines. Et les anciens codes s’accumulent, parce que personne ne sait plus qui s’en sert.
Google Tag Manager simplifie cette organisation. Le développeur pose une seule fois un conteneur, c’est-à-dire le code qui charge toutes les autres balises. Ensuite, vous ajoutez, testez et publiez les balises courantes depuis une interface, sans remettre le site en ligne.
Google Tag Manager ne mesure rien lui-même. Il encadre qui peut changer quoi et quand, avec une trace de chaque changement. Il peut gérer les balises de votre suivi des conversions Google Ads. Mais un mauvais plan de mesure se déploie aussi proprement qu’un bon. Ce qu’il faut compter, et à quelle valeur, se décide donc avant, avec les fondamentaux de la mesure.
Installer Google Tag Manager en quatre étapes
Le conteneur fournit deux extraits de code : l’un se place dans le <head> de chaque page, l’autre juste après l’ouverture du <body>. Votre CMS peut aussi proposer sa propre intégration. La mise en place est rapide, mais la présence du code ne prouve pas que la mesure fonctionne.
- Créer le conteneur. Dans Google Tag Manager, créez un compte puis un conteneur Web pour le site. L’interface vous donne son identifiant et les deux extraits.
- Poser les extraits. Collez-les aux deux endroits prévus, ou utilisez l’intégration de votre CMS après avoir vérifié sa configuration. Il ne faut pas qu’un ancien conteneur ou des codes collés en dur fassent doublon.
- Vérifier l’environnement. Toutes les pages et sous-domaines concernés doivent charger le conteneur. Les règles de sécurité du site ne doivent pas le bloquer, et l’état initial du consentement doit être défini avant les déclencheurs des balises. Reste à tester les données que le site transmet aux balises (le dataLayer, expliqué plus bas).
- Tester puis publier. Parcourez les scénarios utiles en mode Aperçu, puis publiez une version nommée et documentée. L’installation n’est terminée qu’après ces contrôles.
Vérifier qu’une balise se déclenche
Le mode Aperçu ouvre Tag Assistant, relié à votre navigateur. Pour chaque action sur le site, il montre les balises déclenchées et celles qui ne l’ont pas été. Il confirme la logique du conteneur, pas la réception des données. Il faut donc vérifier ensuite l’arrivée des données dans Google Ads ou dans Google Analytics (GA4).
Le refus des cookies par le visiteur fait aussi partie des scénarios à tester. Donnez enfin à la version un nom assez précis pour pouvoir revenir en arrière.
Google Ads signale une balise manquante : pourquoi ?
Parce que le conteneur et la balise que Google Ads attend ne sont pas la même chose. Le conteneur peut être en place sans que la balise Google vise le bon compte. L’événement de conversion peut aussi ne pas se déclencher, ou ne pas arriver. Regardez d’abord comment la conversion a été créée.
- Créée à partir d’une adresse de page, avec une balise Google déjà détectée : elle n’exige pas de balise d’événement en plus.
- Importée depuis GA4 : elle est mesurée dans GA4 puis importée dans Google Ads, sans balise de conversion Google Ads dédiée.
- Créée manuellement : récupérez l’identifiant et le libellé de conversion, puis configurez dans le conteneur la balise de suivi des conversions Google Ads.
Le clic doit pouvoir être relié à la conversion. Si votre conteneur charge déjà la balise Google sur chaque page, un Conversion Linker supplémentaire n’est pas nécessaire. Le parcours se teste ensuite dans Tag Assistant. Le diagnostic de Google Ads confirme la réception, avec un délai possible avant sa mise à jour.
Le dataLayer : ce que le site transmet aux balises
Le dataLayer est une zone de données que le site remplit pour Google Tag Manager. Le site y dépose par exemple la valeur d’une commande, la référence d’un produit ou l’envoi réussi d’un formulaire. Sans lui, les balises dépendent surtout de la page elle-même : textes affichés, éléments de la page, adresse. Or ces éléments sont souvent fragiles quand le site évolue.
Un clic sur « Ajouter au panier » se repère à l’écran. En revanche, le dataLayer permet de transmettre aux balises la valeur du panier au moment voulu, sans dépendre du texte affiché. C’est ce contenu que lisent les déclencheurs et les variables du conteneur, détaillés dans le guide des balises, déclencheurs et variables.
Sauf besoin précis, ne mettez pas de données personnelles en clair dans le dataLayer (nom, e-mail, téléphone). Certaines fonctionnalités Google en utilisent, comme les conversions avancées, qui envoient à Google des coordonnées hachées. Elles restent des données personnelles. Dans ce cas, limitez-vous aux champs et aux règles prévus pour cette fonctionnalité. Le hachage ne remplace ni la base juridique, ni le consentement requis, ni un accès maîtrisé.
Vente en ligne : des données à préparer
Une vente en ligne a un numéro de commande, une valeur et une devise. Si ces champs n’existent pas dans le dataLayer au moment de l’envoi, les balises ne peuvent pas les inventer après coup. C’est l’objet du dataLayer e-commerce : le site transmet ces valeurs au lieu de laisser les balises les lire à l’écran.
Côté données client, une adresse e-mail mal mise en forme reste inutilisable après hachage. Les champs autorisés, leur mise en forme et le consentement se règlent donc en amont, y compris quand vous envoyez les données client côté serveur.
Conteneur Web ou conteneur serveur ?
Le conteneur Web s’exécute dans le navigateur du visiteur. Il s’installe avec deux extraits et permet de gérer les balises courantes.
Le conteneur serveur fait passer les données par un serveur que vous contrôlez avant de les envoyer à Google ou à d’autres outils. Il peut améliorer la vitesse, la sécurité et le contrôle des données transmises. En revanche, ce serveur doit être hébergé, surveillé et exploité par quelqu’un de compétent, et son coût varie selon le trafic.
Il ne contourne pas un refus de cookies et ne garantit pas de récupérer les données bloquées. Il ne répare pas non plus un plan de mesure défaillant. Dans le doute, restez sur un conteneur Web bien tenu. Le serveur se justifie pour un objectif précis, et son effet se mesure avant et après le passage.
Si vous franchissez le pas, il reste à choisir où héberger le conteneur serveur, par exemple sur Google Cloud ou chez Stape. Ce choix change le transport des données, pas les règles de consentement ni de rangement.
Le consentement ne se règle pas à l’installation
Une balise publicitaire ou GA4 qui se déclenche sans respecter le choix du visiteur crée un risque juridique et un risque pour la mesure. Une installation propre ne règle pas cette question.
Le bandeau cookies (CMP) recueille le choix du visiteur. Le Consent Mode transmet ce choix aux balises Google compatibles, qui adaptent leur mesure. Google Tag Manager peut coordonner l’ensemble, mais il ne crée ni le consentement ni la base juridique.
Le Consent Mode propose une configuration de base et une configuration avancée. Sa mise en place doit transmettre au minimum quatre états :
ad_storagepour les cookies publicitaires ;analytics_storagepour les cookies de mesure d’audience ;ad_user_datapour l’envoi à Google de données utilisateur liées à la publicité ;ad_personalizationpour la publicité personnalisée.
Prévoyez aussi ce qui se passe quand le visiteur refuse ou retire son accord. Choisissez donc le bandeau cookies avant de régler les balises.
Trois règles pour garder un conteneur rangé
Lors du passage à Google Tag Manager, retirez du code du site les balises que vous avez transférées et testées. Mais le désordre peut se retrouver dans l’interface. On y trouve alors des balises « Test 2 final OK » que personne n’ose supprimer, des déclencheurs en double et des balises en pause depuis deux ans. La différence, c’est que plus de monde y a désormais accès.
Avant la première balise, fixez ces règles :
- un nom clair pour chaque balise, qui indique son type et son rôle sans avoir à l’ouvrir ;
- un circuit de publication qui précise qui publie et qui relit ;
- une revue régulière qui supprime toute balise inactive ou sans responsable, si personne ne la justifie.
Auditer un conteneur existant en quatre étapes
Si Google Tag Manager est déjà en place, commencez par cet état des lieux avant d’ajouter une balise.
- Faire l’inventaire. Listez les balises, les déclencheurs et les variables, avec les versions et l’historique des publications. Associez chaque élément à son responsable et à son rôle : une balise ancienne est à vérifier, pas forcément à supprimer.
- Repérer les balises qui ne se déclenchent pas. Avant de supprimer une balise sans déclencheur, vérifiez qu’une autre ne l’appelle pas par séquençage. Une balise en pause peut être une archive utile ou un simple oubli.
- Traiter les balises sans responsable. Documentez-les et testez-les ; celles qui ne servent plus sont à supprimer.
- Nettoyer les variables inutilisées. Une variable qu’aucune balise ni aucun déclencheur actif n’utilise alourdit le conteneur pour rien. Vérifiez ce qui en dépend avant de la supprimer.
Installer GTM ou auditer un conteneur existant
Si vous n’avez pas encore Google Tag Manager, évaluez son intérêt avant de multiplier les codes collés en dur sur le site. S’il est déjà en place, ouvrez le conteneur et repérez les balises dont vous ne connaissez pas le rôle.
Ma règle : une balise que personne ne sait expliquer n’a pas sa place en ligne. Je la documente et je la teste, puis je la retire si rien ne la justifie, dans une nouvelle version que l’on peut annuler.
