Google Tag Manager Data Layer — documentation

Installation

Prérequis et installation

Magento 2.4.x (Open Source ou Adobe Commerce), PHP 8.1 à 8.5, Hyvä ou Luma. Un conteneur Google Tag Manager, qui est gratuit.

composer require codingrow/module-gtmdl
bin/magento module:enable Codingrow_Gtmdl
bin/magento setup:upgrade

En mode production, aussi setup:di:compile, setup:static-content:deploy et cache:flush. Les identifiants Composer arrivent par e-mail quand vous demandez le module gratuit ou achetez les événements d'achat.

Tout se configure dans Stores → Configuration → Codingrow Extensions → Google Tag Manager Data Layer, et chaque réglage peut différer par store view : changez le sélecteur Scope en haut à gauche.

Conteneur

Champ	Ce qu'il fait
Enable	Désactivé, la boutique ne rend ni le conteneur ni une ligne de data layer.
Container ID	Votre conteneur, sous la forme `GTM-XXXXXXX`. Écrit autrement, il est ignoré. Laissez vide pour remplir le data layer sans charger de conteneur — ce qu'il faut quand le conteneur est déjà installé par autre chose.
Load the container only after cookie consent	Utilise le Cookie Restriction Mode de Magento. Le data layer est rempli de toute façon : dès que le consentement arrive, rien n'est perdu. Avec le consentement Google actif, ci-dessous, cela ne s'applique plus.

Utilisation

Google Consent Mode v2. L'état initial doit être déclaré avant le démarrage du conteneur : seul celui qui charge le conteneur peut le faire. L'interrupteur a trois positions.

Déclarer uniquement l'état initial est la bonne quand le consentement est déjà géré par une extension dédiée : le module déclare tout refusé, et votre extension envoie la mise à jour en appelant

window.codingrowGtmdl.consent({
    ad_storage: 'granted',
    ad_user_data: 'granted',
    ad_personalization: 'granted',
    analytics_storage: 'granted'
});

Déclarer l'état initial et le mettre à jour laisse le module accorder le consentement depuis l'avis sur les cookies de Magento. Cette option exige le Cookie Restriction Mode de Magento activé (Stores → Configuration → General → Web → Default Cookie Settings) : désactivé, aucun client ne peut accepter et le consentement resterait refusé pour toujours. Une ligne sous les champs dit laquelle des deux se produit vraiment, et passe au rouge dans ce cas.

Comment vérifier que ça marche. Dans le panneau réseau du navigateur, les requêtes vers google-analytics.com/g/collect portent un paramètre gcs : il vaut G100 quand le consentement est refusé et G111 quand il est accordé. S'il change au moment où vous acceptez les cookies, le Consent Mode fonctionne.

Deux autres réglages : masquer les données publicitaires sans consentement (tant que le consentement publicitaire est refusé, Google n'envoie aucun identifiant dans ses appels publicitaires) et transmettre l'identifiant de clic dans l'URL (sans cookies, il voyage de page en page). Les deux sont recommandés.

Les quatorze événements

Un interrupteur par événement. Les quatre de base sont gratuits ; les dix autres demandent la clé des événements d'achat.

Événement	Quand	Niveau
`view_item`	page produit	gratuit
`view_cart`	panier	gratuit
`begin_checkout`	commande	gratuit
`purchase`	page de confirmation, depuis la vraie commande	gratuit
`view_item_list`	catégorie et résultats de recherche	achat
`select_item`	un clic sur un produit dans une liste	achat
`add_to_cart`	depuis la vraie ligne du panier	achat
`remove_from_cart`	depuis la vraie ligne du panier	achat
`search`	le terme et le nombre de résultats	achat
`add_to_wishlist`	le produit ajouté	achat
`add_shipping_info`	le mode de livraison enregistré	achat
`add_payment_info`	le mode de paiement enregistré	achat
`login`	connexion du client	achat
`sign_up`	inscription du client	achat

Deux autres réglages dans ce groupe : compter les commandes créées en administration (les commandes saisies à la main n'ont pas de visite derrière elles, et les compter faussse le coût par conversion) et seulement ces statuts de commande, qui limite l'achat aux statuts qui comptent vraiment comme une vente.

Les événements de livraison et de paiement ne dépendent pas du checkout : ils naissent dans Magento quand le mode est enregistré, et fonctionnent donc sur le checkout standard, sur Hyvä, sur Luma et sur ceux qui répondent sur leur propre route. Les quatre autres sont des événements de page : le module fournit un petit fichier de layout par route, et le support peut en ajouter un pour un checkout qui vit ailleurs.

Conteneur à importer

Tant que le conteneur n'a pas une balise qui lit le data layer, rien n'arrive à Analytics. Renseignez l'ID de mesure GA4 (le G-XXXXXXXXXX dans Analytics, sous Administration → Flux de données) et, si vous voulez aussi la conversion Google Ads, l'ID de conversion (les chiffres après AW-) et le libellé de votre action de conversion d'achat. Puis cliquez sur Télécharger le conteneur.

Le fichier contient la balise de configuration GA4, celle qui transmet les événements ecommerce, le conversion linker, les variables nécessaires et — quand les deux champs Google Ads sont remplis — la conversion d'achat avec le vrai chiffre d'affaires et le numéro de commande.

Dans Google Tag Manager : Administration → Importer un conteneur, choisissez le fichier, cochez Merge et Renommer les balises en conflit, regardez l'aperçu, publiez. Rien de ce que vous avez déjà n'est écrasé.

Achats perdus

Environ un achat sur cinq n'arrive jamais à Analytics : un bloqueur de publicités, un script en échec, un client qui ferme la page trop tôt. Avec ceci actif, la boutique envoie l'achat elle-même quand le navigateur ne l'a pas fait, en portant l'identifiant que ce client avait à ce moment.

Il faut l'ID de mesure GA4 du groupe ci-dessus et une clé API Measurement Protocol, que l'on crée dans Analytics sous Administration → Flux de données → votre flux → Secrets d'API du Measurement Protocol. Elle est enregistrée chiffrée. L'attente avant l'envoi est la marge laissée au navigateur du client : un quart d'heure suffit même avec une connexion lente.

Récupérer aussi les achats sans identifiant Analytics couvre les clients qui bloquent Analytics dès la première page : il n'y a rien à lire, donc l'achat ne peut être envoyé que comme une visite nouvelle et directe. Vous récupérez le chiffre d'affaires dans les rapports et vous perdez l'attribution de ces commandes : c'est pourquoi c'est désactivé au départ.

Sous les champs, un panneau compte les trente derniers jours : commandes enregistrées, celles confirmées par le navigateur, celles récupérées par la boutique, celles encore en attente. Un bouton demande à Google de vérifier le contenu d'un achat de test sans l'enregistrer.

Trois choses à savoir. Les commandes passées avant l'activation ne sont pas récupérées : l'enregistrement commence là. Une clé API erronée ne produit aucune erreur — Google accepte l'appel et jette l'événement — donc le module n'affirme jamais qu'un achat est arrivé : il note qu'il l'a envoyé, et la confirmation se lit dans Analytics, sous Temps réel. Et celui qui a refusé les cookies n'est jamais récupéré, même avec l'option ci-dessus : envoyer son achat depuis le serveur contournerait son refus.

Ce qui entre dans les articles

Champ	Ce qu'il fait
Les prix incluent la taxe	Doit correspondre à la base utilisée par vos rapports Google.
La valeur de l'achat inclut la livraison	Ne change que la valeur de l'achat.
Attribut produit utilisé comme item_id	Utilisez le même identifiant que votre flux produits, sinon Google n'associera pas les articles.
Attribut produit utilisé comme item_brand	N'importe quel attribut produit.
Ajouter les catégories du produit	Met la catégorie dans chaque article.
Nombre maximum d'articles dans view_item_list	Évite qu'une longue catégorie envoie un événement énorme.
Envoyer aussi les clés de remarketing classiques	Pour les conteneurs qui lisent encore les anciennes clés.
Adresses IP à ignorer	Séparées par des virgules. Depuis ces adresses, aucun événement ne part : le bureau, par exemple.
Dimensions personnalisées	Paires attribut produit / nom de paramètre GA4. Le paramètre voyage dans chaque article de chaque événement. Dans GA4, déclarez-le comme dimension personnalisée au niveau article, sinon il arrive mais n'apparaît pas dans les rapports.
Nom supplémentaire pour l'id unique de l'événement	Pour les conteneurs dont les déclencheurs lisent cet id sous un autre nom. La même valeur voyage sous les deux noms : le jour du basculement, vous ne touchez à rien dans le conteneur.

Problèmes courants

J'ai mis l'ID du conteneur mais je ne vois rien dans Google Tag Manager. Vérifiez que Enable est sur Yes dans le scope que vous regardez, que l'ID a la forme GTM-XXXXXXX, et en mode production que vous avez fait le compile, le static deploy et un vidage de cache. Dans l'aperçu de Google Tag Manager, on voit les événements arriver ; s'ils arrivent et que les rapports restent vides, le problème est dans les balises du conteneur.

Un événement ne part jamais. Dix des quatorze appartiennent aux événements d'achat : la clé va dans le groupe de la licence. Sans elle, la boutique continue d'envoyer les quatre de base.

Les événements du checkout arrivent tous ensemble sur la page de confirmation. Normal sur un checkout en une seule page : l'événement est enregistré dès que le client choisit, et livré au chargement de page suivant, qui est là la page de confirmation. Dans Analytics, ils restent dans la même visite et dans le bon ordre, avant l'achat.

Les chiffres ne correspondent pas à Analytics ou Google Ads. Vérifiez la base de taxe, si la livraison doit faire partie de la valeur de l'achat, et que l'attribut utilisé comme item_id est bien l'identifiant de votre flux produits.

L'achat est arrivé deux fois. Pas du module : recharger la page de confirmation ne répète pas l'événement. Cherchez une deuxième balise qui envoie le même achat, par exemple une ancienne conversion Google Ads encore configurée dans Magento sous Sales → Google API.