Dans cet article, nous expliquons les défis posés par la réconciliation des identifiants et nous présentons notre approche pour créer un profil d'identification unifié dans la plateforme Customer Data , en particulier Treasure Data.
Data a été recueillie à partir d'un entrepôt hors ligne ( Data ) et d'un suivi de site web en ligne.
Plate-forme client Data
La plateforme Customer Data (CDP) permet aux entreprises de collecter, de gérer et d'analyser les données clients data provenant de diverses sources de manière unifiée et centralisée. L'objectif d'une CDP est de créer une vue complète et cohérente de chaque client en agrégeant data à partir de plusieurs points de contact, tels que les sites web, les applications mobiles, les médias sociaux, les interactions par courrier électronique, etc.
Trésor Data

Treasure Data est une plateforme client Data basée sur le cloud. Voici quelques cas d'utilisation courants de Treasure Data:
Rapprochement des identifiants
Le rapprochement des identifiants est un processus au cours duquel le site data relatif à une personne est comparé et mis en correspondance dans différents systèmes ou bases de données afin de garantir l'exactitude, la cohérence et une vision unifiée de cette personne.
Cela est particulièrement important dans les scénarios où plusieurs systèmes ou sources data stockent des informations sur les mêmes personnes, mais où le site data peut être incomplet ou incohérent.
Le défi de la réconciliation des données d'identification
Le rapprochement des données d'identification se heurte à de nombreuses difficultés, en particulier dans le cas de vastes ensembles de données et de sources d'information diverses. Parmi ces défis, citons les formats incohérents de data , les problèmes de qualité entraînant de fausses correspondances et la gestion des enregistrements en double résultant d'erreurs ou de modifications du système. La principale difficulté réside dans l'absence d'un identifiant unique représentant l'utilisateur dans les différentes sources d'information, tables et bases de données.
Les organisations relèvent ces défis en investissant dans des outils avancés data tels que Treasure Data.
Mise en œuvre du rapprochement des identifiants
Nous avons mis en œuvre le rapprochement des identifiants pour l'un de nos clients en utilisant la fonctionnalité d'unification de Treasure Data . Dans cet article, nous souhaitons partager notre approche et notre logique de mise en œuvre.
Conditions données : les bases de données de la CDP contenaient des tableaux contenant des informations sur le parcours de l'utilisateur sur le site web, ainsi que des informations sur les clients provenant de la base de données CRM (Customer Relationship Management) de l'entrepôt data .
L'objectif est de disposer d'un identifiant de profil unique dans chaque table CDP. Cela nous permettra de créer un segment principal avec une vue à 360 degrés du client et de son parcours.
Online data disponible : vues sur les pages du site web, soumissions de formulaires sur le site web, autres informations spécifiques au site web, telles que les détails de la page produit qui sont stockés dans un tableau séparé.
data hors ligne disponible : CRM data à partir de l'entrepôt data .
Aperçu des étapes à suivre pour créer un identifiant de profil unique :
Unification des tableaux web
Afin d'unifier le site web data , nous utiliserons la fonctionnalité d'unification de Treasure Data . Il est nécessaire de définir les tables sources et les colonnes qui doivent être unifiées dans une configuration au format YAML. Le guide étape par étape sur la façon d'implémenter l'unification dans Treasure Data peut être trouvé dans Treasure Data Documentation.
En conséquence, il crée un identifiant canonique dans chaque table qui est utilisé dans l'unification. L'objectif de l'identifiant canonique est de créer un identifiant qui représente chaque utilisateur du web. Il est utile pour le site web data, où il est difficile d'identifier les sessions des utilisateurs et d'unifier le site web data entre les différentes sessions.
Nous avons défini que l'identification canonique est basée sur les clés de fusion suivantes :
- name : td_canonical_id
merge_by_keys : [email, phone, td_client_id] source_tables : [web_form_submitted, web_product_detail, web_page_visits]
L'ordre des clés de fusion définit la priorité. La première clé de fusion identifie tous les sites web data ayant le même courriel (courriel fourni dans le formulaire web soumis sur le site web) comme provenant du même utilisateur.
La deuxième priorité est le numéro de téléphone (soumis par les visiteurs du site web) : data avec le même numéro de téléphone est également identifié comme provenant du même utilisateur. La troisième priorité est td_client_id - First-Party Cookie ID. L'identifiant du cookie de première partie est persistant dans les mêmes domaines. Des domaines différents auront des td_client_id différents. L'identifiant td_client_id change si le visiteur du site web efface son navigateur cookies.
Le résultat de l'unification est illustré dans les exemples ci-dessous.
Exemple 1 : Trésor Data a défini ces 3 entrées comme étant le même ID utilisateur (td_canonical_id), puisqu'ils ont le même email. Des numéros de téléphone différents n'affectent pas le résultat car nous avons défini que l'email est plus prioritaire que le numéro de téléphone :

Exemple 2 : lorsque l'adresse électronique n'est pas fournie, le même numéro de téléphone représente le même identifiant (td_canonical_id) :

Exemple 3 : lorsque des champs de correspondance plus prioritaires ne sont pas définis, c'est l'identifiant du cookie de la première partie qui est utilisé. Même td_client_id = même ID utilisateur (td_canonical_id). De tels visiteurs non identifiés, sans aucune information personnelle identifiable (PII), sont fréquents dans les tableaux de visiteurs de sites web. Td_client_id n'est pas totalement fiable puisqu'il peut changer après l'effacement des cookies, mais en l'absence d'IIP data, c'est la meilleure solution dont nous disposons.

Si nous supposons que seule la soumission d'un formulaire sur un site web contient l'adresse électronique et le formulaire, qu'advient-il des tableaux dans lesquels aucune IIP n'est disponible, par exemple web_page_visits? Supposons que les visites sur le site web n'aient qu'un ID de cookie de première partie - td_client_id. Dans le premier exemple, la table web_page_visits avec ces td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' et '567-tyu-ghj-234' aura le td_canonical_id = 'abcd1234'. Puisque la table web_form_submitted a déjà défini que ces 3 cookies ids appartiennent au même utilisateur, web_page_visits s'appuiera sur cette information en l'absence d'email ou de téléphone.
La même logique s'applique aux autres tables du site web data qui ne contiennent pas d'informations confidentielles data.
Créer une table maîtresse qui réunit les données en ligne et hors ligne data
Maintenant que le site web data est unifié, il est temps d'unifier les sites en ligne (web) et hors ligne data. Par data hors ligne, nous entendons CRM data qui contient des informations nominatives. À partir de data en ligne, nous utiliserons les IIP data (courriel, téléphone) dans la table web_form_submitted.
Dans un cas idéal, les ingénieurs de data peuvent ajouter une table CRM dans un fichier yml d'unification, mais nous avons eu un cas où la condition du client sur l'unification en ligne et hors ligne de data était plus complexe que l'unification automatique peut fournir. C'est pourquoi nous nous appuyons ici sur la puissance de SQL.
Nous avons effectué un FULL OUTER JOIN des tables web avec la soumission de formulaire data et des tables CRM sur l'email ou le téléphone. Les noms et prénoms ne sont pas uniques et ne sont donc pas fiables.
SELECT t.crm_client_id, d.td_canonical_id
FROM crm_user_table t
FULL OUTER JOIN web_form_submitted d
ON (t.email = d.email
OR t.phone = d.phone)
Il est également conseillé de définir une logique de correspondance des scores, au cas où plusieurs formulaires seraient soumis avec le même courriel ou numéro de téléphone. Par exemple, les formulaires web dont les noms et prénoms correspondent aux noms des clients CRM ont une priorité plus élevée que ceux qui ne correspondent pas.
Enrichir d'autres tables avec profile_id
Dans cette section, nous définissons l'identifiant de profil final qui est unique pour chaque utilisateur, qu'il soit identifié ou non.
En résumé, profile_id = COALESCE(crm_client_id, td_canonical_id).
Pour les tables web, les crm_client_id sont fournis par clé web(td_canonical_id) de la table maître créée à l'étape 2. En d'autres termes, si des utilisateurs soumettent un formulaire sur un site web et indiquent leur adresse électronique ou leur numéro de téléphone, nous pouvons les identifier dans la base de données CRM en tant que clients connus (au cas où ils seraient déjà clients de l'entreprise). Par conséquent, nous pouvons dire que les visites de pages web dont l'ID de cookie est identique à celui du formulaire web soumis appartiennent également au client identifié dans la base de données CRM.
from web_page_visits t
left join master_table d
on t.td_canonical_id = d.td_canonical_id
et d.rn_web_key = 1
La clé rn_web_key est définie comme suit :
partition par td_canonical_id
order by match_score,
time desc) comme rn_web_key
Son rôle est d'éviter les doublons dans la table de destination, car toutes les tables Web ont des relations de plusieurs à plusieurs. En outre, il partage crm_client_id avec le profil qui présente la meilleure correspondance entre le profil hors ligne et le profil en ligne data. Pour chaque td_canonical_id, il prend celui qui a le score de correspondance le plus élevé et, si le score de correspondance est identique, l'entrée la plus récente.
Créer une table d'audience contenant le profil de toutes les tables
Maintenant que toutes les tables ont un identifiant de profil, il est temps de créer un segment principal. Le Master Segment (Parent Segment) est une fonctionnalité de Treasure Data qui unifie toutes les informations concernant l'utilisateur, y compris l'interaction de l'utilisateur avec le site web et le produit. Il permet aux analystes commerciaux, aux spécialistes du marketing et à d'autres utilisateurs de voir dans Audience Studio tous les profils identifiés et non identifiés et de créer divers segments avec eux sans avoir à écrire de requêtes SQL.
Pour créer un segment principal, nous devons disposer d'une table d'audience qui sera utilisée pour joindre toutes les tables d'attributs et de comportements. L'objectif de la table d'audience est d'avoir tous les profils - en ligne et hors ligne. Elle ne contiendra que l'identifiant du profil, ce qui devrait suffire à la relier à toutes les autres tables (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
La mise en œuvre est aussi simple que l'union de toutes les tables contenant un identifiant de profil et la déduplication de tous les identifiants de profil.