Un audit GA4 utile vérifie que les données permettent de comprendre les parcours et de prendre les bonnes décisions. Je vous propose une méthode pour définir le périmètre, contrôler les fondations de la propriété et tester les scénarios qui révèlent les erreurs de mesure.
Que doit vérifier un audit GA4 ?
Un audit GA4 doit vérifier si les données permettent de prendre de bonnes décisions métier. Je ne le réduis pas à un contrôle technique : une collecte qui fonctionne ne suffit pas si les résultats sont mal définis, si le contexte manque ou si les rapports conduisent à une mauvaise lecture.
Je vérifie d’abord si la mesure restitue les parcours, les résultats et les contextes utiles aux décisions. Un parcours décrit les étapes suivies par une personne ; un résultat correspond à ce que l’activité cherche à obtenir. L’audit doit aussi faire apparaître les signaux manquants, les définitions incohérentes, les lacunes liées au consentement — l’autorisation de mesurer dans un contexte donné — et les risques de reporting, c’est-à-dire de présentation ou d’interprétation des données.
Formez-vous à Google Analytics !
Maîtriser Google Analytics est crucial pour comprendre votre audience, optimiser vos campagnes, améliorer l'expérience utilisateur et mesurer vos conversions... Gagnez du temps avec nos formations Google Analytics.
Pour éviter les diagnostics flous, je distingue quatre niveaux :
- La collecte : les données nécessaires sont-elles bien recueillies ?
- La configuration : les réglages et les définitions correspondent-ils aux besoins métier ?
- Le traitement : les données recueillies sont-elles préparées de façon cohérente avant leur lecture ?
- Le reporting : les résultats sont-ils présentés de manière compréhensible et utilisable pour décider ?
Ces niveaux sont liés, mais ils ne se confondent pas. Un problème visible dans un rapport peut venir d’une collecte incomplète, d’une définition incohérente ou d’un traitement inadéquat. Corriger seulement le rapport ne règle pas nécessairement la cause. J’ai déjà vu des équipes discuter longuement d’indicateurs dont le sens n’était pas partagé : l’audit sert aussi à révéler ce type de décalage.
Objectifs de l’audit :
- Vérifier que la mesure soutient les décisions métier.
- Contrôler la représentation des parcours, des résultats et de leur contexte.
- Repérer les signaux manquants, les incohérences et les lacunes de consentement.
- Identifier les risques liés à la lecture et à l’usage des rapports.
Comment cadrer l’audit avant de modifier GA4 ?
Je cadre l’audit à partir des besoins de mesure établis dans le chapitre précédent. Le périmètre découle de ces besoins : il couvre les parcours et les données nécessaires aux décisions métier, pas l’ensemble des réglages de GA4 par principe. Avant toute modification, je précise ce qui doit être mesuré, pourquoi et par qui.
Je définis ensuite les parcours prioritaires et les comportements attendus à chaque étape. Je fixe les critères d’acceptation : quels événements doivent être collectés, quelles informations doivent leur être associées et quels écarts sont tolérables. Je nomme aussi un responsable pour chaque validation. Sans ces éléments, on risque de corriger la configuration sans savoir si elle répond au besoin.
Je priorise les contrôles selon leur impact sur les décisions réelles. Un contrôle passe en premier s’il peut invalider une mesure utilisée pour décider. Les anomalies secondaires viennent ensuite. Cette hiérarchie évite de consacrer du temps à des réglages sans conséquence sur l’analyse ou l’action.
Avant d’intervenir, je conserve un état de référence : configuration concernée, mesures observées et preuves disponibles. Chaque changement doit rester progressif, documenté et testé. Je vérifie d’abord son effet dans un périmètre contrôlé, puis je confirme le résultat avant de poursuivre.
Pour chaque changement, je consigne trois éléments :
- Le résultat attendu, formulé de manière vérifiable.
- Les éléments de preuve qui permettront de confirmer ce résultat.
- La procédure de retour arrière, pour rétablir l’état précédent si le test échoue ou produit un effet inattendu.
Cette discipline rend l’audit utile et limite les risques. On sait ce qui a changé, pourquoi, et si la mesure obtenue permet réellement de répondre au besoin initial.
Comment contrôler la propriété et les flux de données ?
Je contrôle la propriété et les flux à partir du cadrage métier défini précédemment : les décisions à éclairer, les indicateurs concernés et les périmètres de mesure. Une configuration correcte n’a de valeur que si les données arrivent au bon endroit, avec les bons paramètres et des responsabilités claires.
Je vérifie quatre points liés entre eux. Pour chaque changement, je conserve l’état initial et les éléments qui permettent de le justifier.
- Compte, propriété, flux et paramètres régionaux. Je confirme le compte et la propriété audités, les flux utilisés, le fuseau horaire et la devise. Le résultat attendu est une configuration cohérente avec le périmètre métier et les rapports attendus. Je garde comme preuves les paramètres constatés et leur validation par le responsable métier. Avant toute modification, je note les valeurs initiales ; en cas d’effet inattendu, je rétablis la dernière configuration validée et je vérifie que les rapports correspondent de nouveau au besoin.
- Filtres, références, interdomaines et conservation. J’examine les filtres de trafic interne, les références indésirables, le suivi interdomaines et la durée de conservation des données. Je vérifie leurs dépendances avec les domaines, les environnements et les usages définis dans le cadrage. Une exclusion peut fausser les résultats si elle est appliquée au mauvais périmètre. Je documente les règles en place et les raisons de leur maintien ou de leur modification.
- Environnements, domaines et destination des données. Je m’assure que chaque environnement et chaque domaine envoie les données à la propriété prévue. Je trace les valeurs depuis leur source jusqu’à leur destination, puis je vérifie la minimisation des données et le respect des exigences de consentement. Le contrôle doit confirmer que seules les données nécessaires sont transmises et que leur collecte respecte les choix de consentement applicables.
- Responsabilités et changements. Je confirme les propriétaires, les niveaux d’accès et le processus de changement. Les preuves sont la liste des accès et la trace des validations. Chaque modification doit avoir un responsable, un motif lié au besoin métier et une procédure de retour arrière connue.
Ces contrôles se répondent. Le fuseau horaire et la devise influencent la lecture des résultats ; les filtres, les domaines et le consentement influencent les données disponibles ; les accès déterminent qui peut modifier ces réglages. Sans cette cohérence, les indicateurs ne répondent plus de façon fiable aux décisions ciblées dans le cadrage.
Quels tests révèlent les erreurs de mesure ?
Les erreurs de mesure se révèlent en comparant, pour chaque parcours, le comportement réel du site ou de l’application avec les événements attendus dans GA4. Je repars des fondations vérifiées au chapitre précédent : objectifs métier, événements, paramètres, consentement et responsabilités. Un test n’est utile que si son résultat attendu, sa preuve et son responsable sont définis avant l’exécution.
La matrice doit couvrir des cas positifs, négatifs et limites. Pour chaque scénario, consignez le résultat observé, une preuve exploitable et le rôle chargé de l’analyse : équipe produit, développement, conformité ou analyste.
- Positif : Une action aboutie, comme une inscription, doit produire l’événement prévu avec les paramètres attendus. L’équipe produit valide le comportement, l’analyste la mesure.
- Négatif : Un parcours d’échec ou une annulation ne doit pas être compté comme une conversion réussie. Le responsable métier confirme la règle, le développeur vérifie le déclenchement.
- Limite : Testez un chargement retardé, un retour utilisateur, le mobile et une modification du consentement en cours de parcours. Ces situations révèlent souvent des événements absents, répétés ou envoyés au mauvais moment.
Pour localiser l’écart, distinguez quatre niveaux. Un problème de collecte signifie que l’événement ou ses paramètres ne sont pas transmis comme prévu. Un problème de configuration concerne leur définition dans GA4. Un problème de traitement apparaît entre les données reçues et celles disponibles dans les rapports. Un problème de reporting vient plutôt des filtres, dimensions, périodes ou règles de lecture utilisés. La preuve peut être une capture du parcours, un enregistrement du résultat attendu, une trace disponible côté site ou application, ou un rapport daté. Ne concluez pas à une erreur GA4 avant d’avoir vérifié à quel niveau l’écart apparaît.
Cette synthèse relie chaque test au comportement attendu et à la personne qui peut confirmer ou corriger le résultat.
| Cas à tester | Résultat attendu | Preuve à conserver |
| Action aboutie, par exemple une inscription | Événement attendu, paramètres cohérents et conversion comptabilisée une seule fois. Responsable : produit et analyste. | Parcours exécuté, paramètres attendus et rapport consulté avec sa période. |
| Parcours d’échec | Aucune conversion de réussite. Responsable : produit et développement. | Étape d’échec observée et résultat de mesure associé. |
| Annulation avant la fin | Pas d’événement de réussite après l’annulation. Responsable : produit. | Capture du parcours annulé et mesure observée. |
| Chargement retardé, puis retour utilisateur | Événement transmis au bon moment, sans absence ni doublon. Responsable : développement et analyste. | Étapes horodatées et résultat disponible côté site ou application et dans le rapport. |
| Parcours sur mobile | Mêmes règles de mesure que le parcours équivalent, selon le comportement défini. Responsable : produit et développement. | Appareil, parcours exécuté et résultat observé. |
| Modification du consentement | Mesure conforme aux règles de consentement définies. Responsable : conformité et développement. | État du consentement avant et après modification, et mesures observées. |
Votre mesure permet-elle vraiment de décider ?
Un audit GA4 utile part des décisions métier, pas d’une liste de réglages à cocher. Il précise les parcours prioritaires, les comportements attendus, le périmètre et les responsables. Il vérifie ensuite la propriété, les flux, les dépendances, les accès, le consentement et la destination des données. Enfin, une matrice de tests couvre les cas positifs, négatifs et limites, y compris sur mobile et après un changement de consentement. Chaque modification doit rester progressive, documentée, testée et réversible, avec des preuves et un état de référence conservés. Vous obtenez ainsi une mesure plus fiable pour comprendre vos parcours et prendre des décisions métier mieux étayées.
FAQ
- Quel est l’objectif principal d’un audit GA4 ?
Vérifier que la mesure restitue les parcours, les résultats et les contextes utiles aux décisions métier, et repérer les lacunes qui fragilisent l’analyse. - Que faut-il définir avant de commencer l’audit ?
Les parcours prioritaires, les comportements attendus, le périmètre, les critères d’acceptation et les responsables. - Quels éléments contrôler dans une propriété GA4 ?
Le compte, la propriété, les flux, le fuseau horaire, la devise, les filtres, les références indésirables, le suivi interdomaines et la conservation des données. - Quels scénarios faut-il inclure dans les tests ?
Les cas positifs, négatifs et limites, ainsi que les parcours d’échec, d’annulation, de chargement retardé, de retour utilisateur, sur mobile et après modification du consentement. - Comment sécuriser les changements après l’audit ?
Procéder par changements progressifs et réversibles, les documenter et les tester, puis conserver un état de référence, les preuves et une procédure de retour arrière.
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, intégration de l’IA, SEO et GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des entreprises comme 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.
⭐ 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.