Monitoring de la résolution d'identité

Les bugs de résolution d’identité ne produisent aucune erreur de pipeline. Une modification du tracking qui introduit le bug de la chaîne 'null' entraîne une dégradation ou une hausse soudaine du taux de stitching sans aucune alerte système. Le monitoring couvre deux couches : les métriques de santé quotidiennes qui établissent l’état de fonctionnement normal, et la détection d’anomalies qui fait remonter les changements semaine après semaine.

Métriques de santé quotidiennes

Construire une requête de dashboard qui suit ces quatre métriques quotidiennement :

WITH daily_stats AS (
    SELECT
        event_date,
        COUNT(*) AS total_events,
        COUNTIF(is_identified) AS identified_events,
        COUNTIF(is_shared_device) AS shared_device_events,
        COUNT(DISTINCT resolved_user_id) AS unique_users,
        COUNT(DISTINCT user_pseudo_id) AS unique_devices,
        COUNT(DISTINCT session_id) AS unique_sessions
    FROM {{ ref('int__ga4__events_stitched') }}
    WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
    GROUP BY event_date
)

SELECT
    event_date,
    total_events,
    unique_users,
    unique_devices,
    unique_sessions,

    -- Taux de stitching : % d'événements avec une identité résolue
    ROUND(identified_events * 100.0 / total_events, 2) AS stitch_rate_pct,

    -- Taux de consolidation : dans quelle mesure le stitching réduit le nombre apparent d'utilisateurs
    ROUND((unique_devices - unique_users) * 100.0 / unique_devices, 2) AS consolidation_rate_pct,

    -- Exposition aux appareils partagés : événements qui peuvent avoir une identité mal attribuée
    ROUND(shared_device_events * 100.0 / total_events, 2) AS shared_device_pct

FROM daily_stats
ORDER BY event_date DESC

Le taux de stitching mesure quel pourcentage d’événements portent un user_id résolu. Votre baseline dépend de la proportion de votre trafic qui est authentifié. Pour un produit SaaS où la plupart des sessions nécessitent une connexion, attendez-vous à 60-80 %. Pour un site de contenu avec authentification optionnelle, attendez-vous à 10-30 %. Ce qui importe, c’est la cohérence — une chute soudaine signale que l’implémentation du user_id s’est cassée quelque part ; un pic soudain signale le bug de null en chaîne.

Le taux de consolidation indique dans quelle mesure le stitching réduit le compte brut d’appareils. Si vous avez 10 000 appareils uniques et 8 000 utilisateurs résolus uniques, vous avez consolidé 20 % des appareils en utilisateurs connus. Cette métrique devrait croître lentement à mesure que davantage d’appareils s’authentifient. Un changement soudain et important indique soit un problème de qualité des données, soit un changement significatif dans le comportement des utilisateurs.

Le pourcentage d’appareils partagés indique quelle proportion de vos données porte le risque de mauvaise attribution. Pour la plupart des sites grand public, c’est faible (sous 2 %). Pour les outils B2B utilisés dans des environnements partagés ou les applications retail, cela peut être plus élevé.

Détection d’anomalies

Configurer des alertes pour les variations semaine sur semaine qui dépassent votre seuil de tolérance :

-- Alerte : le taux de stitching a chuté de plus de 10 % par rapport à la semaine précédente
WITH weekly AS (
    SELECT
        DATE_TRUNC(event_date, WEEK) AS week,
        COUNTIF(is_identified) * 100.0 / COUNT(*) AS stitch_rate
    FROM {{ ref('int__ga4__events_stitched') }}
    WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 8 WEEK)
    GROUP BY 1
)

SELECT
    week,
    stitch_rate,
    LAG(stitch_rate) OVER (ORDER BY week) AS prev_week_rate,
    stitch_rate - LAG(stitch_rate) OVER (ORDER BY week) AS week_over_week_change
FROM weekly
ORDER BY week DESC

Exécuter ceci comme un test dbt avec la sévérité warn lorsque le changement absolu dépasse 5 points et error lorsqu’il dépasse 10 points. Une chute de 10 points du taux de stitching en une semaine est presque toujours un problème d’implémentation.

Contrôles de qualité des données sur le mapping d’identité

Deux vérifications détectent les problèmes dans la table de mapping avant qu’ils ne se propagent :

-- Vérification 1 : Appareils avec un nombre implausiblement élevé de user_id
SELECT
    'Trop de user_ids par appareil' AS issue,
    COUNT(*) AS affected_devices
FROM {{ ref('int__ga4__identity_mapping') }}
WHERE user_id_count > 50

UNION ALL

-- Vérification 2 : user_ids à haute cardinalité suspecte dans les données sources
SELECT
    'user_id anormalement fréquent' AS issue,
    COUNT(DISTINCT user_pseudo_id) AS affected_devices
FROM {{ source('ga4', 'events') }}
WHERE user_id IN (
    SELECT user_id
    FROM {{ source('ga4', 'events') }}
    WHERE user_id IS NOT NULL
    GROUP BY user_id
    HAVING COUNT(DISTINCT user_pseudo_id) > 500
)

La première vérification se déclenche lorsque le test de schéma dbt sur user_id_count ne le détecte pas (le test utilise un accepted_range de 100 ; cette vérification cherche le pattern à un seuil plus bas pour détecter l’accumulation progressive). La deuxième vérification scanne les données sources pour le pattern de null en chaîne avant qu’il n’entre dans le pipeline.

Ce que les métriques révèlent

Le taux de stitching chute brutalement → le user_id a arrêté d’être envoyé sur les pages de connexion. Vérifier s’il y a eu un déploiement récent qui a cassé le push gtag ou dataLayer. Vérifier également si un nouveau flux d’authentification ne comporte pas l’appel user_id.

Le taux de stitching monte brutalement → le bug de null en chaîne est apparu. Quelqu’un envoie maintenant 'null' ou une autre valeur aberrante. Requêter les valeurs user_id avec des comptages d’appareils implausiblement élevés.

Le taux de consolidation baisse → davantage d’appareils s’associent à des utilisateurs uniques plutôt que de se consolider. Cela peut être dû à de nouveaux appareils provenant d’une base d’utilisateurs en expansion (bon signe) ou à des problèmes de réinitialisation de cookies réduisant les appareils reconnus (mauvais signe). Vérifier votre requête de taux de fragmentation en parallèle.

Le pourcentage d’appareils partagés monte en flèche → davantage d’appareils s’associent à plusieurs valeurs user_id. Cela peut être dû à une raison métier légitime (nouveau déploiement de kiosque retail, comptes d’équipe partagés) ou à un bug de tracking affectant la façon dont user_id est défini à la déconnexion.

Le nombre d’utilisateurs diverge du nombre d’appareils dans une direction inattendue → si les utilisateurs uniques dépassent les appareils uniques, votre construction de clé de session comporte un bug qui crée des collisions de sessions. Une session ne devrait jamais contenir des événements provenant de plus d’un appareil. Exécuter la requête de validation de clé de session pour diagnostiquer.

Connexion à votre infrastructure de qualité des données plus large

Ces métriques appartiennent à votre infrastructure de tests dbt aux côtés de vos autres contrôles de qualité des données. La détection d’anomalies du taux de stitching peut s’exécuter comme un test dbt en utilisant expression_is_true de dbt-utils ou comme un test générique personnalisé :

# Dans votre schema.yml
models:
  - name: int__ga4__events_stitched
    tests:
      - dbt_utils.expression_is_true:
          expression: "stitch_rate_pct > 0"
          condition: "event_date = CURRENT_DATE() - 1"

Pour les équipes utilisant Elementary, le test elementary.test_anomalies appliqué à stitch_rate_pct dans votre mart de monitoring donne une détection automatique sans écrire de logique de seuil vous-même.

L’objectif est de détecter la dégradation de la résolution d’identité dans les 24 à 48 heures, avant qu’elle ne corrompe les modèles d’attribution en aval, les calculs de LTV ou les tables Customer 360 qui consomment les données stitchées.