Tracking Drupal avec GTM et GA4 : modules, dataLayer et consentement

Sur Drupal, le tracking passe par le module google_tag pour injecter le conteneur GTM, et par un module dataLayer ou un code dédié pour transmettre les données de contenu. Les événements GA4 se construisent dans GTM à partir de ce dataLayer, et le consentement se gère soit par un module de bannière, soit par une CMP externe reliée à Consent Mode v2. Les pièges réels se trouvent dans les versions de modules, le cache de page et le rendu asynchrone.

Si vous avez besoin d’un setup GA4 mené par un consultant sur un site Drupal, l’enjeu principal est de figer ces choix dès le départ, pas de les corriger après coup.

Choisir les modules

L’état des modules change souvent. Je vérifie toujours la version compatible avec la version de Drupal avant toute installation.

Module	Rôle	Statut vérifié (nov. 2026)
google_tag	Injection du ou des conteneurs GTM, conditions d’affichage	Stable, maintenu, compatible Drupal 10 et 11
dataLayer	Expose les données entités, utilisateur et page au front	Stable, compatible Drupal 10.2 et 11 pour la branche 2.x
google_tag_events	API PHP pour pousser des événements dans le dataLayer	Dépend de google_tag ; la branche 3.x suit la branche 2.x de google_tag
Module Google Analytics historique	Ancienne intégration GA	Les utilisateurs de GA sont invités à passer sur la branche 2.x du module

Le module google_tag gère les conteneurs et les conditions : chemin de la page, rôle, langue, domaine. Cela évite de dupliquer des balises dans le thème.

Le dataLayer côté Drupal

Le dataLayer se remplit au rendu de la page, avec les informations que GTM ne peut pas lire seul : type de contenu, identifiant auteur, termes de taxonomie, rôle de l’utilisateur connecté. Le module dataLayer produit ces valeurs ; l’extrait ci-dessous montre la forme d’un événement de lecture de contenu, à adapter à vos champs.

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    content_type: "article",
    content_id: "1234",
    taxonomy_terms: "analytics, gtm",
    user_role: "anonymous"
  });
</script>

Dans GTM, on lit ces variables de la couche de données, puis on les envoie avec les événements GA4. Un point de vigilance : le rôle utilisateur est une donnée personnelle indirecte. Ne l’envoyez pas à GA4 sans l’avoir validé avec votre DPO ou votre CMP.

Pour une explication plus générale du dataLayer et des pièges de base, voir la FAQ sur le dataLayer et GTM et le glossaire du data layer.

Événements Webform

Le module Webform est le plus courant pour les formulaires de contact et de demande. Une soumission réussie doit pousser un événement dédié, avec un identifiant de formulaire. Deux approches :

• un hook de Drupal ou un service PHP qui pousse l’événement via google_tag_events lors de la soumission réussie ;
• un script front qui écoute la fin de soumission et pousse l’événement, à condition de ne pas se déclencher sur une erreur de validation.

Dans les deux cas, distinguez la soumission réussie de la tentative : une erreur de validation ne doit jamais compter comme une conversion. Le même principe s’applique à generate_lead : un seul point de déclenchement, documenté.

Consentement et Consent Mode v2

Sur Drupal, trois options courantes :

• Un module de bannière (type EU Cookie Compliance ou Klaro) : vérifiez qu’il émet bien les états de consentement attendus par GTM et Consent Mode v2. Un module qui bloque les scripts sans transmettre le signal empêche GA4 de mesurer les visiteurs qui acceptent.
• Une CMP externe : elle se charge avant le conteneur GTM et pousse les signaux Consent Mode v2. C’est souvent plus lisible à maintenir sur un site à plusieurs équipes.
• Une combinaison : une CMP pour le consentement, un module pour la gestion des pages sensibles. Dans ce cas, la règle est simple : une seule source de vérité pour le consentement.

Pour la mise en œuvre, voir le guide Consent Mode v2. Pour choisir une CMP, le comparatif Axeptio, Didomi et Cookiebot donne les critères principaux.

Drupal Commerce : les limites

Drupal Commerce permet un tracking e-commerce complet, mais chaque étape du tunnel (panier, adresse, paiement) demande une intégration explicite. Trois limites à anticiper :

• le tunnel de paiement externe (passerelle hébergée) peut couper le dataLayer lors du retour ;
• les événements add_to_cart depuis une vue liste dépendent du thème, pas du module ;
• les montants et devises doivent être remontés depuis l’entité commande, pas recalculés côté front.

Cache et BigPipe : les pièges

Deux mécanismes Drupal peuvent faire disparaître ou dupliquer des événements :

• Le cache de page. Un dataLayer rendu dans une page mise en cache est identique pour tous les visiteurs. Une donnée liée à l’utilisateur (rôle, panier) doit passer par un bloc non mis en cache ou par un contexte de cache adapté.
• BigPipe. Il envoie une partie du HTML après le premier rendu. Un dataLayer injecté tard peut arriver après le déclencheur GTM de la page vue. Vérifiez l’ordre dans le mode aperçu.

Recette minimale : tester une page en cache (utilisateur anonyme) et une page personnalisée (utilisateur connecté), puis comparer les événements dans GTM.

Recette avant mise en production

• Vérifier la version de google_tag et de dataLayer contre la version de Drupal.
• Soumettre un Webform en succès et en erreur : seul le succès doit produire un événement.
• Refuser le consentement, puis tester la mesure : constater ce qui part vers GA4.
• Contrôler une page en cache et une page personnalisée.
• Vider le cache après chaque changement de conteneur, et retester.

Foire aux questions

Faut-il garder le module Google Analytics historique ?

Non, pas pour un nouveau projet. La branche 2.x est la référence. Pour un site existant, la migration se planifie avec un test sur une copie de l’environnement.

Peut-on tout faire avec google_tag seul ?

Il injecte le conteneur et gère les conditions. Le dataLayer enrichi et les événements métier demandent du code ou un module complémentaire.

Le cache Drupal casse-t-il le tracking ?

Il peut, si une donnée utilisateur est mise en cache pour tous les visiteurs. C’est un problème de contexte de cache, à traiter en amont du tracking.

Sources

• Module Google Tag (drupal.org)
• Module dataLayer (drupal.org)