Pour obtenir des rapports GA4 utiles, il faut relier chaque dimension ou métrique à une décision métier, puis vérifier sa collecte, sa portée et sa cardinalité. Je détaille comment cadrer le besoin, contrôler les paramètres transmis et éviter les données qui brouillent vos analyses.
Quel besoin métier voulez-vous mesurer ?
Je pars de la décision métier que vous voulez éclairer, pas d’une dimension ou d’une métrique à créer. Une dimension décrit une caractéristique, comme le type de contenu consulté. Une métrique mesure une valeur, comme le nombre de demandes envoyées. Si aucune décision ne dépend de cette donnée, elle n’a probablement pas sa place dans votre plan de mesure.
Je formule d’abord la question métier en termes concrets : faut-il comparer des parcours, identifier les contenus qui génèrent des demandes ou comprendre où les utilisateurs abandonnent ? Je distingue ensuite trois éléments qui sont souvent mélangés :
- La question métier : quelle décision doit devenir plus facile à prendre ?
- Les données minimales : quels événements et quelles informations sont indispensables pour répondre à cette question ?
- Les usages prévus : quels rapports ou quelles audiences exploiteront ces données ?
Avant de créer quoi que ce soit, je rassemble une spécification de mesure validée par les personnes concernées. Elle évite qu’une même donnée soit interprétée différemment selon les équipes. J’y consigne :
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.
- L’objectif approuvé et les événements concernés.
- Les paramètres attendus, c’est-à-dire les informations associées à ces événements.
- La portée de chaque donnée, les responsables et les dépendances avec d’autres équipes ou outils.
- Les variantes autorisées, par exemple les valeurs qui peuvent être utilisées sans créer d’ambiguïté.
Je relève aussi le comportement initial avant toute modification. Ça permet de comparer la situation de départ avec le résultat du test, et de repérer les écarts existants. Je limite ensuite le périmètre à un cas précis, sur lequel les équipes peuvent s’accorder. Un test reproductible décrit le parcours à suivre, les actions à effectuer et le résultat attendu. J’ai vu des équipes perdre du temps à débattre d’une donnée alors que personne ne pouvait refaire le parcours qui devait la produire. Une question métier claire, des données minimales et un test répétable rendent la mesure plus utile et plus facile à maintenir.
Quels paramètres faut-il enregistrer dans GA4 ?
J’enregistre dans GA4 uniquement les paramètres nécessaires à un rapport ou à une audience. Un paramètre décrit le contexte d’un événement, par exemple le type de contenu ou le mode de paiement. Avant d’ajouter une configuration, j’inventorie ceux qui sont déjà envoyés avec les événements importants.
Pour chaque événement, je vérifie le nom, les paramètres transmis et leur valeur réelle. Je compare ces éléments aux rapports ou audiences qui doivent les exploiter. Cette vérification évite de créer un doublon ou d’enregistrer une donnée inutile. Elle révèle aussi les paramètres absents, mal nommés ou renseignés de façon incohérente.
La traçabilité doit relier clairement trois éléments : l’action de l’utilisateur, la charge utile de l’événement envoyée à GA4, puis le rapport où la donnée est consultée. Par exemple, si un utilisateur valide un achat, je dois pouvoir retrouver l’événement correspondant, ses paramètres utiles — comme le montant ou la devise — et la façon dont ces valeurs apparaissent dans le rapport.
Avant toute modification, je conserve une référence datée de l’état initial : événements, paramètres, définitions et résultats observables. Je clarifie aussi la signification de chaque valeur. Un paramètre nommé « type » ne suffit pas : il faut préciser ce qu’il décrit, les valeurs possibles et les règles de remplissage.
Je limite ensuite le changement à une seule couche logique à la fois, par exemple la collecte ou la configuration GA4. Sinon, en cas d’écart, il devient difficile d’identifier la cause. Je vérifie les dépendances en amont, comme le code ou le gestionnaire de balises, et en aval, comme les rapports, les audiences et les exports.
Pour rendre le changement vérifiable, je consigne :
- Les preuves observables : événement reçu, paramètres et valeurs attendus, résultat dans le rapport.
- Les responsables : personnes chargées de la modification, de la validation et du suivi.
- Le retour arrière : état de référence, procédure de restauration et conditions de déclenchement.
Les événements recommandés par Google ne sont pas des modèles à appliquer mécaniquement. Je les utilise seulement si leur signification correspond réellement à l’action mesurée. Un nom standard mal employé rend les données moins fiables, pas plus utiles.
Comment choisir la portée d’une dimension ?
Je choisis une portée événementielle quand la valeur décrit une interaction précise et peut changer d’un événement à l’autre. Je choisis une portée utilisateur quand elle décrit une caractéristique de la personne, appelée à rester valable au-delà d’une interaction. La question à poser est simple : à quel moment cette valeur évolue-t-elle réellement ?
Les deux portées ne racontent pas la même chose. Une dimension événementielle associe une valeur à un événement donné. Une dimension utilisateur représente une information rattachée à l’utilisateur, même si elle peut évoluer dans le temps. Je ne choisis donc pas la portée d’après le nom du champ ou l’écran où il apparaît, mais d’après le sens et l’évolution de sa valeur dans les données.
Avant de valider une dimension ou une métrique, je contrôle plusieurs points :
- Le nom. Il doit décrire clairement la donnée et rester cohérent avec les noms employés dans les événements et les rapports.
- Le type. Je vérifie que la valeur est transmise sous la forme attendue : texte, nombre, identifiant ou montant. Un nombre envoyé comme texte peut compliquer son analyse.
- La temporalité et les identifiants. Je vérifie quand la valeur est mise à jour, à quel événement ou utilisateur elle se rattache, et si l’identifiant est stable et utilisé de façon cohérente.
- La devise. Pour un montant, je contrôle que la valeur et la devise associée sont présentes et cohérentes. Un montant sans contexte monétaire peut être ambigu.
- Le consentement et les valeurs vides. Je vérifie ce qui est transmis selon l’état du consentement, et si une valeur vide signifie « inconnue », « absente » ou autre chose. Je ne confonds pas une valeur vide avec zéro.
Je vérifie aussi la provenance de chaque valeur. Elle doit venir de la source de référence, comme la donnée métier ou l’information fournie à l’événement. Si elle manque à cette source, je ne la reconstruis pas à partir d’un libellé affiché, d’un texte de bouton ou d’un élément de présentation : ces éléments peuvent changer sans refléter la donnée réelle.
L’inspection visuelle ne suffit pas. Une valeur correcte à l’écran ne prouve pas qu’elle est correctement envoyée à GA4. Je trace les requêtes ou les enregistrements transmis pour contrôler les noms, les valeurs, les identifiants et leur association à la bonne portée.
Comment limiter la cardinalité et fiabiliser les rapports ?
Je limite la cardinalité en écartant des dimensions les identifiants uniques et les valeurs qui changent presque à chaque événement. Ces champs distinguent trop de cas individuels pour faire ressortir une tendance utile. Ils compliquent la lecture des rapports et peuvent exposer des informations qu’il vaut mieux ne pas transmettre.
Une dimension mérite d’être conservée si elle répond à une question concrète : comparer des catégories, repérer une évolution ou créer une audience exploitable. Je privilégie des valeurs stables, compréhensibles et regroupables, comme un type de contenu ou une catégorie de produit. Une valeur très détaillée n’est pas forcément plus utile. Sur un projet client, réduire les variantes d’un champ a souvent rendu les analyses plus lisibles, sans perdre l’information nécessaire à la décision.
Avant d’ajouter un champ, je vérifie qu’il sert réellement aux rapports ou aux audiences. J’écarte les données inutilisées, les identifiants directs et les informations susceptibles d’identifier une personne. Je regarde aussi si une valeur peut révéler des données sensibles, même indirectement. Le consentement doit être respecté dans la collecte et la transmission ; un champ ne devient pas acceptable simplement parce qu’il est techniquement disponible.
Pour fiabiliser le résultat, je change une seule chose à la fois. Je contrôle d’abord les données effectivement transmises, puis je vérifie que la dimension apparaît comme prévu dans le rapport et que ses valeurs sont interprétables. Je teste aussi le comportement selon le consentement applicable. Enfin, je documente la raison du choix, les risques examinés et le résultat des vérifications. Cette trace évite qu’un champ soit réintroduit plus tard sans contexte.
- À retenir : Une dimension doit apporter une lecture utile, pas seulement stocker davantage de détails.
| Étape | Vérification | Résultat attendu |
| Sélection | Utilité pour un rapport ou une audience | Dimension compréhensible et exploitable |
| Confidentialité | Identifiants, données inutiles et consentement | Transmission limitée et justifiée |
| Validation | Un changement à la fois, données et rapport | Résultat observé et documenté |
Vos dimensions GA4 répondent-elles à une vraie décision ?
Une dimension ou une métrique personnalisée n’a de valeur que si elle répond à une question métier et alimente un rapport ou une audience utile. J’ai détaillé le cadrage à prévoir, l’inventaire des paramètres existants, le choix de la portée et les contrôles de collecte à effectuer. La cardinalité, le consentement et la provenance des valeurs comptent autant que leur enregistrement dans GA4. Avancez par changements limités, vérifiez les données réellement transmises et gardez une trace des décisions, des responsables et du retour arrière. Vous réduirez les données inutiles et obtiendrez des rapports plus fiables pour décider.
FAQ
-
Quelle est la différence entre une dimension et une métrique dans GA4 ?
Une dimension décrit une caractéristique ou un contexte, tandis qu’une métrique sert à mesurer une valeur numérique. Le choix dépend de la question métier à laquelle le rapport doit répondre. -
Comment choisir la portée d’une dimension personnalisée ?
Choisissez la portée événementielle ou utilisateur selon la façon dont la valeur évolue. Une valeur liée à un événement doit être traitée comme telle ; une valeur qui caractérise l’utilisateur doit être définie dans cette logique. -
Faut-il enregistrer tous les paramètres envoyés à GA4 ?
Non. Enregistrez uniquement les valeurs nécessaires à vos rapports ou à vos audiences. Commencez par inventorier les paramètres déjà transmis et clarifiez leur définition avant d’en ajouter. -
Pourquoi éviter les identifiants comme dimensions de rapport ?
Les identifiants à forte cardinalité peuvent multiplier les valeurs distinctes et compliquer la lecture des rapports. Préférez des dimensions utiles à l’analyse et écartez les champs qui n’éclairent aucune décision. -
Comment vérifier qu’un paramètre personnalisé est bien collecté ?
Reliez l’action utilisateur à la charge utile de l’événement, puis au rapport. Vérifiez les noms, les types, la portée, la temporalité, les valeurs vides, le consentement et les données réellement transmises. Une inspection visuelle seule ne suffit pas.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code et intégration de l’IA. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor sur la fiabilité de leur mesure. 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.