Pourquoi GA4 perd des données : les 10 causes principales et leurs corrections

GA4 ne perd pas des données par hasard. Quand vous constatez un écart entre les chiffres GA4 et la réalité business — moins de conversions affichées que dans le back-office, sessions sans event de conversion attaché, dimensions qui partent en (other) — il y a toujours une cause technique précise. Voici les 10 raisons que je rencontre le plus souvent en mission d’audit tracking, classées par fréquence et avec la correction adaptée.

1. Le Consent Mode envoie les signaux trop tard

Symptôme : Google Ads voit toutes vos sessions en consent_state='denied' même quand l’utilisateur accepte. GA4 alimente le behavioral modeling au lieu de mesurer la conversion réelle. Cause : le gtag('consent', 'update', ...) est poussé après le chargement des tags GA4, donc l’event purchase ou generate_lead part en denied puis le signal d’acceptation arrive trop tard pour rattraper.

Correction : pousser le signal consent default avant tout autre tag GTM, et le consent update immédiatement après l’action utilisateur dans la CMP (pas après un délai, pas via un dataLayer event qui se traite en queue). Détails dans consultant Consent Mode v2.

2. Safari ITP coupe les cookies de tracking

Symptôme : différence de 15 à 30 % entre les conversions Google Ads ou Meta et les conversions réelles côté back-office, surtout marquée sur Safari iOS. Cause : Intelligent Tracking Prevention raccourcit la durée des cookies _ga à 7 jours puis à 24 heures, et bloque entièrement les cookies tiers identifiables comme tracking.

Correction : passage en tracking server-side avec sGTM ou Cloud Run, ce qui sert les cookies en first-party et envoie les conversions par API serveur. Récupération typique 20 à 40 % sur les sites premium. Voir consultant server-side tracking.

3. Les bloqueurs de publicité bloquent GA4 directement

Symptôme : 8 à 15 % de sessions invisibles, surtout sur les sites éditoriaux et tech. Cause : uBlock, AdBlock Plus, Ghostery, et Brave bloquent les requêtes vers google-analytics.com et googletagmanager.com par défaut.

Correction : tracking server-side avec un sous-domaine first-party (metrics.votresite.fr), ce qui contourne la majorité des bloqueurs publics. Pas une silver bullet — les bloqueurs adaptés (Brave avec listes Easyprivacy fortes) continueront de bloquer — mais sur 80 % des bloqueurs grand public, la récupération est complète.

4. La cardinalité fait tomber des dimensions en (other)

Symptôme : dans les rapports GA4, votre dimension custom product_category affiche correctement 50 valeurs principales puis tout le reste tombe dans (other). La donnée est dans BigQuery mais invisible dans GA4 natif.

Correction : passage en lecture BigQuery pour les analyses qui dépassent la cardinalité native GA4 (limite : 500 valeurs uniques par dimension dans les rapports natifs). Voir GA4 + BigQuery.

5. Les événements purchase sont dédupliqués trop strictement

Symptôme : un même transaction_id envoyé deux fois (refresh page de confirmation, retour navigateur) est compté deux fois si vous n’avez pas de dédup, ou pas compté du tout si la dédup est trop stricte.

Correction : transaction_id unique côté back-office, dédup au niveau du sGTM avec une logique de cache 24 h. Si vous êtes en client-side, vérifier que GTM ne re-déclenche pas le tag purchase sur un refresh page (généralement via un trigger Form Submit qui ne se ré-arme pas).

6. Le data layer mobile est en retard ou vide

Symptôme : conversions OK sur desktop, perdues sur mobile. Cause : application React/Vue/Next qui hydrate après le chargement initial, donc le data layer n’est pas prêt au moment où GTM se déclenche.

Correction : déclenchement des events GA4 sur un dataLayer event explicite ('event': 'page_view_ready') poussé après hydratation complète, plutôt que sur le trigger History Change ou All Pages. Pour Next.js et React Router, configuration spécifique à valider parcours par parcours.

7. Cross-domain non configuré

Symptôme : un utilisateur passe de marketing.votresite.fr à shop.votresite.fr et la session redémarre, l’attribution est perdue, deux utilisateurs sont comptés pour un seul vrai visiteur.

Correction : configuration cross-domain dans GA4 (Admin → Data Streams → Configure tag settings → Cross-domain) avec liste explicite des sous-domaines. Plus le linker GTM qui décore les liens cross-domain avec le _gl parameter.

8. Les conversions Google Ads sont sans value

Symptôme : conversions remontées dans GA4 et dans Google Ads, mais ROAS toujours à 0 ou à 100 selon les périodes. Cause : l’event purchase part sans paramètre value (ou avec value=undefined).

Correction : vérification du data layer Shopify/Woo/Prestashop pour s’assurer que value (et currency, tax, shipping) sont bien remplis au moment de l’event. Voir tracking Shopify pour les pièges spécifiques par plateforme.

9. GA4 utilise le mode behavioral modeling sans qu’on le sache

Symptôme : les chiffres GA4 ne correspondent pas aux chiffres bruts (BigQuery, back-office). Cause : GA4 applique automatiquement le behavioral modeling pour combler les denied, donc une partie de la donnée affichée est modélisée, pas mesurée.

Correction : pas vraiment une “correction” — c’est by design. Mais on peut désactiver le modeling dans les rapports en allant dans Admin → Data Settings → Reporting → User-Provided Data → Off. Et toujours croiser les chiffres GA4 affichés avec BigQuery pour les analyses critiques.

10. Filtres internes mal configurés (IP, internal traffic)

Symptôme : trafic d’agence ou trafic interne (équipe, partenaires) compté dans les chiffres business, ou inversement, du trafic réel filtré par erreur. Cause : filtres Internal Traffic configurés sur des plages IP qui ont changé, ou règles regex erronées.

Correction : revue régulière des filtres internes (tous les 3-6 mois), vérification que les IP correspondent toujours à l’équipe interne, validation des règles regex avec un échantillon de trafic réel.

Foire aux questions

Comment savoir si GA4 perd vraiment des données ?

Trois checks rapides : (a) comparer le total purchase GA4 du mois avec le total transactions back-office sur la même période — l’écart attendu est sous 10 %, au-dessus c’est anormal ; (b) comparer le total sessions GA4 vs le total visiteurs back-office (proxy) ; (c) vérifier dans GA4 → DebugView qu’un parcours test (achat fictif en navigation privée) remonte bien tous les events attendus.

À partir de quel écart faut-il s’inquiéter ?

Sous 8 % d’écart entre GA4 et back-office sur les conversions principales : pas d’inquiétude, c’est l’érosion normale due au consent + ITP + bloqueurs. Entre 8 % et 20 % : anormal, audit ciblé recommandé. Au-delà de 20 % : critique, audit complet immédiat.

GA4 va-t-il s’améliorer avec le temps ?

Marginalement. Le behavioral modeling progresse, le matching cookie-less aussi. Mais les forces qui érodent la donnée client-side (ITP, bloqueurs, refus de consent) progressent plus vite. La trajectoire structurelle est vers le server-side et les API serveur, pas vers une amélioration du client-side.