GA4 export BigQuery : pourquoi, quand activer et quelle question formuler en premier

C'est le prolongement naturel de ce que GA4 pour Google Ads pose comme rôle : quand l'écran GA4 lui-même plafonne, l'exportation prend le relais.

Pourquoi l'export BigQuery est-il la sortie de secours de GA4 ?

Reprenez les pages précédentes : les identifiants uniques que les dimensions personnalisées GA4 rejettent (cardinalité, ligne « (other) »), les quotas d'enregistrement, la rétention bornée de l'écran, l'échantillonnage des explorations sur gros volumes, chaque limite précédente se concluait par le même renvoi.

Le voici. Cette base est la sortie de secours officielle des plafonds de GA4 : chaque interaction collectée reste disponible, brute et ligne à ligne, sans être bridée par l'écran qui l'affiche.

Et la question prioritaire, celle qui justifie souvent la liaison pour un annonceur, est celle que ce socle pose depuis le pilier mesure et tracking Google Ads, sur le terrain de l'unit economics : la LTV par canal d'acquisition.

GA4 vous donne des conversions par source ; il ne répond pas proprement à une question comme « les clients acquis par la campagne X ont généré combien de marge sur 24 mois ». Cette analyse exige une donnée plus fine, croisée avec votre back-office.

Elle vit dans l'entrepôt, et le reporting Looker Studio LTV/CAC qui clôt cette branche s'y alimente : le tableau de bord interroge la base, pas l'inverse.

Comment configurer l'export GA4 vers BigQuery ?

La mise en place est rapide si le projet Google Cloud existe déjà. Le libellé de l'écran GA4 peut évoluer, mais la logique reste la même : lier la propriété au projet, choisir la région, puis sélectionner la fréquence de chargement.

1. Admin → Liaisons produits → BigQuery Dans votre propriété GA4, ouvrez Administration, puis dans la colonne Propriété, trouvez « Liaisons BigQuery ».
2. Sélectionner ou créer un projet GCP Associez un projet Google Cloud Platform existant ou créez-en un. C'est ce projet qui hébergera les tables et supportera les coûts GCP.
3. Choisir la région d'hébergement Sélectionnez une région cohérente avec votre gouvernance de données, souvent une région européenne pour des utilisateurs européens. Ce choix se prépare avant activation.
4. Cocher la fréquence Quotidien pour une table complète de la veille, ou streaming si vous avez un besoin avéré de fraîcheur intra-journalière. Commencez par le quotidien seul dans la plupart des cas analytiques.
5. Valider Les premières tables apparaissent après le démarrage de la liaison. Le dataset s'appelle généralement analytics_<ID_propriété>, avec une table events_YYYYMMDD par jour.

Quel schéma de données vous attend dans BigQuery ?

Le schéma GA4 est imbriqué (nested) dans l'entrepôt. C'est la première source de déroute pour qui l'ouvre en s'attendant à un tableau de bord.

Chaque ligne de la table events_YYYYMMDD représente un fait unitaire : un page_view, un purchase, un click… Les paramètres de ce fait ne sont pas dans des colonnes séparées. Ils sont dans un champ event_params de type ARRAY<STRUCT<key, value>>. Pour lire la valeur d'un paramètre, il faut le dénester avec la fonction SQL UNNEST, sans quoi la requête retourne une colonne de tableaux illisibles.

Deux variantes de tables coexistent dans votre dataset : - events_YYYYMMDD, la table quotidienne complète, généralement disponible en milieu d'après-midi dans le fuseau horaire de la propriété, sans horaire garanti. - events_intraday_YYYYMMDD, la table du jour en cours, alimentée en continu si le streaming est activé, effacée quand la table quotidienne la remplace en fin de journée.

Les dimensions personnalisées GA4 rejetées par l'écran pour cause de cardinalité arrivent ici intactes, dans event_params ou user_properties. C'est précisément l'intérêt du stockage brut : ce que l'écran agrège et tronque, la base le conserve ligne à ligne.

Cet outil n'est pas couvert ici comme un tutoriel SQL. L'objectif est de savoir ce qui vous attend : des tables imbriquées, un SQL particulier, et une structure qui devient lisible dès qu'on a compris la logique d'UNNEST. Le reste, c'est de la pratique.

Voici néanmoins une requête de contrôle utile : elle isole les achats sur une plage de dates et lit leur valeur dans event_params. La pseudo-colonne _TABLE_SUFFIX évite de scanner toutes les tables quotidiennes.

SELECT
  event_date AS date,
  event_timestamp AS timestamp,
  user_pseudo_id,
  (SELECT COALESCE(value.double_value, value.int_value)
   FROM UNNEST(event_params)
   WHERE key = 'value') AS purchase_value
FROM `mon-projet.analytics_123456.events_*`
WHERE event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN '20260101' AND '20260131';

Ce que coûte réellement l'export pour une PME

Coût GCP : stockage, volume de requêtes, et ce que la gratuité ne dit pas

La liaison elle-même est native côté GA4. Ce que vous payez éventuellement, c'est le stockage et le volume interrogé dans l'entrepôt. Les ordres de prix ci-dessous sont indicatifs et doivent être vérifiés dans votre console GCP selon la région, la facturation et les tarifs en vigueur :

• Stockage actif : ~0,02 $/Go/mois, gratuit sous 10 Go/mois
• Requête à la demande : ~6,25 $/To scanné, gratuit sous 1 To/mois

À l'échelle d'une PME standard, le volume reste souvent bas par rapport aux seuils gratuits. Voici des ordres de grandeur indicatifs par palier :

Ces estimations supposent un usage analytique modéré. Le coût GCP n'est généralement pas le premier sujet pour une PME standard ; la décision se joue davantage sur la question métier et la compétence disponible.

C'est l'autre sortie des données GA4 : là où relier GA4 à Google Ads renvoie les conversions vers l'enchère, l'exportation les déverse au niveau événement dans une base de données, deux canaux, deux usages.

Deux coûts réels se cachent derrière la gratuité de façade.

L'exploitation. La donnée arrive brute, dans un schéma imbriqué qui s'interroge en SQL. Pas d'écran, pas de graphique : des tables. Entre « disposer des lignes » et « répondre à une question », il y a de la compétence et de la maintenance. C'est le prix réel.

Le temps. Le chargement n'est pas rétroactif : il accumule à partir de son activation. La question de LTV que vous vous poserez dans dix-huit mois exigera dix-huit mois de données, qui n'existeront que si la liaison tournait déjà.

Deux temps volontairement dissociés : agir tôt, exploiter sur question. La mise en place est un investissement léger dans vos options futures.

L'exploitation ne se lance que sur une question formulée que l'écran a refusée. Accumuler « pour avoir la donnée », sans question, c'est payer un grenier : de la donnée qu'on n'interroge pas n'est pas un actif, c'est du stockage mort.

Quotidien ou streaming : quelle fréquence choisir ?

Le choix ne se prend pas sur un critère technique mais sur une question métier : est-ce que ma question exige une donnée de moins de 24 heures ?

Que faire concrètement de vos données BigQuery ?

Avoir la donnée dans l'entrepôt n'est pas une fin en soi. La page qui explique le POURQUOI de la mise en place oublie souvent d'en montrer le QUOI. Voici les usages, ordonnés par valeur terrain.

LTV par canal d'acquisition : la question prioritaire

C'est la raison principale de s'y mettre. GA4 vous donnera des conversions par source/medium ; il ne calcule pas proprement la marge générée sur 18 mois par les clients acquis via la campagne X. Ce croisement exige les données brutes stockées, canal d'acquisition, user_pseudo_id et dates de transaction, puis les données back-office, montants, marges et réachats. Le résultat alimente directement le reporting Looker Studio LTV/CAC qui en est la sortie naturelle.

Analyses de cohortes sans plafond de rétention

L'écran GA4 borne la rétention exploitable de certaines données utilisateur. L'entrepôt ne suit pas cette logique d'interface : vos tables events_YYYYMMDD s'accumulent tant que la liaison tourne et que vous les conservez. Pour une question de cohorte sur 24 ou 36 mois, comparer la valeur de clients acquis en 2023 vs 2024 sur la durée réelle, c'est le bon endroit pour poser la question.

Réconciliation des écarts GA4 vs Ads avec la donnée brute

Quand les chiffres de conversions divergent entre Google Ads et GA4, l'écran des deux outils ne permet pas de descendre au niveau de la transaction individuelle. L'entrepôt ouvre ce niveau : en croisant les lignes brutes avec le transfert de données Ads, vous identifiez l'origine de l'écart, fenêtre d'attribution, double comptage ou marquage manquant. Pour aller plus loin sur ce sujet : les écarts de conversion Ads vs GA4 est la page dédiée.

Joindre Google Ads à GA4 dans BigQuery : le rôle du gclid

Un flux séparé, à ne pas confondre avec la liaison GA4 : le BigQuery Data Transfer Service pour Google Ads, un service Google distinct qui rapatrie vos données de campagne, clics, coût et association source/medium, dans le même projet. Une fois les deux flux dans la même base, la jointure se fait sur un identifiant commun, le gclid, présent côté GA4 dans collected_traffic_source et côté Ads dans la table de transfert.

Cette association a un usage précis : quand une ligne GA4 affiche une source de trafic non disponible ou tronquée, interroger le gclid peut aider à retrouver la campagne d'origine sans dépendre uniquement du modèle d'attribution de l'écran. C'est une seconde brique, au-delà du flux natif, pour qui pousse l'analyse jusqu'au rapprochement fin Ads/GA4. La mettre en place exige une compétence SQL en plus ; elle s’ajoute au parcours décrit plus haut seulement si la question posée le justifie.

Le sens inverse existe aussi dans certains montages. Une fois des segments construits en SQL dans la base, une audience définie par un comportement précis, pas par une simple visite, vous pouvez les préparer pour l'activation publicitaire. C'est le pont entre la modélisation SQL et le remarketing : le ciblage hérite d'une segmentation plus fine que ce que l'écran GA4 propose nativement, au prix, encore, de la compétence pour l'écrire et la maintenir.

RGPD et export BigQuery GA4 : ce qu'il faut régler avant de vous lancer

L'entrepôt soulève deux implications RGPD à traiter au moment de la mise en place, pas après.

La région d'hébergement se prépare avant activation. Lors de la liaison GA4 → BigQuery, vous choisissez la région GCP où vos données seront stockées. Pour des données d'utilisateurs européens, choisissez une région cohérente avec votre gouvernance (par exemple une région UE comme Belgium/europe-west1, selon votre politique). Une fois la liaison créée, changer de région implique généralement de recréer la liaison et de gérer séparément l'historique accumulé dans l'ancien dataset.

La donnée transférée contient user_pseudo_id, pas l’identifiant utilisateur réel. Par défaut, GA4 transmet un identifiant pseudonymisé. Cela ne dispense pas d'une base légale, d'une information claire et d'une configuration correcte du Consent Mode. Attention : si vous envoyez le user_id via GA4, il arrive dans l'entrepôt. Régissez cela dans votre politique de données et votre DPA GCP avant de le mettre en place.

Cette architecture est un pilier first-party data durable pour votre marketing : une donnée sous votre contrôle, dans votre propre projet GCP, sans dépendance à l'écran web d'un tiers. C'est le complément naturel d'une stratégie cookieless et first-party data sur le long terme.

L'export BigQuery est-il réservé aux grands comptes ?

Le mythe « BigQuery, c'est pour les grands comptes » confond le critère. La taille ne décide rien, la question décide.

Un compte modeste avec un cycle de réachat et une question précise de LTV par canal a plus à y gagner qu'un gros compte qui regarde des CPA hebdomadaires. À l'inverse, si toutes vos questions trouvent leur réponse dans l'écran (pour beaucoup de comptes mono-produit à cycle court, c'est le cas), l'exploitation peut attendre.

La mise en place peut précéder l'exploitation : elle ouvre l'option avant que la question devienne urgente.

Le point honnête : l'entrepôt hérite de la collecte telle quelle. Les trous de consentement, les faits mal formés et les valeurs fausses y arrivent aussi ; la base ne purifie rien, elle conserve.

La qualité se gagne surtout en amont, dans l'architecture qui précède : la même rigueur que pour la liaison GA4 au MCC, où la gouvernance des accès et des propriétés se décide proprement.

Le choix à faire

Aujourd'hui : activez le chargement quotidien si la gouvernance est prête, puis laissez le compteur de données démarrer. Ensuite, seulement sur question : la première exploitation porte souvent sur la LTV/CAC par canal, croisée avec votre back-office.

Vous ne déplacez pas des données pour le plaisir. Vous leur donnez un espace où répondre à une question qui n'avait pas de place ici : assurez-vous d'en avoir une, et que l'accumulation ait commencé avant qu'elle devienne urgente.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026