Techniques de réconciliation d'identité GA4

L’export BigQuery de GA4 livre des données brutes au niveau événement : user_pseudo_id (le cookie de l’appareil) et user_id (votre identifiant métier, lorsque vous l’avez configuré). Lorsqu’un utilisateur navigue anonymement puis se connecte sur un autre appareil quelques jours plus tard, GA4 les traite comme des personnes distinctes. Construire votre propre couche de réconciliation dans BigQuery est le seul moyen de retrouver la vue connectée.

La technique appropriée dépend du besoin de résolution rétroactive dans le temps, de la tolérance aux faux positifs, et de l’analyse en aval qui consommera les données réconciliées.

Les quatre techniques

Attribution au dernier contact (approche par fonction de fenêtrage)

Le dernier contact attribue le user_id connu le plus récent à tous les événements historiques du même user_pseudo_id. Cela gère le flux typique : navigation anonyme suivie d’un événement de connexion.

WITH events_with_last_touch AS (
    SELECT
        event_date,
        user_pseudo_id,
        user_id,
        event_name,
        event_timestamp,
        LAST_VALUE(user_id IGNORE NULLS) OVER (
            PARTITION BY user_pseudo_id
            ORDER BY event_timestamp
            ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        ) AS stitched_user_id
    FROM `project.analytics_XXXXX.events_*`
    WHERE _table_suffix BETWEEN '20250101' AND '20250131'
)

SELECT
    event_date,
    user_pseudo_id,
    COALESCE(stitched_user_id, user_pseudo_id) AS resolved_user_id,
    event_name,
    TIMESTAMP_MICROS(event_timestamp) AS event_time
FROM events_with_last_touch

La clause IGNORE NULLS est essentielle. Sans elle, LAST_VALUE retourne la valeur de la ligne courante — null chaque fois que user_id est absent. Le cadre de fenêtrage ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW garantit qu’on regarde tous les événements précédents dans la partition.

La limite critique : cela ne réconcilie que les événements avant le moment d’identification, dans la plage de dates interrogée. Si un utilisateur s’est authentifié en décembre et que vous interrogez janvier, ses événements anonymes de janvier ne seront pas réconciliés, à moins que les données de décembre ne soient dans la même requête. Pour une véritable rétrocouture inter-sessions, vous avez besoin de l’approche par table de correspondance.

Rétrocouture complète via table de correspondance

Pour une résolution d’identité complète — appliquer un user_id à tous les événements d’un appareil, quelle que soit la date d’authentification — construisez d’abord une table de correspondance, puis joignez-la aux événements. C’est ce que la rétrocouture utilisateur GA4 couvre en profondeur.

Le pattern :

1. Extraire toutes les paires (user_pseudo_id, user_id) observées dans vos données où user_id IS NOT NULL
2. Résoudre les conflits (plusieurs valeurs user_id par appareil) avec une règle de décision cohérente
3. Rejoindre la correspondance résolue à votre table d’événements complète

Le résultat : chaque événement d’un appareil qui s’est un jour authentifié porte le user_id résolu, qu’il se soit produit avant ou après la connexion. Les sessions passées, présentes et futures sont toutes connectées.

Attribution au premier contact

Le premier contact utilise FIRST_VALUE au lieu de LAST_VALUE, attribuant le premier user_id connu à tous les événements. Le cadre de fenêtrage doit couvrir toute la partition :

FIRST_VALUE(user_id IGNORE NULLS) OVER (
    PARTITION BY user_pseudo_id
    ORDER BY event_timestamp
    ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
) AS first_known_user_id

Utilisez le premier contact pour l’analyse d’acquisition : attribuer un utilisateur à son identité authentifiée d’origine, pas à un changement de compte ultérieur. Si quelqu’un change son email (et donc son user_id) six mois plus tard, le premier contact lie tous ses événements à l’identité originale, ce qui est généralement plus utile pour l’analyse de cohortes.

Le dernier contact est préférable lorsque l’identité actuelle compte — personnalisation, contexte de dossier de support, statut de compte actuel.

Réconciliation dans la portée de session

La réconciliation dans la portée de session limite la résolution d’identité aux événements de la même session. C’est l’approche la plus conservatrice et un bon point de départ pour valider votre logique avant de vous engager dans une rétrocouture complète.

WITH session_events AS (
    SELECT
        *,
        (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS ga_session_id
    FROM `project.analytics_XXXXX.events_*`
),

stitched AS (
    SELECT
        *,
        FIRST_VALUE(user_id IGNORE NULLS) OVER (
            PARTITION BY user_pseudo_id, ga_session_id
            ORDER BY event_timestamp
            ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
        ) AS session_user_id
    FROM session_events
)

SELECT
    *,
    COALESCE(session_user_id, user_pseudo_id) AS resolved_user_id,
    CONCAT(
        COALESCE(session_user_id, user_pseudo_id),
        '_',
        CAST(ga_session_id AS STRING)
    ) AS unique_session_id
FROM stitched

Cela gère le cas où un utilisateur se connecte en cours de session — l’événement de connexion fournit le user_id, et il est appliqué à tous les événements de cette session, y compris ceux qui sont intervenus avant. Notez la construction de unique_session_id : ga_session_id seul n’est pas globalement unique (c’est un timestamp Unix), il doit donc toujours être combiné avec l’identifiant utilisateur. Voir Construction de la clé de session GA4 pour comprendre pourquoi cela est important.

Choisir la bonne technique

Commencez par la réconciliation dans la portée de session pour valider votre SQL et vérifier les problèmes d’appareils partagés. Une fois la qualité des données confirmée, passez à la rétrocouture complète pour la production.

L’évaluation du risque reflète le risque d’intégrité des données, pas la complexité d’implémentation. La rétrocouture complète est « plus risquée » non pas parce qu’elle est plus difficile à écrire, mais parce qu’une table de correspondance incorrecte (due à des bugs de déconnexion, des appareils partagés ou des valeurs user_id erronées) corrompt silencieusement chaque modèle en aval qui utilise l’identité réconciliée. Les vérifications de qualité des données user_id appartiennent à l’étape avant la construction de la table de correspondance, pas après.

Le pattern de fallback COALESCE

Les quatre techniques partagent une étape de finalisation commune : lorsque la réconciliation échoue (aucun user_id n’a jamais été observé pour un appareil), revenir à user_pseudo_id comme identité :

COALESCE(resolved_user_id, user_pseudo_id) AS final_user_id

Cela garantit que chaque événement a une identité non nulle. Les utilisateurs anonymes restent des identités distinctes — suivis par leur ID d’appareil plutôt qu’un ID métier — au lieu d’être regroupés dans un seul groupe null. Ne forcez pas la correspondance probabiliste pour combler ce vide ; les faux positifs du fingerprinting avec les données disponibles de GA4 (catégorie d’appareil, navigateur, pays) sont pires qu’accepter un taux d’identification plus faible. Voir Limites de la correspondance probabiliste dans GA4 pour expliquer pourquoi.

Où la réconciliation se situe dans le DAG dbt

Les quatre techniques produisent une colonne resolved_user_id qui remplace le user_id brut dans les modèles en aval. Dans un pipeline dbt en production, la couche de réconciliation se situe entre votre modèle d’événements GA4 de base et vos marts de session/attribution :

base__ga4__events
    ↓
int__ga4__identity_mapping   (la table de correspondance — construire en premier)
    ↓
int__ga4__events_stitched    (appliquer la correspondance aux événements)
    ↓
int__ga4__sessions
mrt__analytics__user_journey

Le modèle de correspondance d’identité utilise la stratégie incrémentielle merge (petite table, mises à jour fréquentes). Le modèle d’événements réconciliés utilise insert_overwrite par partition de date (grande table, retraitement des dates récentes).