DataLayer vs scraping DOM : fiabiliser le tracking de vos événements

Lundi matin, un client appelle son agence : plus aucune vente remontée dans Google Ads depuis vendredi. La cause ? Le développeur a mis à jour le design et renommé la classe CSS du bouton « Ajouter au panier », de .btn-green à .btn-blue. Le tracking, accroché à cette classe, a cessé de fonctionner sans prévenir.

En bref

• Le scraping DOM lit la page affichée : il casse au moindre changement de design, de texte ou de langue.

• Le DataLayer transmet des données structurées à Google Tag Manager, indépendamment du design.

• Pour l'e-commerce, suivez le format officiel de GA4 (purchase, transaction_id, value, currency, items).

• Jamais de données personnelles en clair dans le DataLayer.

Qu'est-ce que le DataLayer ?

Votre site parle HTML, CSS et JavaScript ; Google Tag Manager (GTM) attend des informations claires. Le DataLayer fait le lien entre les deux.

Techniquement, c'est un tableau JavaScript (window.dataLayer) dans lequel le site dépose des informations structurées au bon moment. GTM les lit et les transmet aux outils de mesure.

• Sans DataLayer : GTM devine ce qui se passe en observant la page (classe d'un bouton, texte affiché). C'est fragile.

• Avec DataLayer : le site annonce explicitement « un achat vient d'avoir lieu, voici le montant et l'identifiant ». C'est fiable.

Chez A-Track, nous ne lançons aucun projet d'envergure sans valider ou mettre en place un DataLayer structuré.

Pourquoi le scraping DOM est une mauvaise pratique

Le scraping DOM consiste à configurer GTM pour qu'il « lise » les éléments de la page. Exemple : déclencher la balise Achat quand la page contient le texte « Merci pour votre commande ».

1. Changement de langue : la version allemande affiche « Danke für Ihre Bestellung ». Le déclencheur ne trouve plus rien.

2. Refonte : une classe renommée ou une structure HTML modifiée, et le sélecteur CSS ne correspond plus.

3. Valeurs approximatives : un prix lu à l'écran (« CHF 1'254.00 TTC ») doit être nettoyé, et la moindre variation de format fausse le chiffre d'affaires.

Ces pannes sont silencieuses : aucun message d'erreur, juste des conversions qui disparaissent. C'est l'une des failles que révèle notre checklist d'audit de tracking.

Le standard GA4 : parler le langage de Google

Pour l'e-commerce, inutile de réinventer la roue : GA4 définit un format précis, décrit dans la documentation e-commerce de Google. Donnez-la à vos développeurs.

Pour un achat, le site pousse un événement purchase avec un objet ecommerce qui contient :

• transaction_id : l'identifiant unique de la commande (par exemple T_12345) ;

• value et currency : le montant (254.00) et la devise (CHF) ;

• items : la liste des produits, avec item_id, item_name, price et quantity.

Google recommande de vider l'objet ecommerce avant chaque nouvel événement (dataLayer.push({ ecommerce: null })), pour éviter que des produits d'un événement précédent ne se mélangent au suivant. Ainsi structuré, le suivi ne dépend plus ni de la couleur du bouton ni de la langue du site.

Conseil A-Track

Ne poussez jamais de PII en clair (user_email : « jean@exemple.ch ») dans le DataLayer : n'importe qui peut la lire dans la console du navigateur. Pour les Enhanced Conversions, Google accepte des données déjà hachées en SHA-256 (aide Google Ads) ; le hachage peut aussi se faire dans un conteneur GTM server-side.

Qui fait quoi : agence, développeur et expert tracking

C'est souvent le point de friction : le marketeur ne code pas, le développeur ne connaît pas GTM. Nous recommandons ce partage des rôles :

1. L'expert tracking rédige le plan de taggage : « Sur la page de confirmation, pousser l'événement purchase avec ces variables. »

2. Le développeur intègre les dataLayer.push dans le site selon ces spécifications, sans toucher à GTM.

3. L'expert tracking configure GTM pour lire le DataLayer et envoyer les données à GA4, Google Ads, Meta ou LinkedIn, dans le respect du consentement.

4. Tous valident ensemble en mode aperçu avant la mise en ligne.

CMS ou site sur mesure : qui doit coder ?

Bonne nouvelle : sur les CMS courants, il n'est souvent pas nécessaire de coder.

• WordPress / WooCommerce : des plugins éprouvés comme GTM4WP génèrent un DataLayer compatible GA4. Vérifiez tout de même les valeurs (taxes, remises).

• Shopify : les « Customer Events » natifs et des applications dédiées font le travail.

• Site sur mesure (Laravel, React, Angular...) : l'intervention du développeur est indispensable, et un plan de taggage précis évite les allers-retours.

Conclusion : trois actions pour un tracking qui ne casse plus

1. Listez dans GTM les déclencheurs basés sur des classes CSS, des textes ou des sélecteurs : ce sont vos points de rupture.

2. Remplacez-les par des événements DataLayer, en commençant par les conversions (achat, formulaire, prise de rendez-vous).

3. Testez après chaque mise à jour du site. Pour aller plus loin, voir notre guide mesure de la performance marketing.