Pourquoi votre Google Analytics tracking devient faux ?

Votre Google Analytics tracking devient faux quand le navigateur, le consentement ou l’architecture du site empêche GA de mesurer. Le vrai sujet, c’est de savoir ce qui est mesuré, ce qui est estimé, et où vos décisions business peuvent partir de travers.

Pourquoi GA mesure moins bien ?

Google Analytics mesure moins bien parce qu’il dépend encore beaucoup d’un tag JavaScript exécuté côté navigateur, alors que les navigateurs, le consentement utilisateur et les architectures web modernes bloquent ou fragmentent une partie de la mesure.

GA reste partout, ça c’est clair. On parle d’environ 44 % du web, et de près de 79 % des sites qui utilisent un outil d’analytics selon les chiffres souvent cités. Mais l’adoption ne veut pas dire fiabilité. Un outil peut être massivement installé et quand même voir une partie seulement de la réalité.

Le fonctionnement classique est assez simple. Vous ajoutez un petit script JavaScript sur le site. Ce script se charge dans le navigateur du visiteur, pose ou lit des cookies, puis envoie des informations à Google Analytics. Une page vue. Un clic. Un achat. Un formulaire envoyé. Un événement, c’est juste une action que vous voulez mesurer.

Le problème, c’est que ce modèle côté client devient fragile. Il dépend de trop de choses qui ne sont plus garanties.

• Le script peut ne pas se charger, à cause d’un problème réseau, d’un chargement trop lent ou d’une erreur sur la page.
• Un bloqueur peut couper GA, comme un ad blocker, un navigateur plus strict ou une extension de confidentialité.
• Le consentement peut refuser les cookies, donc GA perd la continuité entre les visites et peut compter un même utilisateur comme plusieurs nouveaux visiteurs.
• Une SPA peut brouiller les pages vues. Une SPA, c’est une application web où la page ne se recharge pas vraiment, comme beaucoup de sites React ou Vue. Si le tracking n’est pas bien prévu, GA ne voit pas correctement les changements d’écran.

Découvrez égalementPourquoi connecter Google Business à Google Analytics

Pour une équipe marketing ou e-commerce, l’impact est très concret. L’attribution devient bancale. Les visiteurs nouveaux sont surestimés. Les sessions sont éclatées. Les campagnes semblent moins bonnes ou meilleures qu’elles ne le sont vraiment. Et parfois, on coupe un budget rentable ou on pousse un canal qui récupère juste le crédit à la fin.

J’ai vu ça chez un client qui regardait surtout le volume de conversions GA4. Le chiffre avait baissé, donc l’équipe pensait que la performance chutait. En réalité, le périmètre mesuré avait changé avec le consentement et une partie du parcours n’était plus suivie pareil. Le business n’avait pas bougé autant que GA le racontait.

Le sujet, ce n’est pas GA contre un autre outil. C’est mesure réelle contre mesure supposée. Et aujourd’hui, si on ne comprend pas ce que GA ne voit plus, on prend vite des décisions sur une photo incomplète.

Quels blocages faussent les rapports ?

Les principaux blocages viennent de deux endroits très concrets : les protections de confidentialité des navigateurs et le refus des cookies via les bannières de consentement. C’est souvent là que Google Analytics commence à raconter une histoire incomplète.

Safari a son système, appelé ITP pour Intelligent Tracking Prevention. Firefox a ETP, Enhanced Tracking Protection. Brave a Shields. Derrière les acronymes, l’idée est simple : le navigateur essaie de limiter le suivi des utilisateurs, surtout quand il reconnaît des traceurs connus.

Découvrez égalementComment fonctionne l’attribution Google Analytics ?

Ces protections peuvent bloquer certains appels de tracking, réduire la durée de vie des cookies, ou empêcher certains scripts de fonctionner correctement. Safari ITP, par exemple, peut limiter la durée de vie de certains cookies côté client à 7 jours ou moins selon les cas. Résultat assez classique : quelqu’un revient sur votre site après 10 jours, mais GA peut le voir comme un nouveau visiteur.

Et là, les rapports bougent dans tous les sens :

• Les sessions peuvent être sous-estimées ou mal rattachées.
• Les utilisateurs récurrents peuvent être comptés comme nouveaux.
• Le nombre de nouveaux visiteurs peut gonfler artificiellement.
• L’attribution devient moins fiable, parce que GA perd une partie de l’historique entre les visites.

Le deuxième gros sujet, c’est le consentement. Sous RGPD et régulations similaires, les cookies d’analyse demandent souvent un consentement préalable, sauf cas particuliers d’exemption très encadrés. Si l’utilisateur refuse, GA ne peut plus mesurer comme avant. Il peut manquer la visite, la conversion, la source d’acquisition, parfois tout le parcours.

J’ai déjà vu des écarts énormes chez des clients, surtout quand la bannière est très stricte ou mal configurée. Certaines études ou configurations parlent même de pertes massives de données, jusqu’à environ 97 % dans les cas les plus extrêmes cités. Je le prends avec prudence, mais ça montre bien le problème : GA ne mesure pas la réalité, il mesure ce qu’il a encore le droit et la capacité de mesurer.

Il faut bien distinguer les trois. Le refus de cookies vient du choix utilisateur. Le blocage navigateur vient des règles intégrées à Safari, Firefox ou Brave. L’adblocker, lui, est une extension ou un outil qui bloque volontairement des scripts publicitaires ou analytiques.

Pourquoi les estimations GA4 posent problème ?

Découvrez égalementComment Google Analytics 4 améliore vos App campaigns ?

Les estimations GA4 posent problème parce qu’elles remplacent parfois une mesure absente par un modèle statistique. Et un modèle, ce n’est pas une observation. C’est une hypothèse calculée à partir de ce que GA4 arrive encore à voir.

Avec le Consent Mode, Google adapte le tracking selon le choix de consentement de l’utilisateur. Si une personne refuse les cookies analytics ou marketing, GA4 ne reçoit pas forcément les mêmes informations. Il peut manquer une page vue, une session, une conversion, ou une partie du parcours. Pour éviter d’avoir des rapports trop vides, GA4 peut alors utiliser des données modélisées. En clair, il estime une partie du comportement ou des conversions à partir des utilisateurs qui, eux, sont observables.

Sur le papier, ça aide. Ça permet de garder une tendance quand la mesure directe est cassée ou incomplète. Mais dans la vraie vie, ça peut aussi masquer les trous de mesure. Et c’est là que ça devient dangereux.

L’hypothèse fragile, c’est de croire que les utilisateurs mesurés ressemblent aux utilisateurs non mesurés. Ce n’est pas toujours vrai. Une personne qui accepte le tracking peut avoir plus confiance dans la marque. Elle peut être plus engagée, plus fidèle, plus avancée dans son intention d’achat. À l’inverse, quelqu’un qui refuse peut venir d’un contexte différent, d’un navigateur plus strict, d’un pays plus sensible au consentement, ou simplement d’un canal qui attire un autre type de trafic.

J’ai déjà vu ce cas chez un client. L’équipe comparait deux canaux d’acquisition. Sur le tableau GA4, un canal semblait meilleur. Sauf qu’une partie plus importante de sa performance reposait sur des conversions modélisées, alors que l’autre canal était davantage mesuré directement. Le classement avait l’air propre, mais il était discutable. On ne comparait plus seulement deux canaux. On comparait aussi deux niveaux d’incertitude.

Le risque est simple dans vos arbitrages marketing :

• Une campagne peut sembler rentable parce que le modèle comble les blancs.
• Un canal peut être sous-estimé parce qu’il est moins bien modélisé.
• Une décision budget peut partir dans la mauvaise direction si vous regardez le total sans regarder la qualité de la donnée.

Je garde toujours cette règle en tête : séparer mentalement les données mesurées, les données modélisées et les données absentes. GA4 peut aider à lire une tendance, oui. Mais quand vous devez décider où mettre votre argent, il faut savoir quelle part du chiffre a été observée, quelle part a été estimée, et quelle part reste tout simplement invisible.

Où les sites modernes cassent GA ?

Les sites modernes cassent GA quand le modèle classique de page vue ne colle plus au comportement réel du site. Google Analytics a longtemps très bien fonctionné avec une idée simple : une page se charge, GA enregistre une page vue. Sauf qu’aujourd’hui, beaucoup de sites ne fonctionnent plus comme ça.

Le cas le plus courant, c’est la Single Page Application, souvent appelée SPA. C’est un site où l’utilisateur passe d’un écran à l’autre sans rechargement complet de la page. Vous cliquez sur “Tarifs”, puis “Contact”, puis “Réserver”, l’URL peut changer, l’écran aussi, mais techniquement le navigateur n’a pas forcément rechargé une vraie nouvelle page.

Si le tracking n’est pas prévu pour ça, GA peut raconter n’importe quoi. Il peut rater des page_view, dupliquer des événements, ou reconstruire un parcours qui ne ressemble pas du tout à ce que l’utilisateur a vécu. Je l’ai vu chez un client avec un tunnel en React : GA montrait très peu de vues sur certaines étapes, alors que le back-office prouvait que les utilisateurs y passaient bien.

L’autre gros point, c’est le cross-domain tracking. En clair : le suivi entre plusieurs domaines. Par exemple votre site principal, un moteur de réservation, un espace paiement, ou un sous-domaine. Si l’identifiant utilisateur ne suit pas proprement, GA peut croire qu’un nouvel utilisateur arrive au milieu du parcours.

Le résultat est assez classique :

• Une source de trafic qui change en plein tunnel.
• Une session coupée en deux.
• Une conversion attribuée au mauvais canal.
• Un referral interne qui apparaît comme si votre propre site était une source d’acquisition.

Les assistants IA ajoutent aussi un changement de contexte. Une partie de la recherche, de la comparaison ou de la décision peut se faire hors site. GA ne voit pas tout ce qui s’est passé avant la visite. Ça ne “casse” pas GA techniquement, mais ça réduit la visibilité sur les parcours classiques.

Voilà les contrôles simples que je demanderais avant de tirer des conclusions sur les chiffres :

Si ces points ne sont pas propres, le problème ne vient pas forcément de GA. Il vient souvent du fait que le site a évolué, mais pas le plan de tracking.

Comment retrouver une mesure fiable ?

Je retrouve une mesure plus fiable quand j’arrête de chercher le chiffre parfait. Le bon réflexe, c’est de construire un dispositif de mesure cohérent, documenté, et adapté au web actuel. Avec les refus de cookies, les bloqueurs, les navigateurs plus stricts et la modélisation, le chiffre exact n’existe plus vraiment.

Avant de commenter une baisse de trafic ou une chute de conversion, j’audite le périmètre mesuré. Sinon, on analyse parfois un problème de tracking comme si c’était un problème business. Je l’ai vu chez un client e-commerce récemment, la “baisse” venait surtout d’un événement purchase déclenché une fois sur deux sur mobile.

Je vérifie toujours quelques points simples avant de tirer une conclusion :

• Le consentement est-il bien collecté et transmis aux outils de mesure ?
• Les tags se déclenchent-ils au bon moment, sur les bonnes pages ?
• Les événements clés sont-ils nommés et envoyés de façon stable ?
• Les SPA, donc les sites qui changent de page sans vrai rechargement, sont-ils bien suivis ?
• Le cross-domain est-il configuré si le parcours passe sur plusieurs domaines ?
• Les écarts avec le CRM, donc l’outil commercial, ou le back-office sont-ils compris ?

GA4 peut rester utile. Je ne le jette pas à la poubelle. Mais je lis ses rapports avec prudence, surtout quand Consent Mode et la modélisation interviennent. Consent Mode permet à Google d’adapter la mesure selon le choix de consentement de l’utilisateur. La modélisation complète ensuite certains trous avec des estimations. C’est pratique, mais ce n’est pas la même chose qu’une donnée observée.

Je regarde aussi les alternatives comme Matomo, Plausible ou d’autres outils plus orientés confidentialité. Ce n’est pas automatiquement meilleur pour tout le monde. Par contre, ça peut donner plus de contrôle sur l’hébergement des données, la configuration du consentement et la transparence de mesure.

Le server-side tracking peut aussi aider. L’idée, c’est de faire passer une partie de la collecte par un serveur contrôlé par l’entreprise. Ça peut améliorer la qualité et le contrôle des données, mais ce n’est pas une baguette magique. Si l’utilisateur refuse le tracking, on doit respecter ce choix.

Ma grille de décision reste simple :

• Ce que je veux mesurer.
• Ce que j’ai le droit de mesurer.
• Ce que l’outil mesure vraiment.
• Ce qui est estimé ou reconstruit.

Alors on mesure quoi maintenant ?

Je ne jetterais pas Google Analytics à la poubelle. Je le vois plutôt comme un outil à remettre à sa place. Il donne des tendances utiles, mais il ne raconte plus toujours la réalité complète. Entre les navigateurs privés, les refus de consentement, les données modélisées, les SPA et les parcours cross-domain, il faut regarder la donnée avec plus de recul. Le bon réflexe, c’est d’auditer ce qui est vraiment mesuré, puis de compléter avec une architecture plus solide si besoin. Vous gagnez surtout une chose précieuse. Des décisions marketing moins biaisées, donc moins d’argent brûlé.

FAQ

• Pourquoi Google Analytics peut-il afficher des données fausses ?
  Google Analytics peut afficher des données trompeuses quand son tag JavaScript ne s’exécute pas, quand les cookies sont refusés, quand un navigateur limite le tracking ou quand le site est mal configuré. Le chiffre n’est pas forcément faux partout, mais il peut être incomplet ou estimé.
• Le Consent Mode de GA4 corrige-t-il les pertes de données ?
  Le Consent Mode aide GA4 à fonctionner avec le consentement, mais il ne recrée pas une mesure réelle. Quand certaines données ne sont pas observables, GA4 peut utiliser de la modélisation. C’est utile pour lire une tendance, mais ce n’est pas équivalent à une donnée collectée.
• Les navigateurs comme Safari ou Brave bloquent-ils Google Analytics ?
  Ils peuvent limiter ou bloquer une partie du tracking. Safari ITP, Firefox ETP et Brave Shields réduisent la capacité des outils analytics à suivre les utilisateurs dans le temps. Résultat possible, des visiteurs récurrents reclassés comme nouveaux, des sessions fragmentées et une attribution moins fiable.
• Pourquoi les SPA posent-elles problème avec GA4 ?
  Dans une Single Page Application, la page ne se recharge pas forcément à chaque navigation. Si les événements page_view ne sont pas envoyés correctement lors des changements d’écran ou d’URL, GA4 peut rater des vues, dupliquer des interactions ou reconstruire un parcours incomplet.
• Faut-il remplacer Google Analytics par Matomo ?
  Pas automatiquement. Matomo peut être intéressant si vous voulez plus de contrôle sur vos données, votre hébergement et votre approche de confidentialité. Mais le vrai sujet reste le même. Il faut définir ce que vous mesurez, ce que vous avez le droit de mesurer et ce que l’outil mesure vraiment.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA appliquée en entreprise et SEO/GEO. J’accompagne des équipes qui veulent fiabiliser leurs données au lieu de piloter au doigt mouillé. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez remettre votre tracking, vos tableaux de bord ou vos automatisations à plat, contactez-moi.

Franck Scandolera

⭐ 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.