ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Écarts de chiffres entre GA4 et BigQuery

Pourquoi le nombre de sessions et d'utilisateurs dans BigQuery ne correspondra pas à l'interface GA4, et l'approche pratique pour gérer un écart de 1 à 5 %.

Planté
ga4bigqueryanalyticsdata quality

Attendez-vous à un écart de 1 à 5 % entre les requêtes BigQuery et les rapports de l’interface GA4. Cet écart est normal, architecturalement inévitable, et ne devrait pas déclencher des efforts de réconciliation intensifs. Comprendre les causes spécifiques vous aide à définir des attentes appropriées auprès des parties prenantes et à éviter de perdre du temps à chercher un accord parfait entre deux systèmes conçus pour produire des chiffres différents.

Comptage probabiliste (HyperLogLog++)

L’interface GA4 utilise HyperLogLog++ pour compter les utilisateurs et les sessions uniques. Il s’agit d’un algorithme probabiliste qui échange la précision parfaite contre la vitesse et l’efficacité mémoire. Le taux d’erreur est typiquement inférieur à 1-2 % pour les cardinalités élevées.

BigQuery, lorsque vous écrivez COUNT(DISTINCT user_pseudo_id), retourne des comptages exacts. Il déduplique chaque valeur en mémoire. Le résultat est précis mais plus coûteux à calculer.

L’impact pratique : sur une métrique de 1 million d’utilisateurs uniques, HLL++ pourrait indiquer 995 000 ou 1 005 000. BigQuery indique exactement 1 000 000 (ou quel que soit le vrai comptage). Les deux sont corrects dans les définitions de leurs systèmes respectifs.

Pour reproduire le comportement de comptage de GA4 dans BigQuery à des fins de comparaison, utilisez APPROX_COUNT_DISTINCT() :

SELECT
  APPROX_COUNT_DISTINCT(user_pseudo_id) AS approx_users,
  COUNT(DISTINCT user_pseudo_id) AS exact_users
FROM sessionized_events
WHERE event_date = '2026-01-15'

Le comptage approximatif sera plus proche du chiffre GA4, bien que pas identique car GA4 utilise des paramètres de précision différents en interne.

C’est généralement la principale source d’écart. Le Consent Mode de GA4 permet aux utilisateurs de refuser le tracking. Pour les utilisateurs qui refusent le consentement, GA4 modélise leur comportement probable en se basant sur les patterns observés chez les utilisateurs consentants. Il estime les conversions, l’engagement et le nombre de sessions pour la population non-consentante et inclut ces données modélisées dans l’interface.

Ces données modélisées n’atteignent jamais les exports BigQuery. Vous n’obtenez que les événements des utilisateurs qui ont consenti au tracking.

L’écart dépend de votre taux de refus de consentement. Un site européen avec une bannière de cookies stricte peut voir 30 à 40 % de refus de consentement, ce qui signifie que l’interface GA4 rapporte 30 à 40 % de sessions et d’utilisateurs en plus que ce que BigQuery peut comptabiliser. Ce n’est pas une erreur — c’est le comportement prévu. GA4 affiche un modèle du trafic total ; BigQuery affiche le trafic observé.

Il n’existe aucun moyen de réconcilier cet écart côté BigQuery. Vous n’avez pas les données que GA4 a modélisées. Documentez cela pour les parties prenantes : « BigQuery rapporte uniquement le trafic consenti. GA4 inclut des estimations modélisées pour les utilisateurs non-consentants. »

Déduplication cross-device via Google Signals

Google Signals active la déduplication cross-device des utilisateurs dans l’interface GA4. Lorsqu’un utilisateur est connecté à son compte Google à la fois sur son téléphone et son ordinateur portable, GA4 peut le reconnaître comme une seule personne et dédupliquer ses sessions en conséquence.

BigQuery voit chaque device comme un user_pseudo_id distinct. La même personne sur téléphone et ordinateur compte comme deux utilisateurs dans vos données BigQuery. Il n’y a aucun lien entre leurs identifiants de device, sauf si ils s’authentifient dans votre application et que vous capturez un user_id.

GA4 peut donc rapporter moins d’utilisateurs uniques que BigQuery pour la même période. La différence est proportionnelle au nombre d’utilisateurs connectés à Google et utilisant plusieurs devices — ce qui varie significativement selon le type d’audience.

Délais de traitement des données

GA4 met à jour les tables d’export jusqu’à 72 heures après la date de l’événement. Les événements arrivent en retard en raison des délais réseau, des envois par batch du SDK mobile et des files d’attente de traitement côté serveur. L’interface GA4 traite certains de ces événements tardifs plus rapidement qu’ils n’apparaissent dans BigQuery.

Comparer des données de moins de 72 heures montrera des écarts qui se résolvent d’eux-mêmes avec le temps. C’est l’écart le plus facile à gérer : attendez 72 heures avant de comparer.

Pour vos modèles dbt incrémentaux, cela implique de configurer une fenêtre de lookback qui retraite les partitions récentes :

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

Un lookback de 7 jours capture toute arrivée tardive raisonnable tout en limitant le coût de retraitement.

Seuillage

GA4 applique un seuillage lorsque Google Signals est activé et que le nombre d’utilisateurs pour une valeur de dimension tombe en dessous d’un seuil de confidentialité. Dans ce cas, GA4 supprime des lignes des rapports pour empêcher l’identification des utilisateurs individuels. Les données ne sont pas perdues — elles sont simplement masquées dans l’interface.

BigQuery n’applique pas de seuillage. Vous voyez chaque événement collecté et exporté. Cela peut amener BigQuery à afficher des décompositions plus détaillées que l’interface GA4 pour les dimensions à faible trafic.

Gérer l’écart

  1. Documenter l’écart attendu. BigQuery et GA4 différeront de 1 à 5 %, parfois davantage pour les propriétés européennes avec un taux de refus de consentement élevé. C’est par conception.

  2. Comparer des données de plus de 72 heures. Éliminez la variable du délai de traitement avant d’investiguer d’autres écarts.

  3. Utiliser BigQuery comme source de vérité pour les tableaux de bord. BigQuery donne des chiffres exacts, reproductibles et auditables. L’interface GA4 donne des estimations modélisées. Les mélanger crée de la confusion.

  4. Surveiller l’écart dans le temps. Un changement soudain de l’écart (de 3 % à 15 %, par exemple) signale un changement de configuration — probablement une mise à jour de la bannière de consentement, un toggle Google Signals, ou un problème d’implémentation du tracking.

  5. La modélisation comportementale du Consent Mode ne peut pas être reconstruite à partir des données BigQuery. Les données modélisées ne sont pas dans l’export. L’écart entre les chiffres BigQuery et l’interface GA4 sur les propriétés européennes reflète le taux de refus de consentement, pas un problème de qualité des données.

La réconciliation parfaite n’est pas réalisable compte tenu des différences architecturales entre les deux systèmes.