Google Analytics 4 : configurer les événements essentiels sans mesurer n’importe quoi

Google Analytics 4 ne mesure pas seulement des pages vues : il enregistre des événements, c’est-à-dire des actions réalisées par les visiteurs. Clic sur un bouton, envoi d’un formulaire, téléchargement d’un document ou lecture d’une vidéo peuvent ainsi devenir des signaux exploitables.

La difficulté ne consiste pas à créer le plus grand nombre d’événements possible. Elle consiste à sélectionner ceux qui éclairent une décision : améliorer une page, comprendre un parcours ou mesurer une conversion. Voici une méthode pratique pour structurer ce suivi dans GA4, le tester et éviter les données inutilisables.

Un événement GA4 décrit une action, pas une page

Dans Universal Analytics, les catégories, actions et libellés occupaient une place centrale. GA4 repose sur une logique différente : chaque interaction est enregistrée sous un nom d’événement, éventuellement accompagné de paramètres.

Par exemple, un clic vers un document peut être décrit ainsi :

• nom de l’événement : file_download ;
• paramètre : type de fichier, comme PDF ;
• paramètre : nom ou adresse du fichier ;
• contexte : page depuis laquelle le téléchargement a été déclenché.

Cette structure sépare l’action de ses détails. Elle permet ensuite de répondre à des questions plus précises : quels documents sont téléchargés, depuis quelles pages et par quels profils de visiteurs ?

Commencer par les décisions à prendre

Avant d’ouvrir l’interface de Google Analytics, listez les décisions que vos données doivent aider à prendre. Un site vitrine, une boutique et un média n’ont pas besoin des mêmes événements.

Pour un indépendant qui cherche des prospects, les actions prioritaires peuvent être l’envoi d’un formulaire, le clic sur une adresse e-mail, la prise de rendez-vous et l’appel téléphonique. Pour un site de contenu, la consultation d’un article, le téléchargement d’une ressource et l’inscription à une newsletter seront probablement plus instructifs.

Une grille simple permet de filtrer les idées :

Si vous ne savez pas quelle action une donnée pourrait influencer, elle ne mérite probablement pas d’être suivie en priorité.

Les événements à prévoir sur un site courant

GA4 collecte automatiquement certaines interactions lorsqu’une propriété et un flux de données sont correctement configurés. D’autres événements nécessitent une mise en place complémentaire. Les noms exacts et les conditions disponibles peuvent évoluer dans l’interface ; vérifiez toujours la documentation et les recommandations affichées dans votre propriété.

Les actions commerciales

Sur un site qui cherche à générer des contacts, commencez par les étapes qui matérialisent une intention forte :

• envoi réussi d’un formulaire ;
• clic sur un numéro de téléphone ;
• clic vers une prise de rendez-vous ;
• demande de devis ;
• inscription à une liste de diffusion.

Un simple clic sur le bouton « Envoyer » ne prouve pas toujours qu’un formulaire a été transmis. Lorsque c’est possible, déclenchez l’événement après la confirmation réelle : message de succès, page de confirmation ou réponse positive du système. Vous éviterez de compter comme prospects les utilisateurs qui ont laissé un champ obligatoire vide.

Les actions éditoriales

Pour un site qui publie des contenus, les événements doivent compléter les pages vues plutôt que les remplacer. Un téléchargement, une inscription ou une interaction avec un lecteur vidéo peut signaler un intérêt plus fort qu’une visite rapide.

La profondeur de lecture mérite une interprétation prudente. Le temps passé dans un onglet ouvert ne signifie pas nécessairement que la page a été lue. Un événement déclenché lors d’un défilement doit donc être considéré comme un indicateur de progression, pas comme une preuve d’attention.

Les événements liés au commerce

Une boutique en ligne doit utiliser les événements et paramètres prévus pour le commerce électronique, comme la consultation d’un produit, l’ajout au panier, le début du paiement ou l’achat. Ces événements nécessitent une structure cohérente : identifiant du produit, nom, prix, quantité et valeur doivent rester correctement associés.

Évitez de créer des noms personnalisés quand un événement recommandé correspond déjà à votre besoin. Les rapports et intégrations disponibles s’appuient plus facilement sur les conventions prévues par GA4.

Nommer les événements pour conserver des données lisibles

Un plan de marquage court vaut mieux qu’une collection de noms improvisés. Choisissez une convention avant l’implémentation et appliquez-la partout.

Une bonne règle consiste à utiliser des noms en minuscules, avec des mots séparés par des underscores : contact_form_submit, booking_click ou guide_download. Le nom doit décrire l’action, non son apparence. « bouton_bleu » sera rapidement incompréhensible si le design évolue, alors que « demande_devis » conserve son sens.

Documentez au minimum :

• le nom de l’événement ;
• la condition qui le déclenche ;
• les paramètres envoyés ;
• la page ou le composant concerné ;
• la personne responsable de sa maintenance ;
• la décision que la donnée doit éclairer.

Cette documentation évite notamment de créer deux événements différents pour la même action, comme formulaire_envoye et contact_submit, simplement parce que deux personnes ont travaillé séparément.

Créer un événement : trois approches selon le contexte

Depuis l’interface GA4

GA4 permet de créer certains événements à partir d’événements déjà reçus, en ajoutant des conditions. Cette approche convient à des cas simples, par exemple transformer une visite d’une page de confirmation en événement spécifique.

Elle devient moins adaptée lorsque le déclenchement dépend d’une logique complexe, d’un formulaire dynamique ou de paramètres qui ne sont pas encore transmis. Dans ce cas, créer une règle dans l’interface ne fera pas apparaître une information absente de la collecte initiale.

Avec Google Tag Manager

Google Tag Manager offre davantage de souplesse pour déclencher des balises selon un clic, une soumission de formulaire, une classe CSS ou un événement poussé dans la couche de données. Il faut toutefois garder une architecture compréhensible : multiplier les déclencheurs fragiles rend les erreurs difficiles à diagnostiquer.

Pour un formulaire, préférez un signal fiable fourni par le site, comme un événement de succès ou une page de confirmation, plutôt qu’un simple clic qui peut être effectué plusieurs fois.

Dans le code du site

Le code est souvent la meilleure option quand l’application connaît précisément le résultat de l’action. Un site peut envoyer un événement au moment où une commande est réellement validée ou lorsqu’une réponse serveur confirme une inscription.

Cette approche demande une coordination entre le développement, le consentement des utilisateurs et la documentation du plan de mesure. Elle est plus robuste, mais pas forcément nécessaire pour une interaction très simple.

Tester avant de faire confiance aux rapports

Une balise publiée sans test peut produire des doublons, des événements jamais déclenchés ou des conversions artificiellement gonflées. Le contrôle doit être réalisé avant et après la mise en production.

1. Ouvrez le site dans une fenêtre de test et réalisez l’action comme un visiteur.
2. Vérifiez dans le rapport en temps réel ou dans DebugView que l’événement arrive.
3. Contrôlez son nom et la valeur de chaque paramètre.
4. Répétez l’action dans les cas d’erreur : formulaire incomplet, retour arrière, double clic ou rechargement.
5. Vérifiez qu’une seule action réelle ne produit pas plusieurs événements.
6. Testez aussi sur mobile si le parcours ou le composant diffère.

Les données peuvent apparaître avec un délai dans certains rapports. L’absence immédiate d’une information dans un rapport standard ne prouve donc pas nécessairement que la collecte est défaillante. DebugView sert à examiner le comportement pendant le test, tandis que les rapports servent davantage au suivi dans la durée.

Marquer comme conversion uniquement ce qui compte vraiment

Dans GA4, certains événements peuvent être désignés comme conversions, appelées aujourd’hui « événements clés » dans certaines interfaces et documentations. Cette distinction doit rester stricte : une conversion représente une action qui a une valeur directe pour l’objectif du site.

Pour un site de services, l’envoi confirmé d’une demande peut être une conversion. Le défilement à 90 % ou la visite d’une page ne le sont généralement pas, même si ces signaux peuvent aider à analyser le comportement.

Une conversion trop facilement déclenchée dégrade les comparaisons entre canaux et campagnes. Si chaque visiteur est compté comme prospect dès qu’il atteint une page, les rapports donnent une impression de performance qui ne correspond pas aux résultats commerciaux.

Les erreurs qui rendent le suivi inutilisable

• Tout mesurer sans hiérarchie : le volume d’événements masque les signaux importants.
• Déclencher sur un clic plutôt que sur un résultat : un clic n’implique pas toujours une action réussie.
• Changer les noms en cours de route : les historiques deviennent difficiles à comparer.
• Envoyer des informations personnelles : les adresses e-mail, noms et autres données directement identifiantes ne doivent pas être transmis à Analytics.
• Oublier le consentement : la collecte doit respecter le cadre applicable à votre audience et à votre configuration.
• Ne jamais retester après une refonte : un changement de formulaire, de thème ou de gestionnaire de balises peut interrompre le suivi.

Le suivi d’audience n’est pas un dispositif que l’on installe une fois pour toutes. Il doit être revu lorsqu’un parcours, une offre ou un objectif commercial change.

La méthode la plus fiable consiste à partir de quelques décisions concrètes, à définir un petit nombre d’actions prioritaires, puis à vérifier chaque événement dans des scénarios réels. Un plan de mesure limité mais exact sera toujours plus utile qu’un tableau de bord rempli d’interactions impossibles à interpréter.