Relier les rapports GA4 à un plan de mesure

Pour Atelier Rivage, l’objectif commercial est d’obtenir des demandes de devis confirmées. Le plan de mesure le traduit en éléments observables :

• Objectif : le résultat recherché par l’activité.
• Action attendue : ce que la personne doit avoir réellement accompli.
• Événement : la trace envoyée à GA4 pour cette interaction.
• Déclenchement : le moment précis où cette trace doit être envoyée.
• Paramètres utiles : des précisions descriptives, sans donnée personnelle.

Un événement ne prouve pas à lui seul l’intention ou la qualité commerciale d’une demande : il est la trace d’une interaction que la collecte est censée enregistrer.

Voici la première vue courte du plan de mesure. Chaque colonne répond à une question différente : pourquoi mesurer, quelle action observer, quelle trace attendre, à quel moment et avec quel contexte.

Un clic sur « Envoyer » exprime une tentative, mais le formulaire peut ensuite être refusé : champ manquant, erreur de validation ou problème technique. Pour mesurer une demande confirmée, le déclenchement attendu est donc la réussite visible sur /merci-devis.

Le plan indique ce qui devrait être collecté. Il ne démontre pas que l’intégration envoie effectivement l’événement, ni qu’elle l’envoie une seule fois. Les données observées devront être comparées plus tard à cette attente.

Pour Atelier Rivage, le plan de mesure ne retient pas tous les événements au même niveau. Certains décrivent le parcours ; un autre signale le résultat commercial suivi : une demande de devis confirmée.

Un événement clé est un événement que l’activité choisit de mettre en évidence parce qu’il correspond à une action particulièrement importante. Ce marquage aide à isoler le résultat retenu parmi les interactions observées ; il ne crée pas l’événement.

Le choix dépend de la question commerciale : « Combien de demandes de devis confirmées avons-nous mesurées ? » Les événements précédant cette réussite restent utiles pour comprendre le parcours, sans représenter à eux seuls le résultat recherché.

GA4 compte des signaux, pas directement des personnes ni des résultats commerciaux.

• Un utilisateur est une identité reconnue par GA4. Elle ne correspond pas forcément à une personne réelle unique.
• Les Utilisateurs actifs constituent une métrique courante : ils ne représentent pas automatiquement tous les visiteurs ni tous les clients.
• Une session regroupe des interactions successives. Après 30 minutes d’inactivité, par défaut, une nouvelle session commence.
• Un même utilisateur peut donc réaliser plusieurs sessions et déclencher plusieurs événements.

Voici le jeu principal d’Atelier Rivage. Ces totaux décrivent des unités différentes : ils ne doivent pas être rapprochés comme s’ils désignaient les mêmes personnes ou les mêmes demandes.

generate_lead est déjà marqué comme événement clé. Son comptage est effectué une fois par événement.

Une session est considérée avec engagement si au moins une de ces conditions est remplie :

• sa durée dépasse le seuil configuré, de 10 secondes par défaut ;
• elle contient au moins un événement clé ;
• elle comporte au moins deux vues de page ou d’écran.

Ces critères sont alternatifs : un seul suffit. Une session avec engagement n’est pas, à elle seule, la preuve d’une réussite commerciale.

Pour Atelier Rivage, les paramètres UTM décrivent le contexte d’un lien de campagne. Ils ne modifient pas la page /devis : ils ajoutent des informations lisibles dans l’adresse afin de distinguer l’origine de la visite.

• utm_source : l’origine précise du trafic ; ici, la newsletter.
• utm_medium : la catégorie du levier ; ici, l’e-mail.
• utm_campaign : le regroupement marketing ; ici, la campagne de rentrée.
• utm_content : le placement ou la variante du lien dans le même message.

Ces repères aident à nommer les campagnes de façon cohérente. Ils ne prouvent pas, à eux seuls, qu’une visite sera effectivement collectée dans GA4.

Visualisez les UTM comme quatre étiquettes ajoutées au même lien, avant l’arrivée sur la page de devis.

L’adresse de départ ne possède pas encore de paramètre. Ajoutez ? avant le premier paramètre, puis & entre les suivants. Si une adresse possède déjà une chaîne de paramètres, & permet d’en ajouter un autre.

Pour distinguer un second emplacement dans le même e-mail, gardez la source, le support et la campagne identiques ; seul utm_content change, par exemple avec lien_texte.

Une même personne peut arriver une première fois par la recherche naturelle, puis revenir plus tard depuis une newsletter. Ces deux informations sont justes, mais elles ne répondent pas à la même question.

• Acquisition d’utilisateurs décrit l’origine de la première acquisition de l’utilisateur.
• Acquisition de trafic décrit l’origine de chaque session.

Ne choisissez donc pas le rapport selon le canal que vous espérez voir, mais selon la portée de votre question : utilisateur initial ou session donnée.

Pour analyser les sessions provenant de l’e-mail, utilisez une dimension de portée session. La campagne renseignée dans le lien de newsletter est alors lue avec Campagne de la session.

Gardez la même période, les mêmes filtres et le même périmètre lorsque vous rapprochez deux rapports. Des libellés ou l’emplacement des rapports peuvent varier selon la collection publiée dans la propriété GA4 : vérifiez surtout le nom du rapport et la portée de la dimension affichée.

Après le plan de mesure, chaque question doit mener vers un rapport et une métrique précis.

• Pour savoir si une page a été consultée, utilisez Pages et écrans et lisez ses vues ou ses utilisateurs actifs.
• Pour savoir si une action a été enregistrée, utilisez Événements et recherchez son nom, par exemple generate_lead.

Une page consultée n’est pas une demande de devis : ce sont deux traces différentes, lues dans deux rapports différents.

Les mesures ne répondent pas toutes à la même question.

Dans Pages et écrans, une vue est une consultation enregistrée : une même identité reconnue peut consulter /devis plusieurs fois et contribuer à plusieurs vues. Les Utilisateurs actifs indiquent le nombre d’identités actives associées à la page dans le périmètre du rapport ; ce n’est pas le total des consultations.

Dans Événements, le nombre associé à generate_lead est un nombre d’occurrences enregistrées. Même lorsque cet événement est marqué comme événement clé et compté une fois par événement, ce total ne démontre pas un nombre de personnes, de clients ou de demandes uniques.

Les paramètres du plan, tels que form_name=devis_velo et service_type=reparation, décrivent le contexte attendu de generate_lead. Leur présence dans le plan — ou même leur envoi avec l’événement — ne les transforme pas automatiquement en dimensions disponibles dans les rapports standards.

Avant de fonder une lecture sur un paramètre, vérifiez qu’il est réellement exploitable dans le rapport et le périmètre utilisés. L’absence d’une colonne dans un tableau ne prouve pas, à elle seule, que le paramètre n’a pas été envoyé.

Un plan de mesure énonce ce qui devrait être observé : une action réalisée, son résultat confirmé, puis l’événement attendu. Le contrôle consiste à comparer ce scénario à un journal d’actions et d’événements réellement reçus.

Pour Atelier Rivage, une demande de devis confirmée doit produire un generate_lead. Un échec de validation ne doit pas le produire. Un rechargement de /merci-devis, sans nouvelle demande, peut produire une vue de page, mais ne doit pas créer un nouveau generate_lead.

Un écart est un signal à vérifier : il ne démontre pas, à lui seul, la cause technique de l’écart.

Ce journal sépare ce que la personne a fait de ce que la collecte a enregistré. Il constitue un constat : l’analyse vient ensuite.

Dans le journal, la ligne de 09:00 est cohérente : la validation a échoué et aucun generate_lead n’apparaît. Celle de 09:03 l’est aussi : une réussite confirmée est associée à une occurrence.

À 09:07, deux occurrences pour une réussite constituent un doublon possible. À 09:10, un generate_lead après un simple rechargement est un déclenchement potentiellement indu. À 09:15, la confirmation sans generate_lead signale une absence possible.

Ces mots restent prudents : le journal révèle une anomalie de cohérence, non sa cause démontrée.

Une baisse dans un rapport est un fait mesuré : moins d’éléments ont été enregistrés dans le périmètre affiché. Elle ne prouve pas, à elle seule, une baisse des demandes réelles.

Ce périmètre peut changer avec les choix de consentement, la configuration de collecte, des bloqueurs ou une erreur d’intégration. Des délais de traitement peuvent aussi retarder l’apparition de données.

Selon la configuration, certaines données peuvent être modélisées. Elles restent une estimation dans un périmètre donné, et non l’observation exhaustive de toutes les actions.

Pour raisonner prudemment, formulez trois éléments séparés :

1. Le fait observé : ce que montre précisément le rapport.
2. L’explication possible : une piste compatible avec ce fait, sans la présenter comme démontrée.
3. La vérification prioritaire : le contrôle concret qui peut confirmer ou écarter cette piste.

Une baisse peut venir de l’activité, du périmètre effectivement observé, ou de la collecte elle-même.

Avant de comparer commercialement deux périodes, adoptez un ordre de contrôle :

1. Confirmez les dates, la propriété, les filtres appliqués et la portée du rapport consulté.
2. Recherchez les changements documentés pendant la période : consentement, intégration, publication ou blocage connu.
3. Vérifiez le parcours attendu : une réussite confirmée doit produire l’événement prévu, sans émission inattendue.
4. Confrontez ensuite le signal GA4 avec une source opérationnelle disponible, en gardant leurs périmètres distincts.
5. Formulez une conclusion limitée aux éléments vérifiés.

Dans le rapport Événements, une baisse de generate_lead décrit d’abord moins d’occurrences enregistrées. Elle ne permet pas à elle seule d’affirmer que l’activité commerciale a baissé.

Un mini-plan exploitable relie toute lecture de rapport à une chaîne vérifiable : un objectif commercial, une action attendue, une trace GA4, puis un indicateur et un rapport adaptés. La trace prévue ne prouve pas seule que la collecte fonctionne : la vérification fait partie du plan.

Pour Atelier Rivage, le résultat recherché reste une demande de devis effectivement confirmée. Le plan ne confond donc ni la visite de /devis, ni le début du formulaire, avec ce résultat.

La deuxième vue complète la traçabilité. Les paramètres décrivent le contexte de l’événement sans identifier une personne. L’indicateur compte ici des occurrences : il ne permet donc pas, à lui seul, d’affirmer un nombre de clients ou de demandes uniques.

Pour une campagne, choisissez aussi la portée de la question : l’origine de la première acquisition concerne l’utilisateur ; l’origine d’une visite ou d’une campagne concerne la session.