Impact de Consent Mode sur la résolution d'identité

Consent Mode V2 change la forme des données dans l’export BigQuery d’une manière qui affecte directement le stitching d’identité. Le comportement varie selon le mode d’implémentation. Les événements des utilisateurs non consentants en mode Advanced arrivent dans BigQuery sans identifiants et ne peuvent pas être stichés.

Mode Basic vs Advanced dans BigQuery

Le mode Basic de Consent Mode est simple : lorsque analytics_storage est refusé, aucune donnée n’est collectée et rien n’atteint BigQuery. L’utilisateur est complètement invisible. Votre pipeline de stitching ne voit que les événements consentis, et ils ressemblent exactement aux données d’avant Consent Mode.

Le mode Advanced de Consent Mode est là où les choses se compliquent. Lorsque analytics_storage est refusé en mode Advanced, GA4 envoie des “pings sans cookies” à BigQuery — des événements qui existent dans l’export mais ne portent aucune information d’identification :

-- À quoi ressemblent les pings sans cookies dans BigQuery
SELECT
    event_name,
    user_pseudo_id,           -- NULL
    user_id,                  -- NULL
    privacy_info.analytics_storage  -- 'No'
FROM `project.analytics_XXXXX.events_*`
WHERE privacy_info.analytics_storage = 'No'
LIMIT 5

Ces événements ont :

NULL pour user_pseudo_id
Aucun ga_session_id dans event_params
privacy_info.analytics_storage = 'No'

Ils ne peuvent pas être stichés ou sessionisés. Il n’y a aucun identifiant sur lequel effectuer une jointure, aucune session à leur assigner. Ils sont utiles pour la modélisation comportementale de Google dans l’interface GA4, mais pour votre pipeline de warehouse, ce sont des bruits qui doivent être filtrés avant d’atteindre votre couche de stitching.

Auditer la distribution de votre consentement

Avant de supposer que tous vos événements sont stichables, vérifiez comment vos données sont réellement distribuées :

SELECT
    privacy_info.analytics_storage AS consent_status,
    COUNT(*) AS events,
    COUNT(DISTINCT user_pseudo_id) AS unique_devices,
    ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(), 2) AS pct_of_total
FROM `project.analytics_XXXXX.events_*`
WHERE _table_suffix >= FORMAT_DATE('%Y%m%d', CURRENT_DATE() - 30)
GROUP BY privacy_info.analytics_storage
ORDER BY events DESC

Trois valeurs possibles pour analytics_storage :

'Yes' — consenti, identifiants complets présents
'No' — refusé, ping sans cookies (si mode Advanced)
NULL — collecté avant l’implémentation de Consent Mode ; traitez comme consenti

Un site avec Consent Mode Advanced et 40 % de refus de consentement en France montrera environ 40 % des événements avec analytics_storage = 'No'. Ces événements contribueront à votre nombre total d’événements mais ne pourront pas participer au stitching d’identité.

Le filtre pour un stitching propre

Pour votre pipeline de stitching d’identité, filtrez les événements consentis le plus tôt possible dans le modèle :

WHERE privacy_info.analytics_storage = 'Yes'
   OR privacy_info.analytics_storage IS NULL  -- Données historiques pré-Consent Mode

Ce filtre appartient à votre modèle de base des événements GA4, pas à votre logique de stitching. Laisser les événements non consentis circuler dans la table de correspondance d’identité puis filtrer à ce niveau est plus coûteux et plus sujet aux erreurs que de les supprimer à la source.

La conséquence pratique : vos comptages d’utilisateurs BigQuery seront inférieurs aux chiffres de l’interface GA4. L’interface GA4 applique une modélisation comportementale pour estimer ce que les utilisateurs ayant refusé le consentement ont fait ; ces données modélisées n’atteignent jamais BigQuery. N’essayez pas de réconcilier l’écart — il est architectural. Consultez GA4 BigQuery Number Discrepancies pour savoir comment présenter cela aux parties prenantes.

La nuance du backstitch sur la même page

Il existe un cas limite à connaître, même s’il cause rarement des problèmes en pratique.

Si un utilisateur refuse le consentement au chargement de la page puis l’accorde sur cette même page (en cliquant sur “Accepter” après le refus initial), GA4 applique rétroactivement l’identifiant Client aux hits précédemment refusés de cette page. Ces événements passent de pings sans cookies à des événements identifiés dans les tables quotidiennes.

Ce backstitch sur la même page ne fonctionne pas entre les chargements de page. Une fois qu’un utilisateur navigue avec un consentement refusé, ces événements restent définitivement anonymes. La correction rétroactive ne s’applique qu’à l’intérieur d’une seule vue de page.

En pratique, cela signifie que vos tables intraday peuvent montrer des incohérences qui se résolvent dans les tables quotidiennes. Si vous effectuez une analyse en temps réel ou intraday sur le stitching, vous pourriez voir des événements qui semblent anonymes dans les données intraday devenir identifiés dans les données quotidiennes plus tard dans la journée. Pour les pipelines par lots s’exécutant sur des tables quotidiennes avec une fenêtre de traitement rétrospectif de 3 jours, cela est géré automatiquement par la fenêtre de retraitement.

Implications pour la confidentialité du filtrage

Filtrer les événements où analytics_storage = 'No' de votre pipeline de stitching n’est pas seulement techniquement correct — c’est légalement requis dans la plupart des juridictions. Un utilisateur qui a refusé le consentement aux cookies analytics n’a pas consenti à ce que son comportement de navigation soit lié à son identité. Tenter de sticher des événements non consentis (par exemple, en utilisant des patterns comportementaux pour les associer probabilistiquement à des utilisateurs connus) constitue une violation du consentement.

L’architecture de consentement doit rendre ce filtre structurel, pas optionnel. Les événements non consentis doivent bifurquer vers un chemin d’agrégats anonymes distinct avant de jamais toucher la couche d’identité :

base__ga4__events
  ├── événements consentis → int__ga4__events_stitched → marts liés à l'identité
  └── événements non consentis → int__ga4__anonymous_aggregates → marts agrégats uniquement

Cela rend la frontière de consentement visible dans votre DAG dbt et empêche de futurs développeurs de router accidentellement des événements non consentis vers la résolution d’identité.