Article · Analytics

Suivre ses conversions avec Google Analytics 4 : le plan de marquage minimal

Sur un site vitrine ou dans une PME, on n’a pas besoin de cinquante événements dans Google Analytics 4. Il en faut trois ou quatre qui comptent vraiment, bien nommés, notés quelque part et vérifiés. Je décris le plan de marquage que j’applique, et celui, très court, que j’ai mis en place sur ce site.

J’ai souvent vu le même scénario chez des clients. GA4 est installé, quelqu’un regarde les pages vues pendant deux semaines, puis plus personne n’ouvre le compte. Il ne répond à aucune question utile, à commencer par la plus simple : est-ce que le formulaire de contact est rempli ? Un plan de marquage, c’est le document qui évite ça, la liste des actions que le site signale à Google Analytics, avec ce qui les déclenche. Pour un site vitrine, une conversion est rarement une vente. C’est un contact, un devis, un document téléchargé, un appel. Le plan sert à nommer ces actions et à les séparer du bruit.

Un événement, c’est une clochette au-dessus de la porte

Imaginez une boutique avec une clochette au-dessus de la porte, une autre à la caisse et une troisième sur le présentoir des catalogues. Chaque fois qu’une clochette sonne, le commerçant note l’heure et ce qui vient de se passer. Un événement GA4, c’est cette clochette. Il sonne quand un visiteur fait quelque chose de précis, charger une page, cliquer sur un lien, envoyer un formulaire, et il transmet à Google Analytics une petite note avec le nom de l’action et quelques détails, qu’on appelle des paramètres. Sans ces détails, la clochette sonne dans le vide : on sait qu’il s’est passé quelque chose, pas quoi.

Ce que GA4 note déjà tout seul

La page vue est envoyée à chaque chargement, le début de session et la première visite sont créés automatiquement. Cela suffit pour connaître le trafic, d’où il vient et quelles pages sont les plus lues.

La mesure améliorée, activée par défaut dans le flux de données du compte, ajoute d’autres clochettes sans rien installer : le défilement quand le visiteur atteint 90 % de la page, le clic sur un lien sortant vers un autre site, le téléchargement d’un PDF ou d’un tableur, la recherche interne, et le début puis l’envoi d’un formulaire. Ces deux derniers sont pratiques mais imparfaits : certains formulaires qui s’envoient sans recharger la page ne les déclenchent pas, et j’ai appris à ne jamais leur faire confiance sans test.

Les événements clés, anciennement les conversions

Google a renommé les conversions en « événements clés », mais le principe reste le même. Dans l’administration de GA4, on coche un événement comme clé, et il devient un objectif dans les rapports d’acquisition. On sait alors quel canal amène des contacts, pas seulement des visites.

Ma règle : un événement clé correspond à une action qui a de la valeur pour l’entreprise, même sans montant. Faire défiler une page n’en est pas une. Envoyer un formulaire, oui. Sur pierreturpin.org, j’en ai retenu deux, l’envoi du formulaire de contact et le téléchargement de mon CV, capté par l’événement de téléchargement de la mesure améliorée. Ce sont les deux actions que je veux voir augmenter, et j’ai préféré m’en tenir là.

Le plan minimal tient sur une feuille

Le document est une feuille de calcul de cinq colonnes : l’événement, ce qui le déclenche, les détails qu’il emporte, événement clé oui ou non, et la page concernée. Pour le nommage, les noms s’écrivent comme ceux de Google, en minuscules avec des tirets bas, et on garde un seul vocabulaire d’une page à l’autre. Quand Google propose déjà un nom pour une action courante, je le reprends plutôt que d’en inventer un. Un détail personnalisé doit aussi être déclaré comme dimension personnalisée dans l’administration, sinon il est collecté mais invisible dans les rapports. Pour un site vitrine, le plan minimal ressemble à ceci :

  • Page vue (page_view) : se déclenche quand une page se charge, sur toutes les pages. Ce qu’on enregistre : l’adresse et le titre de la page. Pas un événement clé.
  • Envoi de formulaire (form_submit ou generate_lead) : se déclenche quand le formulaire de contact est bien envoyé. Ce qu’on enregistre : le nom du formulaire. Événement clé.
  • Téléchargement (file_download) : se déclenche au clic sur un lien PDF, où qu’il soit. Ce qu’on enregistre : le nom du fichier et l’adresse du lien. Événement clé si le fichier compte pour vous (un CV, une brochure).
  • Clic sortant (click) : se déclenche quand un visiteur suit un lien vers un autre site. Ce qu’on enregistre : l’adresse du lien. Pas un événement clé.
  • Clic téléphone ou e-mail (phone_click, email_click) : se déclenche au clic sur un numéro ou une adresse e-mail, dans l’en-tête, le pied de page ou la page contact. Ce qu’on enregistre : l’adresse du lien. Événement clé.

Pour une boutique WooCommerce, on ajoute les événements e-commerce standards, de la vue d’un produit jusqu’à l’achat. Je ne les fabrique pas à la main : une extension de suivi dédiée les fournit, et l’achat est l’événement clé évident.

Site Kit ou Google Tag Manager ?

Site Kit, l’extension officielle de Google, connecte GA4 et la Search Console en quelques clics, insère la balise et gère le mode consentement. C’est ce que j’utilise sur ce site : mon besoin se limite à deux événements clés, et je ne veux pas entretenir un conteneur de plus.

Google Tag Manager devient nécessaire quand plusieurs outils partagent les mêmes déclencheurs, GA4, Ads, Meta, ou quand une personne non développeuse doit pouvoir modifier le marquage sans toucher au thème. Le prix à payer, c’est une couche de plus à documenter. Site vitrine géré par une personne, Site Kit. Boutique avec des campagnes payantes, Tag Manager.

Le consentement avant la mesure

Un plan de marquage qui ignore le RGPD est un plan qui devra être refait. GA4 ne doit déposer aucun cookie ni envoyer d’identifiant tant que le visiteur n’a pas accepté. Avec le Consent Mode v2, la balise démarre avec les autorisations de statistiques et de publicité refusées, et le bandeau de cookies les met à jour après le choix. J’ai détaillé cette mise en place dans mon article sur le bandeau de cookies et Consent Mode sur WordPress.

Conséquence à dire au client avant qu’il compare avec les statistiques de son hébergeur : une partie des visiteurs refuse, et les chiffres de GA4 sont en dessous de la réalité. Ce n’est pas un défaut de marquage.

Je ne crois un événement que quand je l’ai vu arriver

DebugView, dans l’administration de GA4, affiche en direct les événements envoyés par un appareil en mode débogage, avec leurs détails. On l’active avec l’extension de navigateur Google Analytics Debugger. J’accepte le bandeau, je remplis le formulaire, je télécharge le PDF, et je vérifie que chaque action produit un seul événement avec les bons détails. Le lendemain, je confirme que les événements clés apparaissent dans les rapports standards.

Les erreurs que je croise le plus souvent tiennent en quelques lignes. Tout mesurer, avec trente événements que personne ne regarde. Les balises en double, Site Kit plus un ancien code de suivi resté dans le thème plus Tag Manager ajouté par une agence, et chaque page vue comptée deux ou trois fois. Oublier de relier la Search Console, qui ajoute dans GA4 les requêtes Google à l’origine du trafic ; sur ce site, la liaison est faite depuis Site Kit. Et oublier d’exclure le trafic interne, alors que le client, son équipe et le développeur visitent le site tous les jours et que, sur un petit site, quelques sessions font bouger les pourcentages.

Un bon plan de marquage pour une PME tient sur une page : la mesure améliorée, deux à quatre événements clés, un nommage cohérent, le consentement respecté et un passage par DebugView. Le reste peut attendre que quelqu’un pose vraiment la question. Je commence toujours par le tableau, jamais par l’outil.

Un poste à pourvoir ? Parlons-en.

Je recherche un CDI de développeur WordPress ou de chargé de marketing digital, à Paris, ailleurs en France ou au Luxembourg.