La vue d’ensemble de GA4 pose le cadre : BigQuery ne rend pas la collecte plus juste. Il rend les événements exportés interrogeables, ligne par ligne. Si le consentement, le marquage ou l’identité client cassent en amont, le SQL expose la cassure. Il ne la répare pas.
Pourquoi exporter GA4 vers BigQuery ?
BigQuery répond à une limite précise des surfaces de reporting. Une dimension à forte cardinalité peut pousser l’interface ou l’API Analytics à regrouper des lignes sous « (other) ». Une exploration peut aussi être échantillonnée. Dans l’export événementiel, ces deux traitements de lecture ne s’appliquent pas.
Ce n’est pas une sortie de secours sans plafond. L’export reste soumis à la collecte GA4, aux flux et événements que vous avez choisi d’inclure, aux exclusions, au consentement et aux quotas Cloud. Pour une propriété standard, l’export quotidien est limité à un million d’événements par jour. Un dépassement répété peut suspendre ce flux, sans retraitement des jours manqués.
Autre limite souvent oubliée : BigQuery reçoit les événements observés et les signaux sans cookies collectés. Il ne reçoit ni la modélisation des événements clés, ni la modélisation comportementale, ni l’attribution fondée sur les données affichées dans certaines surfaces GA4. Une différence avec l’interface n’est donc pas automatiquement une erreur SQL.
Pour un annonceur, la première question rentable est souvent la LTV par canal. Sauf que user_pseudo_id ne constitue pas une identité client durable. Avant de calculer, il faut savoir relier une transaction à un client, puis choisir une règle d’attribution explicite. Sinon, la précision de la requête masque une identité cassée.
Sources officielles Google vérifiées le 21 juillet 2026 : aide Google Analytics sur le périmètre et les limites de l’export BigQuery et les différences entre rapports, explorations et BigQuery ; documentation Google Analytics sur les écarts attendus avec l’interface.
Comment configurer l’export GA4 vers BigQuery ?
La liaison demande plus qu’un projet Cloud vide. Il faut un rôle Éditeur ou supérieur sur la propriété Analytics, les autorisations requises sur le projet Google Cloud, l’API BigQuery active et un cadre de facturation. Le bac à sable convient au quotidien sous ses limites. Il ne prend pas en charge l’import intrajournalier.
- Préparer le projet et les droits Sélectionnez le projet Google Cloud, vérifiez les autorisations de gestion du projet et l’API BigQuery. Après la liaison, contrôlez aussi les rôles du compte de service créé pour l’export.
- Fixer l’emplacement des données Choisissez la région avant la première écriture. Ce choix touche la gouvernance, les coûts et les futures jointures avec d’autres ensembles de données.
- Choisir ce qui part Sélectionnez les flux de données exportés et les événements à exclure. Pour les applications, décidez séparément si les identifiants publicitaires doivent être inclus.
- Distinguer les options L’export quotidien et l’exportation en flux continu existent pour les propriétés standard et 360. L’option « Mise à jour quotidienne » est réservée à certaines propriétés Analytics 360. L’export quotidien des données utilisateur est une option distincte, avec ses propres tables.
- Valider et surveiller L’ensemble de données documenté se nomme
analytics_<property_id>. Contrôlez l’arrivée de la première table, le nombre d’événements, les exclusions et les erreurs de facturation dès le lendemain.
N’activez pas l’exportation en flux continu « au cas où ». Elle ajoute un coût et une surface de contrôle. La bonne fréquence vient du délai réellement utile à la décision, pas de l’envie de voir des lignes arriver plus vite.
Sources officielles Google vérifiées le 21 juillet 2026 : aide Google Analytics sur les droits, les étapes, les filtres, les fréquences et la facturation et sur l’export quotidien distinct des données utilisateur.
Quel schéma de données vous attend dans BigQuery ?
Chaque ligne de events_YYYYMMDD représente un événement. Ses paramètres ne deviennent pas automatiquement des colonnes plates. event_params, user_properties et items sont des champs répétés et imbriqués. La fonction UNNEST sert à lire leurs clés et leurs valeurs.
Deux tables répondent à deux niveaux de fraîcheur :
events_YYYYMMDDcontient l’export quotidien. GA4 peut encore la mettre à jour pendant trois jours pour intégrer des événements tardifs. Un événement reçu après cette fenêtre n’est normalement pas enregistré par ce mécanisme de retard ; une réexécution historique exceptionnelle reste possible en cas de correction de traitement.events_intraday_YYYYMMDDreçoit les données du flux continu de la journée. Cette table provisoire fonctionne sans garantie d’exhaustivité, peut présenter des trous et disparaît lorsque la table quotidienne la remplace. Certaines données d’attribution utilisateur ou de session ne sont pas disponibles immédiatement.
La forte cardinalité ne fait pas « rejeter » une dimension personnalisée par BigQuery. L’interface peut regrouper des valeurs peu fréquentes sous « (other) ». L’export conserve les paramètres effectivement collectés. Il ne peut pas restituer un paramètre absent, exclu, refusé par le consentement ou bloqué par une limite de collecte.
La requête suivante est un test de lecture, pas un calcul de LTV. Elle vérifie les achats, leur horodatage, l’identifiant de transaction, le revenu et la devise sur une plage bornée. Avant toute somme, contrôlez l’unicité de transaction_id, les devises, les remboursements et le rapprochement avec le back-office.
SELECT
event_date,
TIMESTAMP_MICROS(event_timestamp) AS event_timestamp,
user_pseudo_id,
ecommerce.transaction_id,
ecommerce.purchase_revenue AS purchase_revenue,
(SELECT value.string_value
FROM UNNEST(event_params)
WHERE key = 'currency') AS currency
FROM \`mon-projet.analytics_123456.events_*\`
WHERE event_name = 'purchase'
AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
ORDER BY event_timestamp;Sources officielles Google vérifiées le 21 juillet 2026 : aide Google Analytics sur le schéma, les tables, les champs répétés et la fenêtre des événements tardifs ; documentation Google Analytics sur UNNEST, _TABLE_SUFFIX et les requêtes de contrôle.
Ce que coûte réellement l’export BigQuery
Comment mesurer le coût Cloud sans inventer un prix par événement
Le nombre d’événements ne suffit pas à prévoir la facture. Deux propriétés au même volume peuvent produire des tables de tailles différentes. Une requête qui sélectionne toutes les colonnes et toutes les dates ne scanne pas le même nombre d’octets qu’une requête bornée par date et limitée aux colonnes utiles.
Au 21 juillet 2026, le niveau sans frais BigQuery comprend les 10 premiers GiB de stockage par mois et le premier TiB de données traité par mois pour les requêtes à la demande. Au-delà, les tarifs dépendent notamment de la région, du modèle de stockage, du modèle de calcul et de la devise. Ces seuils ne promettent rien selon la taille de l’entreprise.
| Poste | Ce qu’il faut mesurer | Contrôle utile |
|---|---|---|
| Stockage | GiB logiques ou physiques réellement conservés | Détails de l’ensemble de données et rapport de facturation Cloud |
| Requêtes à la demande | Octets traités par requête, fréquence et colonnes lues | Estimation avant exécution, bornage par date et octets maximum facturés |
| Exportation en flux continu | Gigaoctets exportés en continu | Ligne de coût distincte du stockage et des requêtes |
| Exploitation | Temps SQL, contrôles qualité et maintenance du schéma | Responsable nommé, alertes et revue des requêtes récurrentes |
Le cache, le partitionnement, le regroupement des données et le choix des colonnes modifient les octets facturés. Du coup, un tableau « un million d’événements égale tel coût » serait trompeur. Mesurez d’abord le stockage réel et les octets scannés sur votre compte de facturation.
Sources officielles Google vérifiées le 21 juillet 2026 : grille Google Cloud sur les GiB stockés, les TiB traités et les facteurs de facturation ; aide Google Analytics sur le coût propre à l’exportation en flux continu.
L’export quotidien n’est pas rétroactif. Ce point justifie de ne pas attendre la veille d’une analyse de cohorte. Il ne justifie pas d’accumuler sans règle. Une table sans finalité ni propriétaire devient une dette, pas une option stratégique.
Quotidien ou flux continu : quelle fréquence choisir ?
Posez deux questions : à quelle vitesse la décision doit-elle partir, et quel niveau d’incomplétude pouvez-vous accepter ? Pour la LTV, les cohortes ou un rapprochement comptable, la table quotidienne stabilisée est le point de départ. Pour une alerte intrajournalière, l’exportation en flux continu peut servir de signal provisoire.
events_intraday_YYYYMMDD comme une table provisoire. Rejouez l’analyse sur la table quotidienne.| Critère | Export quotidien | Exportation en flux continu |
|---|---|---|
| Disponibilité | Une fois par jour, horaire non garanti | En quelques minutes, en continu |
| Stabilité | Mises à jour possibles pendant trois jours | Sans garantie d’exhaustivité |
| Attribution | À privilégier pour les données utilisateur stabilisées | Certaines sources utilisateur et de session arrivent plus tard |
| Limite et coût | Un million d’événements par jour pour une propriété standard | Pas de limite de volume GA4 publiée ; 0,05 $ par gigaoctet exporté, hors stockage et requêtes |
| Bac à sable | Possible sous les limites du bac à sable | Import intrajournalier indisponible |
« Mise à jour quotidienne » ne constitue pas une troisième option universelle. Cette fréquence plus rapide est réservée à certaines propriétés Analytics 360. Ne la mélangez pas avec l’exportation en flux continu dans votre cahier des charges.
Sources officielles Google vérifiées le 21 juillet 2026 : aide Google Analytics sur l’export quotidien, la mise à jour quotidienne, l’exportation en flux continu et son tarif et sur l’absence d’import intrajournalier dans le bac à sable.
Que faire concrètement des données exportées ?
BigQuery devient utile lorsque la question exige une granularité ou une jointure que l’interface ne fournit pas. Le SQL n’est pas la finalité. La décision métier l’est.
LTV par canal : l’identité avant le calcul
user_pseudo_id identifie de façon pseudonyme une instance d’application ou un navigateur. Un changement d’appareil, de navigateur, de cookie ou d’état de consentement peut donc fragmenter une même personne. Google Signals ne fournit pas son identité interappareils dans l’export BigQuery.
Une LTV client fiable demande une clé plus solide : un user_id gouverné ou un identifiant métier consenti, sans donnée directement identifiante envoyée à GA4, plus un transaction_id unique relié au back-office. Le rapprochement doit aussi traiter remboursements, devises, marges et doublons. Sans cette discipline, vous calculez une LTV de navigateur.
Choisissez ensuite la portée d’acquisition. traffic_source décrit le premier contact utilisateur. session_traffic_source_last_click porte la source et le support attribués à la session. collected_traffic_source conserve les valeurs collectées avec l’événement. Ces champs ne répondent pas à la même question, et BigQuery n’applique pas l’attribution fondée sur les données de l’interface.
Cohortes : sortir de la rétention d’interface, pas de la gouvernance
Les tables quotidiennes peuvent être conservées au-delà des fenêtres de lecture de certaines surfaces GA4. Vous définissez alors la durée dans BigQuery. Ce contrôle ne signifie pas « conserver pour toujours ». Fixez l’expiration, la suppression et la justification de chaque historique selon votre finalité.
Sources officielles Google vérifiées le 21 juillet 2026 : schéma Google Analytics sur user_pseudo_id et les portées de source de trafic ; documentation Google Analytics sur les niveaux utilisateur, session et événement et les ruptures d’identité et l’absence de Google Signals.
Écarts GA4 et Google Ads : diagnostiquer, pas promettre l’égalité
BigQuery aide à repérer un achat dupliqué, une devise absente, un marquage interrompu ou une portée d’attribution mal choisie. Il ne reconstitue pas pour autant la modélisation des événements clés, les conversions interappareils ni toute la logique d’attribution de Google Ads. Certains écarts resteront légitimes.
Le bon objectif n’est donc pas une égalité ligne à ligne. Cherchez une cause documentée, mesurez son effet et acceptez les différences de périmètre qui subsistent. La donnée détaillée améliore le diagnostic. Elle ne fusionne pas deux systèmes de mesure.
Rapprocher Google Ads avec le gclid : une jointure conditionnelle
Le connecteur BigQuery Data Transfer Service charge des rapports Google Ads dans BigQuery. Il ne transforme pas la source et le support Analytics en données Ads. Pour certains clics, une jointure est possible entre collected_traffic_source.gclid côté GA4 et le champ gclid de la table ads_ClickStats_<customer_id>.
Cette jointure suppose l’auto-tagging, un gclid effectivement collecté, la table ClickStats disponible et des dates compatibles. Elle ne couvre ni les interactions sans identifiant exploitable, ni wbraid ou gbraid, absents de l’export BigQuery GA4. Elle peut renseigner certains clics Google Ads marqués « non disponibles ». Pas corriger toute source manquante.
Le retour vers la publicité n’est pas natif à l’export GA4. Pour activer une liste préparée dans BigQuery, une voie distincte consiste à connecter BigQuery à Google Ads Data Manager pour Customer Match. Cette voie exige les droits Cloud et Ads, des données propriétaires admissibles, un compte éligible et le respect des règles Customer Match. Dans l’EEE, les signaux ad_user_data et ad_personalization doivent refléter le consentement requis.
Sources officielles Google vérifiées le 21 juillet 2026 : documentation sur la jointure GA4 avec ClickStats et le transfert des rapports Google Ads ; aides Google sur la connexion BigQuery à Ads Data Manager, l’éligibilité et les règles Customer Match et les signaux de consentement Customer Match.
RGPD et export BigQuery GA4 : quels réglages prévoir ?
user_pseudo_id est pseudonyme, pas anonyme. Il peut permettre un rapprochement et rester une donnée personnelle au sens du RGPD. Le fait que Google ne le classe pas comme information directement identifiante dans ses contrats ne le sort pas du droit européen.
Votre dossier doit couvrir au minimum la finalité, la minimisation, la base légale, l’information des personnes, la durée de conservation, la suppression, les droits d’accès, la journalisation, les sous-traitants, les transferts et l’analyse de risque. Dans BigQuery, traduisez cela en expirations de tables, droits au moindre privilège, contrôles par ligne ou colonne si nécessaire, et journaux d’accès revus.
La région se choisit avant la liaison, mais elle ne règle pas seule la conformité. Si elle doit changer, Google documente deux voies. La première supprime puis recrée la liaison après déplacement des données, avec un risque de trou d’export. La seconde utilise la réplication interrégionale de l’ensemble de données pour migrer sans interrompre la liaison.
Le mode Consentement change ce qui arrive. En mode basique, aucune donnée n’est envoyée avant consentement. En mode avancé, des signaux sans cookies peuvent être collectés quand le stockage Analytics est refusé. Ces signaux figurent dans BigQuery, mais la modélisation comportementale et celle des événements clés restent dans les surfaces de reporting. Chaque session sans stockage Analytics peut recevoir un user_pseudo_id distinct.
Vous contrôlez le projet Cloud et ses listes d’accès. Vous ne contrôlez pas seul la collecte, le traitement ni l’évolution du schéma GA4. Une architecture durable documente cette dépendance, les modalités de suppression et la portabilité. Elle ne se contente pas de l’étiquette « donnée propriétaire ».
Sources officielles Google vérifiées le 21 juillet 2026 : aides Google sur les modes de consentement basique et avancé, les signaux sans cookies et la modélisation absente de BigQuery, les identifiants pseudonymes et les données personnelles et les deux méthodes de changement de région ; Google Cloud sur le RGPD et les engagements Cloud et les journaux d’audit BigQuery.
L’export BigQuery est-il réservé aux grands comptes ?
Non. Mais la taille compte quand même. La question métier détermine la valeur ; le volume détermine le quota, le stockage, les octets scannés et l’effort d’exploitation. Opposer les deux revient à ignorer la moitié de la décision.
Un volume modeste peut justifier BigQuery si une jointure avec le back-office répond à une décision rentable. Un gros volume ne le justifie pas sans finalité, propriétaire et compétence SQL. La facture Cloud n’est qu’une partie du coût. Le temps de contrôle et de maintenance pèse aussi.
Enfin, l’export ne copie pas « tout GA4 sans filtre ». Il contient les événements reçus après consentement et traitement, selon les flux sélectionnés et les exclusions configurées. Les erreurs de marquage, valeurs incohérentes et certains doublons peuvent rester. Vérifiez la fraîcheur, le schéma et les transactions avant chaque usage décisionnel.
Activer l’export quotidien si
- une finalité et une durée de conservation sont écrites
- le volume reste sous contrôle ou les filtres sont prévus
- les accès, la facturation et les alertes ont un propriétaire
- une première requête de contrôle est définie
Attendre si
- l’identité client et les transactions ne sont pas fiables
- aucune question ne dépasse les rapports GA4
- personne ne maintiendra le SQL et le schéma
- la base légale ou les règles de suppression restent floues
- BigQuery évite la ligne « (other) » et l’échantillonnage des surfaces de reporting, pas les limites de collecte, d’export ou de Cloud.
- Une propriété standard reste plafonnée à un million d’événements par jour pour l’export quotidien.
- La modélisation des événements clés, la modélisation comportementale et Google Signals ne sont pas présents dans l’export événementiel.
- Une LTV fiable commence par l’identité, la transaction et la règle d’attribution, avant le SQL.
La décision
Activez l’export quotidien seulement si la finalité, la gouvernance, le volume et le budget Cloud sont documentés. Puis lancez une requête de contrôle : nombre d’achats, unicité des transactions, devises, consentement et fraîcheur. Ce résultat décide si la donnée peut soutenir une analyse plus ambitieuse.
Le retournement est simple. La question n’est pas « pouvons-nous envoyer GA4 dans BigQuery ? ». La liaison sait le faire. La vraie question est : quelle décision accepterez-vous de prendre avec ces lignes, et quelles limites afficherez-vous à côté ?
