Audit GA4 : les 11 erreurs de configuration à corriger en 2026

La plupart des propriétés GA4 tournent sans planter : les chiffres bougent, les rapports se chargent, tout semble normal. Et pourtant elles mentent. Le trafic interne gonfle les sessions, la rétention par défaut à deux mois ampute vos explorations, et de faux key events font passer un scroll pour une conversion. Un audit GA4 sérieux ne vérifie pas si l’outil fonctionne, il vérifie si vous pouvez faire confiance à ses chiffres. Voici une checklist d’audit GA4 en 11 points, ordonnée par impact, avec pour chaque erreur de configuration le symptôme, l’endroit exact où regarder dans l’Admin, et le correctif. En une heure, vous saurez si vos données tiennent debout.

Cet article porte sur la couche configuration de la propriété : les paramètres GA4 dans l’Admin. Si vos problèmes viennent plutôt du code de collecte (events qui partent en double, paramètres mal nommés à la source), commencez par notre guide sur les 7 erreurs de dataLayer qui faussent vos données. Et si vous partez de zéro, le pendant logique de cet audit est notre guide pour configurer GA4 from scratch.

Comment auditer vite : 3 réflexes avant la checklist

Avant d’ouvrir les paramètres, équipez-vous de trois outils intégrés à GA4. Le DebugView (Admin → DebugView) montre en direct les events d’un appareil de test : c’est votre microscope pour vérifier qu’un event part, une seule fois, avec les bons paramètres. Le rapport Temps réel confirme qu’une action déclenche bien ce que vous croyez. Enfin, la comparaison avec une source externe (votre back-office, votre CRM, votre plateforme de paiement) reste le juge de paix : si GA4 compte 100 commandes et votre back-office 130, vous avez une fuite à trouver. Gardez ces trois réflexes sous la main, ils servent à valider chacun des correctifs ci-dessous.

Le tableau de priorités : quelle erreur corriger en premier

Les onze points ne pèsent pas le même poids. Ce tableau classe les erreurs par impact business pour décider quoi traiter en premier.

1. La rétention des données est restée à 2 mois

Symptôme. Vos explorations ne remontent pas au-delà de huit semaines. Toute analyse de cohorte, de saisonnalité ou de comparaison annuelle se heurte à un mur invisible. C’est l’erreur la plus répandue, car le réglage par défaut piège tout le monde.

Où vérifier. Admin → Paramètres des données → Conservation des données.

Correctif. Passez la conservation des données sur les événements utilisateur de 2 mois à 14 mois, puis enregistrez. Le changement n’est pas rétroactif : les données déjà supprimées sont perdues, d’où l’urgence de corriger ce point dès le premier jour. Notez que ce réglage n’affecte que les explorations ; les rapports standard agrégés restent disponibles plus longtemps.

2. Le trafic interne n’est pas filtré

Symptôme. Vos sessions sont gonflées par votre propre équipe, vos développeurs et vos prestataires. Le taux de conversion paraît faible parce que des dizaines de visites internes ne convertiront jamais, et vos pages de recette polluent les rapports.

Où vérifier. Admin → Flux de données → votre flux web → Configurer les paramètres de la balise → Définir le trafic interne. Puis Admin → Paramètres des données → Filtres de données.

Correctif. Définissez d’abord une règle de trafic interne basée sur vos adresses IP (le paramètre traffic_type prend la valeur internal), sans oublier celles de vos agences et consultants. Créez ensuite le filtre de données correspondant. Point capital : un filtre nouvellement créé est en mode « Test », pas « Actif ». Tant qu’il n’est pas passé en Actif, il n’exclut rien réellement. Pensez aussi à activer le filtre « Trafic des développeurs », qui exclut les hits émis en prévisualisation GTM. Vérifiez l’état des deux filtres, c’est l’oubli classique qui annule tout le travail.

3. Les key events ne reflètent pas vos vrais objectifs

Symptôme. Vos « conversions » comptent des page_view, des scroll ou des clics sans valeur, tandis que vos vrais résultats business (devis, achats, prises de rendez-vous) n’apparaissent pas. Vos décisions reposent alors sur des chiffres qui ne mesurent rien d’utile.

Où vérifier. Admin → Événements (ou Événements clés) → colonne « Marquer comme key event ».

Correctif. Faites le tri. Ne gardez comme key events que les actions à valeur réelle pour l’entreprise. Gardez en tête que chaque key event alimente le taux de key events (l’ancien taux de conversion) et les rapports Publicité : un event marqué à tort fausse ces deux mesures. Désactivez les events de simple navigation marqués par habitude ou par défaut. Un compte sain compte en général une poignée de key events, pas vingt. Moins, mais justes.

4. Un event existe mais n’est pas marqué comme key event

Symptôme. Vous voyez bien votre event generate_lead dans la liste des événements, mais le rapport des key events affiche zéro. La donnée est collectée, simplement elle n’est jamais comptée comme conversion.

Où vérifier. Admin → Événements → l’interrupteur « Marquer comme key event » en face de l’event concerné.

Correctif. Activez l’interrupteur sur le bon event. Si l’event n’apparaît pas encore dans la liste (il faut qu’il se soit déclenché au moins une fois), créez-le manuellement ou déclenchez-le en test, puis vérifiez en DebugView qu’il remonte avant de l’activer. Attendez ensuite quelques heures : la prise en compte n’est pas instantanée.

5. Vos conversions sont comptées en double

Symptôme. Votre nombre de conversions dépasse la réalité. Un même lead est compté deux fois parce qu’un event form_submit et un event personnalisé lead se déclenchent ensemble, ou parce qu’une plateforme e-commerce tire l’event d’achat à chaque rechargement de la page de confirmation. Votre ROAS paraît meilleur qu’il ne l’est.

Où vérifier. Admin → Événements pour repérer les paires redondantes, et DebugView pour observer un parcours réel de bout en bout.

Correctif. Ne gardez qu’un seul event par conversion réelle. Pour les achats, appuyez-vous sur le transaction_id : GA4 déduplique les transactions qui partagent le même identifiant, à condition qu’il soit transmis. La cause racine se loge souvent dans la couche de collecte ; pour l’attaquer en amont, voyez la déduplication détaillée dans notre guide sur les erreurs de dataLayer.

6. Vos events ne suivent pas le nommage standard

Symptôme. Vos rapports e-commerce natifs restent vides alors que vous envoyez bien les données. La cause : un nommage maison comme addToCart ou ValidationPanier au lieu des noms attendus par GA4. L’outil ne reconnaît pas vos events, donc il ne les branche pas sur ses rapports prêts à l’emploi.

Où vérifier. Admin → Événements, et DebugView pour lire les noms exacts qui arrivent.

Correctif. Adoptez le snake_case et les noms d’events recommandés par Google (add_to_cart, begin_checkout, purchase, generate_lead). Aligner le nommage débloque les rapports natifs sans aucun autre réglage. Pour le détail des conventions de nommage à la source, là encore notre article sur la collecte fait référence.

7. Vos paramètres personnalisés ne sont pas enregistrés en custom definitions

Symptôme. Vous envoyez un paramètre utile (par exemple methode_paiement ou categorie_article), il est bien présent dans le flux, mais impossible de le retrouver comme dimension dans vos rapports ou explorations. La donnée existe, elle est juste invisible côté analyse.

Où vérifier. Admin → Définitions personnalisées → Dimensions personnalisées (et Métriques personnalisées).

Correctif. Enregistrez chaque paramètre que vous voulez exploiter, en veillant à ce que le nom de la dimension corresponde exactement à la clé envoyée dans le hit. Attention au quota (le nombre de définitions personnalisées est limité par propriété) : n’enregistrez que ce qui sert vraiment à l’analyse, et nettoyez les définitions abandonnées. La prise en compte démarre à l’enregistrement, donc les données antérieures ne seront pas rétro-remplies.

8. Le cross-domain et les exclusions de référents sont mal réglés

Symptôme. Un seul parcours utilisateur se découpe en plusieurs sessions dès qu’il franchit un sous-domaine ou un domaine de paiement externe. Vous voyez votre propre site, ou votre prestataire de paiement, apparaître comme source de trafic : c’est de l’auto-référencement, et il vole le mérite de vos vraies sources.

Où vérifier. Admin → Flux de données → votre flux → Configurer les paramètres de la balise → Configurer vos domaines (cross-domain) et Liste des référents indésirables.

Correctif. Déclarez tous vos domaines et sous-domaines dans la configuration cross-domain pour qu’une session traverse l’ensemble sans se rompre. Inutile d’ajouter votre propre domaine à la liste des référents indésirables ; ajoutez-y en revanche vos prestataires de paiement. Quand un domaine de paiement est difficile à isoler (cas fréquent avec le 3D Secure), forcez plutôt le paramètre page_referrer sur la page de confirmation pour neutraliser le faux référent. Une fois propre, recoupez vos sources avec la dimension Source Group de GA4 pour une lecture consolidée de vos canaux.

9. Des données personnelles (PII) atterrissent dans vos rapports

Symptôme. Vous voyez des adresses e-mail, des numéros de téléphone ou des identifiants clients dans vos URLs de page ou vos paramètres d’event. Au-delà du bruit dans les rapports, c’est un vrai risque de conformité : GA4 interdit la collecte de données personnelles identifiantes.

Où vérifier. Rapports → Engagement → Pages et écrans (cherchez des e-mails ou des ?email= dans les chemins), et vos paramètres d’event personnalisés.

Correctif. Coupez le mal à la source : nettoyez les URLs avant collecte (suppression des paramètres sensibles) et n’envoyez jamais de PII dans un paramètre d’event. Activez le masquage des e-mails au niveau du flux web, prévu à cet effet. Pour le passé déjà collecté, utilisez les redactions et les filtres de données pour masquer ce qui peut l’être. Mieux vaut prévenir : passez en revue ce que vos formulaires et vos redirections placent dans l’URL.

10. Consent mode et Google Signals sont mal configurés

Symptôme. Vos conversions et vos audiences s’effondrent sans raison apparente, ou à l’inverse vous collectez malgré un refus de consentement. Le signal de consentement n’est pas transmis correctement, et GA4 modélise mal ce qu’il manque.

Où vérifier. Admin → Paramètres des données → Collecte des données (Google Signals), et la transmission du consentement côté balise ou CMP.

Correctif. Vérifiez que votre bannière transmet bien les états de consentement (analytics_storage, ad_storage) avant le déclenchement des balises, et que le mode par défaut est cohérent avec votre politique. Ce point évolue vite et mérite un traitement dédié : suivez notre guide complet sur le Consent Mode v2 dans GA4 pour valider la chaîne de bout en bout.

11. Une part du trafic tombe en « Unassigned » ou « (not set) »

Symptôme. Un bloc entier de votre trafic atterrit dans le canal « Unassigned », parfois en première ou deuxième source d’acquisition. En creusant, vous trouvez soit des UTM que GA4 ne sait pas ranger, soit une source/medium à (not set), c’est-à-dire une origine purement et simplement perdue. Dans les deux cas, vos arbitrages budgétaires reposent sur une part de trafic aveugle.

Où vérifier. Rapports → Acquisition → Acquisition de trafic : posez-vous sur la ligne « Unassigned » et ajoutez « Source / Medium » en dimension secondaire. Puis Admin → Affichage des données → Identité pour le reporting.

Correctif. Il y a deux causes, donc deux remèdes. D’abord les UTM mal taguées qui ne collent pas aux règles du groupe de canaux par défaut : alignez votre nomenclature (un utm_medium standard comme cpc, email, organic_social) et, au besoin, créez un groupe de canaux personnalisé pour ranger les sources égarées. Ensuite la source (not set), l’origine perdue, qui vient souvent de la combinaison Consent Mode plus identité de reporting « Combinée » (Blended) : GA4 modélise des sessions à partir de hits non consentis qui n’ont pas de source. Passez l’identité de reporting sur « Basée sur l’appareil » (Device-based), un changement rétroactif qui ne garde que les données réelles d’utilisateurs consentants. Vérifiez enfin deux causes techniques classiques : des hits Measurement Protocol non rattachés à une session existante, et des session_start manquants. Un délai d’expiration de session trop court peut aussi renvoyer une page de destination en (not set).

La checklist d’audit GA4 à copier

Gardez cette liste sous la main pour votre prochain audit, dans l’ordre de priorité :

1. Rétention des données passée à 14 mois.
2. Trafic interne défini ET filtres « interne » et « développeurs » en mode « Actif ».
3. Key events nettoyés : uniquement de vrais résultats business.
4. Chaque event de conversion bien marqué comme key event (vérifié en DebugView).
5. Aucune conversion en double (transaction_id transmis pour les achats).
6. Events en snake_case et noms recommandés pour les rapports natifs.
7. Paramètres utiles enregistrés en définitions personnalisées (quota surveillé).
8. Cross-domain déclaré et référents de paiement traités.
9. Aucune PII dans les URLs ni les paramètres d’event.
10. Consent mode transmis correctement et cohérent avec la bannière.
11. Trafic « Unassigned » maîtrisé : UTM propres, identité de reporting « Basée sur l’appareil ».

En résumé

Un audit GA4 ne sert pas à confirmer que l’outil tourne, il sert à savoir si vous pouvez décider sur la base de ses chiffres. Les erreurs les plus coûteuses sont silencieuses : un trafic interne qui gonfle les sessions, une rétention par défaut qui ampute vos analyses, des conversions comptées deux fois, ou un quart du trafic perdu en « Unassigned ». Reprenez la checklist dans l’ordre, du critique au secondaire, validez chaque correctif en DebugView et par comparaison avec une source externe, et vous transformerez une propriété qui « ment » en une source de décision fiable. Pour aller plus loin, reliez cet audit à votre installation initiale avec notre guide pour configurer GA4 from scratch.