Auteur
Dans cet article, nous expliquons les défis liés au rapprochement des identifiants et présentons notre approche pour créer un identifiant de profil unifié dans Data clients, plus précisément Treasure Data.
Data recueillies à partir d'un Data hors ligne et d'un système de suivi en ligne du site web.
Data clients
Data clients (CDP) permet aux entreprises de collecter, de gérer et d'analyser data clients data diverses sources de manière unifiée et centralisée. L'objectif d'une CDP est de créer une vue d'ensemble complète et cohérente de chaque client en regroupant data multiples points de contact, tels que les sites web, les applications mobiles, les réseaux sociaux, les échanges par e-mail, etc.
Treasure Data
Treasure Data une Data clients (CDP) cloud. Voici quelques cas d'utilisation courants de Treasure Data:
Rapprochement des identifiants
Le rapprochement des identités est un processus qui consiste à comparer et à faire correspondre data à une personne entre différents systèmes ou bases de données afin de garantir leur exactitude, leur cohérence et une vision unifiée de cette personne.
Cela revêt une importance particulière dans les cas où plusieurs systèmes ou data stockent des informations sur les mêmes personnes, mais où ces data être incomplètes ou incohérentes.
Le défi du rapprochement des identités
La mise en correspondance des identifiants se heurte à de nombreux défis, notamment lorsqu'il s'agit de vastes ensembles de données et de sources d'informations variées. Parmi ces défis figurent l'incohérence data , les problèmes de qualité entraînant des correspondances erronées, ainsi que la gestion des enregistrements en double résultant d'erreurs ou de modifications du système. Le principal défi réside dans l'absence d'un identifiant unique permettant de désigner l'utilisateur de manière univoque à travers les différentes sources d'informations, tables et bases de données.
Les entreprises relèvent ces défis en investissant dans data de pointe tels que Treasure Data.
Mise en œuvre du rapprochement des identifiants
Nous avons mis en place un processus de rapprochement des identifiants pour l'un de nos clients à l'aide de la fonctionnalité Data Treasure Data . Dans cet article, nous souhaitons vous présenter notre approche et notre logique de mise en œuvre.
Contexte : les bases de données CDP contenaient des tables fournissant des informations sur le parcours des utilisateurs sur le site web, ainsi que des informations sur les clients issues de la base de données CRM (gestion de la relation client) hébergée dans data .
L'objectif est de disposer d'un identifiant de profil unique dans chaque table de la plateforme de données clients (CDP). Cela nous permettra de créer un segment de référence offrant une vue à 360 degrés du client et de son parcours.
data en ligne : nombre de pages consultées sur le site web, soumissions de formulaires sur le site web, ainsi que d'autres informations spécifiques au site web, telles que les détails des pages produits, qui sont stockées dans un tableau distinct.
data hors ligne data : data CRM data data .
Présentation des étapes à suivre pour créer un identifiant de profil unique :
Harmonisation des tableaux Web
Afin d'harmoniser data Web, data exploiterons les capacités de la fonctionnalité Data Treasure Data . Cela nécessite de définir les tables sources et les colonnes à harmoniser dans un fichier de configuration au format YAML. Data un guide détaillé sur la mise en œuvre de la fonctionnalité « Unification » dans Treasure Data dans Data Treasure Data .
Il en résulte la création d'un identifiant canonique dans chaque table utilisée pour l'unification. L'objectif de cet identifiant canonique est de créer un identifiant qui représente chaque utilisateur Web. Il s'avère utile lorsqu'il est appliqué aux data Web, où il est difficile d'identifier les sessions des utilisateurs et d'unifier data Web data différentes sessions.
Nous avons défini que l'identifiant canonique repose 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étermine la priorité. La première clé de fusion identifie toutes data Web data la même adresse e-mail (adresses fournies dans le formulaire Web soumis sur le site) comme provenant du même utilisateur.
La deuxième priorité est le numéro de téléphone (fourni par les visiteurs sur le site web) : data le même numéro de téléphone sont également identifiées comme provenant du même utilisateur. La troisième priorité est le td_client_id — l'identifiant First-Party . L'identifiant First-Party est persistant sur les mêmes domaines. Des domaines différents auront des td_client_id différents. Le td_client_id change si le visiteur du site web efface les cookies de son navigateur.
Le résultat de cette unification est illustré dans les exemples ci-dessous.
Exemple 1 : Treasure Data ces trois entrées comme correspondant au même identifiant utilisateur (td_canonical_id), car elles partagent la même adresse e-mail. Les différences de numéro de téléphone n'ont aucune incidence sur le résultat, car nous avons défini que l'adresse e-mail avait une priorité plus élevée que le numéro de téléphone :
Exemple 2 : lorsqu'aucune adresse e-mail n'est fournie, un même numéro de téléphone correspond à un même identifiant utilisateur (td_canonical_id) :
Exemple 3 : lorsque aucun champ de correspondance prioritaire n'est défini, l'identifiant du cookie propriétaire est utilisé. Un même td_client_id correspond à un même identifiant utilisateur (td_canonical_id). Ces visiteurs non identifiés, dépourvus de toute information personnelle identifiable (PII), sont fréquents dans les tableaux de visiteurs des sites web. Le td_client_id n'est pas totalement fiable, car il peut changer après la suppression des cookies, mais en l'absence de data PII, c'est la meilleure option dont nous disposons.
Si l'on part du principe que seule la soumission d'un formulaire sur un site web contient une adresse e-mail et un formulaire, qu'en est-il alors des tables dans lesquelles aucune information personnelle identifiable n'est disponible, par exemple la table web_page_visits? Supposons que les visites sur le site web ne contiennent que l'identifiant First-Party : td_client_id. Dans le premier exemple, la table web_page_visits contenant les td_client_id « asd-123-qwe-456 », « zxc-234-ert-345 » et « 567-tyu-ghj-234 » aura le td_canonical_id = « abcd1234 ». Comme la table web_form_submitted a déjà défini que ces 3 identifiants de cookie appartiennent au même utilisateur, web_page_visits s'appuiera sur cette information en l'absence d'adresse e-mail ou de numéro de téléphone.
La même logique s'applique aux autres data Web qui ne contiennent pas data à caractère personnel.
Créer une table de référence qui regroupe data en ligne et hors ligne
Maintenant que data Web data harmonisées entre elles, il est temps d'harmoniser data en ligne (Web) et hors ligne. Par « data hors ligne », data entendons data CRM data des informations personnelles identifiables (PII). Parmi data en ligne, data utiliserons data personnelles identifiables data adresse e-mail, numéro de téléphone) contenues dans la table « web_form_submitted ».
Dans l'idéal, data peuvent ajouter une table CRM dans un fichier YML d'unification, mais nous avons été confrontés à un cas où les exigences du client en matière d'unification data en ligne et hors ligne data trop complexes pour être satisfaites par une unification automatique. C'est pourquoi nous nous appuyons ici sur la puissance du langage SQL.
Nous avons effectué une jointure externe complète (FULL OUTER JOIN) entre les tables Web contenant data de soumission de formulaires data les tables CRM sur la base des adresses e-mail ou des numéros de téléphone. Les prénoms et noms de famille ne sont pas uniques et ne constituent donc pas une source fiable.
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 pondération, au cas où plusieurs formulaires seraient envoyés avec la même adresse e-mail ou le même numéro de téléphone. Par exemple, les formulaires web dont le prénom et le nom correspondent à ceux des clients du CRM ont une priorité plus élevée que ceux qui ne correspondent pas.
Ajouter le champ « profile_id » aux autres tables
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 identifiants crm_client_id sont fournis par clé Web (td_canonical_id) à partir de la table principale créée à l'étape 2. Cela signifie que si des utilisateurs ont soumis un formulaire sur un site Web et ont fourni leur adresse e-mail ou leur numéro de téléphone, nous pouvons les identifier dans la base de données CRM comme des clients connus (dans le cas où ils sont déjà clients de l'entreprise). Par conséquent, nous pouvons affirmer que les visites de pages Web dont l'identifiant de cookie correspond à 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
AND d.rn_web_key = 1
rn_web_key est défini comme suit :
partition by td_canonical_id
order by match_score,
time desc) as rn_web_key
Son rôle est d'éviter la création de doublons dans la table de destination, car toutes les tables Web ont des relations « plusieurs-à-plusieurs ». De plus, il partage l'identifiant crm_client_id avec le profil présentant la meilleure correspondance entre data hors ligne et en ligne. Pour chaque td_canonical_id, il retient celui qui présente le score de correspondance le plus élevé ; en cas d'égalité des scores, c'est l'entrée la plus récente qui est retenue.
Créer une table d'audience contenant les profils de toutes les tables
Maintenant que toutes les tables disposent d'un identifiant de profil, il est temps de créer un segment maître. Le segment maître (ou segment parent) est une fonctionnalité de Treasure Data regroupe toutes les informations relatives à l'utilisateur, y compris ses interactions avec le site web et le produit. Il permet aux analystes métier, aux spécialistes du marketing et aux autres utilisateurs de visualiser dans Audience Studio l'ensemble des profils identifiés et non identifiés, et de créer divers segments à partir de ceux-ci sans avoir à écrire de requêtes SQL.
Pour créer un segment maître, nous devons disposer d'une table d'audience qui servira à joindre toutes les tables d'attributs et de comportements. L'objectif de cette table d'audience est de regrouper tous les profils, qu'ils soient en ligne ou hors ligne. Elle ne contiendra que le profil_id, car cela devrait suffire pour la joindre à toutes les autres tables (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
La mise en œuvre consiste simplement à regrouper toutes les tables contenant un « profile_id » et à éliminer les doublons parmi ces « profile_ids ».
