Auditer un setup tracking en 5 étapes : la méthode que j'applique

La plupart des audits tracking que je reprends après d’autres prestataires partagent un défaut : ils listent 40 problèmes en vrac, sans hiérarchie ni format clair. Le client lit, hoche la tête, et ne fait rien. Un audit utile est un fichier de fixes que l’équipe peut attaquer le lendemain — pas un PDF qu’on archive.

Voici la méthode que j’applique sur chaque mission, structurée en cinq étapes. Elle marche pour un e-commerce sur Shopify comme pour un site PrestaShop ou WooCommerce, avec ou sans server-side GTM.

L’essentiel

5 étapes : cadrage, GTM, GA4, Google Ads, site live.
Durée cible : 2 heures pour un setup standard, 4 heures avec server-side complet.
Livrable : un document structuré avec “Most important” en tête, sections par plateforme, une recommandation concrète par finding.
Priorisation : data quality > RGPD > attribution > conversions > nice-to-haves.

Le pipeline complet

Étape 1 — Cadrer le contexte avant d’ouvrir le moindre outil

Avant de me connecter à GTM ou GA4, je collecte un minimum de contexte. Ça paraît évident, mais 80 % des audits qui partent dans le mur ratent cette étape.

Ce que je demande au client

Plateforme e-commerce (Shopify, WooCommerce, PrestaShop, Magento, custom)
CMP utilisée (OneTrust, Axeptio, Didomi, tarteaucitron, custom)
Outils tracking actifs en plus de GTM (Jentis, TripleWhale, ProfitMetrics, app Google & YouTube de Shopify, etc.)
Server-side GTM en place ? Si oui, hébergé où (Stape, Addingwell, Cloud Run autogéré) ?
Issues déjà identifiées par l’équipe — souvent un pourcentage de “Direct” anormal en GA4, ou un écart suspect entre Ads et GA4

Les IDs GTM, GA4 et Google Ads, je les découvre moi-même à l’étape 2. Demander des IDs au client est une perte de temps, et ça réduit la fiabilité (un ID donné de mémoire est souvent celui d’une ancienne propriété).

Pourquoi cette étape compte

Le contexte oriente la lecture. Un même comportement peut être un défaut critique sur un setup ou une décision assumée ailleurs. Exemple : un Google & YouTube channel Shopify activé en parallèle d’un container GTM custom fait du double-firing — sur 90 % des setups, c’est un problème ; sur quelques-uns, c’est temporaire et conscient pendant une migration.

Étape 2 — Inventorier les containers GTM (web + server)

C’est l’étape la plus longue de l’audit (~45 min). Je parcours systématiquement le container web, puis le container server s’il existe.

Sur le container web, les vérifications qui paient

Consent Mode v2 default : où est-il défini ? S’il est dans un Custom HTML tag GTM, il fire trop tard. Le default doit venir de la CMP, avant le chargement de GTM. C’est la cause numéro un des taux de “Direct/Unassigned” anormaux en GA4.
Triggers des tags non-Google : Meta, TikTok, LinkedIn doivent fire sur cookie_consent_update, pas sur “All Pages”. Sinon, ils tirent avant consentement, Consent Mode les bloque, et les click IDs sont perdus.
Naming conventions : tags nommés Tag 14 copy ou FB Pixel - Old paused = dead weight. Un container clean = [Plateforme] - [Type] - [Nom].
Google Tag pour Ads : depuis la mise à jour GTM de fin 2024, un Google Tag explicite pour Ads est requis. Beaucoup de containers n’en ont pas.

Sur le container server, ce qui revient le plus souvent

Facebook CAPI sans event ID : pas de déduplication entre le pixel browser et CAPI = doublons systématiques côté Meta
CAPI avec trigger trop large : il forward scroll, file_download, click vers Meta = pollution d’événements qui dégrade Event Match Quality
GCLID restoration absente : les restrictions navigateur stripent les click IDs, sans restoration server-side l’attribution Ads est trouée
Microsoft Ads incomplet : souvent uniquement le PageView est server-side, les conversions restent en client-side

Sur les setups complexes, l’inventaire bénéficie d’un appui méthodologique structuré. Je détaille la procédure que j’applique container par container dans la méthodologie d’audit tracking.

Étape 3 — Vérifier GA4 jusqu’aux paramètres invisibles

GA4 a quelques réglages cachés dans les profondeurs de l’Admin qui changent radicalement la valeur des données collectées. Les plus impactants :

Réglage	Valeur attendue	Pourquoi
Rétention des données	14 mois	Le défaut est 2 mois — explorations historiques perdues
Google Signals	Activé ET accepté	L’acceptation est une case séparée, souvent oubliée
Collecte de données utilisateur	Acceptée	Conditionne Enhanced Conversions côté GA4
Modèle d’attribution	Paid + organic	Beaucoup de comptes sont en paid-only par défaut
Identité de reporting	Pas DEVICE_BASED si Consent Mode actif	DEVICE_BASED ignore les données modélisées

Les rapports qui révèlent les vrais problèmes

Sur les 30 derniers jours, trois rapports suffisent à diagnostiquer 80 % des soucis :

Canaux — un pourcentage de “Direct” ou “Unassigned” supérieur à 25 % signale presque toujours un problème de timing du Consent Mode
Sources de session — la présence de Mollie, PayPal, Klarna ou Stancer en source = liste d’exclusion de référents manquante
Événements clés — purchase, add_to_cart, begin_checkout, view_item : absent = trou de tracking, anormalement élevé = duplication

L’export BigQuery est un autre point que je vérifie systématiquement. Activable gratuitement, il devient indispensable dès qu’on veut creuser au-delà des dashboards GA4 standards. Le sujet est détaillé dans la petite-fille BigQuery du cocon GA4.

Étape 4 — Auditer les conversions côté Google Ads

Étape rapide (~20 min) mais à fort impact. Trois points concentrent l’essentiel des problèmes :

Source de la conversion principale

La conversion principale doit être un tag GTM natif (type WEBPAGE), pas un import GA4 (GOOGLE_ANALYTICS_4). Les imports GA4 ne supportent pas Enhanced Conversions et arrivent avec 24h de délai — le Smart Bidding optimise sur de la donnée éventée.

Enhanced Conversions

À activer absolument sur la conversion principale. Sans elles, on perd 15 à 30 % de matching côté Google. Le setup nécessite que les données utilisateur (email, téléphone) soient bien mappées dans le tag GTM et hashées avant envoi.

Conversions historiques à nettoyer

Quasiment tous les comptes Ads que j’audite ont des conversions Universal Analytics encore actives (UA est arrêté depuis juillet 2023), des conversions de test datées de 2022, ou des doublons “Purchase” et “Purchase - GA4”. À supprimer pour clarifier le reporting.

Sur les setups e-commerce, je vérifie aussi que les Conversions with Cart Data fonctionnent. Cela suppose que le tableau items du dataLayer envoie un paramètre id aligné avec le flux produit Google Merchant Center — sinon, le remarketing dynamique tape à côté.

Étape 5 — Inspecter le site en live

15 minutes dans Chrome DevTools, panneau Network + console, parfois Tag Assistant. Ce que je regarde :

Comment GTM se charge : via un sous-domaine first-party (metrics.client.fr) ou via googletagmanager.com direct ? La deuxième option laisse 8 à 15 % de visites bloquées par les ad blockers.
Ordre des scripts : gtag('consent', 'default', ...) doit apparaître avant le snippet GTM dans le dataLayer. Une CMP bien configurée le pousse dans le <head> avant tout le reste.
Bandeau de consentement : accepter et refuser doivent être aussi visibles l’un que l’autre — la CNIL sanctionne les dark patterns depuis 2022.
Doublons : si GTM, l’app Google & YouTube Shopify, Jentis et TripleWhale envoient tous des hits en parallèle, on a un mille-feuille de données dupliquées difficile à démêler en analyse.

La hiérarchie des findings : prioriser pour rendre l’audit actionnable

Un audit sérieux trouve facilement 15 à 30 findings. Sans hiérarchie, le client est noyé. La grille que j’applique :

L’ordre n’est pas arbitraire. Si la data n’est pas propre, tout ce qui se construit dessus est bancal. Si le consentement n’est pas conforme, c’est un risque légal qui n’attend pas. L’attribution casse ensuite, puis les conversions, puis le confort opérationnel.

Le format de livrable qui passe

Le contenu d’un audit ne suffit pas — sa forme conditionne sa lecture. Le format qui fonctionne le mieux chez mes clients :

Structure du document

Section “Le plus important” en tête : 5 à 7 issues critiques en une ligne chacune, avec la plateforme entre parenthèses. C’est ce que le décisionnaire lit en premier.
Une section par plateforme dans l’ordre : Shopify (si applicable), GTM web, GTM server, GA4, Google Ads, Meta, autres, site live.
Une finding = un format fixe : titre court (pas une phrase), diagnostic en un paragraphe avec les noms exacts de tags ou paramètres, Recommandation sur une ligne.

Le ton

Direct, factuel, sans fluff. Référencer les noms exacts (G-XXXXXX, cookie_consent_update, TWO_MONTHS) pour que la finding soit traçable dans l’outil. Et surtout : ne lister que les findings qui appellent une action. Un audit n’est pas une checklist de ce qui va bien — c’est une liste de corrections.

Pour aller plus loin sur le format du livrable et ce qu’un client est en droit d’attendre d’un audit tracking, voir la petite-fille dédiée au livrable d’audit. Sur la question du timing d’un audit — à quel moment c’est pertinent dans la vie d’un compte — je détaille les déclencheurs dans la page quand auditer son tracking.

En synthèse

Cinq étapes, une priorisation claire, un format de livrable qui force l’action. La méthode tient en deux heures sur un setup standard et reste reproductible d’un client à l’autre.

Si vous voulez auditer un setup spécifique avant de prendre une décision (migration vers server-side, refonte du Consent Mode, MAJ GTM en cours de déploiement, etc.), c’est exactement ce que couvre mon audit tracking complet — livré sous 5 à 10 jours selon la complexité.

Pour la partie Consent spécifiquement, j’utilise la méthode d’audit Consent Mode v2 en 12 points — décodage gcs=, scénarios refus/retrait, mapping CMP. Vous pouvez la passer en autonomie avant ou après l’audit global.

Sources

The Complete Tracking Audit Framework — framework détaillé qui m’a servi de base pour structurer ma propre méthode
Simo Ahava — articles sur GTM, Consent Mode et server-side — référence pour les bonnes pratiques techniques