Auteur
Dans cet article, nous expliquons les défis liés au rapprochement des identités et présentons notre approche pour créer un identifiant de profil unifié sur la plateforme Customer Data, plus précisément...
Data a été recueilli à partir d'un entrepôt Data hors ligne et du suivi d'un site web en ligne.
Client Data Plate-forme
La Customer Data Platform (CDP) permet aux entreprises de collecter, de gérer et d'analyser les data des clients à partir de différentes sources de manière unifiée et centralisée. La objectif d'un CDP est de créer une vision globale et cohérente de chaque client en regroupant data de plusieurs points de contact, 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 cloud. Voici quelques cas d'utilisation courants de Treasure Data :
Rapprochement des identifiants
Le rapprochement des identifiants est un processus au cours duquel les data relatifs à une personne sont comparés et mis en correspondance dans différents systèmes ou databases afin de garantir l'exactitude, la cohérence et une vision unifiée de cette personne.
Ceci est particulièrement important dans les scénarios où plusieurs systèmes ou sources data stockent des informations sur les mêmes individus, mais où les data peuvent être incomplètes ou incohérentes.
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 d'ensembles data étendus et de sources d'information diverses. Ces défis comprennent des formats data incohérents, des problèmes de qualité entraînant de fausses correspondances et la gestion d'enregistrements en double résultant d'erreurs ou de changements de système. La principale difficulté réside dans l'absence d'un identifiant unique représenter l'utilisateur à travers les différentes sources d'information, les tableaux et les bases data.
Les entreprises relèvent ces défis en investissant dans des outils data avancés 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 : Dans les bases CDP data, des tableaux contenant des informations sur le parcours de l'utilisateur sur le site web étaient disponibles, ainsi que des informations sur les clients provenant de la base CRM (Customer Relationship Management) data dans l'entrepôt data.
L'objectif est d'avoir 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.
data disponible en ligne : les consultations des pages du site web, les soumissions de formulaires sur le site web, d'autres informations spécifiques au site web, telles que les détails des pages de produits, qui sont stockées dans un tableau séparé.
data disponible hors ligne : CRM data 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 web data, nous exploiterons les capacités de 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 est disponible à l'adresse suivante 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 dans le cas du 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 :
- nom : 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 web data avec la même courriel (courriels fournis dans le formulaire web soumis sur le site web) comme provenant du même utilisateur.
La deuxième priorité est 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 - ID du cookie de première partie. 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 : Le trésor Data a défini ces 3 entrées comme étant le même ID utilisateur (td_canonical_id), étant donné qu'elles ont le même ID utilisateur. courriel. Les différents numéros de téléphone 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'email n'est pas fourni, le même numéro de téléphone représente le même identifiant d'utilisateur (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é. Idem td_client_id = même ID utilisateur (td_canonical_id). De tels visiteurs non identifiés et dépourvus d'informations personnelles identifiables (IPI) sont fréquents dans les tableaux de visiteurs des 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 IPI n'est disponible, par exemple visites_de_page_web? Supposons que les visites d'un site web n'aient qu'un ID de cookie de première partie - td_client_id. Dans le premier exemple visites_de_page_web avec les td_client_id ‘asd-123-qwe-456’, ‘zxc-234-ert-345’ et ‘567-tyu-ghj-234’ aura le td_canonical_id = ‘abcd1234’. Puisque web_form_submitted a déjà défini que ces 3 identifiants de cookies appartiennent au même utilisateur, visites_de_page_web s'appuiera sur ces informations en l'absence de courrier électronique ou de téléphone.
La même logique s'applique aux autres tableaux web data qui n'ont pas d'IIP data.
Créez une table maîtresse qui joint les données en ligne et hors ligne data
Maintenant que data en ligne est unifiée, il est temps d'unifier data en ligne (web) et hors ligne. Par data hors ligne, nous entendons data CRM qui contient des informations confidentielles. A partir de data en ligne, nous utiliserons PII data (email, 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 ce 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 le formulaire de soumission 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, dans le cas où plusieurs formulaires sont 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.
Enrichissez 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 tableaux web crm_client_id sont fournis par clé web (td_canonical_id) de la table maîtresse 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 CRM data comme des 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 CRM identifié.
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, étant donné que 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 data hors ligne et data en ligne. 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éez la table audience qui contient 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. Segment principal (segment parent) est une fonctionnalité de Treasure Data qui unifie toutes les informations concernant l'utilisateur, y compris son interaction avec le site web et le produit. Elle 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 audience qui sera utilisée pour joindre toutes les tables d'attributs et de comportements. L'objectif de la table 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.
