Cette formation sur Google Analytics 4 (GA4) vous permet :
De choisir la solution web analytics qu’il vous faut (Google Analytics 4, Piano Analytics, Matomo, Piwik Pro, etc) en se basant sur les aspects légaux ainsi que sur les avantages et inconvénients de chaque solution ;
D’assimiler parfaitement les concepts fondamentaux de Google Analytics 4 ;
De déployer un tracking Google Analytics 4 primaire (configuration initiale + tracking d’un événement spécifique) ;
D’assimiler parfaitement le fonctionnement de la visualisation des données Google Analytics 4 avec BigQuery et Looker Studio ;
De créer une première visualisation de données Google Analytics 4 (automatisée) en passant par BigQuery et Looker Studio.
Les cas pratiques de cette formation nécessitent un minimum de connaissances sur Google Tag Manager, Looker Studio et BigQuery, voici donc respectivement 3 formations sur ces sujets :
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 :
Google Analytics 4 (GA4) est la dernière version de l’outil d’analyse de données web (et mobile) proposé par Google. Il s’agit d’une évolution majeure par rapport à la version précédente, Google Analytics 3 (Universal Analytics ).
Cet outil permet aux propriétaires de sites web et d’applications mobiles de collecter, mesurer et analyser des données sur le comportement des utilisateurs. L’objectif principal de Google Analytics 4 est de fournir des informations précieuses sur la façon dont les visiteurs interagissent avec un site web ou une application, afin d’optimiser les performances, d’améliorer l’expérience utilisateur et d’atteindre les objectifs business.
Google Analytics 4 permet de mener à bien 2 sous-ensembles de 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)
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 (août 2023) peut induire chez certaines personnes un sentiment d’incertitude désagréable ;
Le produit n’étant pas terminé, à date (août 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 ;
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) 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.
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.
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èrent 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.
Voici 2 documentations relatives aux limites de Google Analytics 4 :
Nous reviendrons sur la connexion native entre BigQuery et Google Analytics 4 dans la partie cas pratique de cette formation.
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 d’intégrer différents flux de données provenant de différentes plateformes dans une seule et 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.
Du changement dans la comptabilisation des 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) n’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.
Du changement dans la comptabilisation des 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, initialement, 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 induisent 3 conversions. Cependant, il est maintenant possible de modifier la méthode de comptabilisation et de définir la même que dans Google Analytics 3, plus d’informations ici :
Il est possible de calculer comme bon vous semble les conversions en passant par BigQuery.
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 votre 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ée par le nombre de sessions, le tout lui même divisé par 1000.
Il est possible de calculer comme bon vous semble les différentes métriques d’engagement en passant par BigQuery.
Du changement dans la comptabilisation des 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
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
Google Analytics propose nativement des dimensions et des métriques “basiques” adaptées à tout type de business. Cependant, chaque business a 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 (août 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 3, 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.
Du changement sur l’interface utilisateur
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 (août 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 :
Introduction de plusieurs 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 des 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à.
Suppression de la limite des 10M de hits par mois
Contrairement à Google Analytics 3, Il n’y a aucune 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.
Du changement dans l’échantillonnage des données
Google Analytics 3 activait l’échantillonnage des données dans les rapports lorsque qu’une requête agrégeait plus de 500 000 sessions au niveau de la propriété sur la plage de dates 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 dates sélectionnée.
Suppression des 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).
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.
Des analyses et visualisations ad hoc facilitées.
Nous retrouvons beaucoup moins de rapports dans Google Analytics 4 que dans Google Analytics 3 et la capacité d’analyse sur la majorité d’entre eux est, à date (août 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.
Uniquement 2 modèles d’attribution
Les modèles d’attribution “first click”, “linear”, “position-based” et “time decay” anciennement disponibles sur Google Analytics 3 ne le sont pas sur Google Analytics 4. Cette dernière version propose uniquement les modèles d’attribution suivants :
Le modèle “last click” : Contrairement au modèle d’attribution data-driven qui prend en compte toutes les sources contributives et utilise des algorithmes de machine learning, ce modèle attribue tout le crédit de conversion à la dernière source de l’utilisateur concerné avant la conversion (ce modèle ignore les accès directs) ;
Le modèle “data-driven” : Contrairement aux modèles d’attribution traditionnels qui utilisent des règles prédéfinies, le modèle data-driven prend en compte toutes les sources contributives et utilise des algorithmes de machine learning.
Plus d’informations sur les modèles d’attribution de Google Analytics 4 ici :
Il est possible de créer vos propres modèles d’attribution en passant par BigQuery.
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 de 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énements 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 collecter 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 collecter 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 collecter et associer 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 collecter et associer à vos événements. Comme l’indique Google :
Elles sont identifiables par le préfixe up. dans un hitetdoivent être enregistrées 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, Looker Studio et BigQuery, voici donc respectivement 3 formations sur ces sujets :
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 ;
Vous avez déjà un compte de facturation BigQuery ainsi qu’un projet. Si ce n’est pas le cas, rendez-vous ici (c’est vraiment très simple). Tout est également expliqué dans la formation sur BigQuery 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 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 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.
Voici tout de même une documentation sur le sujet :
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 (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).
Voici tout de même une documentation sur le sujet :
Créer une dimension personnalisée (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.
Voici tout de même une documentation sur le sujet :
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.
Voici tout de même une documentation sur le sujet :
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 :
Voici tout de même une documentation sur le sujet :
Activer la connexion avec BigQuery (cas pratique 9)
L’objectif de ce cas pratique et d’activer la connexion native entre Google Analytics 4 et BigQuery afin d’exporter automatiquement tous les événements bruts d’une propriété Google Analytics 4 vers BigQuery.
Chaque jour, une exportation complète des événements de la journée passée a lieu. Cette exportation donne lieu à la création d’une nouvelle table de données brute “events_YYYYMMDD” dans l’ensemble de données concerné “analytics_123456789”. Les tables créées peuvent être mises à jour par Google Analytics dans les 72 heures suivant la création.
Il est possible d’activer une exportation en flux continu, afin d’obtenir les données du jour en quelques minutes, mais cette option implique des coûts supplémentaires et les données provenant de ce flux sont moins fiables.
Pour configurer la connexion entre BigQuery et Google Analytics 4, rendez-vous dans votre propriété Google Analytics 4 > Administration > Associations à BigQuery, cliquez sur “Associer”, renseignez les informations demandées puis cliquez sur “Envoyer”.
Vous n’avez pas besoin de créer un ensemble de données au préalable, il se crée automatiquement une fois que la connexion est établie (son nom sera “analytics_{id_propriété}” – “analytics_123456789”). En revanche, pensez à désactiver l’expiration des tables de cet ensemble de données qui est par défaut fixée à 60 jours.
Pour désactiver l’expiration des tables d’un ensemble de données, rendez-vous ici, cliquez sur l’ensemble de données concerné, cliquez sur “Modifier les détails”, décochez la case “Activer l’expiration de la table” puis cliquez sur “Save”.
Voici tout de même une documentation sur le sujet :
Créer et exécuter une requête SQL sur BigQuery (cas pratique 10)
L’objectif de ce cas pratique est de créer une première requête SQL donnant le nombre de sessions par jour depuis la date de la configuration de la connexion native entre une propriété Google Analytics 4 et BigQuery.
C’est une requête SQL très simple, mais essentielle (nous vous partagerons plein d’autres requêtes SQL Google Analytics 4 plus complexes tout au long de l’année 2023 😉).
Pour retrouver le nombre de sessions par jour, vous devez compter le nombre de concaténations “ga_session_id + user_pseudo_id” uniques et différentes par jour.
Vous devez utiliser l’ID “user_pseudo_id” en plus de “ga_session_id” car ce dernier n’est pas unique (c’est juste un horodatage du moment où l’événement “session_start” s’est produit). Ainsi, en concaténant les deux, vous aurez toujours un ID de session unique.
Voici la requête SQL :
Pour exécuter cette requête rendez-vous ici, cliquez sur “Saisir une nouvelle requête”, copiez-collez la requête en modifiant le “{projet}.{ensemble de données}”, vérifiez que le voyant est vert en haut à droite puis cliquez sur “Exécuter”.
Voici un aperçu du résultat de notre côté :
Automatiser l’exécution d’une requête SQL sur BigQuery (cas pratique 11)
L’objectif de ce cas pratique est de créer une table analysée “analysed_session” répertoriant les sessions par jour (cf. cas pratique précédent) et de la mettre à jour chaque matin à 6h avec les nouvelles données.
Les tables analysées sont généralement celles que nous connectons aux outils de data visualisation comme Looker Studio, Power BI ou encore Tableau.
Afin de limiter la consommation en puissance de calcul, et prendre en compte les éventuelles mis à jour de données dans le temps (le 72h énoncé un peu plus haut), il faut exécuter chaque jour une requête SQL qui :
Supprimera les données des 7 derniers jours de la table analysée “analysed_session” ;
Enverra les sessions par jour des 7 derniers jours vers la table analysée “analyses_session” depuis les tables de données brutes Google Analytics 4 concernées.
Avant tout, vous devez créer la table analysée “analysed_session” et envoyer l’historique des sessions par jour dans cette dernière en exécutant la requête du cas pratique précédent et modifiant les paramètres de requête.
Pour modifier les paramètres de requête, cliquez sur “Plus”, cliquez sur ”Paramètres de requête”, renseignez les informations comme ci-dessous en choisissant l’ensemble de données de votre choix, vérifiez que le voyant est vert en haut à droite, cliquez sur “Enregistrer” puis sur “Exécuter”.
À ce stade, votre table analysée est créée et l’historique envoyé. Il ne vous reste plus qu’à automatiser l’exécution de la requête ci-dessous afin de mettre à jour la table analysée chaque matin à 6h.
Pour planifier/automatiser l’exécution de cette requête SQL, cliquez sur “Planifier”, cliquez sur “Créer une nouvelle requête programmée”, renseignez les informations comme ci-dessous (07:00 UTC = 06:00 en France), vérifiez que le voyant est vert en haut à droite puis cliquez sur “Enregistrer”.
Visualiser le résultat d’une requête SQL BigQuery automatisée sur Looker Studio (cas pratique 12)
L’objectif de ce cas pratique est de visualiser dans Looker Studio (avec un graphique de série temporelle) les données de la table analysée “analysed_session” (résultat d’une requête SQL) créée dans le cas pratique précédent et mise à jour chaque jour.
Pour visualiser les données de la table “analysed_session” dans Looker Studio, rendez-vous ici, cliquez sur le “+”, cliquez sur BigQuey, sélectionnez la table “analysed_session”, cliquez sur “Ajouter”, puis créez et configurez un graphique de série temporelle avec “date” en dimension et “session” en métrique.
Voilà, vous venez de créer un graphique (basique) automatisé avec des données brutes issues de Google Analytics 4 !
Nous vous partagerons pleins d’autres requêtes SQL Google Analytics 4 plus complexes/avancées tout au long de l’année 2023 afin que vous puissiez construire un reporting/dashboard complet !
N’hésitez pas à nous envoyer un petit message si vous avez des questions 😉
Partie 3 : Une checklist exhaustive pour une configuration de Google Analytics 4 impeccable
Cette checklist se concentre uniquement sur la configuration au sein de l’outil Google Analytics 4 avec flux de données web. Nous partons du principe que vous avez déjà créé votre flux de données, intégré un plan de taggage et configuré votre gestionnaire de balises (Google Tag Manager par exemple).
Voici :
Vérifier que les données remontent dans Google Analytics 4 (plus d’informations ici)
Définir les accès et restrictions de données (plus d’informations ici)
Configurer les mesures cross-domaine si besoin (plus d’informations ici)
Définir les sites référents à ignorer (plus d’informations ici)
Exclure le trafic interne pour garder des données reflétant le plus possible la réalité (plus d’informations ici)
Vérifier que le fuseau horaire de la propriété est correct
Vérifier que la devise de la propriété est correcte
Vérifier que la rétention de données est à 14 mois (plus d’informations ici)
Activer les signaux Google (plus d’informations ici)
Activer la collecte de données précises sur l’appareil et la zone géographique (plus d’informations ici)
Activer et sélectionner les mesures améliorées souhaitées (plus d’informations ici)
Créer les différentes métriques personnalisées souhaitées (plus d’informations ici)
Créer les différentes dimensions personnalisées souhaitées (plus d’informations ici)
Créer les différentes conversions souhaitées (plus d’informations ici)
Définir la méthode de comptabilisation des conversions (plus d’informations ici)
Créer les groupements de canaux personnalisés souhaités (plus d’informations ici)
Activer la connexion entre Google Analytics 4 et Google Ads (plus d’informations ici)
Activer la connexion entre Google Analytics 4 et Google BigQuery (plus d’informations ici)
Activer la connexion entre Google Analytics 4 et Google Search Console (plus d’informations ici)
Choisir le modèle d’attribution à utiliser dans les rapports et la période d’analyse (plus d’informations ici)
Créer les audiences souhaitées (plus d’informations ici)
Créer les segments souhaités (plus d’informations ici)
Téléchargez notre formation sur Google Analytics 4 (version longue)
