Limites du matching probabiliste dans GA4

Quand le matching déterministe (associer user_id à user_pseudo_id) vous laisse avec un taux d’identification inférieur à ce que vous souhaitez, le matching probabiliste semble attrayant. L’idée : faire correspondre des utilisateurs anonymes entre les sessions en prenant l’empreinte des caractéristiques de l’appareil, de la localisation, et des patterns comportementaux. En pratique, cette approche se heurte durement aux données spécifiques que GA4 exporte vers BigQuery.

Ce que GA4 exclut intentionnellement

L’export BigQuery de GA4 omet les signaux qui rendent le fingerprinting efficace :

Pas d’adresses IP — supprimées avant l’export pour des raisons de confidentialité
Pas de chaînes user agent — non disponibles dans aucun champ BigQuery de GA4
Pas d’empreintes canvas — non collectées par GA4
Pas d’identifiants matériels — pas d’adresses MAC, numéros de série d’appareils, ou hachages d’empreintes d’appareils

Ce n’est pas un oubli. La conception de la confidentialité de GA4 supprime explicitement ces signaux d’identification avant que les données n’atteignent votre warehouse. Google les utilise en interne pour la modélisation, mais ils ne quittent pas la plateforme.

Ce à quoi vous avez accès

Les signaux qui survivent jusqu’à BigQuery sont agressivement grossiers :

SELECT DISTINCT
    device.category,           -- mobile, desktop, tablet (3 valeurs)
    device.operating_system,   -- Android, iOS, Windows, macOS, etc.
    device.browser,            -- Chrome, Safari, Firefox, etc.
    device.language,           -- en-US, fr-FR, etc.
    geo.country,
    geo.city,
    geo.metro
FROM `project.analytics_XXXXX.events_*`
WHERE _table_suffix = FORMAT_DATE('%Y%m%d', CURRENT_DATE() - 1)

Considérez ce que le matching sur ces champs produit réellement. Combien d’utilisateurs à San Francisco utilisent Chrome sur un MacBook ? Des dizaines de milliers. Combien à Paris utilisent Safari sur iOS avec la langue fr-FR ? Des centaines de milliers. Le taux de collision sur n’importe quelle combinaison de ces signaux grossiers est énorme, et il s’aggrave au fur et à mesure que votre volume de trafic augmente.

Le coût cumulatif des faux positifs

Les profils incorrectement fusionnés n’inflatent pas seulement votre taux d’identification — ils corrompent activement les analyses en aval de façons qui s’accumulent dans le temps :

Les systèmes de recommandation s’entraînent sur des historiques comportementaux fusionnés. L’utilisateur A parcourt des logiciels d’entreprise ; l’utilisateur B achète des appareils de cuisine. Fusionnez-les et aucun ne reçoit des recommandations précises.

La personnalisation des emails référence un comportement de navigation que le destinataire ne reconnaît pas. Les taux d’ouverture et de clic baissent ; les taux de désinscription augmentent.

Les modèles d’attribution créditent des canaux qui n’ont pas contribué à la conversion. Vos calculs de ROAS deviennent peu fiables, et les décisions d’allocation de budget basées sur eux poussent les dépenses vers des canaux qui semblent fonctionner mais ne fonctionnent pas.

Le contexte de support client devient confus. Un agent de support qui voit un historique fusionné diagnostique mal les problèmes et fournit des conseils incorrects.

Ces problèmes ne s’annoncent pas. Les données semblent correctes. Les rapports continuent de tourner. Les métriques évoluent dans des directions plausibles. La corruption n’est visible que quand quelqu’un audite les données sous-jacentes — souvent des mois plus tard quand les dégâts sont profonds.

Les mathématiques des faux positifs

Même un matcher probabiliste “bon” qui atteint 95 % de précision (taux de faux positifs de 5 %) produit des problèmes cumulatifs à grande échelle. Si vous avez 100 000 utilisateurs anonymes et essayez de les associer probabilistement à 50 000 utilisateurs connus, un taux de faux positifs de 5 % signifie 5 000 fusions incorrectes. Ces 5 000 profils pollués contaminent toute analyse qui les touche.

La recherche sur la résolution d’identité Customer 360 de la communauté dbt montre que les outils probabilistes spécialisés comme Splink atteignent une meilleure précision que les approches SQL naïves — mais même le matching probabiliste optimisé introduit des faux positifs que la plupart des équipes analytics n’ont pas la capacité d’auditer et de nettoyer. Le gain marginal en taux de matching justifie rarement le coût en qualité des données en aval.

Quand accepter un taux de matching inférieur

La bonne réponse pour la plupart des implémentations GA4 est : utilisez uniquement le matching déterministe, acceptez le taux d’identification que vous obtenez, et investissez dans son amélioration via l’implémentation plutôt que l’inférence.

Moyens d’améliorer les taux de matching déterministe légitimement :

Corriger les lacunes d’implémentation de user_id — auditer quelles pages et événements déclenchent user_id et lesquels ne le font pas. Un utilisateur qui se connecte à la page 5 de votre tunnel de commande devrait avoir user_id défini depuis la page 1.
Capturer user_pseudo_id à la soumission du formulaire — quand des utilisateurs anonymes soumettent un formulaire de contact, un champ caché peut capturer l’ID client GA4 et le transmettre à votre CRM, créant un lien déterministe sans nécessiter d’authentification.
Étendre le stitching au niveau de la session — si un utilisateur s’authentifie au cours d’une session, appliquez son user_id à tous les événements antérieurs de cette session en utilisant FIRST_VALUE IGNORE NULLS sur la fenêtre de session.

Ces approches augmentent votre taux de matching déterministe sans introduire de faux positifs. Un taux d’identification de 40 % avec une haute confiance est plus précieux qu’un taux d’identification de 70 % construit sur des données auxquelles vous ne pouvez pas faire confiance.

L’exception : signaux comportementaux de qualité connue

Il existe des cas étroits où les signaux probabilistes sont suffisamment fiables pour être utilisés. La condition clé est que le signal doit être suffisamment unique en lui-même :

Un utilisateur soumettant un formulaire avec une adresse email fait un lien déterministe vers un contact CRM. La soumission du formulaire est le signal ; l’email est déterministe.
Un achat avec un ID de transaction qui apparaît également dans votre système de gestion des commandes fait un lien déterministe. L’ID de transaction est le signal.
Une séquence comportementale très spécifique (par exemple, compléter un flux multi-étapes spécifique dans une fenêtre de temps spécifique) combinée avec des signaux de timing peut être fiable dans des contextes B2B à faible volume où la population d’utilisateurs est petite.

Ce ne sont pas des signaux probabilistes — ce sont des signaux déterministes qui semblent probabilistes parce qu’ils nécessitent une inférence. La différence est importante. Tenez-vous aux signaux pour lesquels vous seriez à l’aise d’expliquer le matching à un auditeur.