Types de tables dans l'export GA4 BigQuery

Lorsque vous liez une propriété GA4 à BigQuery, un dataset nommé analytics_<property_id> apparaît dans votre projet. Il contient quatre types de tables distincts qui servent des objectifs différents. Utiliser le mauvais type pour votre cas d’usage signifie soit des données manquantes, des coûts inutiles, ou des rapports basés sur des chiffres qui ne seront jamais définitifs.

Les quatre types de tables

Tables quotidiennes : votre source de vérité

Les tables events_YYYYMMDD contiennent des données d’événements entièrement traitées avec une attribution utilisateur complète. C’est sur elles que vous construisez vos modèles de reporting.

Temporalité : Les tables quotidiennes arrivent généralement en milieu d’après-midi dans le fuseau horaire de votre propriété. Il n’existe pas de SLA garanti pour les propriétés standard — « milieu d’après-midi » décrit le comportement typique, pas un engagement. Planifiez l’ordonnancement de vos pipelines en conséquence.

Fenêtre de données tardives : Ces tables continuent d’être mises à jour jusqu’à 72 heures après leur date. Le batching du SDK mobile et les hits Measurement Protocol arrivent fréquemment avec du retard. Si vous exécutez un modèle incrémental sur les données de la veille tôt le matin, vous manquerez des événements qui ne sont pas encore arrivés. Utilisez une fenêtre de lookback dans votre stratégie incrémentale :

{% if is_incremental() %}
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
{% endif %}

Ce que les tables intraday n’ont pas : traffic_source (attribution premier contact), user_ltv (métriques de valeur vie) et is_active_user. Si votre analyse dépend de l’un de ces champs, vous devez utiliser les tables quotidiennes.

Limites : Les propriétés GA4 standard peuvent exporter jusqu’à 1 million d’événements par jour dans les tables quotidiennes. Les propriétés GA4 360 peuvent en exporter jusqu’à 20 milliards par jour.

Tables intraday : uniquement pour le monitoring temps réel

Les tables events_intraday_YYYYMMDD fournissent des données en quelques minutes après l’occurrence de l’événement. Elles sont mises à jour en continu tout au long de la journée au fil de l’arrivée des événements en streaming.

La suppression automatique : Les tables intraday sont automatiquement supprimées une fois que la table quotidienne correspondante est complète. Elles n’existent que pour le monitoring de la journée en cours — vous ne pouvez pas vous en servir pour l’analyse historique.

Ce qui manque : Trois champs ne sont jamais renseignés dans les tables intraday :

• traffic_source — pas d’attribution premier contact
• user_ltv — pas de données de valeur vie
• is_active_user — pas de flag d’utilisateur actif

Les modèles d’attribution au niveau session et l’analyse d’acquisition utilisateur qui dépendent de traffic_source produiront des résultats incorrects si exécutés sur des données intraday. Les requêtes s’exécutent sans erreur ; elles retournent simplement des valeurs vides ou trompeuses.

Précision : Attendez-vous à un écart de 0,5 à 2 % entre les données intraday et les données quotidiennes finales dans des conditions normales, avec des cas limites pouvant atteindre 20 % ou plus. Les données intraday représentent un état de traitement en cours, pas un comptage définitif.

Coût : L’ingestion en streaming coûte 0,05 $ par Go. Un site avec 1 million d’événements quotidiens paie environ 1,50 $/mois pour les exports intraday. Le chargement par batch quotidien est gratuit — vous ne payez que le stockage et les requêtes. Le coût est modeste mais vaut la peine d’être connu avant d’activer les exports intraday pour plusieurs propriétés.

Quand utiliser intraday : Tableaux de bord du jour même, alertes sur anomalies, monitoring opérationnel temps réel. Pas pour toute analyse où la précision importe ou où des champs d’attribution sont requis.

Tables utilisateurs : exports d’identité optionnels

Les tables pseudonymous_users_YYYYMMDD et users_YYYYMMDD exportent des données au niveau utilisateur plutôt qu’au niveau événement. Elles sont désactivées par défaut et nécessitent une activation explicite dans les paramètres de liaison BigQuery.

pseudonymous_users_YYYYMMDD : Indexée sur user_pseudo_id — l’identifiant cookie du device ou du navigateur. Une ligne par device actif. Contient les appartenances aux audiences, les métriques de valeur vie et les scores prédictifs (probabilité d’achat, probabilité de désabonnement) pour chaque device.

users_YYYYMMDD : Indexée sur votre user_id personnalisé — l’identifiant que vous définissez via gtag('set', 'user_id', '...') ou équivalent. N’est renseignée que pour les événements où user_id a été explicitement défini.

Quand les utiliser : Ces tables deviennent utiles lorsque vous avez besoin d’agrégations au niveau utilisateur sans les construire à partir des tables d’événements. Si vous accédez aux scores prédictifs de GA4, c’est le seul endroit dans BigQuery où ils apparaissent. Pour la plupart des travaux d’analytics engineering, construire des modèles utilisateurs directement depuis les tables d’événements offre plus de contrôle et de flexibilité.

Mise en garde : Si votre équipe envisage d’activer la fonctionnalité « Données fournies par l’utilisateur » dans l’admin GA4, soyez conscient de l’interaction critique avec l’export user_id. Cette fonctionnalité désactive définitivement user_id dans les exports BigQuery sans possibilité de retour arrière.

Choisir entre quotidien et intraday

Le choix n’est pas binaire. Activez les deux exports et utilisez-les à des fins différentes.

Jour N :
  Les événements se produisent tout au long de la journée
  → Les tables intraday se mettent à jour en quelques minutes (pour le monitoring)

Jour N+1 :
  L'export quotidien se termine (~10-16 heures après minuit)
  → La table intraday est supprimée
  → Le reporting de production s'exécute sur la table quotidienne

Jour N+3 :
  La fenêtre de données tardives se ferme
  → La table quotidienne est désormais stable et définitive
  → Les requêtes historiques produisent des résultats cohérents

Recommandations pratiques :

• Exécutez les tableaux de bord de monitoring du jour sur les tables intraday. Documentez explicitement les limitations de précision dans le tableau de bord.
• Exécutez tout le reporting de production, l’analyse d’attribution et les métriques KPI sur les tables quotidiennes.
• Si vos parties prenantes ont besoin de données du jour même pour prendre des décisions (pas seulement pour du monitoring), documentez clairement les limitations intraday connues afin qu’elles comprennent ce qu’elles consultent.

Pour les patterns de requêtes permettant d’accéder efficacement à ces tables, notamment le filtrage _TABLE_SUFFIX et la syntaxe des plages de dates, consultez Patterns de requêtes GA4 BigQuery.