BigQuery GA4 Data Warehouse Reconciliation

GA4 interface vs BigQuery export : pourquoi vos chiffres ne matchent pas (et comment les réconcilier)

Le sujet brûlant pour les CMO en 2026 : démêler les écarts entre l'interface GA4 et BigQuery, et savoir lequel croire pour décider

Robin Guedoit 10 min de lecture
Sommaire de l'article

C'est la question qui revient le plus souvent en réunion CMO en 2026 : "mon analyste me sort 47 320 utilisateurs sur BigQuery la semaine dernière, mais l'interface GA4 m'affiche 51 480. Lequel je crois pour décider ?". La réponse est plus subtile que "celui-ci a raison" — c'est un problème de réconciliation, pas de bug. Ce guide résume la méthode que nous utilisons chez Data Detective pour démêler les écarts entre l'interface GA4 et l'export BigQuery, et expliquer à un comité de direction pourquoi les deux chiffres sont valides chacun à leur manière.

Pourquoi le sujet est devenu critique en 2026

Pendant longtemps, peu de CMO regardaient les deux sources en parallèle. Quand BigQuery a commencé à se généraliser en PME en 2024-2025, les écarts sont devenus visibles dans tous les comités de direction — et personne dans les équipes ne savait les expliquer.

Trois raisons font que le sujet est maintenant incontournable :

Premièrement, la généralisation du Consent Mode V2. Depuis mars 2024, le Consent Mode V2 est obligatoire pour alimenter les audiences Google Ads en zone EEE. Cela introduit une couche massive de données modélisées dans GA4 — des chiffres estimés par algorithme pour combler les utilisateurs qui ont refusé le tracking. Comme l'explique la documentation Google, aucune de ces données modélisées n'est exportée vers BigQuery. Résultat : les deux sources affichent des chiffres légitimement différents.

Deuxièmement, l'utilisation croissante des dashboards Looker Studio branchés directement sur BigQuery. Quand le CMO regarde un dashboard, il voit BigQuery. Quand il ouvre l'interface GA4 à côté, il voit autre chose. La confiance dans la donnée s'érode si personne n'arrive à expliquer pourquoi.

Troisièmement, les exigences accrues de défense devant un comité. En 2026, un CMO doit pouvoir justifier d'où vient chaque euro investi en média. Si la donnée varie de 8% entre deux sources Google sans qu'on puisse l'expliquer, le crédit data de l'équipe marketing s'effondre.

Les symptômes qui doivent vous alerter

Trois signaux concrets qui indiquent qu'un travail de réconciliation est urgent :

  • Vos chiffres GA4 et BigQuery affichent des écarts supérieurs à 5% sur les métriques utilisateurs ou sessions, et personne dans l'équipe n'arrive à les expliquer simplement.
  • Vous avez un dashboard Looker Studio branché sur BigQuery et un dashboard GA4 natif côte à côte, et les deux affichent des KPI qui divergent.
  • Une réunion de comité de direction a tourné court parce que les chiffres BigQuery présentés ne matchaient pas avec ce que le CFO voyait dans GA4.

Si l'un de ces symptômes est présent, le sujet doit être documenté avant la prochaine réunion stratégique.

Étape 1 — Comprendre le principe fondateur : ce sont deux mondes différents

La documentation officielle Google le pose clairement : l'export BigQuery est conçu pour fournir la donnée collectée — celle envoyée par votre site à GA4. L'interface GA4, elle, applique par-dessus une couche de valeur ajoutée : modélisation, signaux Google, attribution session, déduplication cross-device.

L'image qui marche en réunion : BigQuery, c'est l'enregistrement audio brut d'une conversation. L'interface GA4, c'est la transcription avec correction grammaticale et résumé. Les deux versions parlent du même événement, mais elles ne contiennent pas exactement la même information.

Pour la grande majorité des cas d'usage, les deux sources ne sont pas censées matcher exactement. Ce qu'on cherche, c'est de la cohérence interne des deux côtés et une explicabilité de l'écart.

Vos chiffres GA4 et BigQuery ne matchent plus ?

30 minutes pour identifier les 3 raisons précises de l'écart dans votre setup et la méthode pour réconcilier.

Réserver un audit flash

Étape 2 — Les 7 raisons précises pour lesquelles les chiffres divergent

Voici la liste que nous utilisons en audit, dans l'ordre de fréquence.

1. L'échantillonnage côté GA4. Quand vos rapports GA4 dépassent un certain volume ou complexité, GA4 calcule sur un sous-ensemble et extrapole. BigQuery travaille toujours sur la donnée complète. Le sampling est documenté côté Google mais reste invisible à l'œil nu dans la plupart des rapports.

2. La cardinalité. GA4 plafonne à 500 valeurs uniques par dimension par jour et regroupe le surplus dans une ligne "(autre)". Sur un site ecommerce avec 2000 références produit, cela peut représenter 20 à 30% du trafic invisibilisé dans l'interface mais visible dans BigQuery.

3. Active Users vs Total Users. La documentation Google insiste sur ce point : la métrique principale dans l'interface GA4 est "Active Users" (utilisateurs avec une session engagée), pas "Total Users". Si vous comptez les utilisateurs distincts dans BigQuery sans filtrer sur l'engagement, vous obtenez les Total Users — toujours plus haut que les Active Users de l'interface. Le filtre clé est is_active_user, un champ booléen présent dans l'export.

4. L'algorithme HyperLogLog++. Pour estimer rapidement le nombre d'utilisateurs uniques, GA4 utilise une approximation statistique plutôt qu'un comptage exact. La précision est typiquement de plus ou moins 1,63% à 95% de confiance. BigQuery, lui, peut faire un comptage exact. Donc même sans aucun autre facteur, les deux sources peuvent diverger d'un pourcent ou deux.

5. Les signaux Google. Si vous avez activé les signaux Google et qu'un utilisateur visite le site sur trois navigateurs différents avec son compte Google connecté, l'interface GA4 le compte comme un utilisateur. BigQuery, qui ne reçoit pas la donnée des signaux Google, le compte comme trois utilisateurs distincts (user_pseudo_id différents).

6. Le Consent Mode et la donnée modélisée. Quand un utilisateur refuse les cookies, GA4 dans l'interface affiche des chiffres modélisés (estimés). Aucune de ces estimations n'est exportée vers BigQuery — vous y trouvez à la place des "cookieless pings" anonymes.

7. Le décalage temporel. Les tables daily BigQuery peuvent être mises à jour jusqu'à 72 heures après la date du rapport pour intégrer les événements en retard (offline, mobile). Le conseil Google : pour comparer GA4 et BigQuery, comparez sur des données plus vieilles que 72 heures.

Étape 3 — Identifier les écarts spécifiques entre Data API et BigQuery

Beaucoup de CMO confondent "interface GA4" et "Data API GA4" (utilisée notamment dans les connecteurs Looker Studio natifs). Ce n'est pas la même chose.

InfoTrust résume bien la distinction : la Data API est conçue pour matcher exactement l'interface GA4, même quand le Consent Mode est activé. Donc Data API et interface GA4 doivent être strictement cohérentes. BigQuery, lui, contient la donnée brute, pas la donnée retraitée.

Les différences entre Data API et BigQuery sont donc :

  • Data API : données agrégées, soumises à l'échantillonnage, à la cardinalité et à la rétention quand les quotas sont dépassés. Inclut les signaux Google et les données modélisées.
  • BigQuery : export brut, sans échantillonnage, sans cardinalité, sans seuillage. Pas de signaux Google, pas de données modélisées.

Pour un CMO qui veut faire un dashboard fiable, la règle est simple : si vous voulez du reporting de surface qui matche l'interface GA4 (à montrer en réunion direction), utilisez la Data API. Si vous voulez répondre à des questions business avancées, utilisez BigQuery.

Étape 4 — La méthode de réconciliation en pratique

Voici la méthode en 4 étapes que nous appliquons à chaque mission.

Première étape : choisir une fenêtre stable. Comparer GA4 interface et BigQuery sur une période d'au moins 7 jours, terminée il y a plus de 72 heures. Cela neutralise le décalage temporel des événements offline et les mises à jour rétroactives.

Deuxième étape : aligner les définitions. Comme le détaille GA4BigQuery, il faut explicitement filtrer sur is_active_user = true côté BigQuery pour comparer aux Active Users de l'interface, et utiliser une combinaison user_id + user_pseudo_id pour la déduplication. Sans ces deux conditions, l'écart est mécanique et ne signifie rien.

Troisième étape : calculer les écarts par cause. On isole l'écart attribuable à chaque cause (échantillonnage, cardinalité, signaux Google, Consent Mode, HLL++) en faisant des comparaisons ciblées. Par exemple : segmenter le trafic par canal, comparer trafic direct vs trafic Google Ads, comparer mobile vs desktop. Cela permet d'attribuer chaque pourcent d'écart à une cause précise.

Quatrième étape : produire un document de référence. Un PDF de 2 pages, partagé avec le comité de direction, qui explique : voici les écarts mesurés, voici leur cause, voici lequel utiliser pour quelle décision. C'est ce document qui restaure le crédit data de l'équipe marketing.

Besoin de reconstruire un système data fiable ?

On audite, répare et documente votre stack tracking en 4 à 6 semaines.

Voir la méthode Data Detective

Étape 5 — Quels chiffres utiliser pour quelle décision

Voici la matrice de décision que nous remettons systématiquement à nos clients CMO.

Pour la communication externe (presse, investisseurs, comité de direction) : utilisez les chiffres GA4 interface. Ils sont les chiffres officiels Google, ils intègrent la modélisation et les signaux Google, ils sont défendables même sans expertise technique. Si on vous demande "combien de visiteurs uniques", la réponse de référence est l'interface GA4.

Pour le pilotage opérationnel marketing (campagnes, créa, budget) : utilisez les deux. Interface GA4 pour les vues de surface, BigQuery pour les analyses fines (cohortes, attribution, mix par canal). Les deux sources sont valides à leur niveau.

Pour les analyses avancées (modèles d'attribution, scoring, machine learning) : utilisez exclusivement BigQuery. La donnée brute est la seule base saine pour ces usages. Les approximations de l'interface GA4 fausseraient les modèles.

Pour le reporting fiscal ou comptable : ni l'un ni l'autre. Utilisez votre back-office ou votre ERP. GA4 et BigQuery sont des outils d'analyse marketing, pas des sources comptables certifiées.

Étape 6 — Les erreurs de calcul fréquentes côté BigQuery

Avant de blâmer GA4, vérifiez que vos requêtes BigQuery ne contiennent pas une de ces erreurs récurrentes que Google liste explicitement.

  1. Compter les sessions à la journée puis sommer. Une session GA4 peut s'étendre sur plusieurs jours (un visiteur qui revient à 23h59 et part à 00h05). Si vous comptez les sessions par jour et que vous additionnez, vous comptez la même session deux fois. La méthode correcte : compter les combinaisons uniques user_pseudo_id + ga_session_id sur la période complète, sans agrégation par jour.

  2. Oublier le fuseau horaire. Dans BigQuery, event_date est dans le fuseau horaire de votre propriété GA4, mais event_timestamp est en UTC. Mélanger les deux dans une même requête fausse les bornes journalières.

  3. Ne pas filtrer la donnée intraday. Si vous incluez les tables events_intraday_* dans une comparaison avec l'interface GA4, vous comparez de la donnée non finalisée avec de la donnée finalisée. Les chiffres divergent forcément.

  4. Ne pas dédupliquer les utilisateurs avec COALESCE. Pour matcher l'interface GA4, il faut utiliser une combinaison COALESCE(user_id, user_pseudo_id) pour gérer les utilisateurs connectés et anonymes dans le même comptage. Compter uniquement user_pseudo_id surcompte les utilisateurs cross-device.

Étape 7 — Documenter la réconciliation pour l'équipe

Le dernier livrable d'une mission de réconciliation est toujours un document de référence pour l'équipe interne. Trois sections obligatoires :

  • Pour chaque KPI principal (utilisateurs, sessions, conversions), un écart attendu en pourcentage entre interface GA4 et BigQuery, et l'explication courte.
  • Une matrice de décision : pour quelle question, quelle source. À afficher en notion ou en wiki interne.
  • Un protocole de vigilance trimestriel : si l'écart sur un KPI dépasse une marge de tolérance (typiquement 8 à 10%), on déclenche une investigation. C'est le signal que quelque chose a bougé dans le tracking ou dans les paramètres GA4.

Ce document devient le socle de défense data de l'équipe marketing devant le comité de direction. Sans lui, chaque réunion devient une chasse au chiffre. Avec lui, on parle stratégie.

Conclusion

Les chiffres GA4 interface et BigQuery ne matchent pas, et c'est normal. Les deux sources ne sont pas conçues pour produire la même chose : l'une vous donne une synthèse retraitée par Google, l'autre vous donne la donnée brute événementielle. Le travail d'un CMO en 2026 n'est pas de chercher à les faire matcher exactement — c'est de comprendre l'écart, de le documenter, et de savoir lequel utiliser pour quelle décision.

La règle qui marche dans 95% des audits que nous menons : interface GA4 pour la communication externe et la cohérence avec les standards Google, BigQuery pour les analyses fines et le pilotage opérationnel. Et un document de réconciliation tenu à jour chaque trimestre, partagé avec le comité de direction, qui explique précisément les écarts. C'est ce qui sépare une équipe marketing data-driven crédible d'une équipe qui se fait challenger sur ses chiffres à chaque réunion.


Sources et ressources complémentaires

Robin Guedoit
À propos de l'auteur
Robin Guedoit
Fondateur Data Détective

Spécialiste data marketing. J'audite, répare et construis des systèmes data qui permettent de piloter efficacement votre marketing et d'exploiter à 100% vos données.

Prêt à arrêter de défendre des chiffres que vous ne maîtrisez pas ?

Data Detective réconcilie GA4 et BigQuery, documente les écarts et construit un dashboard Looker Studio défendable.

Réserver un appel découverte