Événements orphelins du Consent Mode GA4

Lorsque les utilisateurs refusent le consentement analytics_storage sous le Consent Mode avancé de Google, GA4 continue de collecter des événements sous forme de « pings sans cookie ». Ces événements apparaissent dans votre export BigQuery mais avec deux champs critiques supprimés : user_pseudo_id est null et ga_session_id (dans event_params) est null.

Le résultat est des événements sans identité et sans association de session — des lignes orphelines qui ne peuvent pas être attribuées à des utilisateurs ni regroupées en sessions.

À quoi ressemblent les événements orphelins

Une ligne standard d’événement GA4 contient :

• user_pseudo_id : un identifiant de device tel que 1234567.8901234
• ga_session_id dans event_params.int_value : un timestamp Unix tel que 1706400000

Un ping cookieless orphelin contient :

• user_pseudo_id : NULL
• ga_session_id dans event_params : la clé n’existe pas ou retourne null

Ces lignes existent dans votre export. Elles gonflent votre comptage brut d’événements tout en étant inutiles pour toute analyse au niveau utilisateur ou session. Si vos requêtes de comptage d’événements ne les filtrent pas, vous sur-comptez les événements par rapport à votre analyse attribuée.

Le RECORD privacy_info vous indique l’état de consentement de chaque ligne :

privacy_info.analytics_storage  -- 'Yes', 'No' ou 'Unset'
privacy_info.uses_transient_token  -- TRUE si mesure cookieless utilisée

Filtrez ou segmentez sur ces champs pour séparer les événements consentis des événements non consentis :

-- Compter uniquement les événements consentis
SELECT COUNT(*) AS consented_events
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX = '20260127'
  AND privacy_info.analytics_storage = 'Yes'

-- Compter tous les événements incluant les pings orphelins
SELECT COUNT(*) AS total_events
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX = '20260127'

La différence entre ces deux chiffres est le volume de trafic à consentement refusé en événements bruts.

Impact sur les modèles de session

Les événements orphelins sont la principale raison pour laquelle le filtrage des clés de session nulles doit être placé dans la couche de modèle la plus précoce possible. Un ga_session_id null rend la construction de la clé de session nulle ou malformée, ce qui casse ensuite toutes les fonctions fenêtre qui partitionnent par clé de session.

Le filtre standard dans votre modèle de base :

WHERE (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') IS NOT NULL
  AND user_pseudo_id IS NOT NULL

Cela exclut entièrement les événements de consentement orphelins de vos modèles sessionisés. Ils ne sont pas récupérables — il n’y a aucun identifiant pour les regrouper — et les inclure corrompt les calculs au niveau session.

Backstitching sur la même page

GA4 implémente un comportement spécifique lorsqu’un utilisateur refuse le consentement puis l’accorde ultérieurement au cours de la même session de page : le système « recoud » le consentement aux hits précédemment refusés sur cette page.

Vous observerez cela comme user_pseudo_id qui devient renseigné sur des événements qui, dans un état de traitement antérieur, avaient des identifiants nuls. C’est un signal positif — plus d’événements deviennent attribuables — mais cela crée une considération temporelle pour le pipeline.

Si vous exécutez des modèles incrémentaux avec une courte fenêtre de lookback, le backstitching du jour même peut signifier que l’exécution du traitement d’aujourd’hui voit des données différentes de l’exécution du traitement de demain pour les mêmes événements. Un lookback d’un jour est insuffisant ; GA4 recommande la fenêtre de données tardives de 72 heures, et pour les données liées au consentement, c’est l’une des raisons les plus fortes de respecter cette fenêtre.

Configurez votre modèle incrémental en conséquence :

{{ config(
    materialized='incremental',
    incremental_strategy='insert_overwrite',
    partition_by={'field': 'event_date', 'data_type': 'date'}
) }}

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

Un lookback de 7 jours couvre les données tardives de toute source, y compris le backstitching de consentement.

Pourquoi vos chiffres BigQuery sont inférieurs à l’interface GA4

C’est l’une des causes principales de l’écart systématique entre les chiffres BigQuery et l’interface GA4, notamment pour les propriétés européennes avec des bannières de consentement strictes.

L’interface GA4 inclut des données modélisées provenant du Consent Mode. Lorsque les utilisateurs refusent le consentement, GA4 utilise le machine learning pour estimer leur comportement probable en se basant sur les patterns des utilisateurs consentants. Ces conversions et sessions modélisées apparaissent dans les rapports de l’interface.

Ces données modélisées n’apparaissent jamais dans BigQuery. Votre export BigQuery contient uniquement les événements observés des utilisateurs consentants (plus les pings orphelins des utilisateurs refusant, que vous filtrez).

L’écart est proportionnel à votre taux de refus de consentement. Un site e-commerce européen avec une gestion agressive du consentement peut voir 35 % de refus de consentement. L’interface GA4 rapporte 35 % de sessions modélisées de plus que BigQuery ne peut en comptabiliser. Ce n’est une erreur dans aucun des systèmes — c’est le comportement prévu.

Il n’existe aucun moyen de reconstruire le modèle comportemental de GA4 à partir des données BigQuery. Documentez cette attente pour les parties prenantes : « BigQuery rapporte uniquement le trafic consenti. L’interface GA4 inclut des estimations modélisées pour les utilisateurs non-consentants. La différence reflète votre taux de refus de consentement, pas un problème de qualité des données. »

La différence entre Consent Mode basique et avancé

Le comportement des événements orphelins ne se produit que sous le Consent Mode avancé. Sous le Consent Mode basique, GA4 ne déclenche aucun événement lorsque le consentement est refusé — les tags ne se déclenchent pas du tout jusqu’à ce que le consentement soit accordé.

Avec le mode basique, votre export BigQuery est plus propre : pas de lignes orphelines, pas d’identifiants nuls. La contrepartie est que vous perdez entièrement le signal sur le volume de trafic à consentement refusé. Le mode avancé vous donne les lignes orphelines (qui sont analytiquement inutiles pour la sessionisation mais vous indiquent que le consentement a été refusé), plus la capacité pour GA4 de modéliser ce trafic dans l’interface.

La plupart des implémentations modernes utilisent le mode avancé, ce qui signifie que la plupart des exports GA4 BigQuery contiennent des événements orphelins. Le filtre null dans la couche du modèle de base est une pratique standard, pas un cas limite.