Audit tracking : formation et méthode complète 2026

Un audit tracking consiste à vérifier, dans l’ordre, que la donnée existe, qu’elle part, qu’elle a le droit de partir, qu’elle arrive complète, qu’elle survit aux navigateurs, et qu’elle correspond à la réalité de votre back-office. Huit vérifications suffisent, et la plupart se font depuis l’onglet Réseau de votre navigateur, sans aucun accès.

La majorité des audits tracking s’arrêtent à la première question : « est-ce que le tag se déclenche ? ». C’est la moins intéressante. Un tag peut se déclencher parfaitement et envoyer une donnée fausse, illégale, ou bloquée avant d’arriver. Cette méthode est celle que nous appliquons chez nos clients, dans l’ordre où nous l’appliquons. Elle est reproductible sur n’importe quel site.

La version vidéo, 27 minutes, dans laquelle Luc Ham-Chou-Chong, Web Analyst Senior chez Boryl, déroule cette méthode en direct sur un site e-commerce :

De quoi avons-nous besoin pour commencer un audit tracking ?

Les trois outils nécessiares

Nous n’aurons besoin d’aucun logiciel payant. Trois outils suffisent, et deux d’entre eux sont déjà installés sur votre ordinateur.

– L’onglet Réseau de Google Chrome. C’est le panneau qui affiche, en temps réel, toutes les requêtes que la page envoie vers l’extérieur. On l’ouvre par un clic droit n’importe où sur la page, puis Inspecter, puis en sélectionnant l’onglet Réseau, ou Network si votre navigateur est en anglais. C’est là que se déroulera environ 80 % de notre travail.

– La console JavaScript, qui se trouve dans le même panneau, sous l’onglet Console. Elle nous servira à lire la couche de données du site et à simuler des interactions sans cliquer.

– Un bloqueur de publicité, Ghostery ou uBlock Origin. Nous ne l’activerons qu’à l’étape 6, et il nous servira à mesurer ce que le site perd réellement.

Les accès GTM, GA4 et au CMS rendent l’audit plus complet, mais ils ne sont indispensables qu’à partir de l’étape 7. Tout le reste s’observe de l’extérieur.

Faut-il des accès pour auditer un tracking ?

Non, et c’est probablement la chose la plus utile à savoir avant de commencer.

Un audit complet nécessite en théorie les accès à Google Tag Manager, à Google Analytics 4 et au système de gestion de contenu du site. Dans les faits, nous allons très loin sans aucun de ces accès, simplement en lisant les requêtes qui partent du navigateur. Sur les huit étapes de cette formation, sept se font entièrement de l’extérieur.

Seule la huitième, la mesure de fiabilité, exige des accès : nous y comparerons la donnée collectée aux chiffres du back-office, et cette comparaison est impossible sans les deux.

1. Comment auditer la qualité de la couche de données ?

Qu’est-ce qu’une couche de données ?

La couche de données, que l’on appelle presque toujours par son nom anglais dataLayer, est un espace de stockage temporaire dans lequel un site web dépose des informations sur ses visiteurs et sur ce qu’ils font. Techniquement, il s’agit d’un objet JavaScript, plus précisément d’un tableau, qui vit dans le navigateur le temps de la visite.

Son rôle est celui d’un intermédiaire. Le site y dépose l’information « cet utilisateur vient d’ajouter le produit X au panier ». Google Tag Manager, ou tout autre gestionnaire de balises, vient l’y lire, puis décide quoi en faire et à qui l’envoyer.

Pourquoi passer par cet intermédiaire plutôt que d’envoyer directement l’information à Google Analytics 4 et à Meta ? Parce qu’il découple la production de la donnée de sa distribution. Le développeur du site pousse l’information une fois, sans savoir qui la consommera. L’équipe marketing branche ensuite autant de destinations qu’elle veut, sans redemander une ligne de code.

La couche de données n’est pas quelque chose dont tous les sites disposent par défaut. Elle doit être construite, et c’est précisément l’objet d’un plan de taggage. Un site peut parfaitement avoir Google Tag Manager installé sans avoir de couche de données digne de ce nom.

Si vous découvrez cette notion, notre formation Google Tag Manager la détaille en profondeur.

Comment lire la couche de données d’un site ?

C’est la manipulation la plus simple de toute cette formation, et elle nous apprend déjà beaucoup.

Ouvrez le site, puis les outils de développement, puis l’onglet Console. Tapez simplement :

« `js

dataLayer

« `

Appuyez sur Entrée. Le navigateur nous renvoie un tableau contenant tous les événements poussés depuis le chargement de la page. Chaque ligne se déplie et montre son contenu détaillé.

Si la console répond `Uncaught ReferenceError: dataLayer is not defined`, c’est qu’il n’y a pas de couche de données sur ce site, ou qu’elle porte un autre nom. Certains sites la nomment `digitalData`, `utag_data` ou autre chose. Dans ce cas, tapez `window` et cherchez un tableau qui ressemble à une liste d’événements.

Naviguez ensuite : allez sur une fiche produit, ajoutez au panier, et retapez `dataLayer` à chaque étape. Le tableau s’allonge au fil de vos actions, et nous voyons ainsi quels événements le site produit réellement.

Le test qui révèle qui pilote vraiment le tracking

Voici la manipulation la plus instructive de cette première étape. Elle prend trente secondes et répond à une question que personne ne pense à poser : est-ce que les balises écoutent la couche de données, ou est-ce qu’elles écoutent autre chose ?

Placez-vous sur une fiche produit. Dans la console, poussez vous-même l’événement d’ajout au panier, sans toucher au bouton :

« `js

dataLayer.push({ event: ‘add_to_cart’ });

« `

Passez immédiatement à l’onglet Réseau et regardez ce qui part.

– Si des requêtes partent vers Google Analytics 4, vers Meta, vers TikTok : ces balises sont pilotées par la couche de données, donc par Google Tag Manager. C’est l’architecture que nous voulons.

– Si rien ne part, et que ces requêtes n’apparaissent que lorsque vous cliquez réellement sur le bouton d’ajout au panier, alors quelque chose d’autre écoute les clics en parallèle de la couche de données.

Ce « quelque chose d’autre », c’est presque toujours une extension du système de gestion de contenu. Un module Shopify, un plugin WordPress, une extension Magento, qui installe le pixel de la plateforme et écoute directement les clics sur les boutons.

Nous avons rencontré exactement ce cas chez une marque française de cosmétique masculine, sous Magento. Google Analytics 4 répondait parfaitement au test : l’événement poussé à la main déclenchait bien la requête. Meta ne répondait pas du tout, et n’envoyait son événement qu’au clic réel. Deux outils, deux mécanismes indépendants, et personne dans l’équipe ne le savait.

Un second indice confirme le diagnostic : regardez le nombre de paramètres envoyés au pixel. Une extension de CMS en envoie souvent une quarantaine, bien au-delà de ce qu’une configuration manuelle produirait. Cette générosité est sa signature.

Pourquoi une extension de CMS finit par poser problème

Soyons justes : ces extensions sont une excellente solution pour démarrer. Elles s’installent en deux clics, elles sont fiables sur les événements standards, et elles permettent à une jeune marque d’avoir un tracking correct sans compétence technique.

Deux limites apparaissent ensuite, et toutes deux arrivent au moment où l’entreprise grandit.

La première est l’impossibilité de centraliser. Un tracking server-side propre exige que tout passe par Google Tag Manager. Des extensions qui envoient leurs données en parallèle, sans passer par lui, rendent cette centralisation impossible. Nous verrons à l’étape 2 pourquoi cela compte.

La seconde est l’impossibilité de personnaliser. L’extension décide à votre place de ce qui part. Vous ne pouvez ni ajouter un paramètre, ni conditionner l’envoi, ni distinguer deux types d’achat. Nous verrons à l’étape 4 pourquoi cette limite coûte cher en publicité.

Que devons-nous vérifier dans un événement e-commerce ?

Une fois que nous savons qui pilote le tracking, nous regardons la qualité de ce qui est poussé. Dépliez un événement `add_to_cart` ou `purchase` dans la console, et passons en revue cinq points.

Le nommage

Les noms d’événements et de paramètres doivent être identiques partout, et correspondre au plan de taggage. Un site qui pousse `add_to_cart` sur les fiches produit et `addToCart` depuis le panier produit deux événements distincts aux yeux de Google Analytics 4. Les rapports séparent ce qui devrait être additionné.

Vérifiez également la casse et les accents. `Ajout_Panier` et `ajout_panier` sont deux événements différents.

La complétude

Sur un événement e-commerce, certains paramètres ne sont pas optionnels. Vérifiez la présence de :

– `currency`, la devise, sans laquelle Google Analytics 4 ne peut pas calculer de chiffre d’affaires

– `value`, le montant total

– et dans le tableau `items`, pour chaque produit : `item_id`, `item_name`, `price` et `quantity`

L’`item_id` mérite une attention particulière. C’est lui qui permet de relier l’événement à votre catalogue produit dans Meta ou dans Google Ads. Un `item_id` absent, ou qui ne correspond pas aux identifiants du flux catalogue, rend le remarketing dynamique inopérant. Les publicités montreront des produits au hasard, ou n’en montreront aucun.

Les valeurs vides

Regardez les valeurs, pas seulement les clés. Un paramètre `price` qui vaut `undefined`, `null`, `0` ou une chaîne vide est pire qu’un paramètre absent : il se propage silencieusement jusqu’aux rapports, où il produit des moyennes fausses que personne ne remarque.

Ce défaut apparaît souvent sur un seul type de produit : les articles en promotion, les produits vendus par abonnement, les coffrets. Testez donc plusieurs produits différents, pas seulement le premier de la liste.

Les doublons

Comptez les occurrences d’un même événement dans le tableau `dataLayer`. Un `purchase` poussé deux fois, une fois par le thème du site et une fois par une extension, double le chiffre d’affaires dans vos rapports.

Ce cas est fréquent après une migration, quand l’ancienne implémentation n’a pas été retirée.

Les données sensibles

La couche de données est lisible par n’importe quel visiteur, en trois secondes, avec la manipulation que nous avons vue plus haut. Rien de confidentiel n’a sa place dedans.

Cherchez donc les adresses email en clair, les numéros de téléphone, les identifiants clients, et surtout les données commerciales sensibles comme la marge produit.

Comment faire, alors, si nous avons besoin de la marge pour piloter nos campagnes ? Nous poussons dans la couche de données une simple clé de réconciliation, un identifiant de commande par exemple, et nous allons chercher la marge côté serveur au moment de l’envoi. Nous verrons le mécanisme à l’étape 2.

Le cas particulier de Shopify

Shopify impose une contrainte que les autres plateformes n’ont pas, et elle change complètement cette première étape.

Depuis l’obligation du checkout extensibility en 2024, le tunnel de commande est un environnement isolé. Les fichiers de thème `.liquid` n’y sont plus éditables, et la couche de données classique n’y existe plus. Le seul moyen d’y collecter quoi que ce soit est le custom pixel, un bac à sable dédié alimenté par l’API de Shopify.

Conséquence directe pour notre audit : toutes les vérifications que nous venons de faire ne disent rien de ce qui se passe dans le checkout. Il faut les refaire entièrement à l’intérieur du tunnel, séparément, et souvent le constat y est très différent.

2. Comment savoir si un site fait vraiment du tracking server-side ?

Qu’est-ce que le tracking server-side ?

Le tracking server-side, ou tracking côté serveur, est une façon de collecter les données dans laquelle les événements ne partent plus directement du navigateur vers Google, Meta ou Klaviyo, mais transitent d’abord par un serveur que l’entreprise contrôle.

Imaginons un bureau de poste. Dans un tracking classique, chaque visiteur envoie lui-même ses lettres à une dizaine de destinataires différents, et chaque enveloppe porte visiblement le nom du destinataire. En tracking server-side, le visiteur remet une seule enveloppe à un bureau de poste qui lui appartient, et c’est ce bureau qui se charge de la redistribution.

Ce détour apporte trois choses : les identifiants vivent plus longtemps, les envois résistent mieux aux bloqueurs, et l’entreprise décide de ce qui part vers qui.

Quel est le seul critère qui permet de trancher ?

Il n’y en a qu’un, et il est binaire : le conteneur de balises est-il servi depuis un domaine qui appartient au site ?

Rien d’autre ne tranche. Ni le nom d’un fournisseur trouvé dans le code, ni la présence d’un cookie longue durée, ni un sous-domaine au nom évocateur.

Voici la manipulation. Dans l’onglet Réseau, tapez `gtm.js` dans le champ de filtre, puis rechargez la page. Regardez le domaine qui sert le fichier.

– `googletagmanager.com/gtm.js` : le conteneur vient de chez Google. Il n’y a pas de tracking server-side, quoi qu’en dise le prestataire.

– `metrics.lesite.fr/a1b2c3.js` : le conteneur est servi depuis un domaine du site. Un serveur de collecte existe.

Refaites la même chose en filtrant sur `gtag/js`, qui charge la librairie de Google Analytics 4.

Quels sont les deux pièges à éviter ?

Premier piège : le nom d’un fournisseur ne prouve rien. Trouver « Stape », « Addingwell » ou « Elevar » dans le code source d’une page ne signifie pas qu’un conteneur serveur tourne. Ces outils se vendent aussi en simple couche de données côté client. Nous avons vu des audits conclure à un server-side sur cette seule base, à tort.

Second piège : un cookie de longue durée ne prouve rien non plus. Un cookie de treize mois peut parfaitement avoir été écrit en JavaScript. Nous allons voir pourquoi juste après.

Que trouve-t-on le plus souvent ? Un server-side à moitié fait

Chez la marque de cosmétique dont nous parlions plus haut, nous avons trouvé un chemin first-party servant les ressources du gestionnaire de balises depuis le domaine principal. Les traces d’un Google Tag Gateway.

Mais en regardant mieux, deux anomalies apparaissaient.

Le conteneur se chargeait deux fois en parallèle. Une fois par ce chemin first-party, et une fois par `googletagmanager.com`. Cette seconde instance était bloquée par tous les bloqueurs, ce qui annulait en partie le bénéfice de la première.

Et les requêtes de Google Analytics 4 partaient toujours directement vers `analytics.google.com`. La proxyfication avait été commencée sur le chargement du conteneur, jamais finie sur l’envoi des données.

Cet état intermédiaire est très fréquent. Si vous découvrez un conteneur servi en first-party, ne concluez donc pas trop vite. Mesurez ce qui passe réellement par lui.

Comment mesurer ce qui passe vraiment par le serveur ?

Restez dans l’onglet Réseau, videz le filtre, et parcourez le site normalement. Nous allons chercher les destinations appelées directement par le navigateur.

Filtrez successivement sur :

– `facebook.com/tr` pour Meta

– `googleads.g.doubleclick.net` pour Google Ads

– `analytics.tiktok.com` pour TikTok

– `a.klaviyo.com` pour Klaviyo

– `google-analytics.com` pour Google Analytics 4

Chaque destination trouvée est un flux qui ne passe pas par le serveur. Comptez-les, et comparez au nombre total d’outils présents sur le site.

Un conteneur serveur qui ne route qu’un tiers des flux fait payer une infrastructure complète pour un tiers du bénéfice. Ce n’est pas un défaut de configuration ponctuel, c’est un projet qui s’est arrêté au milieu. Si vous hésitez sur le niveau réel de votre installation, c’est le premier point que nous regardons dans un audit de collecte.

Qu’est-ce qu’un cookie serveur, et comment le distinguer d’un cookie JavaScript ?

Un cookie serveur, ou cookie posé par en-tête HTTP, est un cookie que le serveur demande au navigateur d’enregistrer, en l’écrivant lui-même dans sa réponse. Il s’oppose au cookie JavaScript, que le code de la page crée une fois celle-ci chargée. Les deux produisent un cookie identique en apparence, portant le même nom et la même valeur, mais les navigateurs ne les traitent pas du tout de la même façon.

Pourquoi cette distinction nous intéresse-t-elle dans un audit ? Parce que Safari plafonne à 7 jours tout cookie écrit en JavaScript, y compris quand ce cookie appartient au site que nous visitons. Le même cookie, écrit par le serveur, peut vivre treize mois.

Et c’est le point que la plupart des équipes découvrent trop tard : installer un conteneur serveur ne suffit pas à obtenir un cookie serveur. Un conteneur peut très bien faire transiter les requêtes par votre domaine tout en laissant le cookie être écrit en JavaScript, exactement comme avant. Le tuyau change, la durée de vie ne change pas.

Nous allons donc vérifier deux choses : qui écrit le cookie, puis combien de temps il vit.

Première vérification : qui écrit le cookie ?

L’onglet Application ne nous le dira pas. Il affiche la date d’expiration et la valeur, mais pas l’auteur. C’est une erreur fréquente, et elle conduit à croire qu’un cookie de longue durée prouve un cookie serveur.

Nous passons donc par l’onglet Réseau. Cliquez sur une requête, ouvrez la section En-têtes de réponse, et cherchez une ligne `Set-Cookie` contenant `_ga`. Parcourez ainsi les premières requêtes de la page.

– Si nous trouvons cette ligne, le serveur écrit le cookie.

– Si nous ne la trouvons nulle part, le cookie est écrit en JavaScript.

Seconde vérification : combien de temps vit-il ?

Cette fois nous ouvrons l’onglet Application, puis Cookies dans la colonne de gauche, et nous sélectionnons le domaine du site. La colonne Expires donne la date de péremption du cookie `_ga`. Comparons-la à la date du jour.

Que pouvons-nous conclure ?

– Ligne `Set-Cookie` présente et expiration à plus d’un an : le serveur pose l’identifiant. C’est la configuration que nous cherchons, et elle tiendra face à Safari.

– Aucune ligne `Set-Cookie`, expiration à treize mois sur Chrome : le cookie est écrit en JavaScript. Chrome l’accepte tel quel, mais le même visiteur sur Safari verra son cookie réduit à 7 jours. Le chiffre affiché dans Chrome nous rassure à tort.

– Aucune ligne `Set-Cookie`, expiration à 7 jours : nous sommes sur Safari, et nous observons le plafond en action.

Ce que le deuxième cas coûte, concrètement

Prenons un visiteur qui arrive sur le site par une publicité Instagram. Il regarde, il ne commande pas, il repart. Dix jours plus tard, il revient directement et passe commande.

Sur Chrome, tout se passe bien : son cookie est toujours là, Google Analytics 4 le reconnaît, et la conversion est attribuée à la campagne Instagram qui l’avait fait venir.

Sur Safari, son cookie a expiré au septième jour. Google Analytics 4 ne le reconnaît plus. Il devient un nouvel utilisateur, sa session est classée en trafic direct, et la campagne Instagram ne reçoit rien.

Remarquons bien ce qui se passe ici, parce que c’est ce qui rend le problème difficile à repérer : nous ne perdons pas la conversion, nous la rangeons au mauvais endroit. Le chiffre d’affaires total reste juste. C’est sa répartition par canal qui devient fausse, et elle devient fausse toujours dans le même sens, au détriment des campagnes payantes et au profit du trafic direct.

Sur un site dont le cycle d’achat dépasse une semaine, c’est le défaut qui fausse le plus les arbitrages budgétaires. Une campagne qui fonctionne est coupée parce qu’elle semble ne rien rapporter.

Le mécanisme complet, ainsi que la règle d’adresse IP que Safari applique depuis avril 2023, sont détaillés dans notre page sur le tracking server-side.

3. Comment auditer la gestion du consentement ?

C’est l’étape où un audit trouve des problèmes de conformité, et pas seulement des problèmes de qualité de données. Elle mérite d’autant plus d’attention que ses défauts sont invisibles depuis les interfaces : rien dans Google Analytics 4 ne signale qu’un consentement est mal transmis.

Pourquoi la bannière compte autant que le code

Avant même de regarder une requête, observons la bannière de consentement, telle qu’un visiteur la découvre.

Trois questions se posent.

– Bloque-t-elle la navigation tant qu’un choix n’a pas été fait, ou peut-on l’ignorer et continuer ?

– Les deux boutons ont-ils un poids visuel comparable ? Un bouton « Tout accepter » en couleur vive face à un lien « Continuer sans accepter » en gris clair oriente le choix.

– Le refus est-il accessible au premier niveau, ou faut-il ouvrir un panneau de paramètres pour le trouver ?

Ces questions ne sont pas que réglementaires. Plus le taux de consentement est élevé, plus le volume de données collectées est important, et plus les rapports sont fiables. Une bannière bloquante, avec un bouton accepter bien visible et un refus accessible, est un bon point de départ.

Qu’est-ce que le Consent Mode ?

Le Consent Mode, ou mode de consentement, est le mécanisme par lequel un site informe Google de ce que le visiteur a accepté. Ce n’est ni une bannière, ni un outil : c’est un signal, transmis avec chaque requête.

Dans sa version 2, obligatoire pour les annonceurs européens depuis mars 2024, il transporte quatre autorisations distinctes :

– `analytics_storage`, pour la mesure d’audience

– `ad_storage`, pour la publicité

– `ad_user_data`, pour l’envoi de données utilisateur aux plateformes publicitaires

– `ad_personalization`, pour la personnalisation des annonces

Les deux dernières sont celles que la version 2 a ajoutées, et ce sont celles que les configurations anciennes oublient.

Un point est souvent mal compris, alors prenons le temps. Quand un visiteur refuse, les requêtes partent quand même vers Google, mais sans aucun identifiant. Elles ne permettent pas de suivre cette personne. Elles permettent en revanche à Google de modéliser statistiquement les conversions manquantes. Voir des requêtes partir après un refus n’est donc pas, en soi, un problème de conformité. Ce qui en serait un, c’est qu’elles emportent des identifiants.

Comment vérifier le Consent Mode de Google ?

Nous allons lire le paramètre `gcs`, qui résume l’état du consentement en cinq caractères.

Dans l’onglet Réseau, filtrez sur `G-`, qui est le préfixe des identifiants de mesure de Google Analytics 4. Cliquez sur une requête, puis ouvrez l’onglet Charge utile, ou Payload. Cherchez `gcs`.

Deux valeurs nous intéressent :

– `G100` : le stockage analytics et publicitaire est refusé, ou pas encore accordé

– `G111` : les deux sont accordés

Voici le test complet, en trois temps.

1. Chargez la page sans répondre à la bannière. Le paramètre doit valoir `G100`.

2. Acceptez. Le paramètre doit passer à `G111` sur les requêtes suivantes, sans que vous ayez rechargé la page.

3. Refusez dans une nouvelle session de navigation privée. Il doit rester à `G100`.

Si le paramètre reste figé quelle que soit votre action sur la bannière, c’est que le Consent Mode n’est pas relié à votre plateforme de gestion du consentement. Si le paramètre est absent, c’est qu’il n’est pas implémenté du tout.

Comment vérifier le Consent Mode de Microsoft ?

Microsoft Advertising, anciennement Bing Ads, possède son propre mécanisme, et c’est celui que nous trouvons le plus souvent en défaut.

La manipulation est la même, avec deux différences : filtrez sur `bing` au lieu de `G-`, et cherchez le paramètre `asc` au lieu de `gcs`. Ses valeurs sont explicites, `denied` ou `granted`.

Chez la marque de cosmétique que nous auditions, les requêtes partaient bien avec `asc=denied` lorsque le visiteur refusait. Correct. Mais après acceptation, le statut ne se mettait jamais à jour. Microsoft continuait de recevoir des signaux en mode refusé, indéfiniment.

Deux conséquences, et elles ne sont pas de même nature.

– Une non-conformité, puisque le consentement accordé n’est pas transmis à un partenaire qui le réclame.

– Des campagnes faussées, puisque les conversions obtenues après acceptation ne remontent pas correctement. Les rapports sous-estiment les performances, et l’algorithme apprend sur des données incomplètes.

Ce défaut est classique chez les équipes qui ont soigné le Consent Mode de Google et n’ont pas pensé qu’il en existait un équivalent chez Microsoft.

La vérification que presque personne ne fait : refuser, puis regarder

Nous arrivons au contrôle le plus important de cette étape, et c’est aussi le plus rare.

Ouvrez une fenêtre de navigation privée, chargez le site, et refusez tout. Naviguez ensuite normalement : fiche produit, ajout au panier. Puis filtrez l’onglet Réseau sur `facebook`, `tiktok`, `doubleclick`, `klaviyo`, `snapchat`.

Ce que nous cherchons n’est pas l’absence totale de requêtes. Ce sont des requêtes qui emportent des identifiants malgré le refus. Ouvrez-les et cherchez des paramètres contenant un identifiant de cookie, une adresse email hachée, un identifiant publicitaire.

Si vous en trouvez, vous n’avez pas un problème de mesure. Vous avez un problème réglementaire, et il passe avant tout le reste de l’audit.

Le cas Shopify : la Customer Privacy API

Sur Shopify, une vérification supplémentaire s’impose, et son oubli est systématique.

Depuis le checkout extensibility, le consentement doit être transmis à la Customer Privacy API de Shopify. C’est elle qui autorise ou non les applications natives, celles du App Store, à recevoir des données.

Le problème est simple : si une plateforme de consentement est installée sans que cette transmission soit configurée, elle ne l’est probablement pas. Les applications natives continuent alors de collecter, quel que soit le choix du visiteur, et la bannière ne sert à rien pour elles.

Vérifiez-le dans la console en tapant :

« `js

window.Shopify.customerPrivacy.currentVisitorConsent()

« `

Le retour doit refléter le choix que vous venez de faire sur la bannière.

4. Comment auditer la collecte e-commerce de bout en bout ?

Parcourir le tunnel complet

Il n’y a pas de raccourci : il faut faire un achat réel, ou une commande test si le site en permet.

Relevez chaque événement au passage, et vérifiez qu’aucun ne manque :

– `view_item_list`, l’affichage d’une liste de produits

– `view_item`, l’ouverture d’une fiche produit

– `add_to_cart`, l’ajout au panier

– `view_cart`, l’affichage du panier

– `begin_checkout`, l’entrée dans le tunnel

– `add_payment_info`, la saisie du moyen de paiement

– `purchase`, la commande validée

Un maillon manquant casse l’entonnoir entier dans les rapports. Si `begin_checkout` n’est jamais envoyé, il devient impossible de savoir si les abandons ont lieu au panier ou au paiement, et donc impossible de savoir quoi corriger.

Le transaction_id, le paramètre qui évite de compter deux fois

Le `transaction_id` est l’identifiant unique d’une commande. Son rôle est de permettre à Google Analytics 4 de reconnaître qu’une même commande lui est envoyée deux fois, et de n’en compter qu’une.

Quand cela arrive-t-il ? Plus souvent qu’on ne le croit. Un client qui recharge la page de confirmation, qui revient en arrière dans son navigateur, ou qui ouvre la page dans un second onglet, déclenche un second `purchase`.

Deux vérifications :

– Le paramètre est-il présent dans l’événement `purchase` ?

– Est-il stable ? Rechargez la page de confirmation et vérifiez qu’il ne change pas. Un identifiant régénéré à chaque chargement ne dédoublonne rien.

Sans lui, le chiffre d’affaires de vos rapports est surévalué, et personne ne sait de combien.

Les identifiants de clic, le défaut silencieux du checkout Shopify

Voici un cas qui mérite qu’on s’y arrête, parce qu’il casse l’attribution sans casser les chiffres.

Sur un site classique, les cookies déposés sur votre domaine sont automatiquement attachés aux requêtes sortantes. L’identifiant de clic de Google, le `gclid`, et celui de Meta, le `fbclid`, partent avec l’événement sans que personne ait à y penser.

Dans le checkout de Shopify, ce n’est plus vrai. Les cookies sont toujours déposés, ils restent lisibles, mais ils ne sont plus joints automatiquement aux requêtes.

Le résultat est le suivant : vous collectez bien l’achat, vous l’envoyez bien à Google Ads, et il arrive sans identifiant de clic. La conversion existe, elle est comptée, elle n’est rattachée à aucune campagne.

Remarquez la difficulté : le volume total de conversions reste correct. C’est la répartition par canal qui devient fausse. Le trafic payant semble ne rien rapporter, et le trafic direct semble extraordinaire.

La correction consiste à lire la valeur du cookie côté client, puis à la transmettre explicitement comme un paramètre d’événement, exactement comme on transmet un identifiant de transaction.

Le statut du client, la donnée la plus rentable et la plus rare

Terminons cette étape par la vérification qui rapporte le plus, et que presque aucun site ne passe.

Posons le raisonnement. Pour une marque dont les produits se rachètent régulièrement, crème, café, croquettes, compléments, le budget publicitaire sert à acquérir de nouveaux clients. Les rachats, eux, s’obtiennent par l’email et le SMS, à un coût très inférieur.

Pour que cette stratégie fonctionne, les plateformes publicitaires ont besoin de savoir qu’un achat donné est un premier achat. Sans cette information, l’algorithme optimise sur l’ensemble des conversions, rachats compris, et va donc chercher en priorité des gens qui auraient acheté de toute façon. Le coût d’acquisition affiché est excellent, et la croissance ne vient pas.

Vérifiez donc si l’événement `purchase` porte un paramètre distinguant nouveau client et client existant.

Cette information n’est accessible que depuis le gestionnaire de balises. Une extension de CMS ne peut pas la produire : au moment où elle déclenche son pixel, elle n’a pas accès à l’historique d’achat du client. C’est la raison la plus concrète, et la plus chiffrable, de centraliser le tracking sur Google Tag Manager plutôt que d’empiler des extensions.

5. Comment vérifier les API de conversion et la déduplication ?

Qu’est-ce qu’une API de conversion ?

Une API de conversion est un canal par lequel un serveur envoie directement les conversions à une plateforme publicitaire, sans passer par le navigateur du visiteur. Meta l’appelle Conversions API, ou CAPI. TikTok l’appelle Events API. Pinterest et Snapchat ont les leurs.

L’intérêt est évident dès qu’on a compris le problème des bloqueurs : une requête qui part d’un serveur vers un autre serveur ne peut être bloquée par aucune extension de navigateur.

Pourquoi deux appels valent mieux qu’un

Voici le point le plus souvent mal interprété dans les audits, y compris par des équipes techniques.

Le déploiement recommandé par Meta, TikTok et Pinterest n’est pas de couper l’envoi navigateur au profit de l’envoi serveur. C’est d’envoyer les deux.

– L’événement part du navigateur, comme avant. Il sera peut-être bloqué.

– Le même événement part du serveur vers l’API de conversion. Celui-là arrivera.

– Les deux portent un identifiant de déduplication identique, qui permet à la plateforme de comprendre qu’il s’agit du même achat et de ne le compter qu’une fois.

Autrement dit, voir deux appels vers Meta pour un même achat n’est pas un bug. C’est la configuration correcte. Conclure l’inverse est l’erreur d’audit la plus fréquente que nous rencontrions.

Comment vérifier la déduplication ?

Il faut ouvrir la requête et chercher le paramètre d’identifiant, dont le nom change selon la plateforme :

– Meta : `eid`

– TikTok : `event_id`

– Pinterest : `event_id`

– Snapchat : `client_dedup_id`

Ce que nous cherchons vraiment, c’est un appel direct qui ne porte aucun identifiant de déduplication. Celui-là pose un vrai problème : soit il crée un doublon si le serveur envoie aussi de son côté, soit il est simplement bloqué et la conversion est perdue.

Une API de conversion ne signifie pas un tracking server-side

Terminons par un contresens à éviter, qui fausse beaucoup de diagnostics.

Une plateforme peut recevoir des conversions par API sans qu’aucun conteneur serveur n’existe. Sur Shopify, l’application native de Meta envoie les achats de serveur à serveur, directement depuis l’infrastructure de Shopify.

C’est plus simple à mettre en place, et c’est mieux que rien. Mais vous ne maîtrisez ni le contenu des événements, ni les autres destinations, ni la façon dont le consentement est respecté. Trouver une API de conversion active ne doit donc pas vous faire conclure à une architecture server-side.

6. Comment tester la résilience face aux bloqueurs et à Safari ?

Le test du bloqueur, en deux minutes

Activez Ghostery ou uBlock Origin, rechargez la page, et regardez simplement ce qui survit dans l’onglet Réseau.

Chez la marque que nous auditions, le résultat a été immédiat et sans appel : Google Analytics 4, Meta, TikTok, Snapchat et Klaviyo, plus aucune donnée ne partait.

Combien cela coûte-t-il réellement ?

En France, les mesures situent l’usage des bloqueurs entre 25 % sur ordinateur et 36 % tous appareils confondus selon les enquêtes déclaratives. Retenons l’estimation la plus basse : un visiteur sur quatre disparaît des rapports.

Ce chiffre reste abstrait tant qu’on ne le traduit pas en décision. Faisons-le.

Une campagne publicitaire a besoin d’un certain volume de conversions avant qu’on puisse trancher entre la couper et augmenter son budget. Disons cinquante conversions. Si un quart des conversions n’est jamais remonté, il faut un tiers de temps en plus pour atteindre ce volume : trente jours deviennent quarante.

Un concurrent dont la mesure est complète décide donc dix jours plus tôt, chaque mois. Sur un an, il a pris ses décisions quatre mois avant vous.

Pourquoi servir depuis son domaine ne suffit pas

Une idée reçue tenace veut qu’il suffise de faire passer la collecte par son propre domaine pour échapper aux bloqueurs. C’est faux, et voici pourquoi.

Les listes de filtrage ne bloquent pas seulement des domaines. Elles bloquent aussi des chemins, sans aucune condition d’origine.

Nous avons vérifié EasyPrivacy, la liste utilisée par la quasi-totalité des bloqueurs, le 24 septembre 2026, dans sa version 202609241335. Les règles suivantes y figurent sans préfixe de domaine :

– `/gtm.js`

– `/gtag.js`

– `/gtag/js?`

– `GTM-`

Une règle écrite ainsi s’applique à toutes les origines, y compris la vôtre. Servir votre conteneur depuis `votresite.fr/gtm.js` ne le protège donc absolument pas : le chemin reste reconnaissable, et le script est bloqué avant même la première requête de collecte.

C’est exactement la différence entre un Google Tag Gateway et un tracking server-side complet.

Quels sont les quatre éléments à proxyfier ?

Proxyfier signifie servir une ressource depuis une URL qui ne ressemble à rien de connu. Quatre éléments doivent l’être, et oublier le dernier annule souvent les trois premiers.

– Le conteneur de balises, dont le chemin `gtm.js` est filtré

– La librairie gtag, si un transporteur Google Analytics 4 est utilisé, ce qui est le cas presque partout

– Le point de collecte, dont le chemin `/g/collect` est reconnaissable

– La plateforme de gestion du consentement elle-même

Ce dernier point mérite une explication, car il est rarement traité. Les bloqueurs les plus avancés identifient les bannières de consentement et les masquent. Le visiteur ne voit jamais la bannière, il ne peut donc jamais accepter, et aucune donnée ne part, quelle que soit la qualité de votre serveur de collecte. Une infrastructure parfaite peut ainsi être neutralisée par une bannière bloquée.

Le test Safari

Nous avons vu à l’étape 2 comment lire la durée de vie d’un cookie. Voici pourquoi ce test est le plus révélateur de tous.

Safari applique depuis plusieurs années un dispositif nommé Intelligent Tracking Prevention, ou ITP. Il plafonne à 7 jours tout cookie écrit en JavaScript, et descend à 24 heures lorsque l’URL d’arrivée contient des paramètres de campagne, ce qui est le cas de tout clic publicitaire.

Reprenons notre visiteur venu par Instagram. Sur Safari, s’il revient huit jours plus tard, son cookie a disparu, et la plateforme ne peut pas relier son achat à la publicité qui l’a fait venir.

Pour dépasser cette limite, le cookie doit être posé par le serveur, via l’en-tête `Set-Cookie`. S’y ajoute une condition que peu d’équipes connaissent : depuis avril 2023, les deux premiers octets de l’adresse IP du serveur de collecte doivent correspondre à ceux du serveur qui sert le site. Sans cela, Safari replafonne le cookie à 7 jours malgré l’en-tête.

Concrètement, un conteneur hébergé sur une adresse Google Cloud alors que le site est chez un hébergeur français ne passe pas cette règle.

7. Comment mesurer la fiabilité de la collecte ?

Pourquoi vérifier la présence ne suffit pas

Toutes les étapes précédentes répondent à une question : est-ce que ça part ? Celle-ci répond à une question différente, et c’est elle qui transforme une liste de contrôles en audit : est-ce que ce qui arrive correspond à la réalité ?

Un tracking peut passer les six premières étapes sans faute et perdre 20 % des commandes, pour une raison qu’aucune d’elles ne révèle : un événement qui ne se déclenche pas sur un moyen de paiement particulier, une page de confirmation qui n’existe pas sur mobile, un produit dont le prix ne remonte jamais.

C’est ici que les accès deviennent indispensables. Il nous faut l’outil analytics d’un côté, le back-office de l’autre.

Les trois comparaisons à faire

Prenez un mois civil complet, et comparez trois couples de chiffres.

– Le chiffre d’affaires. Celui que votre outil analytics affiche, contre celui du back-office. C’est la comparaison reine, celle qui résume toutes les autres.

– Le volume d’achats reçu par les plateformes. Le nombre d’événements `purchase` reçus par l’API de conversion de Meta, contre le nombre de commandes réelles.

– Les soumissions de formulaires. Les événements collectés, contre les entrées réellement créées dans votre CRM.

Quel écart devons-nous accepter ?

Atteindre 100 % est impossible, et se faire promettre le contraire est un signal d’alerte. Il y aura toujours des commandes passées par téléphone, des remboursements traités différemment, des visiteurs qui bloquent tout.

Sur les configurations e-commerce que nous déployons, nous mesurons en moyenne :

– 93 % de fiabilité sur le chiffre d’affaires

– 95 % sur les achats envoyés à l’API de conversion de Meta

– 97 % sur les soumissions de formulaires

Comment lire ces chiffres ? En dessous de 85 %, il y a un défaut structurel à chercher, et les six étapes précédentes vous diront lequel. Entre 85 et 93 %, la collecte est exploitable mais perfectible. Au-dessus de 95 %, vous êtes dans le haut du panier.

Faites cette mesure à la fin de chaque chantier de tracking, et notez-la. C’est le seul indicateur qui permette de dire si une intervention a servi à quelque chose, et il se suit dans le temps.

8. Comment rédiger le livrable d’un audit ?

Pourquoi la priorisation compte plus que l’exhaustivité

Un audit qui liste trente constats sans les hiérarchiser n’est pas actionnable. Le lecteur ne sait pas par où commencer, et il ne commence pas.

Nous classons systématiquement en trois niveaux, et l’ordre n’est pas négociable.

Niveau 1, la conformité. Consentement non respecté, identifiants envoyés malgré un refus, Consent Mode figé, signal Microsoft bloqué. Ces constats passent avant tout le reste, **quel que soit leur effet sur les chiffres**. Un risque réglementaire ne se met pas en concurrence avec un gain de performance.

Niveau 2, la perte de données. Bloqueurs, cookies plafonnés, flux non routés, identifiants de clic manquants, événements absents du tunnel. Chiffrez chaque perte : « un visiteur sur quatre », « les conversions Microsoft après acceptation », « 12 % d’écart avec le back-office ». C’est le chiffre qui déclenche la décision, pas le constat.

Niveau 3, la finesse. Statut du client, événements personnalisés, enrichissement par les données du CRM. Ce sont des gains de performance, pas des corrections. Ils arrivent après.

Le tableau récapitulatif

Une page suffit. Une ligne par point audité, son statut, sa recommandation. Voici la forme que nous utilisons.

Point audité	Statut	Recommandation
Bannière de consentement	Favorable	Rien à faire
Consent Mode Google	Conforme	Rien à faire
Consent Mode Microsoft	Non conforme	Reconfigurer le signal accordé
Tracking server-side	Incomplet	Finir la proxyfication ou passer à une infrastructure complète
Pixels Meta et TikTok	Gérés par extensions	Centraliser sur Google Tag Manager
Identifiants de clic au checkout	Absents	Lire les cookies et les transmettre en paramètres
Statut nouveau client	Absent	Configurer depuis Google Tag Manager
Fiabilité du chiffre d’affaires	87 %	Chercher les commandes manquantes par moyen de paiement

Ce qu’il faut retenir

– Sept des huit étapes se font sans aucun accès, depuis l’onglet Réseau du navigateur. Les accès ne deviennent indispensables qu’à l’étape de fiabilité.

– Le test décisif de la couche de données tient en une ligne de console : poussez l’événement à la main et regardez si les balises répondent.

– Un seul critère tranche sur le server-side, le conteneur est servi depuis un domaine du site ou il ne l’est pas. Tout le reste est un indice.

– Installer un conteneur serveur ne donne pas automatiquement un cookie serveur, et c’est le cookie qui décide de la durée de vie des identifiants.

– Refuser le consentement puis regarder ce qui part quand même est la vérification la plus rare et la plus importante.

– Un audit se termine par un taux de fiabilité comparé au back-office, pas par une liste de cases cochées. C’est ce que couvre notre audit de collecte GA4, Google Ads et Meta.

FAQ

Peut-on auditer le tracking d’un site sans accès à Google Tag Manager ni Google Analytics 4 ?

Oui, et c’est même la première étape de nos audits. L’onglet Réseau du navigateur montre les requêtes qui partent, leur destination, leur charge utile et le statut de consentement transmis. Sept des huit étapes de cette méthode se font sans aucun accès. Seule la mesure de fiabilité, qui compare la donnée collectée aux chiffres du back-office, exige des accès aux outils.

Comment vérifier que le Consent Mode est bien implémenté ?

Filtrez les requêtes réseau sur le préfixe de votre identifiant de mesure Google Analytics 4, puis ouvrez l’onglet Charge utile d’une requête. Le paramètre `gcs` doit valoir `G100` avant tout choix, et passer à `G111` après acceptation, sans que vous ayez rechargé la page. S’il reste figé quelle que soit votre action sur la bannière, le Consent Mode n’est pas relié à votre plateforme de consentement.

Que signifie gcs=G111 dans une requête Google Analytics 4 ?

Le paramètre `gcs` transmet l’état du consentement à Google. `G100` signifie que le stockage analytics et publicitaire est refusé ou pas encore accordé, `G111` que les deux sont accordés. Les requêtes en `G100` ne sont pas inutiles : elles ne contiennent aucun identifiant, mais elles permettent à Google de modéliser les conversions manquantes dans vos rapports et vos campagnes.

Comment savoir si un site utilise vraiment du tracking server-side ?

Filtrez les requêtes sur `gtm.js` ou `gtag/js`, puis regardez le domaine qui sert le fichier. S’il vient de `googletagmanager.com`, il n’y a pas de conteneur serveur, quoi qu’en dise le prestataire. S’il vient d’un domaine du site, un conteneur existe. Le nom d’un fournisseur trouvé dans le code source ne prouve rien, ces outils se vendent aussi en simple couche de données côté client.

Le Consent Mode existe-t-il aussi pour Microsoft Advertising ?

Oui, et c’est le point le plus souvent oublié. Microsoft utilise le paramètre `asc`, que l’on vérifie en filtrant les requêtes sur `bing`. Il doit valoir `denied` en cas de refus et basculer sur `granted` après acceptation. Nous rencontrons régulièrement des sites où le signal reste bloqué sur `denied` après acceptation, ce qui crée à la fois une non-conformité et des conversions Microsoft manquantes.

Comment savoir si le pixel Meta est géré par Google Tag Manager ou par une extension de CMS ?

Ouvrez la console sur une fiche produit et poussez l’événement à la main avec `dataLayer.push`, sans cliquer sur le bouton. Si un appel part vers Meta, le pixel est piloté par Google Tag Manager. Si rien ne part et que l’événement n’apparaît qu’au clic réel, une extension écoute les clics en parallèle de la couche de données. Un nombre inhabituellement élevé de paramètres dans l’appel est un second indice.

Voir deux appels vers Meta pour le même achat, est-ce un bug ?

Non, c’est le déploiement recommandé par Meta. L’événement part côté navigateur, où il peut être bloqué, et en parallèle du serveur vers l’API de conversion, où il ne peut pas l’être. Les deux portent un identifiant de déduplication, le paramètre `eid`, et la plateforme ne compte la conversion qu’une seule fois. En revanche, un appel direct **sans** cet identifiant est un vrai problème.

Combien de temps prend un audit tracking complet ?

Les six premières étapes prennent vingt à trente minutes sur un site, une fois la méthode maîtrisée. L’audit de la collecte e-commerce demande une commande test, comptez une heure de plus. La mesure de fiabilité exige un mois de données complet et l’accès au back-office. Un audit livré avec ses recommandations représente entre une demi-journée et trois jours de travail selon la taille de la stack.