Le piège des données fournies par l'utilisateur GA4 dans BigQuery

Il existe un paramètre dans l’administration GA4 qui, une fois activé, supprime définitivement user_id de tous les exports BigQuery. Il ne peut pas être annulé. Si vos pipelines de données, modèles dbt, modèles d’attribution ou plateformes de données client dépendent de la présence de user_id dans l’export BigQuery brut, ce paramètre les brise silencieusement sans signal d’erreur immédiat.

Le paramètre s’appelle « Données fournies par l’utilisateur » et se trouve dans Administration GA4 → Collecte et modification de données → Collecter les données fournies par l’utilisateur.

Ce que la fonctionnalité fait

La collecte de données fournies par l’utilisateur permet à GA4 de hacher et d’utiliser les IIP que les utilisateurs fournissent activement — adresses email, numéros de téléphone, noms — pour les Conversions Améliorées et la correspondance d’audience. C’est une fonctionnalité légitime pour améliorer l’attribution des conversions. Le flux UX est que GA4 collecte ces données sous forme hachée pour les faire correspondre au graphe d’identité de Google.

Le problème est un effet secondaire permanent et peu documenté : lorsque cette fonctionnalité est activée, GA4 cesse d’exporter le champ user_id vers BigQuery. Le champ apparaît toujours dans le schéma ; il ne contient simplement plus de valeurs.

Pourquoi c’est irréversible

La raison invoquée par Google est la confidentialité : une fois qu’une propriété est configurée pour collecter des données fournies par l’utilisateur (même des IIP hachées), la politique de Google interdit l’export d’un champ user_id qui pourrait potentiellement être utilisé pour ré-identifier des utilisateurs. Désactiver la fonctionnalité ne restaure pas l’export de user_id parce que la politique s’applique à la configuration de la propriété sur sa durée de vie, pas seulement à son état actuel.

Il n’y a pas de solution de contournement. Il n’y a pas de chemin d’escalade vers Google Support qui restaure cette capacité. Le paramètre, une fois activé, est permanent.

Ce que vous perdez

Le champ user_id dans l’export BigQuery de GA4 est la façon dont vous reliez les données comportementales de GA4 à vos propres systèmes d’identité. C’est le pont entre :

• user_pseudo_id anonyme (cookie de l’appareil) et l’identifiant client de votre CRM
• La rétrocouture des sessions pré-connexion vers les utilisateurs connus
• La construction de modèles Customer 360 qui combinent les données de parcours GA4 avec l’historique d’achats
• Les modèles d’attribution qui ont besoin de lier les conversions à des clients spécifiques

Sans user_id dans l’export BigQuery, la rétrocouture utilisateur devient impossible pour les nouvelles données. Les données historiques conservent leurs valeurs user_id (le champ devient vide à partir du moment où la fonctionnalité est activée), mais la jointure de rétrocouture nécessite des événements où l’utilisateur s’est authentifié — et ces nouveaux événements d’authentification ne porteront plus user_id.

Les sessions peuvent toujours être identifiées avec la clé composite user_pseudo_id + ga_session_id, mais vous perdez la capacité de connecter ces sessions au système d’identité utilisateur de votre application via le champ GA4 standard.

Comment se protéger

Auditez votre état actuel. Vérifiez immédiatement si cette fonctionnalité est activée dans votre propriété :

-- Vérifier que user_id se renseigne toujours
SELECT
  COUNT(*) AS total_events,
  COUNTIF(user_id IS NOT NULL) AS events_with_user_id,
  COUNTIF(user_id IS NOT NULL) / COUNT(*) AS user_id_fill_rate
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN
  FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
  AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))

Votre user_id_fill_rate devrait être supérieur à 0 pour les événements où des utilisateurs connectés étaient actifs. S’il tombe soudainement à 0, la fonctionnalité a peut-être été activée.

Ajoutez ceci à votre monitoring de qualité des données. Une vérification quotidienne du taux de renseignement de user_id pour les événements authentifiés (filtrés par des noms d’événements d’authentification connus) détecte ce problème dès le premier jour plutôt que des semaines plus tard, lorsque quelqu’un remarque que les modèles d’attribution sont brisés.

Établissez une gouvernance autour de ce paramètre d’administration GA4. Toute personne ayant un accès Éditeur à une propriété GA4 peut activer cette fonctionnalité. La pratique recommandée est de documenter l’impact BigQuery et d’exiger la validation de l’équipe data engineering avant l’activation.

Envisagez une alternative. Si votre équipe souhaite des Conversions Améliorées, il est possible de les implémenter côté serveur via l’API Conversions ou le Measurement Protocol sans activer le paramètre de collecte « Données fournies par l’utilisateur » dans l’administration GA4. Un spécialiste Google Ads ou Google Tag Manager peut conseiller sur le chemin d’implémentation qui évite l’effet secondaire BigQuery.

La requête de monitoring

Ajoutez ceci à votre suite de tests de qualité des données, idéalement comme un test dbt avec alerting :

-- Vérifier dans votre fraîcheur de source dbt ou votre configuration de test
-- Alerter si le taux de renseignement de user_id pour les événements de connexion tombe sous le seuil
SELECT
  event_date,
  COUNTIF(user_id IS NOT NULL) AS with_user_id,
  COUNT(*) AS total,
  COUNTIF(user_id IS NOT NULL) / COUNT(*) AS fill_rate
FROM `project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY))
  AND event_name = 'login'  -- ou le nom de votre événement d'authentification
GROUP BY event_date
ORDER BY event_date DESC

Un taux de renseignement de 0 sur des événements qui devraient toujours avoir un utilisateur authentifié est le signal le plus clair qu’un changement a eu lieu dans la configuration de la propriété.