Data layer : structurer la donnée que vous envoyez à vos tags
Le contenu de vos rapports se décide dans une trentaine de lignes de code que le marketing ne voit jamais. Concevoir un data layer qui structure la donnée transmise à vos tags revient à décider, en amont, de ce que la mesure saura dire, et cette étape ouvre notre travail d'implémentation du tracking et de conformité RGPD.
- La couche de données inverse la logique : le site déclare ce qu'il expose, les balises se contentent de lire, et la responsabilité passe côté développement.
- Les noms décrivent le métier, jamais l'interface : une variable nommée d'après un bloc visuel devient fausse à la refonte suivante.
- Un montant transmis tantôt en nombre, tantôt en chaîne avec un symbole monétaire, produit des sommes fausses que personne ne remarque.
- Pour qu'une variable soit disponible au chargement, la poussée doit se situer au-dessus du code du conteneur : sinon la donnée existe sans jamais apparaître.
- Aucune donnée directement identifiante ne transite par cette couche : les fuites arrivent par mécanique, pas par décision.
- Ce que le data layer déplace comme responsabilité
- Concevoir un nommage qui survivra à la prochaine refonte
- Le moment de la poussée, cause silencieuse de la moitié des pertes
- Les données interdites de transit par le data layer
- Questions fréquentes sur le data layer
La documentation officielle décrit cet objet comme le vecteur d'information vers les balises, initialisé sur la page puis alimenté par des poussées successives. Ce que nos experts du web analytics constatent en audit tient moins à la technique qu'aux conventions retenues au premier jour.
Ce que le data layer déplace comme responsabilité
Sans couche de données, chaque balise lit la page pour trouver son information : un montant récupéré dans un élément d'affichage, une catégorie devinée à partir de l'URL. Le dispositif fonctionne jusqu'à la première évolution graphique, puis casse sans prévenir.
La couche de données inverse la logique. Le site déclare explicitement ce qu'il expose, les balises se contentent de lire, et la responsabilité passe côté développement. Ce déplacement est le vrai sujet : il transforme la mesure en fonctionnalité du site, versionnée et testée comme le reste du code.
Une couche de données maintenue par l'équipe de développement survit aux refontes graphiques, aux changements d'agence et aux migrations d'outils. C'est le seul actif du dispositif de mesure qui ne dépend d'aucun éditeur.
Concevoir un nommage qui survivra à la prochaine refonte
Les noms décrivent le métier, jamais l'interface. Une variable nommée d'après un bloc visuel devient fausse à la refonte suivante, alors qu'une variable nommée d'après ce qu'elle représente traverse les versions du site. La règle vaut pour les événements comme pour les propriétés qu'ils transportent.
La granularité se décide au même moment. Un objet trop plat vous oblige à créer une variable par cas, un objet trop imbriqué complique la configuration des balises. Le point d'équilibre place les entités du métier au premier niveau, produit, commande, utilisateur, et leurs attributs en dessous.
Le nommage de votre couche de données mérite la même discipline sur les valeurs que sur les clés. Un montant transmis tantôt en nombre, tantôt en chaîne avec un symbole monétaire, produit des sommes fausses que personne ne remarque avant le premier écart avec la comptabilité. Fixez le format de chaque champ dans le plan de taggage, et faites-le vérifier en recette.
Le moment de la poussée, cause silencieuse de la moitié des pertes
Une variable poussée après le chargement du conteneur arrive trop tard pour les balises qui se déclenchent au chargement de la page. La documentation Google est explicite : pour qu'une variable soit disponible au chargement, l'appel de poussée doit se situer au-dessus du code du conteneur, et chaque variable déclarée ne persiste que le temps de la page courante.
Cette contrainte explique une anomalie que nous voyons souvent. La donnée existe dans le code, un développeur la voit dans sa console, et pourtant elle n'apparaît dans aucun rapport. Rien n'est cassé, la poussée arrive simplement après le passage de la balise.
Le cas se complique sur les sites à navigation dynamique, où la page ne se recharge jamais vraiment. Les informations doivent alors être repoussées à chaque changement de vue, et le contrôle de ce comportement fait partie de la recette.
Les données interdites de transit par le data layer
La règle est simple et elle ne souffre aucune exception : aucune donnée directement identifiante ne passe par cette couche vers vos outils de mesure. Google interdit explicitement l'envoi de toute donnée qu'il pourrait utiliser ou reconnaître comme identifiant une personne, adresses de courriel, numéros de mobile personnels ou numéros de sécurité sociale, et prévoit la suspension du service en cas de manquement.
Les fuites arrivent rarement par décision, presque toujours par mécanique. Une adresse de courriel qui se retrouve dans un paramètre d'URL après validation de formulaire, un identifiant client concaténé dans un nom de page, un champ libre recopié tel quel dans un paramètre d'événement. Ces cas se détectent en recette et se corrigent à la source.
Un identifiant technique interne, sans signification hors de votre système, reste possible pour la réconciliation. Le cadre exact de cette pratique mérite une validation par votre délégué à la protection des données, et notre guide sur GA4 et le RGPD, listé en fin de page, en détaille les conditions.
Questions fréquentes sur le data layer
Une couche de données bien conçue vous évite de refaire tout le marquage dans deux ans. Nos consultants en rédigent la spécification avec vos développeurs, demandez une recette de votre tracking. Vos leviers d'acquisition restent pilotés par notre agence de marketing digital.