Un code absent, une balise GTM mal déclenchée, ou des permissions erronées empêchent GA4 d’afficher des données. Vérifiez le gtag/Tag Manager, le dataLayer, les droits et les rapports en temps réel (source : documentation Google Analytics et Google Tag Manager).
Le code de suivi est-il présent et correct ?
Oui — si le code de suivi est absent ou mal configuré, aucune donnée n’est envoyée à GA4.
Je vérifie d’abord la présence du global site tag (gtag.js), le script officiel qui envoie les hits à Google Analytics 4. Le measurement_id (format G-XXXXXXX) identifie votre propriété GA4. Le tag doit idéalement être placé dans le <head> pour capter toutes les visites.
- Inspecter le source HTML et la console du navigateur : Ouvrir DevTools → Elements (ou View Source) et chercher script[src*= »gtag/js?id= »]. Rechercher aussi window.dataLayer et la fonction gtag dans la Console.
- Repérer le bon measurement_id et l’emplacement : Confirmer que l’id commence par G- et qu’il correspond à la propriété GA4 attendue. Placer la balise dans le <head> réduit les risques de perte d’événements au chargement.
- Détecter les erreurs JavaScript courantes : Vérifier la Console pour erreurs (ReferenceError, SyntaxError, blocked-by-client). Les bloqueurs de pub (adblock) ou les politiques CSP (Content Security Policy) peuvent empêcher le chargement du script.
- Éviter les doublons : Ne pas déployer simultanément un snippet gtag et un tag via Google Tag Manager (GTM) sans coordination. GTM = Google Tag Manager, un conteneur qui peut aussi injecter gtag; deux envois non coordonnés génèrent des doublons.
Exemple de snippet gtag.js minimal pour GA4 :
Formez-vous à Google Analytics !
Maîtriser Google Analytics est crucial pour comprendre votre audience, optimiser vos campagnes, améliorer l'expérience utilisateur et mesurer vos conversions... Gagnez du temps avec nos formations Google Analytics.
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
</script>Exemple de vérification via la console :
// Vérifier présence du script
document.querySelector('script[src*="gtag/js"]');
console.log(window.dataLayer);
console.log(typeof gtag); // doit retourner "function"
// Envoyer un événement de test (si gtag présent)
gtag('event', 'test_event', {send_to: 'G-XXXXXXX'});
Pour valider les hits, ouvrir DevTools → Network et filtrer sur g/collect ou collect pour GA4. Utiliser aussi l’extension Tag Assistant (by Google) pour une détection guidée des erreurs. Voir Documentation Google Analytics (https://developers.google.com/analytics/devguides/collection/ga4) et Guide Google Tag Manager (https://support.google.com/tagmanager) pour les détails officiels.
| Symptôme | Cause probable | Correctif rapide |
| Aucune requête g/collect | Snippet absent ou bloqué | Ajouter le gtag dans le <head> et désactiver le bloqueur |
| Requêtes mais pas de données | Measurement ID incorrect | Vérifier et corriger le G-XXXXXXX |
| Double comptage des sessions | gtag + GTM envoyant mêmes hits | Désactiver l’un des deux ou configurer send_to correctement |
GTM déploie-t-il correctement les balises ?
Non déclenchées — les balises configurées dans Google Tag Manager peuvent ne jamais se publier ou se déclencher à cause de triggers, variables ou d’un dataLayer cassé.
J’active le mode Preview en ouvrant mon conteneur GTM, puis en cliquant sur Preview et en renseignant l’URL du site à tester. La console Tag Assistant s’ouvre dans un nouvel onglet et affiche une connexion entre GTM et la page, avec la timeline des événements (Pageview, DOM Ready, Custom Events).
Je vérifie que le conteneur est publié en regardant le numéro de version dans l’interface GTM et en confirmant qu’il n’y a pas de modifications non publiées dans la workspace. Je rappelle que le mode Preview permet de tester les changements non publiés, mais que les visiteurs réels voient uniquement la version publiée.
Je diagnostique les triggers en inspectant leur type et leurs conditions. Les triggers courants sont Page View (vue de page), Click (clic) et Custom Event (événement personnalisé). Je teste les variables intégrées (Click Classes, Click ID, Page URL) et les variables personnalisées pour m’assurer qu’elles contiennent bien les valeurs attendues.
Je repère un dataLayer mal formé en recherchant des erreurs JSON dans la console navigateur ou des push manquants. Les erreurs classiques sont un dataLayer.push effectué avant l’injection du snippet GTM, des objets non valides ou des clés manquantes pour l’e‑commerce.
Je reproduis un debug pas‑à‑pas : 1) J’ouvre Preview. 2) J’exécute l’action sur le site (navigation, clic, ajout au panier). 3) J’observe la timeline dans Tag Assistant. 4) J’ouvre l’onglet de l’événement et je vérifie quelles balises se déclenchent et pourquoi certaines sont rejetées.
dataLayer.push({
'event': 'purchase',
'ecommerce': {
'transaction_id': 'T12345',
'value': 79.9,
'currency': 'EUR',
'items': [{ 'id': 'SKU-1', 'name': 'T‑shirt', 'price': 39.95, 'quantity': 2 }]
}
});Je considère le tag côté serveur (Server‑side tagging) lorsque l’échantillon de visiteurs concernés par le blocage (adblock, privacy) impacte la qualité des données. Cette approche réduit le blocage côté client, améliore la confidentialité et centralise les enrichissements, mais impose une infrastructure serveur et des coûts.
| Check GTM | Outil | Action corrective |
| Mode Preview | Tag Assistant | Vérifier timeline, relancer actions |
| Publication | Interface GTM | Publier la version ou revert |
| Triggers/Variables | Debugger + Console | Corriger conditions, activer variables intégrées |
| dataLayer | Console JS | Fix JSON, déplacer push après snippet |
Ai-je sélectionné la bonne propriété et les bons droits ?
Parfois oui — les données peuvent être collectées mais invisibles si vous consultez la mauvaise propriété, flux de données ou si vos droits sont limités.
Je commence toujours par distinguer compte, propriété et flux de données : le compte est l’entité parent (souvent l’entreprise), la propriété représente un espace Analytics (GA4) lié à un site ou une appli, et le flux de données (data stream) est le point de collecte précis (site web, iOS, Android) avec un Measurement ID (ex. G-XXXXXXX).
Je contrôle la propriété et le flux actifs en allant dans Admin → Propriété → Flux de données et je note le Measurement ID affiché. Ensuite, je compare ce Measurement ID avec celui présent sur le site :
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX'); // Vérifier que G-XXXXXXX correspond au Measurement ID
</script>
Je vérifie aussi la correspondance via l’onglet Réseau du navigateur (requêtes vers /g/collect) et via Google Tag Manager si utilisé. Pour confirmer la présence de données en temps réel, j’utilise le rapport Temps réel dans l’interface et la DebugView (DebugView nécessite le mode debug dans gtag ou l’extension GA Debug). Ces outils montrent immédiatement si le flux reçoit des hits.
Je contrôle les permissions dans Admin → Gestion des accès (Account/Property Access Management). Les rôles courants sont Administrateur, Éditeur, Analyste, Lecteur. Les erreurs fréquentes en multi‑agences sont : tag déployé sur la mauvaise propriété, container GTM partagé incorrectement, ou droit d’accès insuffisant chez le client (l’agence peut envoyer des données mais ne pas voir la propriété).
Bonnes pratiques : nommage clair (ex. « web – prod – example.com »), documenter chaque propriété/flux avec propriétaire, environnement, et lister les Measurement IDs et conteneurs GTM associés.
- Vérifier la propriété GA4 active et le flux de données dans Admin.
- Comparer le Measurement ID du site avec celui dans Analytics.
- Contrôler Temps réel et DebugView pour confirmer les hits.
- Vérifier les droits utilisateur et les accès multi‑agences.
- Documenter et standardiser les noms et propriétaires.
| Vérification | Qui consulter | Correction |
| Measurement ID sur le site | Développeur front / Agence | Remplacer par le bon G‑ID ou mettre à jour le tag GTM |
| Flux de données dans Admin | Propriétaire de la propriété / Admin Analytics | Associer le bon flux ou créer un flux dédié |
| Présence de hits (Temps réel/DebugView) | Analyste / Développeur | Activer debug ou corriger le déploiement de tag |
| Droits utilisateur | Administrateur | Attribuer rôle adéquat (Lecteur/Analyste/Éditeur) |
Les bloqueurs ou le navigateur empêchent-ils la collecte ?
Souvent partiellement — les bloqueurs d’annonces et les paramètres de confidentialité réduisent la collecte côté client.
Les bloqueurs d’annonces (ad blockers) filtrent les requêtes réseau et empêchent le chargement des scripts de suivi, ce qui fait disparaître des hits côté navigateur.
ITP (Intelligent Tracking Prevention) est la technologie de Safari qui limite le suivi cross-site et réduit la durée de vie des cookies tiers ou même empêche certains cookies côté client; ITP a été introduit par Apple en 2017 et évolue régulièrement.
GA4 signifie Google Analytics 4, la version qui repose principalement sur la collecte côté client via le gtag.js ou Google Tag Manager ; toute interruption côté navigateur se traduit par des données manquantes.
Plusieurs études estiment que l’usage d’ad blockers touche une part non négligeable des utilisateurs (ordre de grandeur 20–30% sur desktop selon rapports industry comme Statista ou PageFair), ce qui impacte directement la complétude des données.
Mesurer l’impact demande des comparaisons directes.
Comparer les données client (GA4) avec une collecte serveur (server-side) permet d’estimer la perte.
Réaliser des tests contrôlés avec et sans bloqueur sur le même navigateur et réseau isole l’effet du bloqueur.
Pour tester rapidement, je propose ces étapes :
- Créer une session test sans bloqueur, ouvrir le rapport en temps réel de GA4, et noter les événements captés.
- Activer un ad blocker (ou le mode strict du navigateur) et répéter la même session: comparer le nombre d’événements et les paramètres manquants.
- Option avancée: envoyer simultanément un hit via Measurement Protocol (collecte serveur) pour comparaison.
Exemple simple d’envoi serveur via Measurement Protocol (remplacer MEASUREMENT_ID et API_SECRET) :
curl -X POST -H "Content-Type: application/json" \
"https://www.google-analytics.com/mp/collect?measurement_id=MEASUREMENT_ID&api_secret=API_SECRET" \
-d '{"client_id":"12345.6789","events":[{"name":"test_event"}]}'Solutions possibles et limites légales.
Mettre en place un consentement clair et granulaire est souvent nécessaire : le RGPD exige un consentement préalable pour les cookies non essentiels et le suivi ciblé en Europe.
Implémenter le server-side tagging augmente la résilience mais ajoute coût et complexité.
Utiliser des heuristiques d’estimation (modélisation) peut compenser partiellement les pertes, mais apporte de l’incertitude.
| Solution | Avantages | Inconvénients |
| Consentement explicite | Conforme au RGPD, transparent pour l’utilisateur | Réduit le volume de données si refus |
| Server-side tagging | Résilience face aux bloqueurs, contrôle serveur | Coût et complexité technique |
| Heuristiques / modélisation | Permet d’estimer les pertes | Introduit des biais et de l’incertitude |
Mes événements et UTM sont-ils bien configurés ?
Pas forcément — GA4 ne collecte pas automatiquement toutes les interactions et des UTM incohérents faussent l’attribution.
GA4 propose des événements automatiques (page_view, first_visit, session_start) et des événements d’Enhanced Measurement (scroll, outbound_click, site_search, file_download, video_start) activables dans l’interface. Je crée des événements personnalisés quand l’interaction n’est pas couverte ou quand je veux des paramètres spécifiques.
Pour implémenter des événements personnalisés, j’utilise soit un dataLayer puis Google Tag Manager, soit gtag directement. Voici deux exemples pratiques :
{
"event": "purchase",
"ecommerce": {
"transaction_id": "T12345",
"value": 129.99,
"currency": "EUR",
"items": [
{"item_id": "SKU-001", "item_name": "T-shirt", "price": 39.99}
]
}
}
gtag('event', 'click_cta', {
'event_category': 'CTA',
'event_label': 'Hero - Inscription',
'value': 1
});Pour le suivi e‑commerce (Enhanced Ecommerce), j’envoie au minimum item_id (identifiant produit), value (montant de la transaction) et currency (devise). Ces paramètres sont indispensables pour les revenus, le ROAS et la segmentation produit.
Pour les UTM, j’applique une norme stricte : tout en minuscules, séparateur tiret-ou-underscore selon convention, et trois paramètres obligatoires utm_source, utm_medium, utm_campaign. Exemples standardisés :
- Paid Search : ?utm_source=google&utm_medium=cpc&utm_campaign=promo_avril
- Email : ?utm_source=newsletter&utm_medium=email&utm_campaign=mai_news
- Social organique : ?utm_source=facebook&utm_medium=social&utm_campaign=branding
- Offline (QR, print) : ?utm_source=flyer&utm_medium=offline&utm_campaign=salon2026
Pour diagnostiquer des campagnes mal attribuées, j’utilise d’abord les rapports Acquisition → Traffic acquisition et User acquisition, en changeant la dimension primaire sur session source/medium ou default channel grouping. Je vérifie aussi DebugView, Realtime et les événements bruts dans BigQuery si le lien est activé. Je compare les UTM reçus (paramètres utm_ dans first_user_source/first_session_source) et les événements associés.
Je maintiens un catalogue d’événements et un guide de tagging partagé avec les équipes marketing pour garantir cohérence, qualité des données et attribution fiable.
| Événement | Paramètres attendus | Exemple UTM |
| purchase | transaction_id, value, currency, items[item_id] | utm_source=google&utm_medium=cpc&utm_campaign=promo |
| add_to_cart | item_id, value, currency, quantity | utm_source=facebook&utm_medium=social&utm_campaign=summer |
| click_cta | event_category, event_label, value | utm_source=newsletter&utm_medium=email&utm_campaign=mai |
| form_submit | form_id, form_name, user_id (si disponible) | utm_source=flyer&utm_medium=offline&utm_campaign=salon2026 |
Prêt à remettre votre suivi Google Analytics en ordre ?
Je récapitule : la majorité des pertes de données provient d’un code manquant/dupliqué, d’un GTM mal publié, d’une mauvaise propriété ou de bloqueurs côté client. En priorisant les vérifications rapides (gtag/GTM, DebugView, permissions, dataLayer) et en standardisant UTM et événements, vous récupérez des mesures fiables. Votre bénéfice : des décisions produit/marketing basées sur des données exploitables et moins d’incertitude opérationnelle.
FAQ
-
Pourquoi mon tableau de bord GA4 est vide alors que j’ai du trafic ?
Vérifiez d’abord la présence du tag (gtag ou GTM) et le measurement_id correct, puis regardez la DebugView et le mode Réel. Assurez-vous aussi d’utiliser la bonne propriété et d’avoir les droits d’accès. -
Comment savoir si GTM ne publie pas mes balises ?
Activez le mode Preview de GTM, reproduisez l’action sur le site et inspectez la timeline : vous verrez quelles balises se déclenchent et lesquelles échouent. Vérifiez aussi que le conteneur est bien publié. -
Les bloqueurs d’annonces peuvent-ils fausser mes données ?
Oui : ad blockers et protections navigateur empêchent le chargement des scripts côté client. Mesurez l’impact avec des tests contrôlés et envisagez le server-side tagging pour améliorer la résilience. -
Mes campagnes ne s’attribuent pas correctement, est-ce un problème d’UTM ?
Souvent oui : des UTM incohérents ou absents entraînent des erreurs d’attribution. Standardisez utm_source, utm_medium et utm_campaign et documentez la nomenclature pour toutes les équipes. -
Dois-je implémenter le suivi côté serveur ?
Le server-side tagging réduit l’impact des bloqueurs et améliore la confidentialité, mais il demande une infrastructure et une gouvernance. C’est pertinent si vous subissez une perte significative de données côté client.
A propos de l’auteur
Je suis Franck Scandolera, expert & formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics, j’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor sur la fiabilité du tracking et l’industrialisation des données. Disponible pour aider votre entreprise : contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.