In dit artikel leggen we de uitdagingen van ID-reconciliatie uit en demonstreren we onze aanpak om een eenduidig profiel-ID te maken in het Customer Data Platform, met name Treasure Data.
Data werd verzameld via een offline Data Warehouse en online website tracking.
Platform voor klanten Data
Customer Data Platform (CDP) stelt bedrijven in staat om data van klanten uit verschillende bronnen op een uniforme en gecentraliseerde manier te verzamelen, beheren en analyseren. Het doel van een CDP is om een allesomvattend en samenhangend beeld van elke klant te creëren door data van meerdere touchpoints te verzamelen, zoals websites, mobiele apps, sociale media, e-mailinteracties en meer.
Schat Data
Treasure Data is een cloud-gebaseerd Customer Data Platform. Hier zijn enkele veelvoorkomende zakelijke use cases voor Treasure Data:
ID afstemming
ID-reconciliatie is een proces waarbij data met betrekking tot een persoon wordt vergeleken en gematcht in verschillende systemen of databases om nauwkeurigheid, consistentie en een eenduidig beeld van die persoon te garanderen.
Dit is vooral belangrijk in scenario's waar meerdere systemen of data bronnen informatie opslaan over dezelfde individuen, maar de data kan onvolledig of inconsistent zijn.
De uitdaging van ID-verzoening
ID-reconciliatie stuit op tal van uitdagingen, vooral met uitgebreide datasets en diverse informatiebronnen. Deze uitdagingen omvatten inconsistente data formaten, kwaliteitsproblemen die leiden tot valse matches en het beheer van dubbele records als gevolg van fouten of systeemwijzigingen. De belangrijkste uitdaging is het ontbreken van een unieke ID die de gebruiker vertegenwoordigt in de verschillende informatiebronnen, tabellen en databases.
Organisaties pakken deze uitdagingen aan door te investeren in geavanceerde data tools zoals Treasure Data.
Implementatie van ID-afstemming
We hebben ID-reconciliatie geïmplementeerd voor een van onze klanten met behulp van de Treasure Data Unification-functionaliteit. In dit artikel willen we onze aanpak en implementatielogica delen.
Gegeven omstandigheden: in CDP-databases waren tabellen beschikbaar met informatie over het traject van de gebruiker op de website, evenals klantinformatie uit de CRM-database (Customer Relationship Management) in data warehouse.
Het doel is om in elke CDP-tabel een unieke profielidentifier te hebben. Hierdoor kunnen we een Master Segment maken met een 360 graden beeld van de klant en zijn reis.
Online data beschikbaar: weergaven op websitepagina's, formulierinzendingen op de website, andere websitespecifieke informatie, zoals details van productpagina's die worden opgeslagen in de aparte tabel.
Offline data beschikbaar: CRM data uit het magazijn data .
Overzicht van stappen om een unieke profiel-ID te maken:
Unificatie van webtabellen
Om web data te unificeren, maken we gebruik van de functionaliteit van Treasure Data Unification. Hiervoor moeten de brontabellen en de kolommen die moeten worden verenigd, worden gedefinieerd in een YAML-geformatteerde configuratie. De stapsgewijze handleiding voor het implementeren van Unification in Treasure Data is te vinden in de Treasure Data Documentatie.
Hierdoor wordt in elke tabel een canonieke ID gecreëerd die wordt gebruikt bij het verenigen. Het doel van canonieke ID is om een ID te maken die elke webgebruiker vertegenwoordigt. Het is nuttig wanneer het wordt toegepast op web data, waar het een uitdaging is om gebruikerssessies te identificeren en web data te unificeren over verschillende sessies.
We hebben gedefinieerd dat de canonieke ID gebaseerd is op de volgende samenvoegsleutels:
- naam: td_canonical_id
samenvoegen_bij_sleutels: [email, telefoon, td_client_id]. bron_tabellen: [web_formulier_ingediend, web_product_detail, web_pagina_bezoeken]
De volgorde van de samenvoegsleutels bepaalt de prioriteit. De eerste samenvoegsleutel identificeert alle web data met hetzelfde e-mailadres (e-mails in het webformulier op de website) als van dezelfde gebruiker.
Tweede prioriteit is telefoonnummer (opgegeven door bezoekers op de website): data met hetzelfde telefoonnummer wordt ook geïdentificeerd als van dezelfde gebruiker. De derde prioriteit is td_client_id - de cookie-ID van de eerste partij. De cookie-ID van de eerste partij is persistent voor dezelfde domeinen. Verschillende domeinen zullen verschillende td_client_id hebben. Td_client_id verandert als de websitebezoeker de browser cookies leegmaakt.
Het resultaat van de unificatie wordt getoond in de onderstaande voorbeelden.
Voorbeeld 1: Treasure Data definieerde deze 3 ingangen als dezelfde gebruikers-ID (td_canonical_id), omdat ze hetzelfde e-mailadres hebben. Verschillende telefoonnummers hebben geen invloed op het resultaat omdat we hebben gedefinieerd dat e-mail een hogere prioriteit heeft dan telefoonnummer:
Voorbeeld 2: als er geen e-mailadres is opgegeven, staat hetzelfde telefoonnummer voor dezelfde gebruikers-ID (td_canonical_id):
Voorbeeld 3: als overeenkomende velden met een hogere prioriteit niet zijn gedefinieerd, wordt cookie-ID van de eerste partij gebruikt. Zelfde td_client_id = zelfde gebruikers-ID (td_canonical_id). Dergelijke niet-geïdentificeerde bezoekers zonder enige persoonlijk identificeerbare informatie (PII) komen vaak voor in websitebezoekerstabellen. Td_client_id is niet volledig betrouwbaar omdat het kan veranderen na het wissen van cookies, maar bij afwezigheid van PII data is het de beste kans die we hebben.
Als we aannemen dat alleen formulierverzending op een website e-mail en formulier bevat, wat gebeurt er dan met de tabellen waar geen PII beschikbaar is, bijvoorbeeld web_page_visits? Laten we aannemen dat websitebezoeken alleen een First-Party Cookie ID hebben - td_client_id. In het eerste voorbeeld heeft de tabel web_page_visits met de td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' en '567-tyu-ghj-234' de td_canonical_id = 'abcd1234'. Aangezien de tabel web_form_submitted al heeft gedefinieerd dat deze 3 cookie-id's bij dezelfde gebruiker horen, zal web_page_visits op deze informatie vertrouwen bij afwezigheid van e-mail of telefoon.
Dezelfde logica geldt voor andere web data tabellen die geen PII hebben data.
Mastertabel maken die online en offline samenvoegt data
Nu web data onderling is verenigd, is het tijd om online (web) en offline data te verenigen. Met offline data bedoelen we CRM data dat PII bevat. Van online data maken we gebruik van PII data (e-mail, telefoon) in de tabel web_form_submitted.
In het ideale geval kunnen data engineers een CRM-tabel toevoegen aan een unificatie yml-bestand, maar we hadden een geval waarin de voorwaarde van de klant om online en offline data te unificeren complexer was dan automatische unificatie kan bieden. Daarom vertrouwen we hier op de kracht van SQL.
We hebben een FULL OUTER JOIN uitgevoerd van webtabellen met aanmeldingsformulieren data en CRM-tabellen op e-mail of telefoon. Voor- en achternamen zijn niet uniek en daarom niet betrouwbaar.
SELECT t.crm_client_id, d.td_canonical_id
VAN crm_user_table t
VOLLEDIG UITVOER JOIN web_formulier_verzonden d
ON (t.email = d.email
OR t.phone = d.phone)
Het is ook aan te raden om een logica te definiëren voor de matchingscore, voor het geval er meerdere formulieren worden ingediend met hetzelfde e-mailadres of telefoonnummer. Bijvoorbeeld, de webformulieren waarvan de voor- en achternaam overeenkomen met de namen van CRM-klanten hebben een hogere prioriteit dan de formulieren waarbij dit niet het geval is.
Andere tabellen verrijken met profile_id
In dit gedeelte definiëren we het uiteindelijke profiel_id dat uniek is voor elke gebruiker, geïdentificeerd en ongeïdentificeerd.
Samengevat, profile_id = COALESCE(crm_client_id, td_canonical_id).
Voor webtabellen wordt crm_client_id verstrekt per websleutel(td_canonical_id) uit de mastertabel die in stap 2 is gemaakt. Dit betekent dat als gebruikers een formulier op een website hebben ingediend en een e-mailadres of telefoonnummer hebben opgegeven, we ze in de CRM-database kunnen identificeren als bekende klanten (als ze al klant zijn bij organisatie). Als gevolg daarvan kunnen we zeggen dat de bezoeken aan webpagina's met dezelfde cookie-ID als het ingediende webformulier ook behoren tot de geïdentificeerde CRM-klant.
uit web_pagina_bezoeken t
links bij master_table d
op t.td_canonical_id = d.td_canonical_id
en d.rn_web_key = 1
rn_web_key is als volgt gedefinieerd:
partitie door td_canonieke_id
order by match_score,
tijd aflopend) als rn_web_key
De rol hiervan is om duplicaten in de bestemmingstabel te voorkomen, aangezien alle webtabellen veel-op-veel relaties hebben. Bovendien deelt het crm_client_id met het profiel dat de beste match heeft tussen offline en online data. Voor elke td_canonical_id wordt die met de hoogste matchscore genomen, en als de matchscore hetzelfde is, dan de nieuwste vermelding.
Maak de tabel audience aan die het profiel van alle tabellen bevat
Nu alle tabellen een profiel-id hebben, is het tijd om een Master Segment aan te maken. Master Segment (Parent Segment) is een functie van Treasure Data die alle informatie over de gebruiker samenbrengt, inclusief de interactie van de gebruiker met de website en het product. Het stelt Business Analisten, Marketeers en andere gebruikers in staat om in Audience Studio alle geïdentificeerde en niet-geïdentificeerde profielen te zien en er verschillende segmenten mee te maken zonder SQL-queries te hoeven schrijven.
Om een Master Segment te maken, hebben we een audience tabel nodig die gebruikt zal worden om alle attribuut- en gedragstabellen samen te voegen. Het doel van de tabel audience is om alle profielen te hebben - online en offline. En het zal alleen profile_id bevatten, omdat het genoeg moet zijn om het te verbinden met alle andere tabellen (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
De implementatie is zo eenvoudig als het samenvoegen van alle tabellen die profile_id bevatten en het ontdubbelen van alle profile_ids.