GA4 données manquantes : bug Google ou votre tracking ?

Le 1er septembre 2026, des milliers de propriétés GA4 ont affiché zéro utilisateur dans les rapports standards alors que le Temps réel continuait de tourner. Traduction : les hits arrivaient bien chez Google, seul l’affichage mentait. Sauf que la plupart des équipes ont mis 24 à 48 heures à comprendre ça. Pendant ce temps, certaines ont paniqué, d’autres ont cru à une chute de trafic bien réelle, et les plus malchanceuses n’ont rien vu du tout parce que personne ne surveillait. Bref, un cas d’école de données manquantes dans GA4 : la donnée était bien là, l’affichage non.

Le vrai problème n’est pas l’incident. Les incidents de reporting GA4, il y en a eu avant et il y en aura d’autres. Le problème, c’est que face à une courbe à zéro, vous devez trancher entre trois hypothèses radicalement différentes : Google a un souci d’affichage, votre collecte est cassée, ou vous avez vraiment perdu du trafic. Chacune appelle une réaction opposée. Cet article vous donne l’arbre de décision qui règle la question en 10 minutes, puis le pipeline de monitoring qui fera le diagnostic à votre place la prochaine fois. Objectif : ne plus jamais confondre un bug d’affichage Google avec une vraie casse de tracking, et le savoir avant votre client.

GA4 données manquantes : le test en 3 minutes

Avant l’arbre complet, le réflexe qui vous fait gagner le plus de temps. Ouvrez GA4 et regardez le rapport Temps réel. S’il affiche des utilisateurs actifs alors que vos rapports standards sont à zéro, vous tenez déjà 80 % de la réponse : la collecte fonctionne, c’est le traitement ou l’affichage côté Google qui coince. Vos données ne sont pas perdues, elles ne sont pas encore affichées.

Si au contraire le Temps réel est vide lui aussi, changez d’état d’esprit tout de suite : le problème est très probablement chez vous, et chaque minute compte parce que vous perdez peut-être de la donnée pour de bon.

Ce simple coup d’oeil oriente tout le reste. Voici comment le rendre fiable.

L’arbre de décision : trois cas, trois verdicts

Trois symptômes, trois sources à croiser, trois verdicts. Le tableau ci-dessous est la version condensée ; les sections suivantes détaillent chaque cas.

La règle de lecture est simple : le Temps réel dit si Google reçoit encore quelque chose maintenant, le DebugView confirme que vos événements sont bien formés, et l’export BigQuery est le seul endroit où vos hits bruts survivent à un incident de reporting. Si les trois sont au vert et que seuls les rapports mentent, vous êtes en Cas A. Dès qu’une de ces sources se tarit, vous basculez en Cas B.

Cas A : incident de reporting Google (ne touchez à rien)

C’est ce qui s’est passé le 1er septembre. Signature typique : Temps réel actif, DebugView qui affiche vos événements quand vous naviguez sur le site, et surtout export BigQuery de la veille présent et complet. Vos hits sont arrivés, ils sont stockés, seuls les rapports d’agrégation ne les affichent pas.

Dans ce cas, la pire décision est de « corriger » quelque chose. Ne republiez pas votre conteneur GTM, ne modifiez pas vos tags, ne repartez pas dans une chasse au bug qui n’existe pas. Vous risqueriez d’introduire une vraie panne pendant un incident qui, lui, va se résorber tout seul. Ce que vous faites à la place : vous annotez la période concernée, vous prévenez les personnes qui liront les rapports (client, direction, équipe SEA) que l’affichage est en retard mais que la donnée est sauve, et vous attendez le retraitement.

Petit point de nuance important : au moment de l’incident du 1er septembre 2026, Google n’avait pas publié de confirmation officielle ni de post-mortem, et n’avait pas garanti de backfill automatique. Le Temps réel restait actif, les rapports standards restaient à zéro, sans cause racine communiquée. Restez donc factuel dans vos communications : « rapports en retard, hits présents dans l’export brut », pas « Google a perdu nos données ».

Cas B : votre collecte est cassée (agissez vite)

Signature inverse : Temps réel vide, DebugView muet même quand vous naviguez avec le mode debug activé, et table events_intraday_ absente ou nettement sous son volume habituel dans BigQuery. Là, ce n’est pas un problème d’affichage, c’est que les hits n’arrivent plus. Et contrairement au Cas A, cette donnée-là est perdue si vous ne réagissez pas.

Par ordre de probabilité, regardez : un déploiement récent du site ou du conteneur (le suspect numéro un, corrélé à l’heure de rupture), un tag GA4 dépublié ou dont l’ID de mesure a changé, un blocage lié au consentement (une CMP mal configurée qui bloque le tag par défaut fait chuter la collecte à zéro sur les régions concernées), ou une balise cassée par une mise à jour. Si vous voulez la liste structurée des causes de configuration, elle est dans l’audit GA4 des 11 erreurs de configuration, et les erreurs côté implémentation sont détaillées dans les 7 erreurs de dataLayer GA4.

Un piège fréquent, à ne pas confondre avec une panne : si vous dépassez la limite d’export gratuite d’un million d’événements par jour vers BigQuery, Google suspend l’export pour la journée. Vous voyez alors un « trou » dans vos tables qui ressemble à une casse, alors que la collecte GA4 tourne parfaitement. Si c’est votre cas, la solution passe par l’export BigQuery direct via sGTM, qui contourne cette limite.

Cas C : c’est une vraie baisse de trafic

Collecte saine (Temps réel actif, export complet) mais volume réellement plus bas : le tracking n’est pas en cause, votre trafic a baissé pour de vrai. Croisez trois sources pour le confirmer et comprendre d’où ça vient : la Search Console pour l’organique, vos logs serveur ou CDN pour le trafic brut toutes sources confondues, et vos plateformes publicitaires pour le payant.

Attention à un sous-cas vicieux : une baisse de conversions sans baisse de trafic. Là, le coupable n’est souvent pas la collecte mais une règle de comptage qui a changé. C’est exactement ce qui s’est joué avec les changements d’attribution GA4 en 2026. De même, si ce sont vos coûts ou vos UTM qui manquent mais pas les sessions, regardez du côté de l’import de données de campagne GA4.

BigQuery, la seule source de vérité qui survit aux incidents

Vous avez remarqué que dans les trois cas, c’est l’export BigQuery qui tranche. Ce n’est pas un hasard. Les rapports GA4 sont une couche d’agrégation et de traitement au-dessus de vos données ; quand cette couche tombe, vos rapports mentent. L’export BigQuery, lui, reçoit vos hits bruts, événement par événement. Tant que la collecte fonctionne, la donnée atterrit dans vos tables même quand les rapports affichent zéro.

Concrètement, deux types de tables cohabitent : les tables events_intraday_YYYYMMDD pour la journée en cours (fraîcheur de quelques minutes à quelques heures) et les tables events_YYYYMMDD figées une fois la journée consolidée. Pendant l’incident du 1er septembre, vérifier la présence et le volume de la table de la veille répondait immédiatement à la question « ai-je perdu de la donnée ? ». Non, elle était là. Si vous n’avez pas encore branché cet export, c’est la première chose à faire, et le guide complet est là : exploiter l’export GA4 dans BigQuery. C’est le socle de tout ce qui suit.

Le pipeline de monitoring : diagnostiquer à votre place

Faire le test à la main une fois, c’est bien. Ne plus jamais avoir à le faire, c’est mieux. L’idée : une requête de contrôle quotidienne sur l’export BigQuery, planifiée, qui compare le volume d’hier à votre normale récente et vous alerte si l’écart dépasse un seuil. Si vous débutez sur ces requêtes, les 10 requêtes BigQuery indispensables posent les bases avant celle-ci.

La requête de contrôle

On compare le volume d’événements et de sessions de la veille à la médiane des 28 jours glissants, par flux de données. La médiane, pas la moyenne : une moyenne se fait déformer par un pic de campagne ou un jour creux, alors que la médiane reste stable et ne déclenche pas de fausse alerte pour un simple week-end.

DECLARE seuil_bas FLOAT64 DEFAULT 0.6;  -- alerte si < 60 % de la normale

WITH quotidien AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS jour,
    stream_id,
    COUNT(*) AS evenements,
    COUNT(DISTINCT CONCAT(
      user_pseudo_id,
      (SELECT value.int_value FROM UNNEST(event_params)
       WHERE key = 'ga_session_id')
    )) AS sessions
  FROM `projet.analytics_XXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 29 DAY))
    AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
  GROUP BY jour, stream_id
),
reference AS (
  SELECT
    stream_id,
    APPROX_QUANTILES(evenements, 2)[OFFSET(1)] AS mediane_evenements
  FROM quotidien
  WHERE jour < DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
  GROUP BY stream_id
)
SELECT
  q.stream_id,
  q.evenements AS evenements_hier,
  r.mediane_evenements,
  ROUND(q.evenements / NULLIF(r.mediane_evenements, 0), 2) AS ratio,
  IF(q.evenements < r.mediane_evenements * seuil_bas, 'ALERTE', 'OK') AS statut
FROM quotidien q
JOIN reference r USING (stream_id)
WHERE q.jour = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY);

Remplacez projet.analytics_XXXXXX par votre dataset et ajustez seuil_bas selon votre tolérance. Un seuil à 0,6 (alerte sous 60 % de la médiane) est un bon point de départ pour un site à volume stable ; descendez à 0,4 si votre trafic est très saisonnier, pour éviter le bruit.

Planifier, seuiller, alerter

Une fois la requête au point, planifiez-la avec une scheduled query BigQuery qui écrit le résultat dans une table de log, une fois par jour après l’heure de fraîcheur de votre export. Trois façons de recevoir l’alerte : brancher un tableau de bord de surveillance qui lit cette table (voir automatiser ses rapports Looker Studio), envoyer un e-mail conditionnel, ou déclencher un webhook (Slack, Teams) via une Cloud Function déclenchée par la scheduled query. Le plus simple qui vous alerte vraiment est le bon.

Côté coût, soyons honnêtes : cette requête scanne surtout des colonnes légères sur 28 jours de tables partitionnées. Sur la plupart des propriétés, on parle de quelques centimes par jour, souvent dans l’enveloppe du palier gratuit BigQuery. Le monitoring qui vous évite une journée de cécité coûte moins cher qu’un café.

Ce que ce pipeline ne détecte pas

Un point de lucidité, parce que promettre l’infaillibilité serait malhonnête. Ce monitoring attrape les variations de volume : un décrochage global, une chute par flux. Il ne voit pas la dérive silencieuse, quand les volumes restent normaux mais que la donnée se dégrade en douce. Trois angles morts à surveiller autrement : un paramètre d’événement qui se met à remonter vide alors que le nombre d’événements est stable, une explosion de la source unassigned (volume identique, attribution cassée), et des valeurs marchandes fausses avec des volumes de transactions corrects. Pour ces cas, il faut des contrôles de qualité ciblés sur les champs, pas seulement sur les compteurs. Mais pour la question qui nous occupe, « ai-je perdu ma collecte ? », ce pipeline répond avant que vous ayez ouvert GA4.

La prochaine cause de décrochage est déjà datée

Un incident Google est imprévisible. Une échéance technique annoncée, non. Le 2 octobre 2026, la méthode gtag('config') cesse de fonctionner dans certains contextes GTM, et une partie des sites qui ne s’y préparent pas verront leur collecte décrocher ce jour-là, sans bug Google pour se dédouaner. Si vous voulez éviter d’ajouter un Cas B évitable à votre calendrier, la marche à suivre est ici : gtag(‘config’) ne fonctionne plus le 2 octobre 2026. Votre pipeline de monitoring le détectera, mais autant ne pas déclencher l’alerte pour rien.

FAQ

GA4 affiche zéro utilisateur, dois-je m’inquiéter ? Regardez le Temps réel d’abord. S’il affiche des utilisateurs actifs, votre collecte fonctionne et le problème est côté affichage Google : pas d’urgence, annotez et attendez. Si le Temps réel est vide lui aussi, là oui, c’est probablement chez vous et il faut agir vite.

Le bug GA4 du 1er septembre 2026 a-t-il fait perdre mes données ? Selon toute vraisemblance, non, à condition que votre collecte tournait. C’était un incident de reporting : le Temps réel restait actif et l’export BigQuery de la période était présent, ce qui indique que les hits sont bien arrivés. Au moment de la rédaction, Google n’avait toutefois pas publié de confirmation officielle ni garanti de backfill automatique des rapports.

Comment être alerté automatiquement la prochaine fois ? Branchez une scheduled query quotidienne sur votre export BigQuery qui compare le volume de la veille à la médiane des 28 derniers jours et déclenche une alerte sous un seuil (par exemple 60 %). C’est le pipeline décrit plus haut : il fait le diagnostic à votre place, avant même que vous ouvriez GA4.

Ce qu’il faut retenir

Face à une courbe GA4 à zéro, ne devinez pas : testez dans l’ordre. Temps réel pour savoir si Google reçoit encore, DebugView pour valider vos événements, export BigQuery pour vérifier que la donnée brute est bien là. Trois sources, trois cas, un verdict en 10 minutes. Puis faites-le une bonne fois : la requête de contrôle quotidienne sur BigQuery transforme ce diagnostic manuel en alerte automatique. La prochaine fois que GA4 affichera zéro, vous saurez en une notification si c’est Google ou vous, et vous le saurez avant que votre client ne vous appelle.