Lorsqu’on parle de GA4, on se focalise souvent sur la collecte de données à proprement parler : Tag de configuration, events natifs, enhanced measurements, events custom, Consent Mode… De quoi vous faire quelques noeuds au cerveau pour comprendre les impacts réels de ce que vous faites dans votre Tag Manager sur les remontées finales dans votre interface GA4. Mais pas de souci de ce côté, vous êtes des pros.
En revanche, un aspect que l’on a souvent tendance à prendre par dessus la jambe est la gestion de la partie Administration dans GA4. En effet, contrairement au petit ange GA3 parti trop tôt (le 1er juillet à très exactement 9h du matin, ou très légèrement plus tard mais ne pinaillons pas), dans lequel l’administration était un sujet que l’on pouvait garder de côté sans trop culpabiliser, du moins pour des configurations assez simples, il est hors de question de laisser de côté cet aspect dans GA4.
La raison première est relativement simple : c’est un joli bazar. Les menus sont organisés avec une logique pour le moins obscure, il y a des menus, des sous-menus, et même (sans déconner) des sous-sous menus. Une partie des paramètres disponibles sont très peu importants, et certains impactent la collecte de données de façon drastique, pas toujours rétroactive, et ce sans que Google daigne ordonnancer tout ceci de façon intelligible. Intelligible pour un être humain, j’entends.
Donc, et puisque chez UnNest Data Consulting, nous sommes des gens consciencieux, pour tous nos audits GA4 et configuration de nouveaux comptes, nous avons dans notre grande mansuétude mis en place une checklist exhaustive des choix que nous faisons côté admin GA4, en complément de la collecte.
Il est important de noter que cette liste inclut des prises de position de notre part sur certains sujets qui peuvent ne pas faire l’unanimité.
Comptes
Vérifier la cohérence de l’architecture des comptes
Vérifier la logique de nommage des propriétés de compte
Vérifier les options de partage de données
Vérifier la signature du DPA (Data Processing Agreement)
Propriétés
Vérifier la cohérence de l’architecture des propriétés
Vérifier la logique de nommage des propriétés
Valider toutes les étapes de l'assistant de configuration pour créer la propriété
Vérifier les paramètres de la propriété (secteur, fuseau, ..)
Vérifier les accès à la propriété
Vérifier l'architecture de flux de données de chaque propriété
Flux de données
Désactiver les mesures améliorées (de préférence)
Désactiver les événements personnalisés (fortement recommandé)
Vérifier la gestion des codes secrets de l'API du protocole de mesure
Désactiver la détection automatique des événements
Balise Google
Configurer les domaines
Autoriser l'utilisation des données fournies par l'utilisateur
Désactiver la collecte des événements Universal Analytics
Définir le trafic interne (adresses IP)
Répertorier les sites référents à ignorer
Ajuster le délai avant expiration de la session si besoin
Configurer les cookies pour une durée de 13 mois non-glissants
Conversions
Valider la méthode de comptabilisation des conversion (session / event)
Définitions personnalisées
Définir les noms de dimension personnalisée
Ajouter la définition des dimensions
Paramètres des données
Conserver les données précises sur l'appareil et la zone géographique
Demander au client de cocher la Confirmation de la collecte de données utilisateur
Conserver la personnalisation des annonces seulement si le cliet exporte des audiences
Passer la conservation des données à 14 mois
Activer le filtre "Internal Traffic" présent par défaut en mode Test
Vérifier si les groupes de canaux par défaut sont pertinents pour le client
Identité de reporting
Passer en mode Device-Based
Paramètres d’attribution
Valider avec le client le modèle d’attribution des conversions (last-click, basé sur les données..)
Valider avec le client quels canaux peuvent se voir attribués des conversions
Valider avec le client les paramètres avancés selon sa stratégie d’acquisition
Associations produits Google
Vérifier liens Google Ads & publicité activée
Mettre en place export vers BigQuery dès que possible
Vérifier les autres associations Ad Manager, Display & Video 360, Merchant Center, Google Play, Search Ads 360
Sommaire
1. Gestion du CompteArchitectureLogique de nommageOptions “Paramètres de partage des données”Signature du DPA2. Gestion des propriétésArchitectureLogique de nommageAssistant de configurationParamètres de la propriétéGestion des accès à la propriétéFlux de donnéesArchitectureMesures amélioréesModifier les événements / Créer des événements personnalisésCodes secrets de l'API du protocole de mesureBalise Google ⇒ Détection automatique des événementsBalise Google ⇒ Configurer vos domainesBalise Google ⇒ Utilisation de données fournies par l'utilisateurBalise Google ⇒ Collecter les événements Universal AnalyticsBalise Google ⇒ Définir le trafic interneBalise Google ⇒ Répertorier les sites référents à ignorerBalise Google ⇒ Ajuster le délai avant expiration de la sessionBalise Google ⇒ Remplacer les paramètres des cookies3. Conversions4. Audiences5. Définitions personnalisées6. Paramètres des donnéesCollecte de donnéesConservation des donnéesFiltres de donnéesGroupes de canaux par défautGroupes de canaux custom7. Import de données8. Identité de reporting9. Paramètres d’attributionModèle d'attribution dans les rapportsCanaux auxquels le crédit peut être attribuéPériode de suivi des conversions10. Associations produits GoogleGoogle AdsBigQueryAutres produits publicitaires
1. Gestion du Compte
Architecture
Sauf cas très particulier, l’ensemble du setup Google Analytics d’un client (cela concerne GA3 également) doit être fait au sein d’un seul compte.
A noter que si ce schéma n’est pas respecté, il est toujours possible de migrer des propriétés d’un compte à un autre en utilisant le bouton “Déplacer la propriété” (en faisant attention aux questions des droits utilisateurs, cf. plus bas) :
Logique de nommage
Le nom du compte doit reprendre le nom de l’entreprise “parente” :
Options “Paramètres de partage des données”
Le paramétrage “Produits et services Google” doit être décoché (dans un passé lointain, ce paramétrage était problématique pour la CNIL sur GA3).
Les autres points liés au partage n’ont pas d’importance.
Signature du DPA
Le DPA doit être signé et validé par le client, et le contact juridique renseigné sur l’interface dédiée marketingplatform.google.com.
2. Gestion des propriétés
Architecture
Recommandation de base pour l’architecture des propriétés GA4 :
- L’ensemble des données de prod doit remonter au sein d’une seule propriété, quel que soit le nombre de sites, d’apps, de domaines, de pays…
- L’ensemble des données de “non prod” doit remonter dans une autre propriété, en faisant le routing au niveau du TMS. Cela inclut également les données de preview GTM (faire un routing GTM sur la base de la version du container)
L’ensemble de la configuration admin doit être, autant que possible, répliqué entre les 2 propriétés, pour avoir des remontées iso.
Dans certains cas, on peut choisir sharder ses données de prod, par pays, site, etc… :
- Pour restreindre les accès aux données à certaines personnes / groupes de personnes
- Si certains sites ont des objectifs de conversion très spécifiques, et donc un taux de conversion qui en dépend
- Si sait que l’on va toujours analyser de façon silotée une propriété en termes d’acquisition / taux de conversion… et que les différentes entités n’ont pas d’intérêt à être analysées de façon transverse.
- Si la propriété doit exporter des objectifs / audiences vers des comptes Google Ads particuliers
- Si les données sont exportées vers BigQuery et que le nombre d’events par jour peut dépasser les quotas :
Il faut bien garder en tête que, dans ce schéma “shardé”, les données seront plus complexes à réconcilier (User ID, etc…), et que le travail d’admin devra être répété sur l’ensemble des propriétés
Logique de nommage
Si la propriété collecte des données sur un seul domaine (ex : siteduclient.com), nommer la propriété sous la forme “siteduclient.com - Prod”, ou “siteduclient.com - Non Prod”.
Dans le cas contraire, nommer la propriété de la façon la plus explicite possible, selon l’écosystème (ex : nomDeLaMarque - Prod).
Assistant de configuration
Ces points n’ont aucun impact, mais s’assurer que l’ensemble des points sont marqués comme “terminés”.
Paramètres de la propriété
Catégorie sectorielle
S’assurer que la catégorie sectorielle est aussi proche que possible de la thématique du client (si des rapports de benchmark sont un jour disponibles dans GA4, ou si jamais cela venait à alimenter des rapports “IA” de comptes similaires).
Fuseau horaire
Si le trafic du site provient majoritairement d’un pays donné, penser à paramétrer le fuseau horaire et la devise en accord avec le pays en question.
Si la propriété collecte des données depuis un grand nombre de pays, utiliser le fuseau horaire de la maison mère
Gestion des accès à la propriété
Faire un checkup exhaustif des droits, et se renseigner auprès du client sur les adresses “suspicieuses” :
- Comptes génériques non nominatifs
- Anciennes agences
- Comptes Gmail
- Combinaisons diverses des 3 points précédents
Vérifier que les utilisateurs qui ont des droits “Administrateur”, et plus encore “Administrateur de l’entreprise” sont bien connus et vérifiés.
Flux de données
Architecture
Vérifier qu’il n’y a bien qu’un seul flux (stream) qui est créé par plateforme de collecte (Web / iOS / Android).
Il n’y a pas, a priori, de raison de créer plusieurs streams pour un même OS.
Mesures améliorées
Deux options sont possibles :
- Notre recommandation standard : ne pas les activer, et faire ce genre de mesures (scroll, players Youtube, téléchargement de fichiers…) via GTM, après avoir fait un recueil du besoin précis avec le client : c’est le cas le plus standard, et il est recommandé de le mettre en place autant que possible, en affinant.
- Les activer : à privilégier dans le cas où il faut démarrer une collecte minimaliste rapidement, et que l’on a pas immédiatement la main sur GTM pour faire les choses proprement. Il est possible de faire quelques exceptions en désactivant certaines mesures particulières.
Modifier les événements / Créer des événements personnalisés
Sauf cas particulier, ces 2 features ne doivent pas être utilisées : toute la logique de création d’événements doit être gérée au niveau de GTM, pour ne pas avoir des logiques dupliquées ou en conflit, et compliquer inutilement le debug
Codes secrets de l'API du protocole de mesure
- Vérifier si des tokens ont été générés, et le cas échéant, s’ils sont utilisés.
- Lors de la création de tokens, les nommer de façon aussi explicite que possible, en détaillant bien leur usage et la techno associée (”Conversions Offlines - Salesforce”)
- Les supprimer si ce n’est pas le cas, et monitorer d’éventuelles pertes de données
Aparté plutôt lié à la collecte de données : si un client utilise Measurement Protocol pour GA4, ajouter une custom dimension collection_method (par exemple) alimentée avec “front” et “MP” (ou similaire) afin de pouvoir à tout moment faire le distinguo entre les différents hits dans l’interface ou dans BigQuery
Balise Google ⇒ Détection automatique des événements
S’assurer que, tout comme Enhanced Measurements, ces événements sont désactivés, puisqu’on gère ces cas via GTM
Balise Google ⇒ Configurer vos domaines
Ce paramètre n’est important que si les données sont collectées sur plusieurs domaines. Dans le cas contraire, on peut par précaution indiquer le domaine principal (ex : siteduclient.com)
Utiliser des patterns aussi précis que possibles (utiliser les regex si cela rend la lecture plus claire)
Balise Google ⇒ Utilisation de données fournies par l'utilisateur
Cette option permet le transfert de données personnelles (listées ici : https://business.safety.google/adsservices/) entre les outils pour lesquels une balise Google est configurée (Google Analytics, Google Ads, …), lorsque l’utilisateur y consent.
S’assurer que l’option est désactivée si vous n’en avez pas l’utilité.
Balise Google ⇒ Collecter les événements Universal Analytics
A désactiver impérativement pour éviter les conflits avec d’éventuels tags UA envoyés en dur via Gtag (rare, mais peut être très problématique)
Balise Google ⇒ Définir le trafic interne
Toujours demander au client s’il est possible / facile d’identifier les adresses IP de ses locaux, et les exclure le cas échéant :
Bien penser dans la foulée à activer le filtre “Internal Traffic” au niveau du menu “Paramètres des données” (cf. plus bas).
Si besoin, utiliser le filtre en mode “Test” afin de s’assurer qu’il ne créé pas de régression
Balise Google ⇒ Répertorier les sites référents à ignorer
Toujours, en amont de l’implémentation, se renseigner sur les cas de “sortie” de site (e-commerce notamment, mais cela peut aussi être des formulaires CRM ou autre), et vérifier s’ils sont renseignés :
Dans le cas (très fréquent) où les domaines de paiement sont difficiles à identifier de façon précise (cf. 3D Secure), il est préférable de passer par un override du paramètre “page_referrer” sur la page de confirmation, si l’on est capable d’identifier de façon précise la page en question (via son URL, un attribut data layer, ou autre) :
javascriptfunction(){ var url = {{URL - Chemin sans params}} , ref = document.referrer; if (url.includes('/checkout/onepage/success/')){ //Identifier le pattern ici ref = null; } return ref; }
Il est inutile d’ajouter son propre domaine à la liste des sites référents à ignorer
Balise Google ⇒ Ajuster le délai avant expiration de la session
Sauf demande expresse du client, conserver le paramétrage par défaut pour la durée des sessions, mais le vérifier par précaution :
Le temps de 10 secondes pour les sessions avec engagement est en général un peu faible, valider avec le client le fait de passer à 30 secondes (selon le contexte et l’objectif du site). Documenter de façon très claire à quel moment un changement est fait côté admin si ce changement est effectué.
Balise Google ⇒ Remplacer les paramètres des cookies
Sauf avis contraire du client, passer les cookies en 13 mois non glissants, pratique généralement reconnue comme un impératif GDPR.
A noter qu’il est également possible de gérer ce paramétrage côté GTM. S’assurer que le travail n’est pas fait en double.
3. Conversions
Garder en tête que tous les events qui sont marqués en tant que conversion :
- Viennent alimenter la metric “taux de conversion de la session”
- Sont utilisables dans les rapports d’attribution
Il faut donc trouver le bon compromis, selon l’objectif du site, pour que les events marqués en tant que conversion ont bien une valeur aux yeux du client.
Ce point est aussi lié à celui sur les patterns d’implémentation GA4 qui fait l’objet d’une doc dédiée
Méthode de comptabilisation
Sensibiliser le client au choix de la méthode de comptabilisation
4. Audiences
Paramétrer quelques audiences basiques comme suggéré par Alexis (purchase, add to cart, toutes les conversions…?), et sensibiliser le client au fait qu’elles ne sont pas rétroactives, Faire le lien avec les objectifs Google Ads
5. Définitions personnalisées
Le nom de la dimension personnalisée dans l’interface doit être le même que la clé alimentée au niveau du hit :
Penser également si cela est pertinent, à renseigner une description. Cela peut être la même définition que celle issue des specs côté data layer si cela est pertinent.
6. Paramètres des données
Collecte de données
Sauf avis contraire, conserver les données précises sur l'appareil et la zone géographique :
Demander au client de cocher la “Confirmation de la collecte de données utilisateur” (aucun impact a priori, mais il y a une probabilité très faible que ça soit sensible d’un point de vue juridique) :
Paramètres avancés pour autoriser la personnalisation des annonces : à conserver si et seulement si le client exporte des audiences vers Google Ads :
Conservation des données
Impérativement passer la conservation des données à 14 mois, sauf demande express du client, et activer l’option “Réinitialiser les données utilisateur lors d'une nouvelle activité”
Filtres de données
En lien avec la ci-dessus, s’assurer que le filtre “Internal Traffic” est bien marqué comme “actif” (et passer par une phase de test si besoin) :
Groupes de canaux par défaut
Pour savoir si le channel grouping par défaut est pertinent, demander au client s’il utilise les solutions suivantes parmi la stack Google Marketing Cloud :
- Google Ads - Shopping
- Google Ads - Display
- Google Ads - Youtube
- Google Ads - Google Display Network
- Google Ads - Discover, Pmax, Smart Shopping
- DV (Display & Video) 360
- Search Ads 360
- Google Merchant Center
Si c’est le cas, le channel grouping par défaut peut être conservé. Il est en effet très lié aux outils publicitaires Google, et n’a que très peu d’intérêt dans le cas contraire.
Groupes de canaux custom
Auditer les sources de trafic existantes dans les rapports d’exploration, et discuter avec le client d’un channel grouping custom sur cette base.
Même si ce type de document n’est pas disponible ou est complexe à obtenir (trop de sources, sans traçabilité ou documentation préalable), il est toujours utile de faire un audit rapide des sources / medium pour savoir si, dans les grandes lignes, les sources sont bien classifiées.
7. Import de données
Auditer si des imports de données existent déjà, et se renseigner sur leur utilisation.
Note recommandation est, au même titre que pour la création / modification d’événements, d’éviter d’utiliser les imports de données comme “pansement” d’une implémentation
- Soit la donnée doit être rectifiée à la base (dans le data layer, ou dans l’implémentation côté GTM)
- Si une question de performance, de normalisation, ou de confidentialité pousse à enrichir la donnée après la collecte, il faut privilégier un vrai pipeline de données côté GCP ou techno équivalente.
8. Identité de reporting
Recommandation : utiliser l’identité “Basé sur l’appareil” pour les problématiques de reporting et d’analyse au quotidien (et les exports Looker Studio), et ne garder les autres options que pour des analyses ponctuelles et assez macro, dont le but est d’estimer la volumétrie d’events perdus lors d’absence de consentement analytics. Lors d’un tel switch, s’assurer que le client est au courant, et faire le switch inverse immédiatement après avoir réalisé son analyse.
A noter ces analyses de type “Changement de reporting identity” ne sont de toute façon valables que si le setup utilise Consent Mode, qui lui-même est tributaire de la logique UX choisie sur la CMP.
9. Paramètres d’attribution
Modèle d'attribution dans les rapports
Recommandation de base :
- Si le client est habitué à utiliser l’attribution “Last Click” de GA3, conserver ce modèle
- Dans le cas contraire, conserver le modèle “Basé sur les données” proposé par défaut dans GA4
A noter qu’il est de toute façon possible de comparer les différents modèles dans les rapports “Publicité”, de façon rétroactive.
Canaux auxquels le crédit peut être attribué
Conserver les canaux naturels et payants :
Période de suivi des conversions
A valider avec le client s’il veut des paramètres spécifiques par rapport à sa stratégie d’acquisition :
10. Associations produits Google
Google Ads
Vérifier que l’association est bien à jour avec le(s) compte(s) du client, et que la publicité personnalisée est activée
BigQuery
Sauf avis contraire du client, le linking avec BQ doit, autant que possible, être activé dés que possible, afin d’avoir une option viable d’analyse des données granulaires, et ne pas être tributaire des limitations de l’interface (échantillonnage, seuils, reporting identity…).
Les 3 types d’exports (”Tous les jours”,“Exportation en flux continu”, et “Données utilisateur / Quotidienne”) doivent être activés.
S’il est nécessaire d’estimer les coûts pour le client, il faut se réferer à la documentation disponible ici : https://cloud.google.com/bigquery/pricing?sjid=10855901153529223040-EU&hl=fr#data_ingestion_pricing
En parallèle, s’assurer de récupérer les accès au projet GCP associé avec les droits suffisants :
Autres produits publicitaires
Liste : Ad Manager, Display & Video 360, Merchant Center, Google Play, Search Ads 360
Vérifier si ces produits sont utilisés par le client (éventuellement agences externes), et que le linking est fait correctement le cas échéant
L’auteur : Aristide Riou
Consultant tracking & expert GA4 chez UnNest
Mon credo : aider les gens à résoudre des problèmes avec les données en brisant les silos entre le monde des affaires et la technologie.
Avec plus de 10 ans d'expérience en marketing digital, développement fullstack, et gestion des données, je travaille sur tous les aspects des projets liés aux données. J'ai travaillé pour des sites de commerce électronique (My M&M's, Cdiscount), des agences (Wunderman, BBDO), et des entreprises mondiales (Mercedes, Procter & Gamble, Danone).
✉️ Me contacter : aristide.riou@unnest.co
