Un rapport GA4 peut afficher des courbes cohérentes tout en reposant sur une collecte incomplète ou mal configurée. Avant d’interpréter une variation de trafic, il faut vérifier les paramètres de la propriété et les événements réellement envoyés. Voici six erreurs à contrôler, avec une méthode de vérification pour chacune.
1. Conserver la durée de rétention des données à deux mois
Par défaut, GA4 fixe la conservation des données utilisateur et événement à deux mois pour les propriétés standard. Les rapports agrégés restent accessibles au-delà de cette fenêtre, mais les explorations (entonnoirs, parcours, segments personnalisés) ne peuvent plus interroger les événements individuels antérieurs.
Toute analyse de cohorte ou de parcours d’achat portant sur un trimestre complet devient alors incomplète. Les lignes disparaissent sans avertissement, et la comparaison mois par mois dans une exploration montre des baisses de volume qui ne reflètent pas une baisse réelle de trafic. Faire appel à un consultant Google Analytics permet de repérer ce type de biais avant qu’il n’affecte les décisions budgétaires.
Le correctif tient en un réglage : dans Administration, puis Paramètres de données, puis Conservation des données, passez la rétention à quatorze mois. L’augmentation de la durée concerne les données encore conservées, mais ne restaure pas celles qui ont déjà été supprimées. Plus tôt le réglage est modifié, plus la profondeur historique des explorations sera exploitable.
2. Oublier la mesure entre plusieurs domaines
Lorsqu’un parcours passe du site principal à une boutique ou à un espace de réservation sur un autre domaine, une configuration incomplète peut séparer l’activité d’une même personne. Le problème affecte la continuité du parcours et peut perturber l’attribution des résultats aux canaux d’acquisition.
Dans Administration, ouvrez le flux de données Web, puis les paramètres de la balise et « Configurer vos domaines ». Vérifiez que les domaines du parcours sont renseignés et utilisent le même identifiant de balise du même flux Web. Le simple fait d’exclure une référence indésirable ne remplace pas cette configuration.
Testez ensuite un passage réel entre les domaines via un lien ou un formulaire. Vérifiez la présence du paramètre _gl sur la destination et contrôlez que les redirections ne le suppriment pas. La page doit continuer de fonctionner normalement. Si le paramètre manque, comparez les domaines déclarés aux destinations effectivement utilisées.
3. Envoyer le même événement plusieurs fois
Un doublon peut venir d’une balise installée dans le code du site et dans Google Tag Manager, de deux conteneurs, ou d’un événement envoyé à la fois automatiquement et manuellement. Les pages vues ou les actions concernées sont alors surcomptées. Cela ne signifie pas que toutes les métriques, notamment les sessions, sont automatiquement multipliées dans les mêmes proportions.
Ouvrez Tag Assistant ou le mode Aperçu de Tag Manager, puis effectuez une seule navigation ou une seule action de test. Comparez les balises déclenchées et les événements reçus dans DebugView. Pour un chargement simple, recherchez notamment plusieurs envois page_view vers le même identifiant de mesure.
Identifiez l’origine de chaque envoi avant de désactiver une balise. Gardez une méthode de collecte cohérente, puis refaites exactement le même test. Sur un site à navigation dynamique, distinguez une véritable nouvelle vue de page d’un envoi répété involontairement.
4. Ignorer le filtrage du trafic interne
Chaque visite d’un membre de l’équipe, d’un prestataire ou d’un développeur qui teste le site est comptabilisée comme une session utilisateur classique. Sur les sites à faible volume, ces visites internes peuvent représenter une part significative du trafic total et fausser le taux d’engagement, le temps moyen sur page et les chemins de conversion.
GA4 propose un mécanisme en deux étapes qui reste souvent à moitié configuré :
- Créer une règle de trafic interne dans Administration, puis Flux de données, puis Paramètres de la balise, en renseignant les adresses IP à exclure
- Activer le filtre associé dans Administration, puis Paramètres de données, puis Filtres de données, en passant le filtre de l’état « Test » à l’état « Actif »
- Vérifier dans le rapport Temps réel que les visites depuis les IP filtrées ne remontent plus
Le piège : créer la règle sans activer le filtre ne bloque rien. GA4 laisse le filtre en mode test par défaut, ce qui signifie que le trafic interne continue d’alimenter tous les rapports.
5. Mal définir les événements clés
Un événement collecté n’est pas nécessairement un indicateur de réussite pour l’entreprise. À l’inverse, une action importante peut manquer ou être marquée comme événement clé alors qu’elle se déclenche sur une interaction sans valeur réelle. Les rapports donnent alors une image trompeuse des résultats commerciaux.
Définissez les actions qui comptent réellement, comme l’envoi confirmé d’un formulaire ou une transaction aboutie. Dans l’administration des événements, vérifiez leur collecte et leur désignation comme événements clés. Ne considérez pas qu’un clic sur un bouton prouve à lui seul qu’une demande a été enregistrée.
Effectuez chaque parcours de test jusqu’au bout dans DebugView. Contrôlez le nom, les paramètres utiles et le nombre de déclenchements, puis vérifiez le comportement dans les rapports après traitement des données. Comparez si possible l’action mesurée avec sa confirmation dans votre outil métier, sans attendre une égalité parfaite entre des systèmes aux règles de mesure différentes.
6. Transmettre un état de consentement incorrect
Le mode Consentement adapte le comportement des balises aux choix de l’utilisateur. Il ne recueille pas ce choix à la place de la bannière. Une mauvaise articulation entre la solution de consentement et les balises peut rendre la collecte incohérente ou contraire à la configuration prévue.
Il faut distinguer les deux implémentations. En mode de base, les balises Google sont bloquées avant le consentement. En mode avancé, elles peuvent envoyer des mesures sans cookie lorsque le consentement est refusé. La présence d’une requête avant acceptation ne suffit donc pas, à elle seule, à diagnostiquer une erreur.
Vérifiez dans Tag Assistant que l’état de consentement par défaut est défini avant les commandes de mesure, puis qu’il est mis à jour lorsque le visiteur fait son choix. Testez séparément un refus, une acceptation et un changement de préférence. Contrôlez notamment analytics_storage et le comportement réel des balises. Le choix entre les modes de base et avancé doit correspondre au cadre de conformité retenu pour le site.
Quand les chiffres ne correspondent plus à l’activité réelle, un consultant Google Analytics peut auditer la propriété et la fiabiliser.
