Un audit GA4 fiable commence par une question simple : les données décrivent-elles vraiment les parcours et les résultats utiles à vos décisions métier ? Je vous propose une méthode pour vérifier les flux, tester les cas réels, repérer les risques et corriger sans fragiliser la mesure.
Comment cadrer l’audit GA4 ?
Je cadre l’audit GA4 avant toute vérification : sans périmètre, parcours prioritaires et critères d’acceptation, on risque de relever des anomalies sans savoir lesquelles comptent vraiment.
Je précise d’abord ce qui est inclus : les sites ou applications concernés, la période à examiner, les événements suivis et les conversions attendues. Je sélectionne ensuite les parcours qui ont un enjeu réel pour l’activité, par exemple une demande de devis ou un achat. Pour chacun, je note les étapes attendues et les résultats qui doivent être mesurés.
Comment Power Query améliore-t-il Report Builder ?
Je réunis les parties prenantes qui peuvent confirmer ces choix : marketing, équipe produit, responsables du site ou de l’application, et personnes chargées de l’implémentation. Les critères d’acceptation doivent être vérifiables. Par exemple : « Une demande valide déclenche l’événement prévu, avec les informations nécessaires, une seule fois. » On fixe aussi les cas qui ne doivent pas être mesurés et les limites acceptables, comme un parcours interrompu avant sa validation.
Comme on dit à Brive, un bon plan de marquage vaut mieux qu’un bon reporting ! Si besoin, consultez moi - faites appel à un super consultant en tracking client et server side.
Avant les tests, je prépare une matrice. Elle couvre trois types de cas :
- Positif : le parcours se déroule comme prévu et la mesure attendue est présente.
- Négatif : l’action ne doit pas produire la mesure attendue, par exemple si le formulaire n’est pas envoyé.
- Limite : le parcours s’arrête à une étape intermédiaire ou une information attendue manque.
Pour chaque test, je consigne la preuve observée, le constat, la décision prise, le responsable de la correction et le résultat du nouveau test. Une capture ou une trace exploitable doit permettre de comprendre ce qui a été vérifié, pas seulement d’affirmer que le test est réussi.
Quelle alternative à Sisense pour l’analytics embarquée ?
Quand une anomalie vient d’une règle de mesure partagée, je corrige cette règle à la source. Une correction isolée dans un rapport peut masquer le symptôme sans réparer les données utilisées ailleurs. J’ai déjà vu ce décalage compliquer les comparaisons entre équipes : le rapport semblait cohérent, mais la mesure commune restait fausse.
Quelles fondations GA4 vérifier ?
Je vérifie d’abord que le compte, la propriété et les flux GA4 correspondent bien à l’organisation, aux sites et aux applications concernés. Un mauvais fuseau horaire ou une devise incorrecte fausse les rapports, parfois sans que ça se voie immédiatement.
Pour chaque propriété, je contrôle son nom, son identifiant, ses accès et ses paramètres. Je vérifie ensuite les flux Web et application, leurs identifiants de mesure et les domaines associés. Chaque domaine et chaque environnement — production, préproduction ou test — doit envoyer ses données à la propriété prévue. Je le confirme en comparant l’identifiant configuré sur le site à celui du flux, puis en observant les événements reçus. Un environnement de test qui alimente les rapports de production, c’est un problème classique.
FireDucks accélère-t-il pandas sur de gros datasets ?
Je passe aussi en revue les réglages qui modifient la collecte ou l’interprétation des visites :
- Le fuseau horaire et la devise de la propriété, cohérents avec le reporting attendu.
- Le trafic interne, filtré à partir de règles et d’adresses IP documentées, sans exclure par erreur des visiteurs réels.
- Les référents indésirables, c’est-à-dire les domaines qui peuvent attribuer à tort une nouvelle source de visite, ajoutés seulement s’ils perturbent réellement l’attribution.
- La configuration interdomaines, qui permet de conserver la même session lorsqu’une personne navigue entre plusieurs domaines de l’entreprise.
- La durée de conservation des données, réglée selon les besoins d’analyse et les règles applicables.
Pour les événements importants, je trace chaque valeur de sa source jusqu’à sa destination dans GA4. Je compare le nom, le type de donnée, la portée — événement ou utilisateur — et le moment d’envoi. Je vérifie aussi les identifiants, la devise, l’état du consentement et les valeurs vides ou incohérentes. Le consentement doit respecter les exigences applicables ; les données collectées doivent être minimisées et ne pas inclure d’informations personnelles inutiles.
Enfin, je documente chaque changement envisagé : résultat attendu, responsable, dépendances, procédure de retour arrière et référence datée, comme une capture ou un ticket. Sans cette trace, il devient difficile de comprendre pourquoi les chiffres ont changé.
Comment tester les parcours et les accès ?
Quel mode de stockage Power BI pour Databricks ?
Pour tester les parcours et les accès, je vérifie qui peut intervenir, puis je confronte des situations réelles — y compris les cas qui dévient du parcours idéal — au comportement attendu. Chaque écart doit être documenté avec une preuve.
Je commence par la gouvernance. La propriété des accès doit être claire : une personne ou une équipe identifiée en est responsable. Les niveaux d’autorisation doivent correspondre aux besoins de chacun, sans droits excessifs ni comptes dont personne ne connaît le propriétaire. Je vérifie aussi qu’un processus de changement est documenté : qui demande une modification, qui l’approuve et comment elle est tracée. Sans cette base, un audit peut constater un problème sans permettre d’en comprendre l’origine.
Je teste ensuite les parcours dans des conditions variées. Pour chaque cas, je compare le comportement observé au comportement attendu et je conserve une preuve datée, par exemple une capture d’écran et une note sur les étapes suivies. Les écarts comptent autant que les résultats conformes.
- Répétitions et actualisations : Je répète une action et je recharge la page. Je vérifie si le comportement reste conforme ou si une étape est répétée, perdue ou modifiée.
- Échecs, annulations et erreurs de validation : Je provoque ces situations lorsqu’elles sont accessibles dans le parcours. Je compare la réponse observée à celle qui est attendue et je conserve la preuve de chaque résultat.
- Chargements différés : J’attends que les éléments apparaissent, puis je vérifie si le parcours se comporte comme prévu. Je note tout délai ou élément manquant.
- Retours d’utilisateurs et usage mobile : Je teste un retour sur le site après une première visite et je répète les vérifications sur mobile. Dans les deux cas, je compare le résultat au comportement attendu et garde une trace.
- Changements de consentement : Je vérifie le parcours avant et après une modification du choix de consentement. Je compare les comportements observés aux attentes définies et conserve les preuves.
Un parcours qui fonctionne une fois ne suffit pas. Les répétitions, les interruptions et les changements de contexte révèlent souvent les défauts que le scénario idéal masque.
Comment prioriser les corrections après l’audit ?
Je priorise les corrections selon le niveau où l’erreur apparaît, puis selon son effet possible sur la lecture des parcours ou des résultats métier. Une anomalie visible dans un rapport ne vient pas forcément du rapport : corriger le mauvais niveau peut masquer le problème sans le résoudre.
Je distingue quatre niveaux. La collecte concerne les données envoyées à GA4 : événement absent, doublon ou paramètre manquant. Elle peut fausser la lecture d’un parcours ou le décompte d’une conversion. La configuration concerne les règles appliquées dans la propriété, comme les événements clés, les filtres ou le modèle d’attribution. Elle peut modifier la façon dont les résultats sont classés ou attribués. Le traitement correspond à la manière dont GA4 transforme et rend disponibles les données, notamment avec les seuils ou certaines modélisations. Il peut limiter les comparaisons entre rapports. Le reporting concerne les explorations, les filtres et les tableaux de bord : une définition incohérente peut faire croire que deux équipes mesurent la même chose alors qu’elles ne le font pas.
Je corrige d’abord les erreurs qui compromettent la fiabilité des données à la source, puis les règles communes, et enfin les vues de reporting. J’ai déjà vu des équipes retoucher un tableau de bord alors que l’événement envoyé par le site était mal défini. Le résultat semblait cohérent, mais la mesure restait fragile.
Pour chaque correction, je garde une intervention limitée et réversible. Je précise le responsable, le résultat attendu et les critères d’acceptation : par exemple, l’événement doit apparaître une fois, avec les paramètres attendus, dans un test contrôlé. Je conserve les preuves de référence avant changement — capture, export ou cas de test — puis je documente le nouveau test. Certaines corrections ne réparent pas les données historiques ; je vérifie donc les rapports après déploiement, sur la période concernée, sans supposer que l’écart disparaîtra partout.
Je privilégie les règles de mesure partagées : même définition d’un événement clé, mêmes conventions de nommage, mêmes filtres documentés. Ça évite de corriger chaque rapport séparément.
| Niveau du problème | Vérification | Trace à conserver |
| Collecte | Tester les événements, doublons et paramètres transmis. | Résultat du test et capture de l’événement reçu. |
| Configuration | Contrôler les réglages de la propriété et leurs effets. | État avant/après et responsable du changement. |
| Traitement | Vérifier les seuils, modélisations et limites de comparaison. | Rapports concernés et période observée. |
| Reporting | Comparer filtres, définitions et calculs utilisés. | Requête ou configuration du rapport validée. |
Votre mesure GA4 est-elle prête à guider vos décisions ?
Un audit GA4 utile ne consiste pas à vérifier quelques rapports isolément. Il part des décisions métier et des parcours à mesurer, puis contrôle les propriétés, les flux, les paramètres, les accès et les situations moins évidentes comme les échecs ou les changements de consentement. En séparant les problèmes de collecte, de configuration, de traitement et de reporting, vous évitez les corrections au mauvais endroit. Chaque changement doit rester limité, documenté et testable, avec une référence avant intervention et un responsable identifié. Vous obtenez ainsi une mesure plus cohérente et des rapports plus fiables pour décider, sans perdre la trace de ce qui a été modifié.
FAQ
- Que faut-il vérifier en priorité pendant un audit GA4 ?
Commencez par les parcours prioritaires et les comportements attendus. Vérifiez ensuite les propriétés, les flux, les paramètres de mesure et la cohérence des données dans les rapports. - Pourquoi tester les cas négatifs et les parcours adjacents ?
Les répétitions, échecs, annulations, erreurs de validation, chargements différés, usages mobiles et changements de consentement peuvent révéler des écarts que le parcours idéal ne montre pas. - Quels réglages de propriété faut-il contrôler ?
Contrôlez notamment le fuseau horaire, la devise, le trafic interne, les référents indésirables, la configuration interdomaines et la durée de conservation. - Comment documenter une correction GA4 ?
Notez le résultat attendu, le responsable, les dépendances, les critères d’acceptation, les preuves de référence et la possibilité de revenir en arrière. Conservez aussi le résultat du nouveau test. - Comment éviter de corriger un problème au mauvais endroit ?
Classez d’abord le constat selon son niveau : collecte, configuration, traitement ou reporting. Cette distinction aide à cibler la correction et à éviter de masquer un problème de mesure par un ajustement isolé dans un rapport.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation no/low code et IA en entreprise. Je dirige webAnalyste et Formations Analytics. J’accompagne notamment Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor. Je suis disponible pour aider votre entreprise : contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.