Le modèle de données GA4 – comprendre la logique des évènements

Mis à jour le 3 juillet 2025

Ce dossier complet décortique le modèle de données événementiel de Google Analytics 4. Vous apprendrez :

• pourquoi Google a abandonné Universal Analytics ;
• comment fonctionne la nouvelle structure event + parameters ;
• les bonnes pratiques 2025 pour le User‑ID, le Consent Mode et l’export BigQuery ;
• les quotas, limites et pièges à éviter.

Objectif : repartir avec un plan d’implémentation prêt à l’emploi et conforme au RGPD.

1. Pourquoi Google a tourné la page Universal Analytics ?

1.1 Contexte – un Web qui a basculé

Au lancement d’Universal Analytics (2012), la navigation se faisait principalement sur desktop, les cookies tiers étaient la norme et la confidentialité des données restait secondaire. Dix ans plus tard :

• les smartphones ont dépassé l’ordinateur sur la plupart des sites ;
• les régulations (RGPD, ePrivacy, CCPA) imposent le consentement préalable ;
• les géants navigateurs (Safari, Firefox, bientôt Chrome) coupent les cookies tiers.

Universal Analytics a donc atteint ses limites techniques et juridiques. Google a réécrit le moteur plutôt que de le rafistoler.

1.2 Trois défis que GA4 relève nativement

Défi	Pourquoi UA bloquait	Réponse GA4
Vie privée & consentement	Cookie _ga obligatoire ; perte totale de données si refus.	Consent Mode v2 : modélisation statistique lorsque les cookies sont refusés ; IP anonymisées par défaut.
Parcours multi‑écrans	Web et App séparés, vues différentes, peu de déduplication.	Flux Web + iOS + Android dans UNE propriété ; User‑ID, Google signals pour recoller le parcours.
Exploration prédictive	Pas de ML intégré ; besoins BigQuery + Data Studio.	Modèles natifs (probabilité d’achat, churn, revenus futurs) accessibles dans l’interface et l’API.

1.3 Bénéfices concrets pour les équipes marketing & data

• ROI plus rapide : temps réel quasi sans échantillonnage jusqu’à 10 M d’événements par exploration.
• Moins de patchs : plus besoin de vues/test/dev, ni de filtres compliqués pour chaque sous‑domaine.
• Activation directe : audiences GA4 exportables en 1 clic vers Google Ads, Search Ads 360, Display & Video 360.

1.4 À retenir

GA4 n’est pas un « UA v2 » : c’est une refonte pensée pour un Web mobile, cross‑device et privacy‑first. Adopter son modèle événementiel, c’est s’assurer des données exploitables après la disparition des cookies tiers.

2. Événement ≠ Catégorie/Action/Label : pourquoi tout devient un évènement (event) + paramètres

2.0 Mise en contexte

Universal Analytics décrivait chaque interaction via trois champs fixes – Category, Action, Label – hérités de 2005. Le Web de 2025, lui, exige :

• des événements plus expressifs (scroll à 90 %, lecture vidéo à 30 s) ;
• la possibilité d’attacher toute information métier sans restructurer la base ;
• une syntaxe unique pour le Web et les Apps.

GA4 passe donc d’un schéma rigide à un modèle “clé‑valeur” : un nom d’événement + jusqu’à 25 paramètres.

2.1 Comparatif express

Universal Analytics (UA)	Google Analytics 4 (GA4)
eventCategory = "video"	event_name = "video_start"
eventAction = "play"	video_percent = 0 (paramètre)
eventLabel = "home"	page_location = "…/home"

• Flexibilité : ajoutez plan='premium' ou layout='AB' sans toucher au schéma.
• Granularité : un seul event scroll avec %_scrolled en param remplace trois catégories.

2.2 Les quatre familles officielles d’événements

1. Automatically Collected – rien à taguer : first_visit, session_start, scroll (40 %+).
2. Enhanced Measurement – un simple interrupteur : outbound_click, file_download, site_search.
3. Recommended – nomenclature Google pour standardiser : login, add_to_cart, purchase, generate_lead.
4. Custom – vos propres events : préfixe conseillé cust_ pour les distinguer (ex. cust_banner_dismissed).

2.3 Limites techniques et bonnes pratiques

Limite	Valeur (GA4 Standard)	Conseil
Nombre d’événements distincts / jour	500	Regroupez (ex. download + param file_type) plutôt que multiplier.
Paramètres par événement	25	Gardez 5‑10 clés essentielles ; supprimez les redondances.
Dimensions personnalisées mappables	50 (25 event, 25 user)	Documentez chaque clé dans un dictionnaire partagé.

2.4 Exemple concret : tracking lecture vidéo

// Lecture à 30 secondes
  gtag('event','video_progress',{
    video_title:'GA4_Tutorial.mp4',
    video_current_time:30,
    video_percent:25
  });

Un seul nom d’event video_progress ; les paramètres capturent titre, timestamp, pourcentage.

2.5 Ce qu’on y gagne

• Modèle unique Web/App → moins de traductions GTM ↔ Firebase.
• Filtres flexibles dans Explorations (drag‐drop n’importe quel paramètre).
• Export BigQuery natif : table event_params déjà normalisée.

2.6 En résumé

Passer au couple event_name + parameters libère votre tracking des carcans Category/Action/Label et prépare votre jeu de données aux futures analyses IA. Commencez par cartographier 20 événements clés, puis enrichissez‑les de paramètres métier plutôt que d’empiler de nouveaux events.

3. Bien écrire son gtag.js : mode d’emploi pas à pas

3.1 Pourquoi parle‑t‑on de gtag .js ?

gtag.js (pour Global Tag) est la librairie JavaScript officielle qui envoie les événements GA4 quand vous n’utilisez pas Google Tag Manager. Elle se charge :

• de charger le fichier de tracking depuis googletagmanager.com ;
• de poser l’ID de mesure (ex. G‑ABCD1234) ;
• de recevoir les appels gtag('event', …) et de les transmettre aux serveurs GA4.

💡 Astuce : même si vous passez par GTM, comprendre la syntaxe native aide à débuguer ou à injecter un tag côté serveur.

3.2 Les deux appels indispensables

Étape	Exemple	Rôle
1 — loader asynchrone	<script async src="https://www.googletagmanager.com/gtag/js?id=G-ABCD1234"></script>	Télécharge la librairie sans bloquer la page.
2 — initialisation	« `js
window.dataLayer = window.dataLayer		[];
function gtag(){dataLayer.push(arguments);}
gtag(‘js’, new Date());
gtag(‘config’, ‘G-ABCD1234’, {debug_mode:true});
« `	Crée le dataLayer, définit l’horodatage, active le mode debug.

3.3 Envoyer un événement (syntaxe simplifiée)

gtag('event', 'purchase', {
  currency: 'EUR',
  value: 49.99,
  items: [{item_id:'T‑123', item_name:'T‑shirt fox', price:24.995, quantity:2}]
});

Trois arguments :

1. le mot‐clé 'event' ;
2. le nom d’événement (purchase) ;
3. un objet clé‑valeur pour les paramètres (obligatoires + optionnels).

3.4 send_to : encore utile ?

• GA4 pur → inutile ; GA route automatiquement vers l’ID indiqué dans config.
• Google Ads → gardez send_to: 'AW‑XXXX/abc' pour marquer la conversion Ads.

3.5 6 erreurs fréquentes à éviter

1. Dupliquer la balise : une seule inclusion gtag.js par page.
2. Oublier debug_mode:true en préprod → rien dans DebugView.
3. Mettre la devise dans le value → value numérique seulement, currency séparé.
4. Envoyer un paramètre non déclaré → ajoutez‑le dans « Custom Definitions » si vous voulez le reporter.
5. Confondre user_id et userId (sensible à la casse).
6. Lancer l’event avant le config → assurez‑vous que le config est appelé avant tout event.

3.6 Quand préférer Google Tag Manager ?

Choisir gtag.js si…	Choisir GTM si…
Vous avez un site statique avec peu d’événements	Vous gérez plusieurs domaines/environnements
Vous maîtrisez le code et poussez les params côté front	Vous voulez déléguer le tracking à une équipe marketing
Vous devez charger le minimum de JS	Vous avez besoin de balises tierces (Meta, TikTok, Hotjar…)

3.7 TL;DR (conclusion)

Une bonne implémentation gtag.js =

• 1 loader async + 1 config avant tout event ;
• des événements clairs + 0 paramètre superflu ;
• le debug activé en staging ;
• send_to réservé à Google Ads.

Suivez ces règles, et votre flux d’événements GA4 restera propre, léger et facile à faire évoluer.

4. Identifier les utilisateurs : device_id, User‑ID, Google signals

4.1 Pourquoi c’est crucial

Une donnée n’a de valeur que si elle relie plusieurs actions à la même personne. Sans liaison, un même client qui revient 3 fois apparaît comme 3 utilisateurs différents ; impossible d’évaluer la fidélité, la LTV ou l’impact réel d’une campagne.

4.2 Les trois briques d’identification GA4

Méthode	Comment ça marche	Cas d’usage	Limites
device_id	ID stocké en cookie ou IDFV (mobile). Créé automatiquement à first_visit.	Analyser le comportement sur un appareil.	Disparaît si l’utilisateur vide ses cookies ou refuse le consentement.
User‑ID	Vous fournissez un identifiant unique (login, CRM). Déclaré via gtag('config', {user_id:'123'}).	Cross‑device fiable (Web + App) ; rapporte au même profil.	Nécessite un système de connexion et gestion RGPD (base légale + opt‑out).
Google signals	Google associe les appareils connectés au même compte Google (si l’utilisateur accepte la personnalisation d’annonces).	Dé‑duplication passive + rapports démographiques + export audiences vers Google Ads.	Off par défaut ; respect des réglages « Ads Personalization ».

4.3 Mettre en place le User‑ID pas à pas

1. Créez un champ user_id dans votre base (hash, sans donnée PII).
2. À la connexion, poussez :

gtag('config','G-ABCD1234', { user_id: 'u_78910' });

3. Dans GA4 → Admin → Flux → User‑ID → activez les rapports dédupliqués.

Tip : GA4 regroupe automatiquement les hits device_id + User‑ID si l’événement login survient en cours de session.

4.4 Activer Google signals en toute conformité

• Admin → Paramètres de données → Collecte des données → basculer Google signals.
• Ajoutez la clause « personnalisation d’annonces » dans votre CMP (Consent Mode v2).
• Effet immédiat : rapports « Âge, Sexe, Centres d’intérêt » + possibilités d’audiences « Cross‑device shoppers » dans Google Ads.

4.5 Quelle stratégie choisir ?

• Site vitrine sans login → device_id + (optionnel) Google signals.
• E‑commerce avec compte client → Activez User‑ID en priorité, puis Google signals pour le marketing.
• App mobile + backend → Poussez User‑ID via Firebase, gardez device_id pour pré-login.

4.6 À retenir

Combinez device_id pour le temps réel, User‑ID pour la fidélité, Google signals pour la portée publicitaire. Documentez la chaîne de consentement et testez vos configurations dans DebugView pour vérifier que chaque hit transporte bien l’ID attendu.

5. Paramètres & propriétés personnalisés : enrichir votre data sans coder une nouvelle base

5.1 Pourquoi aller au‑delà des champs natifs ?

Les événements GA4 collectent déjà l’essentiel (event_name, page_location, device_id…) mais chaque métier a ses propres questions : Quel plan a choisi mon client ? Quel format d’article génère le plus d’engagement ? Quelle couleur de produit convertit ?

Paramètres personnalisés et propriétés utilisateur permettent d’ajouter ces informations métier sans modifier le schéma GA4.

5.2 Deux scopes à retenir

Scope	Déclaration	Vit dans…	Cas d’usage type
event_parameter	Dans l’objet de l’event	Ligne event	article_category, button_color, discount_code
user_property	Via gtag('set',{user_properties:{…}})	Profil utilisateur	plan_type, lifetime_value, preferred_language

Quota (GA4 Standard) : 25 dimensions event‑scope + 25 dimensions user‑scope + 50 metrics personnalisées.

5.3 Implémentation en pratique

5.3.1 Ajouter un paramètre événement (gtag.js)

// L’utilisateur clique sur « Ajouter au panier »
gtag('event','add_to_cart',{
  currency:'EUR',
  value:29.99,
  item_id:'SKU‑123',
  item_color:'red',          // paramètre personnalisé
  page_template:'summer_sale' // paramètre personnalisé
});

1. Poussez le paramètre ; 2. Dans GA4 → Admin → Custom Definitions → mappez item_color comme Dimension event.

5.3.2 Définir une propriété utilisateur (gtag.js)

gtag('set', {
  user_properties: {
    plan_type:'premium',
    acquisition_channel:'newsletter'
  }
});

Les user_properties s’envoient une fois par session (ou lors d’un changement) et se propagent à tous les events suivants.

5.3.3 Tag Manager (méthode sans code)

• Créez une Variable Data Layer DL – article_category.
• Dans votre tag GA4 Event – article_view, ajoutez : Parameter Name = article_category / Value = {{DL – article_category}}.
• Publiez, puis mappez la dimension dans GA4.

5.4 Bonnes pratiques & garde‑fous

• Nommer en snake_case (lettres minuscules, underscore) pour la cohérence.
• Limiter la cardinalité : évitez un paramètre qui peut prendre 100 000 valeurs différentes (risque de sampling & cardinality break).
• Documenter un dictionnaire partagé (Google Sheet ou Notion) : nom, description, type, scope.
• Respect RGPD : jamais de PII (email, phone) dans un paramètre – utilisez un hash irréversible ou une ID interne.
• Nettoyer régulièrement : supprimez les dimensions non utilisées pour libérer des slots.

5.5 En résumé

Les paramètres personnalisés transforment GA4 en entrepôt de données métier léger. Définissez‑les avec parcimonie, documentez‑les, et vous ouvrirez la porte à des segments et rapports ultra‑pertinents — sans une ligne de SQL supplémentaire.

6. e‑commerce nouvelle génération : comprendre le tableau items[]

6.1 Pourquoi Google a changé le modèle ?

UA utilisait jusqu’à 14 champs imbriqués (productSku, productName, etc.). Difficulté à maintenir, divergences Web vs App. GA4 fusionne tout dans un tableau unique items[] partagé par les événements view_item, add_to_cart, begin_checkout, purchase, refund.

6.2 Structure minimale d’un objet item

Champ	Obligatoire	Description
item_id	✅	Identifiant unique (SKU, ISBN).
item_name	✅	Nom lisible par l’humain.
price	✅ (sauf view_item)	Prix unitaire (hors taxe si possible).
quantity	facultatif	Nombre d’unités.
item_category	facultatif	Arborescence jusqu’à 5 niveaux (item_category2…5).

Tip : item_brand, item_variant, coupon existent toujours mais sont optionnels.

6.3 Exemple complet de funnel

// 1) vue produit
{"event":"view_item","items":[{"item_id":"SKU‑123","item_name":"Hoodie Fox","price":49.99}]}
// 2) ajout panier
{"event":"add_to_cart","items":[{"item_id":"SKU‑123","item_name":"Hoodie Fox","price":49.99,"quantity":1}]}
// 3) achat
{"event":"purchase","transaction_id":"ORD‑890","currency":"EUR","value":49.99,
 "items":[{"item_id":"SKU‑123","item_name":"Hoodie Fox","price":49.99,"quantity":1}]}

6.4 Rapports et analyses disponibles

• Monetization → Overview : CA, commandes, AOV, taux panier → achat.
• Explorations Funnel : abandon panier, abandon checkout.
• Item-scoped dimensions (item_name, item_category) dans BigQuery pour analyse top produits.

6.5 En résumé

Passez à items[] dès maintenant : un payload unique, moins de bugs entre Web et App, et une compatibilité immédiate avec Enhanced Conversions for Ads.

7. Quotas & limites : jusqu’où peut‑on pousser GA4 Standard ?

7.1 Pourquoi connaître les plafonds ?

Ignorer les limites GA4, c’est risquer :

• un échantillonnage brutal dans Explorations ;
• la perte de paramètres non mappés faute de slots ;
• un arrêt d’export BigQuery pour dépassement quotidien.

7.2 Tableau récapitulatif (GA4 Standard vs 360)

Ressource	Standard	GA4 360	Comment l’optimiser ?
Noms d’événements distincts	Web : illimité · App : 500 par app user	Web : illimité · App : 2 000 par app user	Regroupez sous un même event_name + paramètre
Paramètres / événement	25	100	Priorisez 5-10 clés vraiment utiles ; supprimez le reste
Dimensions personnalisées (event + user)	50 slots (25 event + 25 user)	225 slots (125 event + 100 user)	Nettoyez les tests obsolètes ; recyclez les slots inutilisés
Métriques personnalisées	50	125	Limitez-vous aux KPI réellement exploités
Rétention des données brutes	14 mois	50 mois	Activez l’export BigQuery pour conserver l’historique
Export BigQuery gratuit	1 M events / jour	Illimité	Si vous frôlez le plafond : serveur-side tagging ou échantillonnage

 

7.3 Astuces pour rester sous les radars

• Naming convention stricte pour éviter les doublons (cust_ préfixé).
• Nettoyage trimestriel des dimensions inutilisées.
• Segments BigQuery pour analyses lourdes plutôt que 100 Explorations.

7.4 Conclusion

Connaître vos quotas = éviter les mauvaises surprises au moment où le C‑level demande un rapport sur 24 mois ! Anticipez avec BigQuery et une taxonomie maîtrisée.

8. Exploiter BigQuery & la Data API : ouvrir GA4 au « raw data »

8.1 Pourquoi exporter dans BigQuery ?

Les rapports natifs se limitent à 10 M d’événements par exploration et subissent un échantillonnage. BigQuery offre :

• l’accès à chaque événement ligne par ligne ;
• la possibilité de joindre vos CRM / coûts média ;
• le langage SQL complet + l’intégration Looker Studio, Python, R.

Bonne nouvelle : l’export quotidien est gratuit jusqu’à 1 million d’événements/jour sur GA4 Standard (illimité en 360).

8.2 Activer l’export en 3 minutes

1. Google Cloud → créez un projet (facturation activée, même si l’export <= 1 M reste $0).
2. Dans GA4 → Admin → BigQuery Links → Link → sélectionnez projet + emplacement (eu/US).
3. Choisissez Daily export (+ streaming si besoin temps quasi réel).

8.3 Comprendre le schéma

• Chaque jour génère une table : events_YYYYMMDD (partition).
• Champs top‑level : event_date, event_timestamp, event_name, user_pseudo_id, geo.country, etc.
• Champs répétés : event_params, user_properties, items.

Tip SQL : utilisez UNNEST(event_params) pour aplatir les paramètres.

Exemple : CA par catégorie sur 30 jours

SELECT
  ip.value.string_value AS category,
  SUM(ecommerce.purchase_revenue) AS revenue
FROM `myproject.analytics_123456.events_*` t,
UNNEST(items) it,
UNNEST(it.item_category) ip
WHERE _TABLE_SUFFIX BETWEEN '20250530' AND '20250628'
  AND event_name = 'purchase'
GROUP BY category
ORDER BY revenue DESC;

8.4 Data API vs BigQuery : quand utiliser quoi ?

Besoin	Data API	BigQuery
Dashboard simple (< 100 K lignes)	✅	✅ (overkill)
Jointure CRM, coûts pub	❌	✅
Temps quasi réel (< 1 h)	✅ (cache 1 h)	Streaming payant
Quotas	10 K requêtes/j, 120/min	Pay‑as‑you‑go (mais export gratuit)

8.5 Bonnes pratiques

• Table partitionnée : interrogez uniquement la plage _TABLE_SUFFIX nécessaire.
• Modèle de coûts : stockage = ~0,02 $/Go/mois ; requêtes = 5 $/To scanné (optez pour tables matérialisées si besoin).
• Automatisation : programmez un scheduled query pour créer des vues agrégées → Looker Studio.

8.6 Conclusion

BigQuery transforme GA4 d’un outil de reporting en un entrepôt analytique temps quasi réel. Activez‑le dès le premier jour : l’historique se construit dès l’activation, jamais rétroactivement.

9. Bonnes pratiques 2025 : checklist pour garder un GA4 propre et scalable

9.1 Pourquoi une checklist ?

GA4 est flexible, mais cette flexibilité peut vite tourner au chaos si personne ne pose un cadre. Les bonnes pratiques ci‑dessous résument l’expérience terrain de milliers d’implémentations ; suivez‑les pour éviter les migrations douloureuses et les rapports illisibles.

9.2 Les 10 règles d’or (avec mini‑explication)

#	Règle	Pourquoi / Comment
1	Préfixer vos customs (cust_)	Distinguer en un coup d’œil ce qui est standard vs personnalisé (custom).
2	Paramétrer vos clés (param_)	Même logique que ci‑dessus et évite les collisions futures.
3	Limitez à 5 KPI déclarés en conversions	Trop de conversions brouille la lecture et — côté Ads — dilue l’optimisation.
4	Un seul flux Web par domaine	Double‑comptes évités ; mesures cohérentes multi‑sous‑domaines.
5	Consent Mode v2 activé	Modélise les conversions perdues sans violer le RGPD.
6	DebugView avant toute mise en prod	Repérez les typos de paramètres, les user_id manquants.
7	Documentation vivante (Notion/Sheet)	Qui a créé quoi, quand, et pourquoi ; facilite l’onboarding des nouveaux.
8	Nettoyage trimestriel (events, dimensions)	Libère les slots, garde les rapports rapides et pertinents.
9	Export BigQuery nightly	Historiser au‑delà de 14 mois et faire du machine learning custom.
10	Monitoring d’échantillonnage	Alerte si une Exploration dépasse 10 M events ⇒ basculez vers BQ.

9.3 Mettre la checklist en action

1. Créez un document de gouvernance partagé (accès rédacteur : équipe data + marketing).
2. Planifiez un audit mensuel : vérifiez nouveaux events, quotas, Consent Mode.
3. Ajoutez une pipeline BigQuery → Looker Studio pour visualiser les dépassements de quotas en temps réel.

9.4 Conclusion

GA4 est un moteur puissant, mais c’est votre rigueur qui le maintient performant. Un petit investissement mensuel en gouvernance vous épargne des semaines de rattrapage plus tard.

10. FAQ éclair

Q	R
Puis‑je encore utiliser la vue « page‑vue » ?	Oui, GA4 crée automatiquement l’événement page_view (scroll, outbound…).
Combien coûte BigQuery ?	L’export est gratuit jusqu’à 1 M events/jour ; stockage et requêtes sont facturés par Google Cloud (≈ 0,02 $/Go/mois et 5 $/To scanné).
Comment taguer sans dev ?	Utilisez Google Tag Manager : un tag “GA4 Event” suffit, sans code front.
La session existe‑t‑elle toujours ?	Oui, GA4 conserve la notion de session via session_start et l’attribut ga_session_id.
Que devient le taux de rebond ?	Remplacé par « Sessions non engagées » ; préférez la métrique Engaged sessions rate.
Comment transformer un event en conversion ?	Admin → Événements → cochez “Mark as conversion” en face de l’événement voulu ; plus de ga('send','timing') ou goals.
Puis‑je supprimer un événement personnalisé erroné ?	On ne peut pas “supprimer” ; désactivez‑le dans Admin → Events, puis filtrez‑le côté rapports ou via BigQuery.
Que se passe‑t‑il si je dépasse 500 events distincts par jour ?	GA4 enregistre toujours les hits, mais les nouveaux noms seront regroupés sous other → perte de visibilité ; consolidez vos events.
Quelle différence entre DebugView et Realtime ?	DebugView montre vos hits en temps réel mais uniquement pour la session marquée debug_mode; Realtime agrège tous les utilisateurs sur 30 min.
Comment migrer mes audiences UA vers GA4 ?	Recréez‑les manuellement : les conditions doivent se baser sur les nouveaux événements/paramètres, puis exportez‑les vers Google Ads si besoin.

Glossaire express

Terme	Définition courte
event	Hit de base GA4 déclenché sur une action (clic, scroll, achat…).
event_name	Nom unique de l’événement (purchase, login).
parameter	Clé‑valeur attachée à un event (currency: 'EUR').
user_property	Attribut persistant lié à l’utilisateur (plan_type:'premium').
device_id	Identifiant stocké dans le cookie/appareil pour un visiteur non connecté.
User‑ID	ID fourni par votre backend pour suivre un utilisateur connecté sur plusieurs appareils.
Google signals	Données cross‑device issues des comptes Google (si l’utilisateur l’a permis).
Consent Mode	API qui adapte la collecte GA4 selon les choix cookies et modélise les données manquantes.
BigQuery	Entrepôt cloud Google pour stocker et analyser les événements bruts.
DebugView	Outil temps réel GA4 pour vérifier les hits pendant le développement.
Engaged session	Session d’au moins 10 s, 1 conversion ou 2 pages/écrans vus.
items[]	Tableau d’objets décrivant chaque produit dans les events e‑commerce GA4.