Google Tag Manager, ou comment arrêter d'appeler le développeur

Le problème que personne ne raconte plus

Avant 2012, ajouter un outil de mesure à un site web était une négociation.

Le marketing voulait tester un nouvel outil. Il fallait écrire un ticket, l’envoyer à l’équipe technique, attendre la prochaine mise en production, découvrir que le code avait été posé sur une seule page au lieu de toutes, refaire un ticket. Trois semaines pour une ligne de JavaScript. Pendant ce temps, la campagne était finie.

Le résultat, c’était des pages web qui accumulaient les couches. Un vieux compteur oublié, un pixel publicitaire d’une agence partie depuis deux ans, un outil de chat qu’on n’utilisait plus. Personne n’osait rien retirer, parce que personne ne savait plus à quoi servait quoi.

Le 1er octobre 2012, Google annonce Tag Manager, avec un titre de billet qui dit tout de l’intention : « Digital marketing made (much) easier ». L’idée tient en une phrase : on pose une bonne fois pour toutes un code sur le site, et tout le reste se gère ailleurs.

Ce que fait vraiment l’outil

Google Tag Manager ne mesure rien.

Je le répète parce que c’est le contresens le plus courant, et parce qu’il coûte cher : des gens installent Tag Manager, attendent, et s’étonnent de ne voir aucun chiffre nulle part. C’est normal. Il n’y a pas de chiffres à voir.

Tag Manager est un aiguilleur. Il attend qu’il se passe quelque chose sur votre site, et quand ça arrive, il déclenche les outils que vous lui avez désignés. Le compteur, c’est Google Analytics. Le pixel publicitaire, c’est Meta ou Google Ads. Tag Manager décide seulement du moment.

Quatre mots à connaître, et pas un de plus

Toute la mécanique tient en quatre notions. Les voici dans l’ordre où elles servent.

Le conteneur est le code posé sur votre site. Un par site, en général. C’est la seule chose que quelqu’un devra toucher au code, une seule fois.

La balise est ce qui s’exécute. « Envoie une page vue à Google Analytics. » « Dis à Meta qu’un achat a eu lieu. » Une balise ne fait rien toute seule, elle attend d’être déclenchée.

Le déclencheur est la condition. « Quand une page se charge. » « Quand ce formulaire est envoyé. » « Quand le visiteur a fait défiler 75 % de la page. » C’est ici que se joue la qualité de votre mesure, et c’est ici que se produisent la plupart des erreurs.

La variable est une information qui change. Le montant d’une commande, le nom d’une page, l’identifiant d’un produit. C’est ce qui transforme un « quelqu’un a acheté » en « quelqu’un a acheté pour 240 dollars ».

Un conteneur bien construit, c’est ça, et rien d’autre. Le reste est de l’accumulation.

La bascule de 2023 que beaucoup ont subie sans la voir venir

Le 1er juillet 2023, Google a arrêté de traiter les données d’Universal Analytics, la version d’Analytics que tout le monde connaissait depuis dix ans. Un an plus tard, à partir de la semaine du 1er juillet 2024, l’accès à l’interface et aux données historiques a été coupé et les données supprimées.

Cette bascule a été vécue comme une corvée administrative. Elle était en fait beaucoup plus profonde : Google Analytics 4 ne raisonne plus en pages vues et en sessions, il raisonne en événements. Tout est un événement, y compris une page vue.

Ce changement de modèle a rendu Tag Manager plus important, pas moins. Dans l’ancien monde, poser Analytics suffisait à avoir des chiffres à peu près corrects tout seul. Dans le nouveau, ce qui compte vraiment, ce sont les événements que vous décidez de mesurer. Et les décider, c’est exactement le travail qu’on fait dans Tag Manager.

Les quatre erreurs qui reviennent tout le temps

Je reprends régulièrement des conteneurs construits par quelqu’un d’autre. Les mêmes quatre problèmes reviennent, dans des proportions qui ne varient presque pas.

Analytics installé deux fois

C’est de loin le plus fréquent, et le plus vicieux, parce que le site a l’air de très bien marcher.

Quelqu’un pose Analytics en direct dans le site. Plus tard, quelqu’un d’autre le pose aussi dans Tag Manager, sans savoir. Chaque visite est comptée deux fois. Le taux de rebond s’effondre, ce qui a l’air d’une excellente nouvelle. Les chiffres sont pourtant faux, et toutes les décisions prises dessus le sont aussi.

Le symptôme qui doit vous alerter : un taux de rebond anormalement bas, autour de 1 à 5 %. Personne n’a un aussi bon site.

Le conteneur dépotoir

Une balise ajoutée pour un test, jamais retirée. Un déclencheur nommé « test2 ». Un autre nommé « test2 final ». Au bout de deux ans, plus personne n’ose rien supprimer, parce que personne ne sait ce qui casserait.

Google surveille d’ailleurs cette dérive : son aide recommande d’optimiser la configuration dès que l’indicateur de taille du conteneur dépasse 70 %. Mon avis, qui n’engage que moi : un conteneur devient ingérable par un humain bien avant d’atteindre une limite technique.

Des conversions supposées plutôt que testées

Une balise est créée, elle a l’air correcte, on passe à autre chose. Six mois plus tard on découvre que le formulaire de contact n’a jamais rien remonté, parce qu’il ouvre une fenêtre au lieu de changer de page.

Une conversion qui n’a pas été testée en conditions réelles n’existe pas. C’est la règle que j’applique sans exception : j’envoie le formulaire, j’achète pour de vrai, je passe l’appel, et je vérifie que la donnée arrive. Ça prend une heure et ça évite six mois de décisions à l’aveugle.

La confusion entre mesure et consentement

Google Tag Manager ne rend pas votre site conforme. Il sait respecter un consentement, il ne sait pas le recueillir.

C’est un point que je vois mal compris presque partout, alors soyons précis. Le mode de consentement de Google fonctionne avec quatre signaux : ad_storage pour les témoins publicitaires, analytics_storage pour la mesure, ad_user_data pour les données transmises à la publicité, ad_personalization pour le reciblage. Ces signaux disent aux balises ce qu’elles ont le droit de faire.

Mais quelqu’un doit poser la question au visiteur, et surtout ne rien charger tant qu’il n’a pas répondu. C’est ce qu’on appelle le blocage préalable, et c’est là que la plupart des sites trichent : ils affichent une bannière pendant que les scripts sont déjà partis. La bannière devient alors une décoration.

Deux façons de sortir de ce piège, et j’ai écrit un outil gratuit pour chacune. Pour vérifier ce que votre site dépose réellement avant le clic, l’extension Chrome Cookie Audit rejoue une première visite et horodate chaque cookie. Pour faire le blocage préalable sur WordPress, le plugin Clear Cookie neutralise les scripts de suivi tant que le visiteur n’a pas répondu.

Depuis mars 2024, ce mode de consentement conditionne l’accès aux fonctions d’audience et de reciblage des services publicitaires de Google dans l’Espace économique européen. Autrement dit, mal le configurer ne vous expose pas seulement juridiquement, ça dégrade aussi vos campagnes.

Le server-side, et à qui il sert vraiment

Depuis quelques années, Google propose de déplacer le traitement des balises du navigateur vers un serveur que vous contrôlez. C’est le server-side tagging.

L’idée : au lieu que le navigateur du visiteur parle directement à dix outils différents, il parle à un seul serveur, qui redistribue ensuite. La documentation de Google met en avant deux bénéfices, de meilleures performances puisque moins de code s’exécute chez le visiteur, et une meilleure maîtrise puisque les données transitent par un environnement que vous gérez.

Ce n’est pas gratuit, et c’est le point qu’on oublie de vous dire. Le serveur tourne sur Google Cloud. La documentation officielle indique de l’ordre de 30 à 50 dollars américains par serveur et par mois une fois sorti du palier gratuit, auxquels s’ajoutent les frais réseau.

Mon avis, franchement : pour un site vitrine ou une PME qui mesure quelques centaines de conversions par mois, le server-side résout un problème qu’elle n’a pas encore. Il devient pertinent quand le volume est réel, quand les blocages de scripts abîment sérieusement la mesure, ou quand la maîtrise des données est une exigence contractuelle. Avant ça, c’est une complexité de plus à maintenir.

Ce que je conseille, dans l’ordre

Si vous partez de zéro, cet ordre évite les trois quarts des problèmes ci-dessus.

Un. Vérifiez d’abord ce qui est déjà installé sur votre site. Avant de poser quoi que ce soit. L’extension Tag Assistant de Google le montre en quelques secondes, et vous découvrirez peut-être un Analytics oublié.

Deux. Posez le conteneur, une seule fois, sur toutes les pages.

Trois. Branchez le mécanisme de consentement avant la première balise. Pas après. L’ordre n’est pas une préférence, c’est ce qui rend le blocage préalable réel.

Quatre. Listez vos conversions par ordre d’importance commerciale, et arrêtez-vous à cinq. Formulaire, appel, prise de rendez-vous, achat, téléchargement. Cinq conversions justes valent mieux que vingt approximatives.

Cinq. Testez chacune en conditions réelles, une par une, et notez ce que vous avez testé et quand.

Si cette liste vous paraît juste mais que vous préférez la faire faire, ou apprendre à la faire, elle fait partie de mes prestations SEO à la carte.

Six. Documentez. Une page, pas dix. Quelle balise, pour quoi, déclenchée quand. Votre vous du futur, ou la personne qui reprendra le dossier, vous en sera reconnaissant.

Ce qui n’a pas changé depuis 2012

Google Tag Manager a beaucoup évolué : le server-side, le mode de consentement, la bascule vers un modèle par événements. Mais la promesse d’origine tient toujours, et c’est ce qui explique sa longévité.

Le pouvoir de décider ce qu’on mesure appartient à ceux qui vont s’en servir. Pas à la file d’attente de l’équipe technique.

C’est une bonne nouvelle et un piège en même temps. Une bonne nouvelle parce que la boucle entre une question et sa réponse se compte désormais en heures. Un piège parce qu’un outil qui rend l’ajout facile rend aussi l’accumulation facile, et qu’un conteneur n’a jamais nettoyé personne à votre place.