Parce que le tracking de site web est plus commun que le tracking d’application mobile, cette formation est axée sur l’utilisation Google Analytics 4 pour un site web.
Google Tag Manager étant le TMS le plus populaire du marché, nous avons choisi ce dernier pour le déploiement de Google Analytics 4 dans les cas pratiques concernés.
Les cas pratiques de cette formation sont orientés sur le tracking Client-Side, si vous voulez en savoir plus sur le tracking Server-Side, voici une formation sur le sujet :
Nous retrouvons 2 sous-ensembles d’analyse dans la web analyse :
L’analyse de l’acquisition marketing sur un site web
L’analyse du comportement des utilisateurs sur un site web (digital product analytics)
L’objectif de l’analyse de l’acquisition marketing sur un site web est de répondre à des questions comme :
Quelles sont les campagnes, groupes d’annonces, annonces et pages d’entrée les plus performantes en termes de trafic, % de conversion, conversion, chiffre d’affaires, ROAS, LTV, CPA, etc ?
Quelles campagnes, groupes d’annonces, annonces et pages d’entrée ont enregistré une importante baisse de performance ce mois-ci par rapport au mois dernier en termes de trafic, % de conversion, conversion, chiffre d’affaires, ROAS, LTV, CPA, etc ?
L’objectif de l’analyse du comportement des utilisateurs sur un site web (digital product analytics) est de répondre à des questions comme :
Combien de temps passent en moyenne les utilisateurs sur le site web ?
Quelles sont les pages d’un site web les plus performantes en termes de nombre de vues, temps moyen passé, % scroll, etc ? (exemple de digital product = site web média)
Quelles sont les fonctionnalités d’un site web les plus (ou les moins) utilisées ? Pourquoi ? (exemple de digital product = site web SaaS)
À quel moment dans le funnel de vente d’un produit spécifique d’un site web les utilisateurs abandonnent leur parcours d’achat ? Pourquoi ? (exemple de digital product = site web e-commerce)
Google Analytics 4 est une solution web analytics permettant de mener à bien ces 2 sous-ensembles d’analyse !
Une question qui revient assez souvent est : “est-ce toujours intéressant de faire de la web analyse avec les pertes de données liées aux consentements utilisateur, adblockers, sécurités navigateur, etc ?”
En web analyse, nous ne cherchons pas forcément une vision exacte de la réalité. Nous cherchons plutôt à suivre des tendances reflétant la réalité afin de valider/invalider des hypothèses.
Par exemple, si avec une perte de données équivalente entre les périodes d’analyse distincte t1 et t2 votre taux de conversion passe de 1% (t1) à 5% (t2) après avoir réalisé des actions pour l’améliorer, vous pouvez affirmer que l’hypothèse “les actions menées ont permis d’améliorer le taux de conversion” est valide.
À cela s’ajoute le fait que tracking Server-Side permet de diminuer la perte de données liée aux adblockers !
Vous l’aurez compris, même si vous ne collectez pas 100% des données, il est effectivement toujours intéressant de faire de la web analyse !
Téléchargez notre formation sur Google Analytics 4 (version longue)
Les inconvénients et avantages de Google Analytics 4
Voici les principaux inconvénients et avantages de Google Analytics 4 :
Inconvénients
Le contexte légal actuel énoncé ci-dessus n’est pas rassurant et peut induire chez certaines personnes un sentiment d’incertitude désagréable. Cependant, il est très probable que des évolutions favorables émergent dans les prochains mois
Le produit n’étant pas terminé, à date (mars 2023), les rapports de l’interface ne procurent pas beaucoup de flexibilité dans les visualisations/analyses. Cependant, le produit est en perpétuelle évolution et devrait s’améliorer avec le temps. L’explorateur permet tout de même une bonne flexibilité dans les visualisations/analyses ad hoc rapides
Le connecteur natif Google Analytics 4 de Looker Studio ne procure pas beaucoup de flexibilité dans les visualisations/analyses. Cependant, cela devrait également s’améliorer avec le temps
Les quotas API du connecteur natif Google Analytics 4 de Looker Studio sont très rapidement atteints, ce qui vient perturber la visualisation des données issues de ce connecteur. Dans certains cas, les rapports utilisant ce connecteur deviennent quasiment inutilisables
Google Analytics 4 ne propose pas de tracking pouvant être exempté au consentement de l’utilisateur
La solution étant gratuite, le support n’est pas au rendez-vous
Avantages
La solution est gratuite
La communauté est très grande ce qui permet de répondre facilement aux questions/problèmes pouvant faire face
Le déploiement de Google Analytics 4 en Server-Side est extrêmement simplifié grâce aux autres produits de Google (Google Tag Manager Server-Side, Google App Engine, etc)
La possibilité d’exporter facilement et automatiquement les données de Google Analytics 4 dans BigQuery ainsi que la connexion native entre Looker Studio et BigQuery confère une flexibilité sans limites dans les visualisations/analyses. En effet, avec un peu de SQL vous pouvez manipuler les données comme bon vous semble, les consolider avec des données provenant d’autres sources (données CRM, données publicitaires, données back-office, etc) et les visualiser sur Looker Studio. En procédant ainsi, vous vous offrez des rapports Looker Studio automatisés, rapides (contre des rapports souvent très lents si vous ne passez pas par BigQuery), non soumis aux éventuels quotas API et répondant parfaitement à vos besoins
Depuis peu (21 février 2023) Google a rendu possible l’export automatique des données Google Search Console dans BigQuery (identique à l’export automatique des données Google Analytics 4 dans BigQuery). Cette fonctionnalité confère un énorme gain de temps, et beaucoup d’opportunités pour les analyses/visualisations (consolidation des données Google Analytics 4 et Google Search Console)
De manière générale, les connexions natives de Google Anlaytics 4 avec les autres produits de Google sont un réel plus (Google Search Console, Google Ads)
Le modèle de données sur lequel est fondé Google Analytics 4 est moderne. Il se base sur les événements et les utilisateurs. Sa structure simple et normée facilite grandement la reconstruction des parcours clients complexes (plusieurs sessions, plusieurs appareils, plusieurs plateformes). Ce modèle est qualifié de moderne, car il répond mieux à la complexification des parcours clients actuels que l’ancien modèle (celui de Google Analytics 3)
Les principales différences entre Google Analytics 3 et Google Analytics 4
Google a construit Google Analytics 4 sur la base de la propriété app + web issue de Google Analytics For Firebase.
Cette nouvelle version peut collecter dans une seule propriété les données relatives aux sites web et aux applications mobiles d’un même business.
Google Analytics 4 centralise la collecte et le stockage des données provenant des différentes plateformes (site web, application mobile) de la même manière, avec un modèle de données commun, établi sur des événements. L’objectif principal étant de simplifier, rationaliser et flexibiliser la collecte, le traitement et l’analyse des données issues des différentes plateformes.
Ce “modèle de données commun, établi sur des événements” est le fondement conceptuel majeur de Google Analytics 4.
Sans plus attendre, voici une liste non exhaustive des principales différences entre Google Analytics 3 et Google Analytics 4.
Google Analytics 4 est fondé sur un modèle de données différent
Alors que Google Analytics 3 utilisait un modèle de données vieux de plus de 15 ans (Urchin) établi sur les sessions et les pages vues, Google Analytics 4 est établi sur les utilisateurs et les événements. Mais ne vous inquiétez pas, les sessions (même si elles sont comptabilisées d’une façon légèrement différente) existent toujours sur l’interface.
Dans cette dernière version, la collecte des données est donc exclusivement réalisée par l’intermédiaire d’événements, et chaque événement dispose d’un ou plusieurs paramètres (informations additionnelles sur l’événement). Ces paramètres peuvent être divisés en paramètres collectés automatiquement et en paramètres personnalisés (plus d’informations sur les paramètres dans la suite de cette formation).
Ainsi, dans Google Analytics 4, une page vue est un hit de type événement à multiples paramètres (page_location, page_referrer, page_title, etc). Ce n’est plus un hit de type page vue distinct d’un hit de type événement comme dans Google Analytics 3.
À savoir, dans cette dernière version, nous ne retrouvons pas la nomenclature d’événement “catégorie – action – libellé – valeur” que nous retrouvions dans Google Analytics 3.
Google Analytics 4 propose une connexion native et gratuite avec BigQuery
Google propose une connexion native entre BigQuery et Google Analytics 4. Cette connexion vous permet d’exporter gratuitement et automatiquement tous les événements bruts d’une propriété Google Analytics 4 dans BigQuery chaque jour. Voici une documentation sur le sujet :
Cette fonctionnalité était anciennement disponible uniquement pour Google Analytics 3 360.
Comme énoncé un peu plus haut, la possibilité d’exporter facilement et automatiquement les données de Google Analytics 4 dans BigQuery ainsi que la connexion native entre Looker Studio et BigQuery confère une flexibilité sans limites dans les visualisations/analyses.
L’autre avantage non négligeable est que les éventuels quotas, l’échantillonnage et les potentiels calculs approximatifs (algorithme HyperLogLog++) pouvant s’appliquer sur l’interface de Google Analytics 4 ne s’appliquent pas aux données brutes exportées dans BigQuery.
Par exemple, si vous avez dépassé le nombre maximal de paramètres d’événement pour un événement (25), vous n’en aurez que 25 de disponibles sur l’interface de Google Analytics 4, mais tous ces paramètres seront quand même exportés et disponibles dans BigQuery.
Voici 2 documentations relatives aux limites de Google Analytics 4 :
Google Analytics 4 permet un tracking cross-device et cross-platform
En plus du tracking cross-device (mobile, desktop, tablette) déjà possible sur Google Anlaytics 3, Google Analytics 4 permet un tracking cross-platform (site web, application mobile).
L’ancienne version de Google Analytics permettait de suivre un même utilisateur sur plusieurs appareils, mais uniquement si la plateforme utilisée par les différents appareils était un site web. La dernière version quant à elle permet de suivre un même utilisateur sur plusieurs appareils, peu importe la plateforme utilisée.
Cette possibilité est offerte grâce à l’user_id (déjà présent dans Google Analytics 3), permettant de rattacher à un utilisateur individuel un identifiant issu d’une plateforme tierce (identifiant client CMS e-commerce, identifiant de login, identifiant CRM, etc). Mais également parce qu’il est possible de d’intégrer différents flux de données provenant de différentes plateformes dans une seule est unique propriété Google Analytics 4.
Google Analytics 4 permet ainsi à un business d’avoir une vision holistique de la relation qu’un utilisateur entretient avec lui en offrant la possibilité de reconstruire des parcours clients multisession, cross-device et cross-platform.
Google Analytics 4 calcule différemment les sessions
Dans Google Analytics 3, une session était une période qui englobait plusieurs hits (événements, pages vues, transaction e-commmerce, etc). C’était en quelque sorte une métrique générée du côté de Google en aval.
Dans cette ancienne version :
Une session n’était pas issue d’un hit de type événement
Une session se terminait après 30 minutes d’inactivité (aucun hit envoyé)
Une session qui s’étendait sur 2 jours (en passant minuit) était comptabilisée une fois pour chaque jour (soit 2 fois)
Une session se terminait et une nouvelle était générée si un utilisateur arrivait par l’intermédiaire d’une campagne X, s’en allait, puis revenait par l’intermédiaire d’une campagne Y
Dans Google Analytics 4, une session est enregistrée lors du déclenchement de l’événement session_start (événement collecté automatiquement) auquel sont rattachés les identifiants ga_session_id et ga_session_number. L’événement session_start n’est pas écrit tel quel dans le event_name d’un hit. Pour l’identifier dans la console network d’un navigateur, vous devez chercher un événement avec le paramètre _ss = 1 :
Le payload de ce hit (requête HTTP) indique que l’événement page_view a démarré une nouvelle session, car le paramètre _ss = 1.
Dans cette dernière version :
Une session est issue du hit de type événement session_start auquel sont rattachés les identifiants ga_session_id et ga_session_number
Par défaut, une session se termine après 30 minutes d’inactivité (ce délai d’expiration peut être modifié)
Une session qui s’étend sur 2 jours (en passant minuit) est comptabilisée qu’une fois
Une session ne se termine pas si un utilisateur arrive par l’intermédiaire d’une campagne X, s’en va, puis revient par l’intermédiaire d’une campagne Y
Ainsi, en raison de ces différences, le nombre de sessions pour un même site web sur Google Analytics 3 peut être supérieur à celui de Google Analytics 4.
Il est possible de calculer comme bon vous semble les sessions en passant par BigQuery.
Google Analytics 4 calcule différemment les conversions
Dans Google Analytics 3, une conversion était comptabilisée une fois par session. Ainsi, si un visiteur réalisait une conversion plusieurs fois au cours de la même session, une seule conversion était comptabilisée.
Dans Google Analytics 4, une conversion est comptabilisée à chaque fois qu’elle se produit (qu’il s’agisse de la même session ou non). Ainsi, 3 soumissions de formulaire (la soumission de formulaire étant une conversion) au cours de la même session comptabilisent 3 conversions.
Il est possible de calculer comme bon vous semble les conversions en passant par BigQuery.
Google Analytics 4 intègre de nouvelles métriques d’engagement
Dans cette dernière version, nous retrouvons 4 noms de métrique absents dans l’ancienne version.
Les sessions avec engagement : Le nombre de sessions qui ont duré plus de 10 secondes, ou qui ont enregistré au moins une conversion, ou qui ont enregistré plus de 2 événements page_view sur une période donnée
La durée d’engagement moyenne par session : la durée moyenne des sessions sur une période donnée (plus d’informations sur le calcul dans la suite de cette partie théorique)
Les sessions avec engagement par utilisateur : Le nombre de sessions avec engagement par utilisateur sur une période donnée (nombre de sessions avec engagement / nombre d’utilisateurs)
Le taux d’engagement : Le pourcentage de sessions engagées sur une période donnée (nombre de sessions avec engagement * 100 / nombre de sessions)
Le calcul de ces métriques est rendu possible par la collecte de l’événement user_engagement ainsi que le paramètre d’événement engagement_time_msec.
L’événement user_engagement (événement collecté automatiquement) est un événement collecté lorsqu’un utilisateur quitte votre site web ou accède à une autre page de ce même site.
Lorsqu’un événement page_view est collecté à l’ouverture d’une page, la balise Google Analytics 4 active “un chronomètre” (en millisecondes). À chaque autre événement collecté sur cette même page (sauf les événements first_visit et session_start), le paramètre engagement_time_msec est associé à l’événement concerné avec la valeur du chronomètre. Lorsque le paramètre engagement_time_msec est collecté, le chronomètre recommence à 0. Ce paramètre n’est pas collecté lorsqu’il n’y a pas de temps d’engagement depuis l’événement précédent de la session concernée.
Voici un exemple proposé par Google afin de mieux comprendre l’événement user_engagement ainsi que le paramètre d’événement engagement_time_msec :
Dans cet exemple, la durée de la session est égale à (8781 + 11856 + 6677 + 7711) / 1000, soit 36 secondes.
De manière générale, la durée d’engagement moyenne par session sur une période donnée est égale à la somme des user_engagement_msec divisés par le nombre de sessions et divisés par 1000.
Il est possible de calculer comme bon vous semble les différentes métriques d’engagement en passant par BigQuery.
Google Analytics 4 calcule différemment les métriques de rebond
Dans Google Analytics 3, un rebond est comptabilisé lorsqu’une session est initiée par un hit de type page_view et qu’aucun autre hit n’est envoyé par la suite. Une session avec rebond a une durée de 0 seconde. Le taux de rebond représente le pourcentage des sessions avec rebond sur une période donnée.
Dans Google Analytics 4, un rebond correspond une session sans engagement. Le taux de rebond représente le pourcentage des sessions sans engagement sur une période donnée.
Les métriques de rebond ne sont pas présentes nativement dans les rapports, vous devez personnaliser les rapports concernés pour les ajouter (plus d’informations sur comment personnaliser un rapport dans la partie pratique).
Il est possible de calculer comme bon vous semble ces métriques de rebond en passant par BigQuery.
Du changement dans les métriques utilisateur principales du côté de Google Analytics 4
La métrique “Utilisateurs” dans Google Analytics 4 représente le nombre d’utilisateurs actifs sur une période donnée. Un utilisateur actif est un utilisateur ayant enregistré une session avec engagement, l’événement first_visite, ou le paramètre engagement_time_msec sur une période donnée. Dans Google Analytics 3 la métrique “Utilisateurs” représente le nombre total d’utilisateurs sur une période donnée.
La métrique “Nombre total d’utilisateurs” dans Google Analytics 4 représente le nombre total d’utilisateurs uniques qui ont enregistré un événement sur une période donnée. Dans Google Analytics 3 la métrique qui correspond le plus à cette définition est la métrique “Utilisateurs” citée juste au-dessus. La métrique “Nombre total d’utilisateurs” n’est pas présente nativement dans les rapports, vous devez personnaliser les rapports concernés pour l’ajouter (plus d’informations sur comment personnaliser un rapport dans la partie pratique).
La métrique “Nouveaux utilisateurs” dans Google Analytics 4 représente le nombre total d’utilisateurs qui ont interagi avec votre site pour la première fois. Cette métrique correspond au nombre de nouveaux ID utilisateur qui ont enregistré l’événement first_visit. Dans Google Analytics 3 la métrique “Nouveaux utilisateurs” est similaire.
Il est possible de calculer comme bon vous semble ces métriques utilisateur en passant par BigQuery.
Du changement dans les dimensions personnalisées du côté de Google Analytics 4
Google Analytics propose nativement des dimensions et des métriques “basiques” adaptées à tout type de business. Cependant, chaque business à ses spécificités. Pour répondre à ces spécificités et permettre plus de flexibilité dans les analyses, Google Analytics permet de créer des dimensions et métriques personnalisées.
Ainsi, dans Google Analytics 4, les paramètres d’événement et propriétés utilisateur qualifiant respectivement les événements et utilisateurs peuvent servir à créer des dimensions personnalisées.
Ces paramètres et propriétés utilisateur ne sont pas nativement disponibles dans les rapports de Google Analytics 4. Si vous voulez pouvoir les utiliser facilement dans vos analyses (pour filtrer, comparer, etc), vous devez les déclarer en tant que métriques ou dimensions personnalisées.
Voici une documentation relative aux métriques et dimensions personnalisées :
Google Analytics 3 permettait la définition de 4 portées différentes pour un paramètre spécifique :
Hit
Session
Utilisateur
Item
En raison du changement de modèle énoncé un peu plus haut, à date (mars 2023), Google Analytics 4 n’en propose que 3 :
Hit (événement)
Utilisateur
Item
Un autre changement important à prendre en compte est la non-rétroactivité des dimensions personnalisées de portée utilisateur dans Google Analytics 4.
Dans Google Analytics 3, une dimension personnalisée de portée utilisateur (définie au milieu d’une session) était appliquée à chaque événement de la même session (y compris les événements enregistrés avant que la dimension ne soit définie). Dans Google Analytics 4, une dimension personnalisée de portée utilisateur est appliquée à tous les événements, mais à partir de ce moment particulier (pas de rétroactivité).
Il est possible de réaliser cette rétroactivité en passant par BigQuery.
Enfin, vous pouvez avoir jusqu’à 25 dimensions personnalisées de portée utilisateur dans une propriété Google Analytics 4 contre 20 dimensions personnalisées (toutes portées confondues) dans Google Analytics 4, ce qui est beaucoup plus.
Voici les limites concernant les métriques et dimensions personnalisées dur Google Analytics 4 :
Plus d’informations sur les paramètres d’événement, propriétés utilisateur, métriques personnalisées et dimensions personnalisées dans la suite de cette partie théorique et dans la partie pratique.
L’interface de Google Analytics 4 est différente
En raison de la différence dans leur modèle de données respectif, les interfaces de Google Analytics 3 et Google Analytics 4 sont différentes.
L’interface de Google Anlaytics 4 est beaucoup plus légère et ergonomique (moins de rapports, moins de métriques, moins de dimensions, etc)
Les rapports de Google Analytics 4 nécessitent une personnalisation (ajout manuel de métriques, de dimensions, de filtres, de comparaisons, etc) afin de répondre correctement à vos besoins en termes de visualisation et d’analyse.
Une bonne prise en main de cette nouvelle interface implique une légère courbe d’apprentissage et demande de la pratique.
À date (mars 2023) les rapports ne sont pas très flexibles, mais comme énoncé un peu plus haut, le produit est en perpétuelle évolution et devrait s’améliorer avec le temps. Comme énoncé également un peu plus haut, il est possible de passer outre ce manque de flexibilité en passant par BigQuery et Looker Studio.
Vous découvrirez davantage l’interface dans la partie pratique.
Voici la documentation de Google relative à l’interface :
Google Analytics 4 utilise des algorithmes de machine learning
Google a introduit plusieurs algorithmes de machine learning dans cette dernière version afin de pouvoir notamment :
Générer des insights mettant en évidence les tendances de performances
Prédire la probabilité d’une conversion
Prédire la probabilité de perte d’un utilisateur
Prédire les revenus
Améliorer son module de recherche interne
Mais ça ne s’arrête pas là !
D’après Google, ces algorithmes de machine learning, couplés aux données dont il dispose sur les détendeurs de compte Google (données Google Signal) permettront à terme, de faire fonctionner Google Analytics 4 sans cookies.
Cependant, une question se pose : quelle confiance et pertinence donner à ces données si nous n’avons aucune traçabilité ?
On attend une forte transparence de la part de Google sur ce point-là.
Google Analytics 4 supprime la limite des 10M de hits par mois
Contrairement à Google Analytics 3, Il n’y a aucune de limite de stockage de données dans Google Analytics 4.
L’ancienne version était limitée à 10 millions de hits par mois et par propriété, obligeant ainsi les sites web générant beaucoup de trafic à créer plusieurs propriétés spécifiques (sous-ensemble) pour un même site web ou à payer la licence Google Analytics 3 360.
Google Analytics 4 gère différemment l’échantillonnage des données
Google Analytics 3 activait l’échantillonnage des données dans les rapports lorsque qu’une requête agrégée plus de 500 000 sessions au niveau de la propriété sur la plage de date sélectionnée.
Dans Google Analytics 4, l’échantillonnage s’active dans les rapports lorsqu’une requête agrège plus de 10 000 000 événements sur la plage de date sélectionnée.
Google Analytics 4 supprime les vues personnalisées
Google Analytics 4 ne propose pas de vues personnalisées comme dans Google Analytics 3. Le filtrage des données s’effectue directement sur les rapports (avec les dimensions natives ou personnalisées).
Google Analytics 4 propose un tracking automatique de plusieurs interactions
À la différence de Google Analytics 3 où le code de suivi initial ne permet pas de collecter beaucoup de données nativement, le code de suivi initial de Google Analytics 4 permet de collecter (sans code supplémentaire) les interactions “primaires” d’un utilisateur avec le contenu d’un site web. Cela est rendu possible uniquement si les mesures améliorées sont activées.
Plus d’informations sur le tracking automatique de plusieurs interactions dans la partie pratique.
Google Analytics 4 facilite les analyses et visualisations ad hoc rapides
Nous retrouvons beaucoup moins de rapport dans Google Analytics 4 que dans Google Analytics 3 et la capacité d’analyse sur la majorité d’entre eux est, à date (mars 2023), assez limitée.
En revanche, cette dernière version propose une nouvelle fonctionnalité : l’explorateur de données !
L’outil d’exploration proposé dans cette dernière version nous donne accès à des analyses et visualisations non réalisables dans les rapports standards. Il nous permet d’explorer les données en détail et de répondre à des questions plus complexes.
Cet outil d’exploration existait déjà, mais uniquement, pour les utilisateurs de Google Analytics 3 360.
Cet outil reste cependant trop rigide pour se passer d’une solution de data visualisation externe comme Looker Studio. Surtout lorsqu’une consolidation avec d’autres données provenant d’autres sources (CRM, média, ERP, back-office, etc) doit être réalisée.
Tout ce qu’il faut retenir sur les événements Google Analytics 4
Google Analytics 4 dispose de 4 types d’événements.
Les événements collectés automatiquement
Ils sont collectés lorsqu’un utilisateur réalise des interactions basiques avec votre site web.
Ces événements sont collectés automatiquement avec la balise de configuration (le code suivi) Google Analytics 4.
Parmi ces événements nous retrouvons par exemple :
page_view
first_visit
session_start
user_engagement
Voici la liste complète des événements collectés automatiquement ainsi que toutes les informations associées (plateforme, règle de déclenchement et paramètre) :
Les événements collectés par les mesures améliorées
Ils sont collectés lorsqu’un utilisateur réalise des interactions avec le contenu de votre site web.
Ces événements peuvent être collectés automatiquement avec la balise de configuration (le code suivi) Google Analytics 4. Il suffit juste d’activer ou non (indépendamment ou non) chacune de ces options de mesure dans la configuration du flux de données web concerné :
Défilements (scroll)
Clics sortants (click)
Site Search (view_search_results)
Interactions avec des formulaires (form_start, form_submit)
Engagement avec des vidéos (video_start, video_progress, video_complete)
Téléchargements de fichiers (file_download)
Voici la liste complète des événements pouvant être collectés par les mesures améliorées ainsi que toutes les informations associées (règle de déclenchement et paramètre) :
Les événements recommandés permettent de collecter des données supplémentaires relatives à un site web et d’activer certains rapports prédéfinis.
C’est par exemple dans cette typologie d’événement que nous retrouvons l’intégralité des événements e-commerce.
Comme ces événements nécessitent davantage de contexte pour être pertinents, ils ne sont pas collectés automatiquement avec la balise de configuration (le code suivi) Google Analytics 4. Pour les collectés il faudra utiliser la balise événement de Google Analytics 4.
Il est très important de respecter le nom des événements recommandés par Google pour le bon fonctionnement de certains rapports standards ainsi que des insights automatiques générés par les algorithmes de machine learning utilisés par Google.
Voici la liste complète des événements recommandés ainsi que les conditions de déclenchement associées :
Les événements personnalisés sont des événements spécifiques (différents des événements recommandés) que vous pouvez collecter. Ils ne sont pas collectés automatiquement avec la balise de configuration (le code suivi) Google Analytics 4. Pour les collectés il faudra utiliser la balise événement de Google Analytics 4.
Voici les limites relatives aux événements à retenir :
Voici les règles relatives à la dénomination des événements :
Tout ce qu’il faut retenir sur les paramètres d’événements Google Analytics 4
Comme énoncé un peu plus haut, chaque événement peut se voir attribuer de multiples paramètres (informations additionnelles sur l’événement). Il existe 3 “familles” de paramètres dans Google Analytics 4.
Les paramètres spéciaux
Ce sont des paramètres collectés et associés automatiquement à chaque hit contenant des informations permettant à Google Analytics 4 de créer les dimensions et métriques principales en aval.
Voici une documentation référençant (entre autres) tous les paramètres spéciaux :
Vous pouvez collectés et associés des paramètres personnalisés à vos événements.
Les paramètres personnalisés se présentent sous 2 formes dans un hit :
Les paramètres de texte commençant par ep. lorsque la valeur définie pour le paramètre n’est pas un nombre
Les paramètres numériques commençant par epn. lorsque la valeur définie pour le paramètre est un nombre
La principale différence est que les paramètres de texte peuvent être utilisés comme dimensions personnalisées dans Google Analytics 4 et que les paramètres numériques peuvent être utilisés comme métriques personnalisées.
Les propriétés utilisateur
Les propriétés utilisateur sont également des paramètres personnalisés que vous pouvez collectés et associés à vos événements. Comme l’indique Google :
Elles sont identifiables par le préfixe up. dans un hit et doivent être enregistrées dans l’interface sur l’interface Google Analytics 4 en tant que dimensions personnalisées pour être disponibles dans les rapports (plus d’informations sur comment définir une dimension personnalisée dans la partie pratique).
Partie 2 : Google Analytics 4 (la pratique)
Téléchargez notre formation sur Google Analytics 4 (version longue)
Comme énoncé au début de cette formation, les cas pratiques qui suivent nécessitent un minimum de connaissances sur Google Tag Manager, voici donc une formation sur le sujet :
Vous avez déjà un compte Google. Si ce n’est pas le cas, rendez-vous ici (c’est vraiment très simple)
Vous avez déjà un compte Google Analytics ainsi qu’une propriété Google Analytics 4 et un flux de données web. Si ce n’est pas le cas, rendez-vous ici (c’est vraiment très simple).
Vous avez déjà un compte Google Tag Manager ainsi qu’un conteneur web intégré correctement sur toutes les pages de votre site web. Si ce n’est pas le cas, rendez-vous ici (c’est vraiment très simple). Tout est également expliqué dans la formation sur Google Tag Manager partagée ci-dessus.
Dans ces cas pratiques, pour simplifier la compréhension, nous n’avons pas intégré le consentement des utilisateurs dans le déclenchement des balises. Il va de soi que c’est quelque chose que vous devez faire pour être conforme au RGPD.
De notre côté, le site web utilisé (traqué) est boryl.fr.
Traquer les événements natifs avec Google Analytics 4 et Google Tag Manager (cas pratique 1)
L’objectif de ce cas pratique est de créer la balise de configuration Google Analytics 4 sur Google Tag Manager afin de traquer les événements “basiques” (page_view, first_visit, session_start, etc).
Pour ce faire :
Copiez votre identifiant de mesure G-XXXXXXXXXX (rendez-vous sur votre propriété Google Analytics 4 > Administration > Flux de données, et cliquez sur le flux de données concerné)
Activez les mesures améliorées de votre choix (rendez vous sur votre propriété Google Analytics 4 > Administration > Flux de données, et cliquez sur le flux de données concerné)
Collez votre identifiant de mesure G-XXXXXXXXXX dans une variable constante de Google Tag Manager. Cette variable est une variable définie par l’utilisateur (rendez-vous sur votre conteneur Google Tag Manager > Variables)
Créez la balise de configuration Google Analytics 4 et associez-lui le déclencheur page vue (rendez-vous sur votre conteneur Google Tag Manager > Balises)
Voilà, c’est terminé, il ne restera plus qu’à publier le conteneur Google Tag Manager après vérification du tracking (cas pratique 3 et 4).
Traquer un événement spécifique avec Google Analytics 4 et Google Tag Manager (cas pratique 2)
L’objectif de ce cas pratique est de créer une balise événement Google Analytics 4 sur Google Tag Manager afin de traquer un événement spécifique.
De notre côté, nous traquons les envois de formulaire (événement recommandé sous le nom generate_lead) réalisés sur cette page :
Pour rappel, la meilleure façon de traquer des événements est d’utiliser le déclencheur sur événement personnalisé qui “écoute” le dataLayer et déclenche les balises concernées lorsqu’un événement spécifique est envoyé dans ce dernier par le back-office et que toutes les autres potentielles conditions sont remplies. Les événements spécifiques à envoyer dans le dataLayer sont normalement (si le travail est bien fait) définis dans un plan de taggage.
Ainsi, de notre côté, un événement (form_submitted) est envoyé dans le dataLayer depuis le back-office lorsqu’un envoi de formulaire est réalisé avec succès.
Pour traquer un événement spécifique :
Créez le déclencheur adapté (rendez-vous sur votre conteneur Google Tag Manager > Déclencheurs)
Créez une balise événement Google Analytics 4 et associez-lui le déclencheur que vous venez de créer (rendez-vous sur votre conteneur Google Tag Manager > Balises)
Voilà, c’est terminé, il ne restera plus qu’à publier le conteneur Google Tag Manager après vérification du tracking (cas pratique 3 et 4).
Vérifier le tracking réalisé (cas pratique 3)
L’objectif de ce cas pratique est de vérifier que le travail réalisé fonctionne correctement (que les balises sont déclenchées au bon moment et que les données qui y sont associées sont complètes et correctes.)
Pour réaliser cette vérification, vous pouvez utiliser le mode de prévisualisation de Google Tag Manager.
Pour ce faire, rendez-vous sur votre compte et conteneur Google Tag Manager, cliquez sur “Prévisualiser” en haut à droite et renseignez l’URL de votre site web. Vous devriez arriver sur une page comme celle-ci :
De notre côté, si nous réalisons plusieurs interactions (y compris l’envoi d’un formulaire), nous pouvons voir que les 2 balises créées dans les cas pratiques précédents se déclenchent correctement.
Si nous cliquons sur la balise “GA4 – Generate Lead (formation)”, nous pouvons également voir que le nom d’événement qui remonte dans Google Analytics 4 est correct (generate_lead) :
Pour réaliser cette vérification, vous pouvez également utiliser le mode DebugView de Google Analytics 4.
Pour ce faire, laissez le mode de prévisualisation de Google Tag Manager activé et rendez-vous sur votre propriété Google Analytics 4 > Administration > DebugView. Vous devriez arriver sur une page comme celle-ci :
De notre côté, si nous réalisons plusieurs interactions (y compris l’envoi d’un formulaire), nous pouvons voir que les événements attendus remontent bien dans Google Analytics 4.
Voilà, c’est terminé, il ne restera plus qu’à publier le conteneur (cas pratique 4).
Publier le tracking réalisé (cas pratique 4)
L’objectif de ce cas pratique est de déployer un tracking en production, en publiant une nouvelle version d’un conteneur Google Tag Manager.
Pour ce faire, rendez-vous sur votre compte et conteneur Google Tag Manager, cliquez sur “Envoyer” en haut à droite, renseignez les informations demandées puis cliquez sur “Publier”.
Marquer comme conversion un événement sur Google Analytics 4 (cas pratique 5)
L’objectif de ce cas pratique est de marquer comme conversion un événement sur Google Analytics 4 afin (entre autres) de remplir certains rapports (ex : le rapport conversions) et d’accéder au taux de conversion.
Une conversion est une interaction importante que vous souhaitez que vos utilisateurs effectuent. Les conversions peuvent être divisées en micro conversions (ex : abonnement à une newsletter) et macro conversions (ex : achat d’un produit).
Pour marquer comme conversion un événement, rendez-vous sur votre propriété Google Analytics 4 > Administration > Événements, puis activez les événements concernés (sur la droite).
Créer une dimension personnalisée sur Google Anlytics 4 (cas pratique 6)
L’objectif de ce cas pratique est de créer une dimension personnalisée sur Google Analytics 4 afin de pouvoir utiliser facilement un paramètre d’événement ou une propriété utilisateur dans les rapports concernés (pour filtrer, comparer, etc).
Pour créer une dimension personnalisée, rendez-vous sur votre propriété Google Analytics 4 > Administration > Définitions personnalisées, cliquez sur “Créer des dimensions personnalisées”, renseignez les informations demandées puis enregistrez.
Personnaliser un rapport sur Google Analytics 4 (cas pratique 7)
L’objectif de ce cas pratique est de personnaliser le rapport “Page de destination” en ajoutant la métrique “Taux de rebond” non présente initialement.
Pour ce faire, rendez-vous sur votre propriété Google Analytics 4 > Rapports > Engagement > Page de destination, cliquez sur “Personnaliser le rapport” (en haut à droite), cliquez sur “Métriques”, ajoutez la métrique de votre choix puis enregistrez.
Réaliser une exploration sur Google Analytics 4 (cas pratique 8)
L’objectif de ce cas pratique est de créer une exploration qui montre comment les utilisateurs progressent dans un funnel e-commerce pour un item (produit) donné.
Vous pouvez utiliser le compte de démonstration de Google Merchandise Store si vous ne disposez pas d’une propriété Google Analytics 4 avec des données e-commerce. Voici une documentation sur le sujet :
Pour créer cette exploration, rendez-vous sur votre propriété Google Analytics 4 > Explorer, cliquez sur “le +”, et appliquez la configuration suivante :
