En bref
- Trois limites justifient un export. L’échantillonnage des analyses complexes, le seuillage qui masque des lignes entières, et l’impossibilité de croiser vos sessions avec vos commandes réelles ou vos marges.
- BigQuery apporte la donnée brute. Un événement par ligne, sans seuillage, et la possibilité de recalculer une attribution selon vos règles plutôt que celles de Google.
- Le coût n’est pas le frein. Le palier gratuit couvre la majorité des PME. Le frein, c’est qu’il faut quelqu’un qui écrit du SQL, sinon l’entrepôt reste un placard.
- L’export n’est pas rétroactif. Activé aujourd’hui, il ne récupère rien d’hier. C’est la raison de le brancher maintenant, même si vous n’en ferez rien avant un an.
Un responsable e-commerce nous pose une question simple en réunion : quel canal d’acquisition lui amène les clients qui rapportent le plus de marge ? Pas le plus de chiffre d’affaires, le plus de marge. GA4 ne peut pas y répondre, ni aujourd’hui ni jamais.
La raison n’est pas un réglage manquant. GA4 ne connaît pas vos prix d’achat, ne voit pas vos retours produits, ignore les commandes annulées après le paiement. Il mesure des comportements sur un site, pas la santé d’un compte de résultat.
C’est à ce moment qu’un prestataire propose « d’exporter vers un data lake ». Parfois c’est le bon réflexe. Souvent c’est un chantier de plusieurs semaines pour une question qu’un tableur aurait traitée en deux heures. Voici comment faire la différence.
Les trois murs de l’interface GA4
Trois plafonds expliquent presque tous les besoins d’export légitimes. Si vous n’en rencontrez aucun, vous n’avez pas un problème de données, vous avez une envie d’outil.
L’échantillonnage sur les analyses complexes
Les rapports standards de GA4 ne sont pas échantillonnés. Les explorations, elles, le sont : au delà d’un certain volume d’événements sur la période demandée (de l’ordre de 10 millions pour une propriété gratuite), Google calcule sur un extrait et extrapole. Un bandeau discret le signale en haut du rapport.
Sur un trafic modeste, vous ne le verrez jamais. Sur une boutique à fort volume qui croise six dimensions, il rend l’analyse fine peu fiable.
Le seuillage qui fait disparaître des lignes
C’est le mécanisme le moins compris. Quand Google Signals est actif et qu’un croisement porte sur un groupe trop petit, GA4 supprime la ligne pour éviter d’identifier quelqu’un. Elle ne s’affiche pas à zéro : elle n’apparaît pas du tout.
Conséquence directe : vos totaux ne se recomposent plus. Vous additionnez les lignes visibles sans retrouver le total affiché, et aucune erreur n’est signalée. Sur une analyse par ville ou par produit peu vendu, la donnée manquante n’est pas une anomalie mais une règle de confidentialité.
Le croisement avec vos données de commande
C’est le mur le plus fréquent en PME. GA4 sait qu’une transaction de 149 EUR a eu lieu. Il dispose bien d’un événement refund natif, mais rien ne l’envoie automatiquement depuis votre back-office : sans câblage explicite, GA4 ignorera le remboursement intervenu trois semaines plus tard. Quant à la marge de 12 % et au fait que ce client en est à sa quatrième commande, aucune capacité native ne les lui apporte.
Ces informations vivent dans votre back-office. Tant que les deux mondes ne se rencontrent pas dans une même table, la marge par canal reste sans réponse, et aucun réglage GA4 ne comble cet écart.
Ce que l’export BigQuery apporte vraiment
L’export natif de GA4 vers BigQuery écrit une ligne par événement, chaque jour, avec l’intégralité des paramètres collectés. Pas d’agrégation préalable, pas de seuillage, pas d’échantillonnage : la table contient ce qui a été collecté, brut.
Deux conséquences pratiques. Vous pouvez joindre cette table à vos commandes réelles sur un identifiant commun, donc répondre à la question de la marge. Vous pouvez aussi recalculer une attribution avec vos règles : fenêtre de 7 jours plutôt que 90, exclusion du trafic de marque, autre pondération du premier point de contact.
Un troisième bénéfice passe inaperçu : la conservation. Les données événementielles exploitables dans les explorations GA4 tiennent 14 mois au maximum, deux mois par défaut si personne n’a touché le réglage. Dans BigQuery, elles restent aussi longtemps que vous les gardez.
| Le besoin exprimé | Ce que GA4 sait faire | Quand il faut sortir de l’outil |
|---|---|---|
| Quels canaux amènent le plus de commandes | Rapport Acquisition, suffisant | Presque jamais |
| Comparer deux segments sur plusieurs dimensions croisées | Exploration, échantillonnée sur gros volumes | Quand le bandeau d’échantillonnage apparaît |
| Analyser un segment fin (une ville, un produit peu vendu) | Lignes supprimées par le seuillage | Quand des lignes manquent sans explication |
| Rapprocher le CA GA4 du CA réellement encaissé | Sans câblage explicite, retours et annulations ne remontent pas | Quand l’écart dépasse ce que vous savez expliquer |
| Classer les canaux par marge et non par CA | Impossible : GA4 ignore vos coûts | Quand la question arrive en comité de direction |
| Recalculer l’attribution avec vos règles | Modèles imposés, non modifiables | Quand le modèle de Google contredit votre terrain |
Le coût réel, présenté honnêtement
L’export quotidien de GA4 vers BigQuery ne coûte rien. Ce qui est facturé, c’est ce que vous faites ensuite : le stockage des tables et le volume de données analysé par vos requêtes.
Les ordres de grandeur, à la grille publique Google et à vérifier avant de vous engager : un palier mensuel gratuit de 10 Gio de stockage actif et de 1 Tio analysé, puis quelques centimes par gigaoctet stocké et quelques euros par tébioctet analysé. Pour une boutique de PME, une année d’événements se compte en gigaoctets, pas en téraoctets, et la facture réelle tourne souvent autour de zéro.
Ce n’est donc pas le coût de l’infrastructure qui fait échouer ces projets. C’est un usage mal maîtrisé.
L’erreur à ne pas commettre Les tables d’export GA4 sont découpées par jour. Une requête sans filtre de date, ou un SELECT * lancé pour « voir à quoi ça ressemble », scanne tout l’historique à chaque exécution. Deux analystes curieux et un tableau de bord qui rafraîchit toutes les heures suffisent à faire passer une facture de 0 EUR à trois chiffres. La parade : filtrer sur la date, et poser un plafond de coût par requête dans le projet Google Cloud.
Sans quelqu’un qui écrit du SQL, l’entrepôt reste vide
Disons-le franchement, parce que c’est le point que les prestataires évitent : un entrepôt de données ne produit aucune valeur tant que personne n’écrit de requêtes dedans.
BigQuery n’a pas d’interface de rapport. Ni graphique de sessions, ni entonnoir de conversion. Des tables, où chaque événement range ses paramètres dans une structure imbriquée qu’il faut savoir déplier avant même de compter une ligne. La première requête utile demande une demi-journée à quelqu’un qui n’a jamais vu ce format.
La question à trancher est donc une question de ressource, pas de technologie : qui écrira les requêtes ? Si la réponse est « personne, on verra plus tard », l’export garde malgré tout un intérêt, pour la raison qui suit.
Le point que presque tout le monde oublie : rien n’est rétroactif
L’export commence le jour où vous l’activez et ne remonte pas dans le temps. Branché en mars 2026, il ne vous donnera jamais l’historique 2025 sous forme brute, quelle que soit la somme que vous y mettrez ensuite.
C’est ce qui rend le conseil asymétrique. Activer l’export coûte vingt minutes et, tant que personne ne requête, zéro euro par mois. Ne pas l’activer coûte une année d’historique le jour où le besoin apparaît.
Ce qu’il faut retenir Activez l’export BigQuery dès maintenant, même sans idée de ce que vous en ferez. C’est la seule décision de cet article qui se prend sans arbitrage : le coût est nul, l’oubli est irrattrapable.
Exporter une donnée fausse ne la rend pas vraie
Un entrepôt amplifie ce qu’on lui donne. Si vos achats sont comptés deux fois parce qu’ils partent à la fois du navigateur et du serveur, BigQuery stockera fidèlement le double comptage, et vos analyses le propageront partout.
Vérifiez donc d’abord que vous exportez quelque chose de juste : rapprocher jour par jour vos commandes réelles et ce que GA4 enregistre suffit à repérer l’essentiel des écarts, méthode que nous détaillons dans notre article sur un tracking qui ment en silence. Pour automatiser ce contrôle, nous déployons chez nos clients DataFirefly Server-Side, éditée par Datafirefly Limited, société sœur de notre agence, dont le forfait gratuit de 10 000 requêtes par mois suffit sur une boutique.
Le second prérequis est documentaire. Sans plan de marquage tenu à jour, vous serez dans six mois devant une table contenant trois versions du même événement, nommées différemment selon la période, sans personne pour dire laquelle fait foi. Ce travail de structuration de la mesure vient avant l’entrepôt.
Ce que vous pouvez faire cette semaine
- Ouvrez l’administration de votre propriété GA4 et regardez si un lien BigQuery existe déjà. Beaucoup en ont un, activé par un ancien prestataire et jamais exploité.
- Sinon, créez un projet Google Cloud et branchez l’export quotidien. Choisissez l’emplacement européen du jeu de données à la création : il ne se change plus ensuite.
- Dans le même écran, portez la conservation des données événementielles à 14 mois si elle est encore sur deux mois.
- Notez la date d’activation. C’est le début de votre historique brut, et il ne commencera pas plus tôt.
- Posez un plafond de coût par requête avant que quiconque n’accède au projet.
- N’écrivez la première requête que le jour où vous avez une question à laquelle GA4 ne répond pas.
Questions fréquentes
L’export de GA4 vers BigQuery est-il gratuit ?
L’export quotidien lui même ne coûte rien sur une propriété GA4 standard. Sont facturés le stockage des tables et le volume analysé par vos requêtes, avec un palier mensuel gratuit qui couvre la plupart des usages de PME. L’export en continu, lui, est facturé au volume et n’a d’intérêt que si la donnée à la minute vous est nécessaire.
Vais-je récupérer mon historique GA4 dans BigQuery ?
Non. L’export démarre à la date d’activation et ne remonte pas dans le passé. D’où l’intérêt de l’activer même sans projet immédiat : la configuration prend quelques minutes, l’historique perdu ne se rattrape pas.
Faut-il un data lake ou BigQuery suffit-il ?
Pour une PME dont la source principale est GA4, BigQuery suffit presque toujours : c’est la destination native de l’export, sans développement à écrire. Un data lake se justifie pour rassembler de nombreuses sources hétérogènes, avec les volumes et l’équipe technique qui vont avec.
Exporter mes données GA4 pose-t-il un problème RGPD ?
L’export déplace des données déjà collectées : il ne change ni la base légale ni le consentement recueilli. À surveiller : l’emplacement du jeu de données, la durée de conservation que vous décidez et les accès accordés. Nos repères sur la conformité de la mesure détaillent ce cadre.
La bonne question n’est pas technique
Avant d’ouvrir un chantier d’export, écrivez la question à laquelle vous voulez répondre et regardez si les rapports GA4 standards y répondent déjà. Dans la majorité des dossiers que nous auditons, ils y répondent, et le problème réel est ailleurs : collecte incomplète, plan de marquage flou, ou données propriétaires jamais rapprochées du reste.
Quand la question résiste vraiment à l’interface, l’export devient non seulement la bonne réponse, mais la seule. L’ordre compte : fiabiliser, documenter, puis exporter.
Un doute sur l’utilité d’un export GA4 vers BigQuery chez vous ? Nous commençons par comparer sur sept jours vos commandes réelles et ce que GA4 enregistre, puis nous listons les questions métier auxquelles votre configuration ne sait pas répondre. Parlons-en.
Sur ces sujets de mesure et de visibilité, la fiabilité de la donnée est décisive. On s'appuie sur le tracking Server-Side DataFirefly pour une mesure durable, résiliente aux bloqueurs et aux restrictions cookies.