Balise, déclencheur, variable : qui fait quoi ?
Une installation de Google Tag Manager (GTM) se lit avec une phrase simple : quand tel événement arrive, exécute telle balise avec telles valeurs. Cette phrase aide à comprendre la configuration, mais elle n’indique pas si la conversion mesurée est réelle.
La balise envoie les données. Elle transmet par exemple une conversion à Google Ads ou un événement à Google Analytics. Sur un modèle de balise copié, adaptez à votre site les identifiants, les paramètres et les règles de consentement.
Le déclencheur choisit le moment. Il attend un événement, comme le chargement de la page, un clic ou un événement envoyé par le site. Il vérifie ensuite ses conditions avant de lancer la balise. Une balise peut aussi être appelée dans une séquence, avant ou après une autre balise ; ses propres déclencheurs sont alors ignorés.
La variable fournit une valeur. Elle lit l’adresse de la page, un cookie ou un élément affiché. Elle lit aussi la couche de données (dataLayer), l’espace où le site range pour GTM des informations comme le montant d’une commande. Une variable peut enfin calculer ou transformer une valeur, ou en appeler une autre. La balise s’en sert pour envoyer le montant et la devise, et le déclencheur pour comparer l’adresse de la page à un chemin.
Le mode Aperçu de GTM et Tag Assistant montrent les événements de la page, les valeurs lues et les balises exécutées ou bloquées. C’est un diagnostic, pas une preuve. La preuve vient de la suite de la chaîne : la requête envoyée, sa réception par Google Ads et la vente ou la demande enregistrée chez vous.
Quel déclencheur choisir ?
GTM propose plusieurs types de déclencheurs, dont la liste et les noms peuvent changer dans l’interface. Le tableau retient ceux qui servent à mesurer pour Google Ads.
Les déclencheurs utiles pour Google Ads
| Déclencheur | Quand il s’exécute | À savoir |
|---|---|---|
| Initialisation du consentement | Avant tous les autres déclencheurs | Il est réservé aux balises qui définissent ou mettent à jour le consentement. |
| Initialisation | Après l’initialisation du consentement, avant la page vue | Il sert à une balise qui doit s’exécuter avant les autres balises de la page. |
| Page vue | Dès que le navigateur commence à charger la page | Il convient pour compter une page vue, pas pour une conversion supposée. |
| DOM prêt | Quand la structure HTML de la page est construite | Un contenu ajouté ensuite par un script peut encore manquer. |
| Fenêtre chargée | Quand les images et les scripts de la page sont chargés | Une page chargée ne prouve ni une commande, ni un paiement, ni une demande reçue. |
| Clic (liens seuls ou tous les éléments) | Quand la personne clique | Un clic ne prouve pas une conversion. Repérer le bouton par son apparence peut devenir impossible après une refonte. |
| Envoi de formulaire | À l’envoi d’un formulaire HTML classique | Les formulaires dynamiques ou d’outils tiers peuvent demander un événement de succès dédié. |
| Événement personnalisé | Quand le site dépose un événement dans la couche de données | Le « Nom de l’événement » doit reprendre exactement ce que le site envoie. |
| Modification de l’historique | Quand l’adresse change sans recharger la page | Il sert aux sites qui changent d’écran sans recharger, une fois leur fonctionnement vérifié. |
| Défilement, minuterie, vidéo YouTube, visibilité | Au seuil ou à l’interaction que vous avez réglés | Il mesure l’intérêt pour la page, pas une vente. |
| Groupe de déclencheurs | Quand chaque membre s’est déclenché au moins une fois sur la page | Il ne garantit ni l’ordre des actions ni qu’elles forment une même conversion. |
Le déclencheur Initialisation du consentement sert aux balises qui définissent le choix par défaut de la personne, ou le mettent à jour, avant toutes les autres. Le bandeau cookies, lui, s’installe selon la méthode prévue par son éditeur. Le mode Consentement de Google adapte ensuite la mesure à ce choix, mais il ne décide pas à lui seul de la base légale de la collecte.
Le déclencheur Envoi de formulaire peut vérifier que les champs sont valides et attendre brièvement les balises. Il ne sait pas si votre serveur a accepté la demande, ni si elle est arrivée dans votre outil de suivi des clients (CRM). Déclenchez donc plutôt la conversion sur un événement envoyé par le site après la réponse positive du serveur.
Combiner plusieurs conditions
Un filtre compare une variable à une valeur, par exemple la variable Page Path au chemin /merci. Les conditions réunies dans un même déclencheur doivent toutes être vraies. Plusieurs déclencheurs associés à une même balise sont des chemins alternatifs, et un seul suffit. Une expression régulière permet de reconnaître plusieurs chemins avec une même règle. Bornez-la au début et à la fin, puis testez-la sur des cas positifs et négatifs.
Les options de fréquence limitent les exécutions de la balise : « une fois par événement » ou « une fois par page ». Elles n’empêchent pas de compter deux fois la même commande sur deux pages, deux visites ou deux sources.
D’où viennent les conversions en double ?
Un mauvais déclencheur est une cause fréquente, mais pas la seule. Avant de corriger, je fais la liste de tous les chemins par lesquels la conversion peut partir. Voici les causes à vérifier :
- La même conversion part de deux endroits, comme le code du site ou un module de boutique en ligne en plus de GTM, ou deux balises sur un même événement.
- La page de confirmation est rechargée ou rouverte depuis un message, et la balise repart.
- Le déclencheur est posé sur le bouton « Envoyer » et compte le geste, même si le formulaire échoue ensuite.
- La conversion est envoyée par le navigateur puis importée depuis votre serveur, sans le même identifiant de transaction.
Avant de désigner une cause, regardez les requêtes réellement envoyées. Pour un achat, Google Ads reconnaît deux envois d’une même commande grâce à l’identifiant de transaction, s’ils visent la même conversion. Cet identifiant de transaction doit être unique, créé par votre système et identique d’une source à l’autre. Il ne doit contenir aucune information qui permette de reconnaître le client.
La vraie protection combine une conversion déclenchée sur le succès réel, un identifiant créé par votre système et le bon réglage de comptage dans Google Ads. Les options de fréquence de GTM ne suffisent pas, car elles repartent à zéro dans un autre contexte.
Une fausse conversion fausse aussi les enchères de Google Ads axées sur les conversions. Elles peuvent alors privilégier des clics susceptibles de déclencher cette fausse conversion, sans rien rapporter. Dans ce cas, Google optimise simplement sur la donnée que vous lui avez envoyée.
Quand ajouter une exception ?
Une exception empêche une balise de partir quand sa condition est vraie sur l’événement en cours. Elle ne se souvient pas d’une condition vue plus tôt sur la page. Restreignez d’abord le déclencheur lui-même : si une balise ne concerne que les pages produit, dites-le dans son déclencheur. Ajoutez une exception seulement quand la règle se lit « sur ces pages, sauf dans ce cas » et reste plus simple à tester ainsi.
Pour exclure /merci, /admin et /panier, prévoyez une exception par chemin, soit trois, ou une seule expression régulière testée sur le chemin de la page, comme ^/(merci|admin|panier)(/|$). Notez les adresses qui doivent être bloquées et celles qui doivent passer.
Le consentement suit une autre logique que les exceptions. Pour les balises Google, utilisez leurs réglages de consentement intégrés et le choix transmis par le bandeau cookies. Ne retirez pas un blocage sans vérifier le mode choisi : le mode de base bloque les balises avant l’accord, tandis que le mode avancé autorise des mesures sans cookie. Pour la balise d’un autre fournisseur, vérifiez ses propres réglages et la règle applicable, au lieu d’ajouter par réflexe un blocage par adresse.
Exclure /merci d’une balise ne veut pas dire couper toute mesure sur la page de confirmation. Si la personne l’a accepté, l’achat peut servir à créer une liste de clients déjà acheteurs, que vous excluez ensuite de la campagne concernée. Cette exclusion prend du temps : la liste doit se remplir et devenir utilisable avant que la diffusion change.
Nommez chaque exception selon sa règle, par exemple BLOC, Chemins internes non publics. L’Aperçu montre ensuite où elle bloque et si elle laisse bien passer le reste.
Nommer et ranger le conteneur
Un bon nom permet de comprendre une balise, un déclencheur ou une variable sans l’ouvrir, et de relire un changement avant publication. Le format compte moins que sa régularité : toute l’équipe applique la même règle écrite.
Une convention de nommage simple
J’utilise le format type, destination, puis événement ou rôle :
- La balise qui envoie un achat à Google Ads :
BALISE, Google Ads, Achat confirmé. - Le déclencheur de l’événement d’achat :
DECL, Événement, purchase. - L’exception qui écarte le site de test :
BLOC, Environnement de test. - La variable du numéro de commande :
VAR, Couche de données, transaction_id.
Le nom affiché d’un déclencheur est libre. Le champ « Nom de l’événement » d’un déclencheur personnalisé, lui, doit reprendre exactement l’événement envoyé par le site, majuscules comprises. Renommer l’affichage ne corrige donc pas un événement mal nommé.
Ajoutez au nom l’environnement, l’action de conversion, le pays ou la version quand ces distinctions existent. Évitez « test2 », « nouveau » ou « copie », qui ne veulent plus rien dire à la publication suivante.
Dossiers, espaces de travail et versions
Créez des dossiers quand l’équipe en a besoin pour s’y retrouver, par fournisseur ou par parcours. Ils rangent les éléments, mais n’isolent pas les changements. Pour cela, chaque lot de modifications passe par son propre espace de travail, où l’on relit les écarts et teste avant de publier une version nommée et décrite. Une version permet de revenir en arrière, mais elle ne remplace ni la gestion des accès ni la revue des modèles personnalisés et de leurs permissions.
Sur un conteneur hérité, faites d’abord l’inventaire de l’existant, versions, installations et responsables compris. Un nom ou un filtre modifié trop tôt peut casser une dépendance invisible.
Obtenir des variables fiables
GTM propose des variables intégrées, prêtes à activer. Activez seulement celles qui servent à une balise ou à un déclencheur.
Pour un montant ou un numéro de commande, préférez la couche de données pour l’e-commerce à un texte lu dans la page. Un texte ou un emplacement de la page change avec le design, alors qu’une couche de données maintenue par le site n’en dépend pas.
Une variable transmet ou transforme une valeur, mais elle ne la rend pas exacte. Le montant payé, un remboursement ou un prospect accepté doivent venir du système qui connaît cet état. La couche de données elle-même doit être cadrée : écrivez pour chaque information son nom, son format et le moment où elle arrive, puis nommez un responsable. Retestez ces règles à chaque évolution du site.
Une information utile sur une nouvelle page doit être déposée de nouveau dans la couche de données, car GTM ne garantit pas de la garder d’une page à l’autre.
N’envoyez aucune adresse e-mail, aucun téléphone, aucun nom ni aucune autre donnée personnelle dans une adresse de page, un nom d’événement ou un identifiant de transaction. Pour chaque fournisseur, et surtout pour une balise active sur toutes les pages, vous devez pouvoir justifier les points suivants :
- Les données envoyées servent à un usage précis et se limitent au nécessaire.
- Le fournisseur et les destinataires sont connus, transferts éventuels compris.
- Un statut commercial visible dans le navigateur n’est pas envoyé sans raison.
- La durée de conservation et la base légale sont définies.
- Le choix de la personne sur les cookies est respecté.
Pour tester une variable, comparez sa valeur dans l’Aperçu à la donnée d’origine, puis à la valeur reçue par l’outil. Rapprochez-la enfin des chiffres de votre CRM ou de vos commandes, annulations et remboursements compris. Google Ads attribue des conversions à vos annonces, mais votre chiffre d’affaires de référence reste celui de vos commandes et de votre CRM.
La version GTM côté serveur utilise aussi des balises, des déclencheurs et des variables, mais ajoute un serveur à héberger, sécuriser et surveiller.
Vérifier les balises GTM avant de publier le conteneur
Pour chaque balise importante, suivez ces étapes dans l’ordre.
- Définir la conversion réelle. Distinguez le clic, la tentative, l’acceptation par le serveur et la demande utile, puis choisissez l’identifiant qui doit rester unique.
- Configurer à l’écart. Dans un espace de travail dédié, adaptez la balise, ses conditions, ses valeurs et ses réglages de consentement.
- Tester sans fausser les chiffres. Le contrôle passe par une commande ou un formulaire de test dans l’Aperçu. Si le test doit se faire sur le site réel, excluez-le des conversions et du chiffre d’affaires.
- Vérifier toute la chaîne. Dans GTM, l’événement, les valeurs et le consentement doivent être justes. Regardez ensuite la requête envoyée, la réception dans Google Ads et une trace unique dans votre système.
- Publier une version suivie. La version a un nom, un responsable et un moyen prévu pour revenir en arrière.
Une configuration GTM est bonne quand ses conversions correspondent à vos ventes réelles, pas seulement quand l’interface affiche un voyant vert.
