Autor
In diesem Artikel erläutern wir die Herausforderungen bei der ID-Abstimmung und stellen unseren Ansatz zur Erstellung einer einheitlichen Profil-ID in Data Customer Data , insbesondere in Treasure Data, vor.
Data aus einem Offline Data und aus Online-Website-Tracking gewonnen.
Kundend Data
Eine Customer Data (CDP) ermöglicht es Unternehmen, data verschiedenen Quellen einheitlich und zentral zu erfassen, zu verwalten und zu analysieren. Das Ziel einer CDP besteht darin, ein umfassendes und ganzheitliches Bild jedes einzelnen Kunden zu erstellen, indem data verschiedenen Kontaktpunkten wie Websites, mobilen Apps, sozialen Medien, E-Mail-Interaktionen und weiteren Quellen zusammengeführt werden.
Treasure Data
Treasure Data eine cloud Data . Hier sind einige gängige Anwendungsfälle für Treasure Data:
ID-Abgleich
Die Identitätsabgleichung ist ein Prozess, bei dem data über verschiedene Systeme oder Datenbanken hinweg verglichen und abgeglichen werden, um die Richtigkeit, Konsistenz und eine einheitliche Sicht auf die betreffende Person sicherzustellen.
Dies ist besonders wichtig in Fällen, in denen mehrere Systeme oder data Informationen über dieselben Personen speichern, die data jedoch unvollständig oder inkonsistent sein data .
Die Herausforderung der Identitätsabgleichung
Die Identitätsabgleichung steht vor zahlreichen Herausforderungen, insbesondere bei umfangreichen Datensätzen und vielfältigen Informationsquellen. Zu diesen Herausforderungen zählen uneinheitliche data , Qualitätsprobleme, die zu falschen Übereinstimmungen führen, sowie die Verwaltung von Datensatzdopplungen, die durch Fehler oder Systemänderungen entstehen. Die größte Herausforderung ist das Fehlen einer eindeutigen Kennung, die den Nutzer über die verschiedenen Informationsquellen, Tabellen und Datenbanken hinweg identifiziert.
Unternehmen begegnen diesen Herausforderungen, indem sie in fortschrittliche data wie Treasure Data investieren.
Implementierung der Identitätsabgleichung
Wir haben für einen unserer Kunden eine ID-Abstimmung mithilfe der Data von Treasure Data implementiert. In diesem Artikel möchten wir unseren Ansatz und die Implementierungslogik vorstellen.
Gegebene Rahmenbedingungen: In den CDP-Datenbanken standen Tabellen mit Informationen zur Nutzerführung auf der Website sowie Kundeninformationen aus der CRM-Datenbank (Customer Relationship Management) im data zur Verfügung.
Das Ziel ist es, in jeder CDP-Tabelle eine eindeutige Profil-ID zu haben. Dies ermöglicht es uns, ein Master-Segment mit einer 360-Grad-Sicht auf den Kunden und seine Customer Journey zu erstellen.
data : Aufrufe von Webseiten, übermittelte Formulare auf der Website sowie weitere webspezifische Informationen, wie z. B. Details zu Produktseiten, die in einer separaten Tabelle gespeichert sind.
data : data dem data .
Übersicht über die Schritte zur Erstellung einer eindeutigen Profil-ID:
Vereinheitlichung von Webtabellen
Um data zu vereinheitlichen, werden data die Funktionen von Treasure Data nutzen. Dazu müssen die Quelltabellen und die Spalten, die vereinheitlicht werden sollen, in einer YAML-Konfiguration definiert werden. Eine Schritt-für-Schritt-Anleitung zur Implementierung von Unification in Treasure Data in Data .
Dadurch wird in jeder Tabelle, die für die Vereinheitlichung verwendet wird, eine kanonische ID erstellt. Das Ziel der kanonischen ID ist es, eine ID zu erstellen, die jeden Webnutzer repräsentiert. Dies ist besonders nützlich bei data, wo es schwierig ist, Nutzersitzungen zu identifizieren und data verschiedene Sitzungen data zu vereinheitlichen.
Wir haben festgelegt, dass die kanonische ID auf den folgenden Zusammenführungsschlü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 Abgleichschlüssel bestimmt die Priorität. Der erste Abgleichschlüssel ordnet alle data derselben E-Mail-Adresse (die im übermittelten Webformular auf der Website angegeben wurde) demselben Benutzer zu.
An zweiter Stelle steht die Telefonnummer (die von Besuchern auf der Website angegeben wird): data derselben Telefonnummer werden ebenfalls als von demselben Nutzer stammend identifiziert. An dritter Stelle steht die td_client_id – First-Party . Die First-Party bleibt über dieselben Domains hinweg bestehen. Unterschiedliche Domains haben unterschiedliche td_client_id-Werte. Die td_client_id ändert sich, wenn der Website-Besucher die cookies löscht.
Das Ergebnis der Vereinheitlichung ist in den folgenden Beispielen dargestellt.
Beispiel 1: Treasure Data diese drei Eingaben als dieselbe Benutzer-ID (td_canonical_id) Data , da sie dieselbe E-Mail-Adresse aufweisen. Unterschiedliche Telefonnummern haben keinen Einfluss auf das Ergebnis, da wir festgelegt haben, dass die E-Mail-Adresse Vorrang vor der Telefonnummer hat:
Beispiel 2: Wenn keine E-Mail-Adresse angegeben ist, entspricht dieselbe Telefonnummer derselben Benutzer-ID (td_canonical_id):
Beispiel 3: Wenn keine Felder mit höherer Priorität für den Abgleich definiert sind, wird die First-Party-Cookie-ID verwendet. Gleiche td_client_id = gleiche Benutzer-ID (td_canonical_id). Solche nicht identifizierten Besucher ohne personenbezogene Daten (PII) kommen in Besucherstatistiken von Websites häufig vor. Die td_client_id ist nicht vollständig zuverlässig, da sie sich nach dem Löschen der Cookies ändern kann, aber in Ermangelung von data ist sie die beste Möglichkeit, die wir haben.
Wenn wir davon ausgehen, dass nur das Absenden von Formularen auf einer Website E-Mail-Adressen und Formulardaten enthält, was geschieht dann mit den Tabellen, in denen keine personenbezogenen Daten vorliegen, beispielsweise „web_page_visits“? Nehmen wir an, dass Website-Besuche nur eine First-Party enthalten – „td_client_id“. Im ersten Beispiel hat die Tabelle „web_page_visits“ mit den td_client_id-Werten „asd-123-qwe-456“, „zxc-234-ert-345“ und „567-tyu-ghj-234“ die td_canonical_id = „abcd1234“. Da in der Tabelle „web_form_submitted“ bereits festgelegt ist, dass diese drei Cookie-IDs zum selben Benutzer gehören, stützt sich „web_page_visits“ auf diese Information, wenn keine E-Mail-Adresse oder Telefonnummer vorliegt.
Das Gleiche gilt für andere Web data , die keine personenbezogenen data enthalten.
Erstellen Sie eine Mastertabelle, die Online- und Offline data miteinander verknüpft
Nachdem data nun untereinander vereinheitlicht data , ist es an der Zeit, Online- (Web-) und data zusammenzuführen. Unter data verstehen data data personenbezogene Daten enthalten. Aus data werden data data personenbezogenen data E-Mail, Telefonnummer) aus der Tabelle „web_form_submitted“ heranziehen.
Im Idealfall können data eine CRM-Tabelle in eine YML-Datei zur Datenvereinheitlichung einfügen, doch in einem konkreten Fall data die Anforderungen des Kunden an die Vereinheitlichung von Online- und data komplexer, als dies durch eine automatische Vereinheitlichung möglich war. Daher greifen wir hier auf die Leistungsfähigkeit von SQL zurück.
Wir haben einen FULL OUTER JOIN der Webtabellen mit data aus den Formularübermittlungen data den CRM-Tabellen nach E-Mail-Adresse oder Telefonnummer 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 empfiehlt sich außerdem, eine Logik für die Übereinstimmungsbewertung festzulegen, falls mehrere Formulare mit derselben E-Mail-Adresse oder Telefonnummer eingereicht werden. So haben beispielsweise Webformulare, bei denen Vor- und Nachname mit den Namen der CRM-Kunden übereinstimmen, eine höhere Priorität als solche, bei denen dies nicht der Fall ist.
Andere Tabellen mit der Profil-ID ergänzen
In diesem Abschnitt definieren wir die endgültige „profile_id“, die für jeden Nutzer – ob identifiziert oder nicht – eindeutig ist.
Zusammenfassend lässt sich sagen: profile_id = COALESCE(crm_client_id, td_canonical_id).
Für Webtabellen wird die „crm_client_id“ pro Web-Schlüssel (td_canonical_id) aus der in Schritt 2 erstellten Mastertabelle bereitgestellt. Das bedeutet: Wenn Nutzer ein Formular auf einer Website absenden und dabei ihre E-Mail-Adresse oder Telefonnummer angeben, können wir sie in der CRM-Datenbank als bekannte Kunden identifizieren (sofern sie bereits Kunden des Unternehmens sind). Daraus folgt, dass auch jene Webseitenbesuche, die dieselbe Cookie-ID wie das übermittelte Webformular aufweisen, zu dem identifizierten CRM-Kunden gehören.
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 ist wie folgt definiert:
partition by td_canonical_id
order by match_score,
time desc) as rn_web_key
Seine Aufgabe besteht darin, Duplikate in der Zieltabelle zu vermeiden, da alle Webtabellen viele-zu-viele-Beziehungen aufweisen. Darüber hinaus teilt es sich die crm_client_id mit dem Profil, das die beste Übereinstimmung zwischen Offline- und data aufweist. Für jede td_canonical_id wird diejenige mit dem höchsten Übereinstimmungswert ausgewählt; bei gleichem Übereinstimmungswert wird der neueste Eintrag gewählt.
Erstelle audience , die die Profile aus allen Tabellen enthält
Da nun alle Tabellen über eine Profil-ID verfügen, ist es an der Zeit, ein Master-Segment zu erstellen. Das Master-Segment (übergeordnetes Segment) ist eine Funktion von Treasure Data alle Informationen zum Nutzer zusammenführt, einschließlich der Interaktionen des Nutzers mit der Website und dem Produkt. Es ermöglicht Business-Analysten, Marketingfachleuten und anderen Nutzern, in Audience alle identifizierten und nicht identifizierten Profile einzusehen und daraus verschiedene Segmente zu erstellen, ohne SQL-Abfragen schreiben zu müssen.
Um ein Master-Segment zu erstellen, benötigen wir eine audience , die zum Verknüpfen aller Attribut- und Verhaltenstabellen verwendet wird. Das Ziel der audience ist es, alle Profile – sowohl online als auch offline – zu erfassen. Sie enthält lediglich die „profile_id“, 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 Umsetzung ist so einfach wie die Vereinigung aller Tabellen, die „profile_id“ enthalten, und die Entfernung von Duplikaten aller „profile_ids“.
