In diesem Artikel erläutern wir die Herausforderungen des ID-Abgleichs und demonstrieren unseren Ansatz zur Erstellung einer einheitlichen Profil-ID in der Customer Data Platform, speziell Treasure Data.
Data wurden in einem Offline-Lager Data und auf einer Online-Website gesammelt.
Kunde Data Plattform
Die Customer Data Platform (CDP) ermöglicht es Unternehmen, Kunden data aus verschiedenen Quellen auf einheitliche und zentralisierte Weise zu sammeln, zu verwalten und zu analysieren. Das Ziel einer CDP ist es, eine umfassende und zusammenhängende Sicht auf jeden Kunden zu erstellen, indem data von verschiedenen Berührungspunkten wie Websites, mobilen Apps, sozialen Medien, E-Mail-Interaktionen und mehr gesammelt wird.
Schatz Data
Treasure Data ist eine cloudbasierte Kundenplattform Data . Hier sind einige häufige Anwendungsfälle für Treasure Data:
ID-Abstimmung
Der ID-Abgleich ist ein Prozess, bei dem data in Bezug auf eine Person in verschiedenen Systemen oder Datenbanken verglichen und abgeglichen wird, um Genauigkeit, Konsistenz und eine einheitliche Sicht auf diese Person zu gewährleisten.
Dies ist besonders wichtig in Szenarien, in denen mehrere Systeme oder data Quellen Informationen über dieselben Personen speichern, die data jedoch unvollständig oder inkonsistent sein können.
Die Herausforderung des ID-Abgleichs
Der ID-Abgleich ist mit zahlreichen Herausforderungen verbunden, insbesondere bei umfangreichen Datensätzen und unterschiedlichen Informationsquellen. Zu diesen Herausforderungen gehören inkonsistente data Formate, Qualitätsprobleme, die zu falschen Übereinstimmungen führen, und die Verwaltung von doppelten Datensätzen, die durch Fehler oder Systemänderungen entstehen. Die größte Herausforderung ist das Fehlen einer eindeutigen ID, die den Nutzer über die verschiedenen Informationsquellen, Tabellen und Datenbanken hinweg repräsentiert.
Unternehmen begegnen diesen Herausforderungen, indem sie in fortschrittliche data Tools wie Treasure Data investieren.
Umsetzung des ID-Abgleichs
Wir haben für einen unserer Kunden einen ID-Abgleich mit Hilfe der Treasure Data Unification-Funktionalität durchgeführt. In diesem Artikel möchten wir unseren Ansatz und unsere Implementierungslogik vorstellen.
Gegebene Bedingungen: In den CDP-Datenbanken waren Tabellen mit Informationen über die User Journey auf der Website sowie Kundeninformationen aus der CRM-Datenbank (Customer Relationship Management) im data warehouse verfügbar.
Ziel ist es, in jeder CDP-Tabelle einen eindeutigen Profilbezeichner zu haben. Dadurch können wir ein Mastersegment mit einer 360-Grad-Sicht auf den Kunden und seine Reise erstellen.
Online data verfügbar: Ansichten auf Webseiten, Formulareingaben auf der Webseite, andere webseitenspezifische Informationen, wie z. B. Details auf der Produktseite, die in einer separaten Tabelle gespeichert werden.
Offline data verfügbar: CRM data aus dem Lager data .
Überblick über die Schritte zur Erstellung einer eindeutigen Profil-ID:
Vereinheitlichung von Webtabellen
Um Web data zu vereinheitlichen, werden wir die Möglichkeiten der Treasure Data Unification-Funktionalität nutzen. Dazu müssen die Quelltabellen und die Spalten, die vereinheitlicht werden sollen, in einer YAML-formatierten Konfiguration definiert werden. Die Schritt-für-Schritt-Anleitung zur Implementierung von Unification in Treasure Data finden Sie in der Treasure Data Dokumentation.
Infolgedessen wird in jeder Tabelle eine kanonische ID erstellt, die bei der Vereinheitlichung verwendet wird. Das Ziel der kanonischen ID ist es, eine ID zu erstellen, die jeden Webbenutzer repräsentiert. Es ist nützlich, wenn es für das Web data angewendet wird, wo es schwierig ist, Benutzersitzungen zu identifizieren und das Web data über verschiedene Sitzungen hinweg zu vereinheitlichen.
Wir haben definiert, dass die kanonische ID auf den folgenden Zusammenführungsschlüsseln basiert:
- name: td_canonical_id
merge_by_keys: [email, telefon, td_client_id] source_tables: [web_form_submitted, web_product_detail, web_page_visits]
Die Reihenfolge der Seriendruckschlüssel bestimmt die Priorität. Der erste Merge-Schlüssel identifiziert alle Web data mit der gleichen E-Mail (E-Mails, die im Webformular auf der Website angegeben sind) als vom gleichen Benutzer stammend.
Zweite Priorität ist die Telefonnummer (die von den Besuchern der Website angegeben wird): data mit derselben Telefonnummer wird ebenfalls als von demselben Nutzer stammend identifiziert. Die dritte Priorität ist td_client_id - First-Party Cookie ID. Die First-Party-Cookie-ID ist über dieselben Domänen hinweg beständig. Verschiedene Domains haben unterschiedliche td_client_id. Die td_client_id ändert sich, wenn der Besucher der Website den Browser löscht cookies.
Das Ergebnis der Vereinheitlichung ist in den folgenden Beispielen dargestellt.
Beispiel 1: Treasure Data definiert diese 3 Eingaben als dieselbe Benutzer-ID (td_canonical_id), da sie dieselbe E-Mail haben. Unterschiedliche Telefonnummern haben keinen Einfluss auf das Ergebnis, da wir definiert haben, dass die E-Mail eine höhere Priorität als die Telefonnummer hat:
Beispiel 2: Wenn keine E-Mail angegeben wird, steht dieselbe Telefonnummer für dieselbe Benutzerkennung (td_canonical_id):
Beispiel 3: Wenn keine übereinstimmenden Felder mit höherer Priorität definiert sind, wird die Cookie-ID der ersten Partei verwendet. Gleiche td_client_id = gleiche Benutzer-ID (td_canonical_id). Solche nicht identifizierten Besucher ohne personenbezogene Daten (PII) sind in den Besuchertabellen von Websites üblich. Td_client_id ist nicht völlig zuverlässig, da sie sich nach dem Löschen des Cookies ändern kann, aber in Ermangelung von PII data ist sie die beste Möglichkeit, die wir haben.
Wenn wir davon ausgehen, dass nur die Formularübermittlung auf einer Website E-Mail und Formular enthält, was geschieht dann mit den Tabellen, in denen keine PII verfügbar sind, z. B. web_page_visits? Nehmen wir an, die Website-Besuche haben nur die Cookie-ID der ersten Partei - td_client_id. Im ersten Beispiel hat die Tabelle web_page_visits mit den td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' und '567-tyu-ghj-234' die td_canonical_id = 'abcd1234'. Da die Tabelle web_form_submitted bereits definiert hat, dass diese 3 Cookie-IDs zum selben Benutzer gehören, wird web_page_visits sich auf diese Information verlassen, wenn keine E-Mail oder kein Telefon vorhanden ist.
Die gleiche Logik gilt für andere Web data Tabellen, die keine PII haben data.
Stammtabelle erstellen, die Online und Offline zusammenführt data
Nachdem Web data nun gegenseitig vereinheitlicht wurde, ist es an der Zeit, Online (Web) und Offline data zu vereinheitlichen. Mit offline data meinen wir CRM data , das PII enthält. Von online data werden wir die Verwendung von PII data (E-Mail, Telefon) in der Tabelle web_form_submitted übernehmen.
Im Idealfall können die Techniker von data eine CRM-Tabelle in eine yml-Datei für die Vereinheitlichung einfügen, aber wir hatten einen Fall, in dem die Bedingung des Kunden für die Vereinheitlichung von online und offline data komplexer war, als es die automatische Vereinheitlichung leisten kann. Daher verlassen wir uns hier auf die Leistungsfähigkeit von SQL.
Wir haben einen FULL OUTER JOIN von Web-Tabellen mit Formularen data und CRM-Tabellen ON E-Mail oder Telefon durchgeführt. Vor- und Nachnamen sind nicht eindeutig und daher nicht zuverlässig.
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)
Es ist auch ratsam, eine Logik für den Abgleich der Punktzahl zu definieren, falls mehrere Formulare mit der gleichen E-Mail oder Telefonnummer eingereicht werden. Zum Beispiel haben die Webformulare, deren Vor- und Nachname mit dem Namen des CRM-Kunden übereinstimmen, eine höhere Priorität als die, die dies nicht tun.
Andere Tabellen mit profile_id anreichern
In diesem Abschnitt legen wir die endgültige profile_id fest, die für jeden identifizierten und nicht identifizierten Nutzer eindeutig ist.
Zusammengefasst: profile_id = COALESCE(crm_client_id, td_canonical_id).
Für Web-Tabellen werden crm_client_id per Web-Schlüssel(td_canonical_id) aus der in Schritt 2 erstellten Master-Tabelle bereitgestellt. Das heißt, wenn Benutzer ein Formular auf einer Website ausgefüllt und ihre E-Mail oder Telefonnummer angegeben haben, können wir sie in der CRM-Datenbank als bekannte Kunden identifizieren (falls sie bereits Kunden des Unternehmens sind). Infolgedessen können wir sagen, dass die Webseitenbesuche mit der gleichen Cookie-ID wie das eingereichte Webformular auch zu dem identifizierten CRM-Kunden gehören.
from web_page_visits t
left join master_table d
on t.td_kanonisch_id = d.td_kanonisch_id
und d.rn_web_key = 1
rn_web_key ist wie folgt definiert:
partition by td_kanonische_id
order by match_score,
time desc) as rn_web_key
Seine Aufgabe ist es, Duplikate in der Zieltabelle zu vermeiden, da alle Webtabellen Many-to-Many-Beziehungen haben. Außerdem wird crm_client_id mit dem Profil geteilt, das die beste Übereinstimmung zwischen offline und online data aufweist. Für jede td_canonical_id wird diejenige mit der höchsten Trefferquote genommen, und wenn die Trefferquote gleich ist, dann der neueste Eintrag.
Erstellen Sie die Tabelle audience , die Profile aus allen Tabellen enthält.
Nun, da alle Tabellen eine Profil-ID haben, ist es an der Zeit, ein Mastersegment zu erstellen. Das Master-Segment (Parent-Segment) ist eine Funktion von Treasure Data , die alle Informationen über den Benutzer vereinheitlicht, einschließlich der Interaktion des Benutzers mit der Website und dem Produkt. Es ermöglicht Geschäftsanalysten, Marketingfachleuten und anderen Benutzern, in Audience Studio alle identifizierten und nicht identifizierten Profile zu sehen und verschiedene Segmente mit ihnen zu erstellen, ohne irgendwelche SQL-Abfragen zu schreiben.
Um ein Mastersegment zu erstellen, benötigen wir eine Tabelle audience , die zur Verknüpfung aller Attribut- und Verhaltenstabellen verwendet wird. Das Ziel der Tabelle audience ist es, alle Profile zu haben - online und offline. Und sie wird nur die profile_id enthalten, da dies ausreichen sollte, um sie mit allen anderen Tabellen (crm_user_table, web_page_visits, web_form_submitted, web_product_detail) zu verbinden.
Die Implementierung ist so einfach wie die Vereinigung aller Tabellen, die profile_id enthalten, und die Deduplizierung aller profile_ids.