L’export GA4 BigQuery fournit des données analytics brutes, non échantillonnées, au niveau événement avec un accès SQL complet. Il utilise un modèle centré sur les événements avec des structures profondément imbriquées, trois systèmes de source de trafic distincts, et plusieurs comportements de schéma que la documentation de Google ne documente pas clairement. Ce hub organise les concepts clés pour travailler avec le schéma.
Ce qui est exporté
Types de tables dans l’export GA4 BigQuery — Les quatre types de tables d’un dataset d’export : quotidien (events_YYYYMMDD), intraday (events_intraday_YYYYMMDD), et deux tables utilisateurs optionnelles. Leur temporalité, leurs limites, leurs coûts et quand utiliser chacune. Le compromis intraday vs quotidien (monitoring temps réel vs source de vérité) et pourquoi les tables intraday manquent de trois champs d’attribution critiques.
Le schéma
Structure des données d’événements GA4 — Le modèle fondamental : une ligne par événement, des RECORDs imbriqués pour device/geo/trafic, des REPEATED RECORDs (tableaux) pour event_params, user_properties et items. Le changement de modèle mental par rapport à Universal Analytics. UNNEST inline vs UNNEST en clause FROM. Prérequis indispensable pour tout ce qui suit.
Détection de type event_params GA4 — Comment GA4 assigne automatiquement les valeurs de paramètres aux champs string_value, int_value ou double_value. L’échec silencieux avec null lorsque vous interrogez le mauvais champ de type. Le pattern défensif COALESCE pour les paramètres dont le type est incertain ou historiquement incohérent.
Champs de source de trafic GA4 — Trois structures de source de trafic différentes dans l’export : traffic_source (premier contact au niveau utilisateur), collected_traffic_source (UTMs bruts et click IDs au niveau événement), et session_traffic_source_last_click (dernier clic au niveau session, depuis juillet 2024). Laquelle utiliser pour quelle question.
Ordonnancement des événements GA4 avec les champs batch — Les trois champs batch (batch_event_index, batch_ordering_id, batch_page_id) ajoutés en juillet 2024 pour un séquencement déterministe des événements. Pourquoi event_timestamp seul produit un ordonnancement peu fiable pour l’analyse de funnel et de parcours.
Schéma e-commerce GA4 dans BigQuery — Le RECORD ecommerce (au niveau transaction) et le REPEATED RECORD items (au niveau produit), incluant le tableau imbriqué item_params ajouté en octobre 2023. Patterns de requêtes pour l’analyse des achats sans double comptage du chiffre d’affaires.
Les pièges
Fiabilité des événements session_start GA4 — Pourquoi compter les événements session_start produit des comptages de sessions incorrects. L’interface GA4 elle-même a abandonné cette approche. La méthode correcte : compter les IDs de session composites distincts.
Construction de la clé de session GA4 — ga_session_id est un timestamp Unix, pas un identifiant unique. Plusieurs utilisateurs démarrant des sessions à la même seconde partagent des valeurs identiques. La clé composite user_pseudo_id + ga_session_id est le bon identifiant de session.
Gestion des fuseaux horaires GA4 BigQuery — Trois contextes de fuseau horaire qui ne concordent pas : event_timestamp (UTC), event_date (fuseau horaire de la propriété), et _TABLE_SUFFIX (heure du Pacifique). Le pattern correct pour les requêtes de plages de dates qui fonctionnent correctement aux limites de journée.
Événements orphelins du Consent Mode GA4 — Le Consent Mode avancé crée des événements avec user_pseudo_id et ga_session_id nuls qui gonflent le nombre d’événements mais ne peuvent pas être sessionisés. Comportement de restitution sur la même page. Pourquoi les chiffres BigQuery sont inférieurs à l’interface GA4 pour les propriétés européennes.
Piège des données fournies par l’utilisateur GA4 BigQuery — Activer « Données fournies par l’utilisateur » dans l’admin GA4 désactive définitivement l’export user_id vers BigQuery. Aucune option de retour arrière. Quel monitoring mettre en place avant que votre équipe ne l’active accidentellement.
Maintenance du schéma
Monitoring de l’évolution du schéma GA4 — GA4 ajoute de nouveaux champs sans annonce. Les champs ne sont jamais rétroactifs — les tables historiques ne gagnent pas les colonnes ajoutées après leur date d’export. Comment surveiller INFORMATION_SCHEMA pour les changements et gérer la période de transition lorsqu’un nouveau champ devient disponible.
Requêtes efficaces
Patterns de requêtes GA4 BigQuery — Filtrage _TABLE_SUFFIX pour les tables date-shardées, UNNEST inline vs UNNEST en clause FROM, macros dbt réutilisables pour l’extraction de paramètres, et pratiques de contrôle des coûts (dry runs, matérialisation, APPROX_COUNT_DISTINCT).
Modèle de coûts BigQuery — Les données GA4 à grande échelle peuvent être coûteuses. Comprendre comment la tarification à la demande et par slots interagit avec les patterns de requêtes influence la conception des modèles de base et des couches intermédiaires.
Pourquoi les chiffres ne correspondent pas à l’interface GA4
Écarts de chiffres entre GA4 et BigQuery — L’écart de 1 à 5 % entre les requêtes BigQuery et les rapports de l’interface GA4 est architectural et inévitable. Les causes : comptage probabiliste HyperLogLog++, modélisation comportementale du Consent Mode, déduplication cross-device via Google Signals, et fenêtre de traitement des données tardives de 72 heures.
Sessionisation
Hub de sessionisation GA4 couvre la couche suivante : sessionisation au grain événement, patterns de fonctions fenêtre pour la propagation du contexte de session, stratégies de modèles incrémentaux pour les données tardives, et assemblage de l’attribution depuis les champs de source de trafic au niveau session.