Configuration avancée GA4 : suivi d'événements et entonnoirs de conversion

Le 1er juillet 2023, Google a définitivement arrêté la collecte de données Universal Analytics. Ce matin-là, en ouvrant le back-office et en voyant la courbe s’arrêter net dans les rapports UA, une seule question me tournait dans la tête : comment utiliser GA4, au juste ?

Si, comme moi, vous avez migré depuis UA en ne déployant qu’un code de base et que l’interface GA4 vous laisse perplexe — rassurez-vous, vous n’êtes pas seul. Beaucoup de webmasters « roulent à vide » : les pages vues sont comptées, mais les clics sur les boutons, le nombre d’articles lus, l’étape où les visiteurs abandonnent — toutes ces données vraiment utiles — ne sont captées nulle part.

Cet article ne vous explique pas ce qu’est GA4, mais comment faire concrètement : utiliser le suivi d’événements pour comprendre le comportement utilisateur, configurer des entonnoirs de conversion pour repérer les points de fuite, et — si vous avez des besoins d’analyse approfondie — exporter les données vers BigQuery pour interroger en SQL. Commençons par les trois types d’événements.

1. Les trois types de suivi d’événements GA4

La logique centrale de GA4 est totalement différente d’UA. UA repose sur un modèle « session + page vue », GA4 sur « tout est un événement ».

Vous avez probablement entendu cette phrase des dizaines de fois — mais concrètement, qu’est-ce que ça signifie ? Simplement : une page vue est un événement, un clic sur un bouton est un événement, la lecture d’une vidéo est un événement, le défilement jusqu’en bas de page aussi. Tous les comportements utilisateur sont enregistrés comme des « événements » distincts dans GA4.

Mais on ne crée pas des événements au hasard. Google les classe en trois catégories, chacune avec ses usages et ses limites.

1. Événements automatiques (Enhanced Measurement) : prêts à l’emploi

C’est le « repas gratuit » offert par GA4. Lors de la création d’un flux de données, Enhanced Measurement est activé par défaut et suit automatiquement 7 interactions :

• Pages vues (page_view)
• Défilement (scroll) — mais uniquement à 90 % de profondeur
• Clics sortants (click)
• Recherche interne (search)
• Interaction vidéo (video_start, video_progress, video_complete)
• Téléchargement de fichiers (file_download)
• Interaction avec les formulaires (form_start, form_submit)

Ça a l’air complet, non ? Mais attention au piège : le suivi du défilement n’enregistre que le passage à 90 % de la page. Si vous voulez savoir combien de lecteurs terminent un article, ou suivre la progression à 50 % ou 75 %, Enhanced Measurement ne suffit pas — il faudra configurer GTM vous-même.

Mon conseil : laissez Enhanced Measurement activé, mais ne comptez pas trop dessus. Il fournit des données de base ; les comportements vraiment utiles, c’est à vous de les capturer.

2. Événements recommandés : suivre le scénario Google

Google a prédéfini un ensemble d’« événements recommandés » par secteur. Par exemple, pour l’e-commerce : add_to_cart, begin_checkout, purchase ; pour les sites de contenu : sign_up, login, share.

L’avantage des événements recommandés : si vous utilisez les bons noms d’événements et paramètres, GA4 génère automatiquement les rapports correspondants. Par exemple, avec l’événement purchase, GA4 produit le rapport associé.

Attention toutefois : les événements recommandés ne se déclenchent pas automatiquement. Vous devez toujours ajouter du code sur le site (ou configurer GTM), en respectant strictement les spécifications Google pour les noms et paramètres.

Exemple d’événements recommandés courants pour un blog :

Sur mon propre blog, j’ai configuré l’événement sign_up pour suivre les abonnements. Au début, j’avais écrit signUp (camelCase) — GA4 ne le reconnaissait tout simplement pas. Les événements recommandés exigent impérativement snake_case, sans la moindre erreur.

3. Événements personnalisés : tout suivre, mais à un prix

Quand le comportement à suivre n’est pas dans la liste recommandée de Google, il faut définir votre propre événement. Par exemple, pour suivre « l’utilisateur a terminé la lecture d’un article », j’ai créé l’événement article_read_complete.

Les événements personnalisés offrent une grande liberté, mais avec quelques contraintes :

1. Limite de paramètres : chaque événement accepte au maximum 25 paramètres personnalisés. Simo Ahava (autorité du domaine GA4) a testé que les données au-delà de 25 paramètres peuvent toujours être exportées vers BigQuery, mais sont ignorées dans les rapports natifs GA4.

2. Convention de nommage : seuls les lettres, chiffres et underscores sont autorisés, le nom doit commencer par une lettre. Utilisez snake_case, comme pour les événements recommandés.

3. Délai des rapports : après configuration, un événement personnalisé peut mettre 24 à 48 heures à apparaître dans GA4. Ne concluez pas trop vite à une erreur — attendez un peu.

Priorité de configuration : un arbre de décision simple

Si vous hésitez sur le type d’événement à utiliser, suivez cet ordre :

1. Vérifier d’abord Enhanced Measurement — prêt à l’emploi, économisez du travail si possible
2. Consulter la liste des événements recommandés — suivez les spécifications, rapports auto-générés
3. Personnaliser en dernier recours — grande liberté, mais coût de maintenance plus élevé

Franchement, pour la plupart des blogs, Enhanced Measurement + quelques événements recommandés suffisent. Les événements personnalisés sont réservés à ceux qui ont des besoins d’analyse approfondie.

2. Configuration pratique du suivi d’événements

Une fois les trois types d’événements compris, passons à la configuration concrète.

Il existe deux approches principales pour configurer les événements GA4 : Google Tag Manager (GTM) ou gtag.js directement dans la page. Je recommande GTM — la courbe d’apprentissage est un peu plus raide, mais la maintenance est bien plus simple : modifier une condition de déclenchement ne nécessite pas de redéployer le code.

Configurer un événement GA4 avec GTM : quatre étapes

Supposons que vous vouliez suivre « lecture d’article terminée ». Voici le flux complet :

Étape 1 : créer un tag GA4 Event

Ouvrez GTM, créez un nouveau Tag, type Google Analytics: GA4 Event. Renseignez votre Measurement ID, nom d’événement : article_read_complete.

Étape 2 : configurer le Trigger

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

C’est ici que vous indiquez à GTM : « quand déclencher cet événement ? »

Pour « lecture terminée », j’utilise un déclencheur de défilement : l’événement se déclenche quand l’utilisateur atteint 90 % de la page. Créez un Trigger, type Scroll Depth, Vertical Scroll Depths à 90 %.

Un détail important : si votre blog affiche une barre de progression de lecture, elle peut entrer en conflit avec le suivi de défilement GTM. J’ai déjà eu ce problème — une barre en haut de page provoquait des déclenchements en rafale, des données pleines de bruit. Solution : limiter à un seul déclenchement par utilisateur et par article.

Étape 3 : ajouter les Event Parameters

Les paramètres sont l’« âme » de l’événement. Savoir qu’un article a été lu jusqu’au bout ne suffit pas — il faut savoir lequel, sa catégorie, son auteur.

Ajoutez les Event Parameters dans la configuration du Tag :

Maintenez la cohérence des types de valeurs. Si reading_time est un nombre, gardez-le numérique ; n’alternez pas entre 5, "5 minutes" — GA4 les traitera comme des paramètres distincts.

Étape 4 : validation en Debug

Ne publiez pas tout de suite. Testez en mode Preview de GTM : ouvrez votre blog, scrollez jusqu’à 90 %, vérifiez que DebugView GA4 reçoit l’événement.

DebugView se trouve dans le back-office GA4, Configure > DebugView. Si l’événement n’apparaît pas, vérifiez les conditions du Trigger ; si l’événement arrive sans paramètres, vérifiez la configuration des Variables.

Pas envie de GTM ? Configuration directe avec gtag.js

Si votre blog utilise un générateur statique (Astro, Hugo, etc.) et que vous ne voulez pas la complexité de GTM, le code gtag.js direct fonctionne aussi.

// Exécuté après le chargement de la page
window.addEventListener('load', function() {
  // Déclenchement à 90 % de défilement
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

Ce code fait la même chose que la configuration GTM : envoyer l’événement article_read_complete à 90 % de défilement. La différence : le code est intégré à la page, toute modification nécessite un redéploiement.

Pièges courants (tous testés par moi)

Piège 1 : nommage d’événement non conforme

articleReadComplete, article-read-complete, article_read_complete — ce sont trois événements distincts dans GA4. Utilisez systématiquement snake_case, comme dans la documentation officielle Google.

Piège 2 : types de valeurs de paramètres incohérents

Aujourd’hui reading_time: 5, demain reading_time: "5 minutes", après-demain reading_time: true. GA4 les traitera comme trois paramètres différents — le rapport devient illisible.

Piège 3 : Consent Mode v2 filtre les événements

Si votre site cible des utilisateurs européens et que Google Consent Mode v2 est activé, certains événements ne seront pas envoyés si l’utilisateur refuse les cookies. Ce n’est pas une erreur, mais les données des rapports « rétrécissent » — ne concluez pas trop vite à un problème de configuration.

Piège 4 : noms d’événements ou de paramètres réservés

page_view, session_start, first_visit sont des noms d’événements réservés GA4 — ne les réutilisez pas pour des événements personnalisés. Il existe aussi une liste de paramètres réservés ; consultez la documentation officielle avant de configurer.

Exemples pratiques pour un blog

Voici quelques configurations d’événements courantes pour un blog :

Une fois ces événements configurés, vous verrez le comportement réel des utilisateurs sur votre blog dans GA4. Ensuite, il faudra analyser ces données — c’est le rôle des entonnoirs de conversion.

3. Configuration et analyse des entonnoirs de conversion

Le suivi d’événements est en place. Reste la question centrale : combien d’utilisateurs abandonnent entre leur première visite et l’accomplissement de votre objectif ?

C’est précisément ce que résolvent les entonnoirs de conversion.

Le rapport Funnel Exploration de GA4 est bien plus puissant qu’UA. Les entonnoirs UA étaient rigides ; GA4 permet de personnaliser chaque étape, d’ajouter des segments comparatifs, d’analyser le temps de fuite — en gros, des fonctionnalités d’outils payants intégrées gratuitement.

Créer votre premier entonnoir de conversion

Ouvrez GA4, accédez à Explore > Funnel Exploration. Vous verrez un modèle d’entonnoir vide.

La première étape consiste à définir les « étapes de l’entonnoir ». Vous pouvez en définir jusqu’à 10, mais pour un blog, 4 à 5 suffisent généralement.

Exemple d’entonnoir d’abonnement pour un blog :

1. Étape 1 : page article (event: page_view, condition : page_location contient /posts/)
2. Étape 2 : visite de la page d’abonnement (event: page_view, condition : page_location contient /subscribe)
3. Étape 3 : soumission du formulaire d’abonnement (event: newsletter_signup)
4. Étape 4 : ouverture de l’e-mail de confirmation (event: email_opened) — nécessite le suivi côté système d’e-mailing

Astuce lors de la définition des étapes : gardez chaque condition simple et claire. Des combinaisons complexes rendent les données difficiles à interpréter.

Analyse de l’entonnoir : repérer les points de fuite

Une fois l’entonnoir configuré, vous verrez le taux de conversion et le nombre d’abandons à chaque étape.

Supposons ces données pour mon entonnoir d’abonnement :

Le premier point de fuite saute aux yeux : « page article → page d’abonnement », seulement 8 % des utilisateurs y vont. L’entrée vers l’abonnement n’est probablement pas assez visible, ou mal positionnée.

Le second : « page d’abonnement → soumission du formulaire », 30 % de conversion. Peut-être un formulaire trop long, ou une proposition de valeur insuffisamment claire.

Une fois les points de fuite identifiés, comparez les segments pour voir si les abandons suivent un schéma.

Segmentation : identifier « qui » abandonne

Funnel Exploration permet d’ajouter des segments (Segments) pour comparer les différences de conversion entre groupes d’utilisateurs.

Dimensions de segmentation courantes :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• Nouveaux vs utilisateurs récurrents : les nouveaux convertissent généralement moins, car ils ne connaissent pas encore la valeur de votre contenu
• Mobile vs desktop : l’expérience de remplissage de formulaire est souvent moins bonne sur mobile
• Canal d’acquisition : utilisateurs venant des moteurs de recherche vs réseaux sociaux

Exemple de comparaison nouveaux vs récurrents sur mon entonnoir d’abonnement :

Les utilisateurs récurrents convertissent mieux à chaque étape — normal, ils ont déjà validé votre contenu. Mais pour les nouveaux, « page article → page d’abonnement » n’atteint que 5 % : l’entrée d’abonnement passe inaperçue.

Suite à cette constatation, j’ai ajouté une carte d’abonnement visible en fin d’article. Le taux de conversion des nouveaux est passé de 5 % à 12 %.

Open Funnel : analyser la diversité des parcours

Par défaut, Funnel Exploration fonctionne en « entonnoir linéaire » : l’utilisateur doit compléter chaque étape dans l’ordre pour être comptabilisé.

Mais le comportement réel est moins rigide. Certains utilisateurs s’abonnent directement en bas d’article sans passer par la page dédiée ; d’autres ouvrent l’e-mail de confirmation puis reviennent lire un article.

GA4 propose le mode « Open Funnel » : sans ordre obligatoire, dès qu’un utilisateur accomplit une étape, il est comptabilisé à cette étape.

Open Funnel révèle les « parcours atypiques » : 15 % de mes abonnés ont soumis le formulaire directement en bas d’article, sans visiter la page d’abonnement. L’entrée en fin d’article est plus efficace que la page dédiée — j’ai donc concentré mes efforts sur l’optimisation de cette zone plutôt que sur la page d’abonnement.

Erreurs courantes dans l’analyse d’entonnoir

Erreur 1 : ne regarder que le taux de conversion final

Le « taux global » de la première à la dernière étape compte, certes, mais ce sont les points de fuite intermédiaires qui guident les améliorations. Ne vous fixez pas sur « 1,8 % des utilisateurs se sont abonnés » — demandez-vous « à quelle étape 92 % ont-ils abandonné ».

Erreur 2 : ignorer la dimension temporelle

Funnel Exploration permet de définir un « délai de conversion » — le temps entre la première et la dernière étape. Si votre entonnoir est « lecture → commande → paiement » et que l’utilisateur met 7 jours entre lecture et paiement, le cycle de décision est long : renforcez la confiance ou ajoutez des relances.

Erreur 3 : analyser avec trop peu de données

L’analyse d’entonnoir nécessite un volume suffisant. Avec seulement quelques dizaines d’utilisateurs par étape, les taux fluctuent fortement et les conclusions peuvent être peu fiables. Attendez quelques centaines d’utilisateurs avant une analyse approfondie.

4. Export BigQuery : mise en pratique

Tout ce qui précède se fait dans l’interface GA4. Mais les rapports natifs ont une limite : l’échantillonnage quand le volume de données est élevé. Par exemple, avec 500 000 utilisateurs actifs mensuels, GA4 peut générer des rapports basés sur seulement 10 % des données.

L’échantillonnage n’est pas mauvais en soi — il accélère le chargement des rapports. Mais pour une analyse précise des taux de conversion ou une combinaison de plus d’une dizaine de dimensions, les résultats échantillonnés deviennent peu fiables.

C’est là que l’export BigQuery devient indispensable.

Configuration de l’export BigQuery : trois étapes

BigQuery est le service d’entrepôt de données de Google. En exportant les données GA4 vers BigQuery, vous interrogez l’intégralité des données en SQL, sans limite d’échantillonnage.

La configuration est simple :

Étape 1 : créer un projet BigQuery

Dans Google Cloud Console, créez un projet et activez l’API BigQuery. Les nouveaux utilisateurs bénéficient d’un quota gratuit : 10 Go de stockage et 1 To de requêtes par mois — largement suffisant pour un blog.

Étape 2 : configurer l’export dans GA4

Ouvrez GA4 Admin, trouvez BigQuery Linking. Cliquez sur Link, sélectionnez votre projet BigQuery, puis choisissez la fréquence d’export :

• Daily : export quotidien des données de la veille
• Streaming : export quasi temps réel (données du jour visibles en quelques heures)

Je recommande d’activer les deux. L’export Daily a une structure plus stable, idéal pour l’analyse long terme ; le Streaming convient pour suivre les données du jour.

Étape 3 : attendre le démarrage du flux de données

Après configuration, GA4 commence l’export sous 24 heures. Attention au piège : BigQuery n’offre pas de rétroimport historique. Si vous configurez aujourd’hui, vous ne récupérez que les données à partir d’aujourd’hui — les deux années de données GA4 passées ne remontent pas automatiquement.

Si vous avez des besoins d’analyse approfondie, configurez l’export BigQuery le plus tôt possible. N’attendez pas d’en avoir besoin pour découvrir qu’il est trop tard.

Structure des données BigQuery : vue d’ensemble

Les données GA4 exportées vers BigQuery forment une table par jour, nommée events_YYYYMMDD. Par exemple, events_20260429 contient les événements du 29 avril 2026.

Chaque enregistrement est un événement, avec les champs suivants :

Point où les débutants bloquent souvent : event_params est un champ imbriqué, pas une colonne simple. Pour lire une valeur de paramètre, il faut utiliser UNNEST pour le déplier.

Quelques requêtes SQL utiles

Nombre d’utilisateurs pour un événement donné :

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

Cette requête calcule combien d’utilisateurs uniques ont terminé la lecture d’un article en avril.

Distribution d’un paramètre d’événement :

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

Cette requête déplie event_params et compte les utilisateurs ayant terminé la lecture par catégorie d’article.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

BigQuery vs rapports natifs GA4 : quand utiliser quoi ?

En bref : rapports quotidiens dans l’interface GA4, analyse approfondie dans BigQuery.

Maîtriser les coûts BigQuery

BigQuery facture selon le volume de données traitées par les requêtes. Pour un blog, les coûts restent généralement maîtrisables, mais quelques astuces d’économie :

1. Limiter la plage de dates avec _TABLE_SUFFIX : n’interrogez pas toute la table, seulement les dates nécessaires
2. Filtrer tôt avec WHERE : plus vous filtrez tôt, moins de données sont traitées
3. Créer des vues matérialisées : pré-agrégez les données fréquemment interrogées

Mon blog génère environ 1 Go de données par mois, avec moins de 100 Go de requêtes/mois — entièrement dans le quota gratuit. Les grands sites devront surveiller les coûts, mais les blogs de taille moyenne n’ont pas à s’inquiéter.

5. GA4 vs UA : ce que les migrateurs doivent savoir

Si vous migrez depuis UA, ce chapitre est pour vous.

La différence entre GA4 et UA ne se limite pas à une interface remaniée — la logique sous-jacente a totalement changé. Beaucoup de concepts « évidents » n’existent plus ou ont une définition différente.

Modèle d’événements vs modèle de sessions

Le cœur d’UA, ce sont les « sessions » : l’utilisateur arrive, navigue, part — c’est une session. Une session peut contenir plusieurs pages vues et plusieurs événements.

Le cœur de GA4, ce sont les « événements » : chaque comportement utilisateur est une unité atomique indépendante. La session devient un ensemble d’événements, plus le point de départ de l’analyse.

Qu’est-ce que ça implique ?

Dans UA, vous regardiez « nombre de sessions », « pages vues par session ». Dans GA4, ces concepts sont remplacés par « nombre d’événements », « nombre d’utilisateurs ».

GA4 conserve le concept de « session », mais ne le met plus au centre — l’accent est sur le « parcours utilisateur ». Un utilisateur peut ouvrir votre blog le matin et revenir l’après-midi : deux sessions dans UA, mais deux visites d’un même utilisateur dans GA4.

Taux d’engagement vs taux de rebond

Le « taux de rebond » (Bounce Rate) d’UA obsédait beaucoup de webmasters : plus il est bas, mieux c’est — l’utilisateur est resté.

Dans GA4, le taux de rebond a disparu. À la place : le « taux d’engagement » (Engagement Rate).

Pourquoi ? Parce que la définition du rebond UA était problématique : l’utilisateur ne consulte qu’une page puis part — c’est un rebond. Mais s’il ne consulte qu’une page, y reste 10 minutes et lit l’article en entier — UA compte quand même un rebond.

Le taux d’engagement GA4 est plus pertinent : l’utilisateur reste plus de 10 secondes, déclenche au moins un événement de conversion, ou consulte plus de 2 pages — la session compte comme « engagée ». Taux d’engagement = sessions engagées / total des sessions.

Ne comparez donc pas directement le taux d’engagement GA4 au taux de rebond UA. Ce ne sont pas des concepts opposés, mais des mesures différentes.

Data Streams vs Views

UA avait le concept de « vues » (Views) : vous pouviez créer plusieurs vues avec des filtres différents — une pour le trafic national, une autre excluant les IP internes.

GA4 n’a plus de vues. À la place : les « flux de données » (Data Streams) — Web, iOS App, Android App, un flux par plateforme.

Et les filtres ? GA4 les remplace par « Property Filters » — mais la fonctionnalité est bien plus limitée que les filtres de vues UA. Vous pouvez filtrer le trafic interne et le spam, mais pas créer plusieurs « vues » avec des jeux de données différents comme dans UA.

Si vous utilisiez les vues UA pour isoler des segments de données, la migration vers GA4 nécessite de repenser l’architecture : export BigQuery + filtrage manuel, ou plusieurs vues de rapport dans Looker Studio.

Les Goals UA doivent être remappés

Les « objectifs » (Goals) UA deviennent des « événements de conversion » (Conversion Events) dans GA4.

La configuration change aussi. Un Goal UA peut être « visiter une page », « rester plus de X minutes », « déclencher un événement ». Un événement de conversion GA4 ne peut être que « un événement se produit » — pour suivre une visite de page comme conversion, configurez d’abord un événement page_view, puis marquez-le comme conversion.

Lors de la migration, listez vos Goals UA un par un et remappez-les en événements de conversion GA4. C’est fastidieux mais nécessaire — sinon, la continuité des données de conversion est perdue.

Pour conclure

En résumé, quatre points essentiels :

1. Suivi d’événements : comprendre les trois types (automatique, recommandé, personnalisé) et configurer par ordre de priorité
2. Entonnoirs de conversion : repérer les points de fuite, comparer les segments, utiliser Open Funnel pour découvrir les parcours atypiques
3. Export BigQuery : configurez tôt si vous avez des besoins d’analyse approfondie — les données historiques ne peuvent pas être rétroactivement importées
4. État d’esprit de migration : n’appliquez pas les métriques UA à GA4, adaptez-vous à la nouvelle logique

Si vous ne deviez faire qu’une chose après avoir lu cet article : ouvrez GA4, vérifiez qu’Enhanced Measurement est activé, puis créez un entonnoir de 3 à 4 étapes pour analyser votre flux d’abonnement blog.

Les données ne vous donneront pas la réponse toute faite, mais elles vous indiqueront où se situe le problème. À vous de trouver la solution.

Références

• Set up events | Google Analytics | Google for Developers — Documentation officielle de configuration des événements GA4
• Recommended events - Analytics Help — Liste des événements recommandés
• Enhanced measurement events - Analytics Help — Documentation des événements automatiques
• Funnel Exploration Report in GA4 - Analytics Mania — Guide détaillé du rapport d’entonnoir
• GA4 BigQuery Export Schema Tutorial - Optimize Smart — Tutoriel d’export BigQuery