Identity stitching : relier les événements anonymes aux profils clients

Une cliente consulte trois fiches produit, quitte votre site, puis revient créer un compte. Votre CRM connaît désormais son identité. Mais retrouve-t-il les interactions qui ont précédé son inscription ?

L’identity stitching relie des interactions enregistrées sous différents identifiants pour reconstituer un parcours client. Dans le cadre plus large de la résolution d’identité, cet article traite une question précise : comment rattacher les événements anonymes à l’historique d’un client après son identification ?

L’enjeu est de préserver un historique utile, sans attribuer à une personne les comportements d’un autre utilisateur.

L’identity stitching consiste à établir une continuité entre des interactions qui portent des identifiants différents. Dans le cas d’un parcours web, il peut relier un identifiant de navigateur à un identifiant client apparu lors d’une connexion.

Le terme event stitching met l’accent sur les événements à rattacher : visites, recherches, achats ou interactions avec le support. Les termes varient selon les solutions ; le périmètre et les règles doivent donc être vérifiés.

Trois opérations restent distinctes :

Un identity graph représente les relations entre identifiants. Il peut soutenir le rapprochement, mais ne remplace ni la collecte ni la définition des règles temporelles.

🟰Le rapprochement déterministe repose sur des règles explicites et des identifiants observés. Lorsqu’une connexion contient à la fois un identifiant de navigateur anonyme et un identifiant client, elle peut fournir le lien nécessaire au stitching.

Une adresse email peut également rapprocher des enregistrements issus de plusieurs systèmes, lorsque son attribution et son utilisation sont suffisamment fiables. Une correspondance exacte reste tributaire de la qualité des sources : les adresses partagées et les identifiants réattribués peuvent produire des erreurs.

🎲 Le rapprochement probabiliste estime si des interactions appartiennent à la même personne à partir d’un ensemble de signaux. Il introduit une incertitude à évaluer selon l’usage envisagé. Une association probable ne doit pas devenir automatiquement une identité confirmée.

Pour une équipe marketing qui personnalise un email à partir des achats, une mauvaise association pourrait utiliser les intérêts ou les transactions d’un autre client.

Il est donc nécessaire de privilégier des liens explicables et vérifiables pour des actions individuelles. Dans les analyses et les profils, gardez la distinction entre correspondances confirmées et associations estimées.

Avant l’identification, un événement peut porter un identifiant de navigateur, sans identifiant client. Ce signal assure une continuité technique limitée au contexte dans lequel il a été créé.

Un identifiant anonyme n’est pas une preuve d’identité personnelle. Plusieurs personnes peuvent utiliser le même appareil. Inversement, une personne peut utiliser plusieurs navigateurs.

Il faut donc conserver les données nécessaires au rapprochement, en respectant les choix de collecte et d’utilisation applicables.

Une connexion peut produire un événement contenant à la fois l’identifiant de navigateur et l’identifiant du compte. Cette coexistence fournit un lien exploitable.

Le simple fait de disposer d’une adresse email dans le CRM ne suffit pas à retrouver toutes les visites de cette personne. Il faut une relation observable entre cette identité et les événements concernés.

Selon le fonctionnement de l’outil, les événements antérieurs peuvent être rattachés au parcours identifié, dans les limites prévues.

La date de l’interaction reste distincte de celle de son rapprochement. Une visite de lundi rattachée jeudi reste une visite de lundi.

Le résultat doit pouvoir être utilisé dans les analyses et les règles de segmentation. Une organisation peut, par exemple, calculer les catégories consultées avant une première commande.

Avant toute activation, elle doit vérifier la fraîcheur des données, les exclusions métier et l’éligibilité du client au canal retenu.

Prenons un exemple fictif dans le e-commerce.

Si les règles le permettent, le lien observé jeudi rattache les consultations antérieures au parcours de C42.

L’équipe marketing peut alors comprendre que le guide des tailles faisait partie du parcours avant achat. Elle peut également éviter une relance destinée aux visiteurs n’ayant pas encore commandé.

Le rapprochement ne prouve pas que le guide a causé la vente. Il enrichit l’observation du parcours ; la mesure de l’impact d’un contenu ou d’une campagne reste un travail distinct.

Si une autre personne utilisait B17 le mardi, le résultat pourrait être incorrect. Cet exemple montre pourquoi les règles doivent traiter les conflits, et pas seulement maximiser le nombre de rapprochements.

Le stitching peut relier les recherches d’un visiteur anonyme à un achat ultérieur. Les équipes analytics examinent alors la séquence observée, au lieu de considérer le visiteur et l’acheteur comme deux enregistrements sans lien.

Vous pouvez, par exemple, comparer les parcours des clients qui ont consulté les conditions de livraison et de ceux qui ne l’ont pas fait. Cette observation aide à formuler des pistes d’analyse ; elle ne prouve pas que ces informations ont provoqué l’achat.

Une fois les rapprochements contrôlés, l’historique de navigation utilisable peut enrichir les profils clients avec des signaux concrets, comme un intérêt récent pour une catégorie de produits. L’équipe marketing dispose d’un contexte supplémentaire pour adapter ses contenus.

L’action doit rester proportionnée au signal. Une seule page consultée anonymement constitue un indice limité pour déduire une préférence durable, même si la visite est correctement rattachée au client.

Un achat enregistré dans un outil peut nécessiter une exclusion d’une relance préparée dans un autre. Le stitching aide à relier l’activité antérieure à la commande ; la campagne exige toujours des données à jour et une règle d’exclusion explicite.

Le parcours devient plus cohérent entre canaux, mais toutes les destinations ne sont pas automatiquement mises à jour. Vérifiez quand les profils et les audiences sont effectivement transmis à l’outil d’emailing ou à la plateforme publicitaire.

La qualité du résultat commence par un event tracking cohérent.

Pour chaque source, la documentation couvre au minimum :

Le rôle de chaque identifiant mérite d’être précisé. Un cookie de navigateur, une installation d’application mobile et un compte client ont des périmètres différents. Une personne peut posséder plusieurs identifiants d’appareil, et un appareil peut être partagé.

Les données first-party collectées sur votre site ou votre application constituent le point de départ de ce fonctionnement. Cela ne rend pas chaque événement identifié, exact ou utilisable pour toutes les finalités. Intégrez les choix de confidentialité, les droits d’accès et les règles de conservation à la conception des rapprochements.

Le choix de la population de référence oriente les règles de rapprochement : le parcours à reconstituer concerne-t-il une personne, un compte partagé ou une entreprise ? Mélanger ces niveaux peut produire des segments incohérents.

En B2B, plusieurs personnes d’une même entreprise peuvent rechercher le même produit. Un domaine email ou un réseau de bureau commun ne suffit pas à établir qu’il s’agit d’une seule personne. Distinguez les parcours individuels de l’activité du compte entreprise : les équipes pourront analyser l’intérêt collectif sans attribuer la navigation d’un contact au profil d’un autre.

Enfin, précisez le traitement des événements reçus en retard. Une commande intégrée après la préparation d’une audience ne doit pas être confondue avec une commande inexistante.

Précisez qui porte ces décisions. Le marketing définit les audiences et les exclusions attendues ; les équipes data vérifient les identifiants et les dates qui rendent ces règles applicables.

Des scénarios dans lesquels deux clients utilisent successivement le même navigateur permettent d’observer le comportement du système à la déconnexion et lors de la connexion suivante.

Un lien technique ne doit pas automatiquement entraîner la fusion de tous les comportements historiques. Documentez les cas exclus ou laissés sans attribution.

Testez aussi le cas d’un client qui recherche un produit sur mobile puis achète sur ordinateur. Si les deux appareils portent ensuite un identifiant client adapté, les liens observés peuvent permettre de reconstituer un parcours commun. Sans ce signal, l’activité mobile peut rester anonyme. Une interaction sans attribution vaut mieux qu’une fausse correspondance.

L’étape Identifier policy définit la priorité des identifiants, leurs limites et leur durée d’utilisation pour le stitching. Interface en anglais.

Le traitement historique dépend des événements qui peuvent être réexaminés et des sorties recalculées. Il reste aussi à vérifier si une correction peut être propagée aux outils qui ont déjà reçu les données.

Une mise à jour de l’historique analytique ne doit pas déclencher involontairement une ancienne campagne. Décidez si un événement nouvellement rattaché peut lancer une action ou seulement enrichir un profil.

Le suivi porte sur la part des événements rattachés, mais aussi sur les conflits, les événements non attribués et les variations inhabituelles de population.

Pour chaque indicateur, fixez son périmètre. Un taux calculé sur les seuls événements éligibles ne se compare pas directement à un taux calculé sur toute la collecte.

Avant d’étendre le périmètre, examinez un échantillon des rapprochements et des exclusions. Vous pourrez mieux distinguer une amélioration de la couverture, un problème de source et une règle trop permissive.

Quelques parcours clients dont le résultat attendu est connu offrent une base de comparaison. L’utilisation des mêmes enregistrements permet d’évaluer les solutions : une fonctionnalité appelée « identity stitching » peut fonctionner différemment d’un outil à l’autre.

La solution produit-elle un jeu d’événements rattachés, des profils clients unifiés ou un graphe d’identité ? Ces résultats répondent à des besoins différents. L’équipe analytics peut chercher une clé stable pour regrouper les interactions ; le marketing a besoin d’un profil exploitable dans ses règles d’audience.

Examinez un visiteur anonyme, un client récurrent et un appareil partagé. Vérifiez quels enregistrements changent, quels identifiants d’origine restent disponibles et comment une correction se répercute sur le résultat.

L’explication de rapprochements individuels aide à comprendre les décisions de l’outil. Quel identifiant a relié les enregistrements ? Quelle source l’a fourni ? La décision repose-t-elle sur une règle déterministe ou sur un modèle probabiliste ?

Un score de confiance doit avoir une signification documentée et faire l’objet d’une validation. Une valeur élevée ne remplace pas la vérification de cas connus. Assurez-vous que l’outil peut laisser les situations incertaines séparées et corriger une erreur sans reconstruire des profils qui ne sont pas concernés.

Vérifiez comment les profils ou les événements rapprochés deviennent disponibles dans les outils analytics, d’emailing et les autres canaux marketing. Examinez les fréquences de mise à jour, les données reçues en retard et la propagation des suppressions ou des corrections.

Un profil unifié peut déjà contenir un achat tandis qu’une audience email utilise encore les données de la veille. Testez le fonctionnement complet, des sources à la destination, exclusions comprises. Le rapprochement ne résout pas à lui seul les délais de transmission.

La répartition des responsabilités précise qui peut consulter les identifiants clients, configurer les règles et approuver leurs évolutions. Pour l’évaluation, des scénarios de test maîtrisés limitent l’exposition inutile de données personnelles.

Les contrôles de confidentialité doivent couvrir les profils obtenus autant que les événements sources. Vérifiez la gestion de la conservation, des restrictions d’accès et des changements d’usage autorisé. Identifiez l’équipe responsable de chaque contrôle et le traitement des exceptions.

Dans DinMo, Event Stitching permet de reconstituer des parcours à partir d’événements anonymes et identifiés. Cette capacité répond à une question concrète : quelles interactions peuvent être rattachées au même parcours, notamment lorsqu’un visiteur se connecte après plusieurs visites ?

Le paramétrage consiste à sélectionner les modèles d’événements, associer leurs champs et définir les règles d’utilisation des identifiants.

Dans notre exemple e-commerce, l’objectif est de déterminer comment exploiter le lien observé entre le navigateur B17 et le client C42. Les équipes data définissent les conditions du rapprochement ; les équipes marketing précisent l’usage attendu, comme analyser les consultations précédant un achat.

Dans DinMo, l’étape Mapping associe les champs des modèles d’événements aux identifiants utilisés pour le rapprochement. Interface en anglais.

La vue d’ensemble du projet présente notamment les événements traités, le taux de stitching et la répartition entre profils connus et anonymes. Elle permet de suivre l’évolution des résultats.

Les contrôles qualité complètent cette lecture avec des informations sur les identifiants et les motifs d’exclusion. Une hausse du taux de rapprochement doit toujours être examinée avec la qualité des associations, particulièrement lorsqu’un appareil est partagé.

L’historique reconstitué peut ensuite contribuer aux analyses et, une fois relié aux données clients appropriées, aux règles de segmentation : intérêt pour une catégorie, consultations avant achat ou exclusion après une commande.

Event Stitching reste distinct de la capacité de Profile Resolution, qui rapproche les enregistrements clients en profils. Les deux capacités produisent des résultats indépendants : leur articulation doit être définie à partir d’identifiants communs fiables.

L’identity stitching devient utile lorsqu’il relie des interactions de personnes non reconnues à des profils exploitable. Il doit avoir des règles compréhensibles et contrôlables.

Un premier périmètre limité permet de tester les situations ambiguës et de vérifier les conséquences sur les audiences. Son extension peut ensuite s’appuyer sur une meilleure visibilité sur la qualité des données et leur usage dans DinMo.