Qualité des données user_id GA4

Les résultats de la réconciliation d’identité dépendent de la qualité des valeurs user_id que l’implémentation envoie. Les mauvaises données user_id ne génèrent pas d’erreurs — elles corrompent silencieusement chaque modèle en aval qui leur fait confiance. Validez les données user_id avant de construire une table de correspondance ou un pipeline de rétrocouture.

Le bug du string ‘null’

L’erreur d’implémentation la plus courante : les développeurs définissent user_id avec la chaîne 'null', 'none', 'undefined', '-' ou 'anonymous' lorsqu’un utilisateur se déconnecte, au lieu de le définir à null réel.

Ce que cela ressemble dans votre code de tracking :

// Buggy : envoie la chaîne "null" au lieu de vider user_id
gtag('config', 'G-XXXXXXX', {
  'user_id': user.isLoggedIn ? user.id : 'null'
});

// Correct : passer null (ou omettre le champ entièrement)
gtag('config', 'G-XXXXXXX', {
  'user_id': user.isLoggedIn ? user.id : null
});

Lorsque ce bug existe, GA4 traite chaque session déconnectée comme appartenant à un seul utilisateur nommé 'null'. Ce faux utilisateur accumule des milliers de correspondances user_pseudo_id, et votre pipeline de réconciliation les fusionne allègrement en une seule identité. Votre taux de réconciliation semble impressionnant ; vos données sont inutilisables.

Détection :

SELECT
    user_id,
    COUNT(*) AS events,
    COUNT(DISTINCT user_pseudo_id) AS devices
FROM `project.analytics_XXXXX.events_*`
WHERE user_id IS NOT NULL
GROUP BY user_id
HAVING COUNT(DISTINCT user_pseudo_id) > 1000  -- Nombre d'appareils suspicieusement élevé
ORDER BY devices DESC
LIMIT 20

Tout user_id correspondant à plus de quelques centaines d’appareils est suspect. Les utilisateurs avancés légitimes peuvent avoir 3 à 5 appareils. Un user_id avec 50 000 correspondances user_pseudo_id est presque certainement un bug.

Une fois confirmé, travaillez avec l’équipe d’implémentation pour corriger le tagging. En attendant, filtrez ces valeurs de votre pipeline d’identité :

WHERE user_id IS NOT NULL
  AND user_id NOT IN ('null', 'undefined', 'none', '-', 'anonymous', 'guest', '')
  AND LENGTH(user_id) > 3  -- Filtrer les valeurs manifestement incorrectes à un seul caractère

Le filtre LENGTH est un outil grossier — les vrais ID d’utilisateurs sont presque toujours plus longs que 3 caractères. Ajustez le seuil selon le format réel de vos ID.

IIP dans user_id

Le champ user_id ne doit jamais contenir d’adresses email, de noms ou d’autres informations personnellement identifiables directement. La documentation de GA4 est claire là-dessus, et c’est une préoccupation RGPD : les valeurs user_id sont enregistrées dans les serveurs de GA4 et exportées vers BigQuery, et les adresses email en texte clair créent une exposition de conformité.

La correction est le hachage avant l’envoi :

// N'envoyez pas l'email directement
gtag('config', 'G-XXXXXXX', {
  'user_id': 'jane@example.com'  // Ne faites jamais ça
});

// Envoyez plutôt un ID de base de données opaque
gtag('config', 'G-XXXXXXX', {
  'user_id': 'user_12345'  // ID de base de données opaque — correct
});

// Ou un hash SHA-256 si vous devez dériver de l'email
gtag('config', 'G-XXXXXXX', {
  'user_id': sha256('jane@example.com')  // Pseudonymisé
});

Si vous trouvez des adresses email dans vos données user_id existantes, consultez votre équipe juridique avant de construire une logique de réconciliation par-dessus. Le graphe d’identité que vous construiriez constituerait un profilage comportemental d’individus identifiés, ce qui nécessite une base de consentement explicite sous le RGPD. Voir Contraintes de confidentialité pour les données analytiques liées pour les implications de conformité.

ID recyclés et temporaires

Les systèmes de checkout invité génèrent souvent des ID de session temporaires qui sont assignés comme user_id et ensuite abandonnés. Si ces ID sont réutilisés pour différentes personnes réelles — comme certains systèmes le font — votre table de correspondance confond des utilisateurs non liés.

Détection : cherchez des valeurs user_id qui apparaissent dans des fenêtres très courtes avec de nombreuses valeurs user_pseudo_id différentes mais peu d’événements totaux par paire :

WITH user_stats AS (
    SELECT
        user_id,
        COUNT(DISTINCT user_pseudo_id) AS device_count,
        COUNT(*) AS total_events,
        TIMESTAMP_DIFF(
            MAX(TIMESTAMP_MICROS(event_timestamp)),
            MIN(TIMESTAMP_MICROS(event_timestamp)),
            DAY
        ) AS days_active
    FROM `project.analytics_XXXXX.events_*`
    WHERE user_id IS NOT NULL
    GROUP BY user_id
)

SELECT *
FROM user_stats
WHERE device_count > 10
  AND days_active < 7  -- Nombreux appareils, fenêtre très courte
ORDER BY device_count DESC

Un utilisateur légitime peut avoir plusieurs appareils. Un ID temporaire assigné à de nombreux utilisateurs non liés affichera de nombreux appareils dans une courte fenêtre avec peu de profondeur d’événements par appareil.

Comptes employés et de test

Les équipes commerciales qui font des démonstrations du produit, les ingénieurs QA qui exécutent des scénarios de test, et l’utilisation quotidienne des employés génèrent tous des événements user_id qui polluent vos analytics. Ils gonflent les comptages de sessions, faussent les taux de conversion des entonnoirs, et peuvent créer des correspondances user_id bizarres si les utilisateurs de test utilisent le même appareil de manière répétée.

Approches courantes :

• Filtrer les valeurs user_id d’employés connues dans votre modèle de base (nécessite de maintenir une liste)
• Exclure les plages IP internes connues (GA4 n’exporte pas les IP, donc cela doit se faire au moment de la collecte via des filtres de tags dans GTM)
• Ajouter un déclencheur de tag séparé qui définit une dimension personnalisée is_internal: true pour le trafic interne identifié, puis filtrer sur user_properties dans BigQuery

Le filtrage doit se faire dans vos données, pas seulement dans votre logique de réconciliation — sinon les sessions des employés contribuent toujours aux comptages de trafic anonyme et aux tables de sessions.

Valider avant de construire

Avant de construire un graphe d’identité en production, exécutez ces vérifications :

1. Audit des null sous forme de chaîne : Des valeurs de chaîne suspectes apparaissent-elles dans user_id ?
2. Vérification de cardinalité : Des valeurs user_id correspondent-elles à un nombre d’appareils implausiblement élevé ?
3. Scan d’IIP : Des valeurs user_id ressemblent-elles à des adresses email ou des noms ?
4. Vérification d’ID recyclés : Certains ID sont-ils de courte durée avec un fort renouvellement d’appareils ?
5. Sanité du volume : Quel pourcentage d’événements a un user_id non null ? S’il est inattendument faible, l’implémentation peut ne pas se déclencher de manière cohérente.

-- Résumé rapide de la santé de user_id
SELECT
    COUNTIF(user_id IS NOT NULL) AS events_with_user_id,
    COUNT(*) AS total_events,
    ROUND(COUNTIF(user_id IS NOT NULL) * 100.0 / COUNT(*), 2) AS pct_identified,
    COUNT(DISTINCT user_id) AS distinct_user_ids,
    COUNT(DISTINCT user_pseudo_id) AS distinct_devices,
    COUNTIF(user_id IN ('null', 'undefined', 'none', '', '-')) AS garbage_user_ids
FROM `project.analytics_XXXXX.events_*`
WHERE _table_suffix >= FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))

Cela donne un résumé en une ligne. pct_identified indique votre taux de réconciliation théorique maximum. Le comptage garbage_user_ids indique combien est fictif.

La qualité de user_id peut se dégrader silencieusement — une mise à jour de framework, une nouvelle page ou une modification du comportement de déconnexion par un développeur peut introduire le bug du null sous forme de chaîne. Exécuter ces vérifications avant les principales constructions de pipeline de réconciliation et après des changements d’implémentation significatifs détecte les régressions tôt.