Autor
In diesem Artikel erläutern wir die Herausforderungen beim ID-Abgleich und stellen unseren Ansatz zur Erstellung einer einheitlichen Profil-ID in der Customer Data Platform vor, insbesondere...
Data wurde von einem Offline-Data-Lagerhaus und einer Online-Website erfasst.
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. Die Ziel eines CDP ist es, eine umfassende und zusammenhängende Sicht auf jeden Kunden zu erstellen, indem data von mehrere Berührungspunkte, wie Websites, mobile Anwendungen, soziale Medien, E-Mail-Interaktionen und mehr.
Schatz Data
Treasure Data ist eine cloud-basierte Data-Kundenplattform. Hier finden Sie einige gängige Anwendungsfälle für Treasure Data:
ID-Abstimmung
Der ID-Abgleich ist ein Prozess, bei dem data zu einer Person in verschiedenen Systemen oder data-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, aber die data unvollständig oder inkonsistent sein können.
Die Herausforderung des ID-Abgleichs
Der ID-Abgleich ist mit zahlreichen Herausforderungen verbunden, insbesondere bei umfangreichen data-Sä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 aufgrund von Fehlern oder Systemänderungen. Die größte Herausforderung ist das Fehlen einer eindeutigen ID die den Benutzer über die verschiedenen Informationsquellen, Tabellen und data-Datenbanken hinweg vertreten.
Unternehmen begegnen diesen Herausforderungen, indem sie in fortschrittliche data-Tools wie Treasure Data investieren.
Implementierung des ID-Abgleichs
Wir haben den ID-Abgleich für einen unserer Kunden mit Hilfe der Treasure Data Unification-Funktionalität implementiert. In diesem Artikel möchten wir Ihnen unseren Ansatz und unsere Implementierungslogik vorstellen.
Gegebene Bedingungen: in CDP databases gab es Tabellen mit Informationen über die User Journey auf der Website, sowie Kundeninformationen aus der CRM (Customer Relationship Management) database im data warehouse.
Das Ziel ist es, in jeder CDP-Tabelle einen eindeutigen Profilbezeichner zu haben. So können wir ein Mastersegment mit einer 360-Grad-Sicht auf den Kunden und seine Reise erstellen.
Online data verfügbar: Aufrufe von Webseiten, Formularübertragungen auf der Website, andere website-spezifische Informationen, wie z.B. Details zur 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 der Unification in Treasure Data finden Sie unter 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. Sie ist nützlich, wenn sie für Web data angewendet wird, wo es schwierig ist, Benutzersitzungen zu identifizieren und Web data über verschiedene Sitzungen hinweg zu vereinheitlichen.
Wir haben definiert, dass die kanonische ID auf den folgenden Merge-Schlüsseln basiert:
- Name: td_canonical_id
merge_by_keys: [email, phone, td_client_id] source_tables: [web_form_submitted, web_product_detail, web_page_visits]
Die Reihenfolge der Zusammenführungsschlüssel definiert die Priorität. Der erste Merge-Schlüssel identifiziert alle Web data mit demselben E-Mail (E-Mails, die im Webformular auf der Website angegeben wurden) als von ein und demselben Benutzer.
Zweite Priorität ist Rufnummer (von Besuchern der Website übermittelt): data mit der gleichen Telefonnummer wird ebenfalls als von demselben Benutzer stammend identifiziert. 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 sehen Sie in den folgenden Beispielen.
Beispiel 1: Treasure Data hat diese 3 Eingänge als dieselbe Benutzer-ID (td_canonical_id) definiert, da sie die gleiche E-Mail. Unterschiedliche Telefonnummern haben keinen Einfluss auf das Ergebnis, da wir festgelegt haben, dass E-Mails eine höhere Priorität als Telefonnummern haben:
Beispiel 2: wenn keine E-Mail angegeben wird, dasselbe Rufnummer steht für dieselbe Benutzer-ID (td_canonical_id):
Beispiel 3: wenn keine übereinstimmenden Felder mit höherer Priorität definiert sind, wird die Cookie-ID der ersten Partei verwendet. Dasselbe td_client_id = gleiche Benutzer-ID (td_canonical_id). Solche nicht identifizierten Besucher ohne persönliche Informationen (PII) sind in den Tabellen der Website-Besucher häufig zu finden. 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 dies die beste Möglichkeit, die wir haben.
Wenn wir davon ausgehen, dass nur das Einreichen von Formularen auf einer Website E-Mail und Formular enthält, was passiert dann mit den Tabellen, in denen keine PII verfügbar sind, zum Beispiel web_page_visits? Nehmen wir an, der Besuch einer Website hat nur die First-Party Cookie ID - td_client_id. Im ersten Beispiel web_page_visits Tabelle mit den td_client_id ‘asd-123-qwe-456’, ‘zxc-234-ert-345’ und ‘567-tyu-ghj-234’ wird die td_canonical_id = ‘abcd1234’ haben. Da web_form_submitted hat bereits festgelegt, dass diese 3 Cookie-IDs zum selben Benutzer gehören, web_page_visits wird sich auf diese Informationen verlassen, wenn Sie nicht per E-Mail oder Telefon erreichbar sind.
Die gleiche Logik gilt für andere Web data-Tabellen, die keine PII data haben.
Erstellen Sie eine Master-Tabelle, die Online und Offline zusammenführt data
Jetzt, wo die Web-data untereinander vereinheitlicht sind, ist es an der Zeit, Online- (Web) und Offline-data zu vereinheitlichen. Mit offline data meinen wir CRM data, das PII enthält. Aus dem Online data werden wir die PII data (E-Mail, Telefon) in der Tabelle web_form_submitted verwenden.
Im Idealfall können data-Ingenieure eine CRM-Tabelle in eine yml-Datei für die Vereinheitlichung einfügen, aber wir hatten einen Fall, in dem die Bedingungen des Kunden für die Vereinheitlichung von Online- und Offline-data komplexer waren, als es die automatische Vereinheitlichung leisten kann. Daher verlassen wir uns hier auf die Leistungsfähigkeit von SQL.
Wir haben einen FULL OUTER JOIN der Web-Tabellen mit der Formularübermittlung data und der 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. So haben z.B. die Webformulare, deren Vor- und Nachname mit dem Namen des CRM-Kunden übereinstimmen, eine höhere Priorität als diejenigen, bei denen dies nicht der Fall ist.
Andere Tabellen mit profile_id anreichern
In diesem Abschnitt definieren wir die endgültige profile_id, die für jeden identifizierten und nicht identifizierten Benutzer eindeutig ist.
Zusammengefasst, profile_id = COALESCE(crm_client_id, td_canonical_id).
Für Web-Tabellen crm_client_id werden pro Webschlüssel bereitgestellt (td_canonical_id) aus der in Schritt 2 erstellten Stammtabelle. Das heißt, wenn ein Benutzer ein Formular auf einer Website ausgefüllt und seine E-Mail-Adresse oder Telefonnummer angegeben hat, können wir ihn in der CRM data-Datenbank als bekannten Kunden identifizieren (falls er bereits Kunde des Unternehmens ist). Folglich können wir sagen, dass die Webseitenbesuche mit der gleichen Cookie-ID wie das eingereichte Webformular auch zu dem identifizierten CRM-Kunden gehören.
von web_page_visits t
left join master_table d
on t.td_canonical_id = d.td_canonical_id
und d.rn_web_key = 1
rn_web_key ist wie folgt definiert:
partition by td_canonical_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 teilt sie crm_client_id mit dem Profil, 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. Master-Segment (übergeordnetes Segment) ist eine Funktion von Treasure Data, die alle Informationen über den Benutzer zusammenfasst, einschließlich der Benutzerinteraktion mit der Website und dem Produkt. Sie ermöglicht es Business-Analysten, Marketingfachleuten und anderen Benutzern, in Audience Studio alle identifizierten und nicht identifizierten Profile zu sehen und mit ihnen verschiedene Segmente zu erstellen, ohne SQL-Abfragen schreiben zu müssen.
Um ein Mastersegment zu erstellen, benötigen wir eine audience-Tabelle, die zur Verbindung 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 verknüpfen.
Die Implementierung ist so einfach wie die Vereinigung aller Tabellen, die profile_id enthalten, und die Deduplizierung aller profile_ids.
