Auteur
In dit artikel leggen we de uitdagingen van ID-conciliatie uit en demonstreren we onze aanpak om een eenduidig profiel-ID te maken in het Data platform van de klant,...
Data werd verzameld uit een offline Data Warehouse en online website tracking.
Klant Data Platform
Met het Customer Data Platform (CDP) kunnen bedrijven data van klanten uit verschillende bronnen op een uniforme en gecentraliseerde manier verzamelen, beheren en analyseren. De doel van een CDP is het creëren van een uitgebreid en samenhangend beeld van elke klant door het samenvoegen van data van meerdere aanrakingspunten, zoals websites, mobiele apps, sociale media, e-mailinteracties en meer.
Schat Data
Treasure Data is een cloud-gebaseerd platform voor klanten. Hier zijn enkele veelvoorkomende zakelijke gebruikssituaties voor Treasure Data:
ID afstemming
ID-reconciliatie is een proces waarbij data met betrekking tot een persoon vergeleken en gematcht wordt in verschillende systemen of data-bases 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 personen, maar de data kan onvolledig of inconsistent zijn.
De uitdaging van ID-verzoening
ID reconciliatie stuit op vele 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 systeemveranderingen. De belangrijkste uitdaging is het ontbreken van een unieke ID de gebruiker vertegenwoordigen bij de verschillende informatiebronnen, tabellen en data-bases.
Organisaties pakken deze uitdagingen aan door te investeren in geavanceerde data tools zoals Treasure Data.
Implementatie van ID-afstemming
Wij 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 met u delen.
Gegeven voorwaarden: in CDP databases waren er tabellen beschikbaar met informatie over het gebruikersgedrag op de website, evenals klantinformatie uit de CRM (Customer Relationship Management) database in data warehouse.
Het doel is om een unieke profielidentifier in elke CDP-tabel te hebben. Hierdoor kunnen we een Master Segment creëren met een 360-graden beeld van de klant en zijn reis.
Online data beschikbaar: weergaven op websitepagina's, formulierinzendingen op de website, andere website-specifieke informatie, zoals details van productpagina's die in de aparte tabel worden opgeslagen.
Offline data beschikbaar: CRM data van 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 mogelijkheden van de Treasure Data Unification-functionaliteit. 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 vindt u in Treasure Data documentatie.
Hierdoor wordt in elke tabel een canonieke ID aangemaakt die gebruikt wordt bij de unificatie. Het doel van canonieke ID is om een ID te creëren 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.
Wij hebben gedefinieerd dat de canonieke ID gebaseerd is op de volgende samenvoegsleutels:
- naam: td_canonical_id
samenvoegen_bij_sleutels: [email, phone, td_client_id]. bron_tabellen: [web_form_submitted, web_product_detail, web_page_visits]
De volgorde van de samenvoegsleutels bepaalt de prioriteit. De eerste samenvoegsleutel identificeert alle web data met dezelfde e-mail (e-mails in het webformulier op de website) als van dezelfde gebruiker.
Tweede prioriteit is telefoonnummer (ingediend door bezoekers op de website): data met hetzelfde telefoonnummer wordt ook geïdentificeerd als afkomstig van dezelfde gebruiker. Derde prioriteit is td_client_id - Eerste partij cookie-ID. De ID van het First-Party Cookie is persistent voor dezelfde domeinen. Verschillende domeinen zullen verschillende td_client_id hebben. Td_client_id verandert als de websitebezoeker de browser leegmaakt cookies.
Het resultaat van de unificatie wordt in de onderstaande voorbeelden getoond.
Voorbeeld 1: Schat Data definieerde deze 3 ingangen als dezelfde gebruikers-ID (td_canonical_id), omdat ze dezelfde e-mail. 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-mail is opgegeven, hetzelfde telefoonnummer staat voor dezelfde gebruikers-ID (td_canonical_id):
Voorbeeld 3: als overeenkomende velden met een hogere prioriteit niet gedefinieerd zijn, dan wordt cookie-ID van de eerste partij gebruikt. Hetzelfde td_client_id = dezelfde 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 het indienen van formulieren op een website e-mail en formulier bevat, wat gebeurt er dan met de tabellen waar geen PII beschikbaar is, bijvoorbeeld web_pagina_bezoeken? Laten we aannemen dat websitebezoeken alleen een First-Party Cookie ID hebben - td_client_id. In het eerste voorbeeld web_pagina_bezoeken tabel met die td_client_id ‘asd-123-qwe-456’, ‘zxc-234-ert-345’ en ‘567-tyu-ghj-234’ zal de td_canonical_id = ‘abcd1234’ hebben. Aangezien web_formulier_ingediend tabel heeft al gedefinieerd dat die 3 cookie-ids tot dezelfde gebruiker behoren, web_pagina_bezoeken zal op deze informatie vertrouwen bij afwezigheid van e-mail of telefoon.
Dezelfde logica geldt voor andere web data tabellen die geen PII data hebben.
Mastertabel maken die online en offline samenvoegt data
Nu web data onderling verenigd is, 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 voorwaarden van de klant voor het unificeren van online en offline data complexer waren dan automatische unificatie kan bieden. Daarom vertrouwen we hier op de kracht van SQL.
Wij hebben FULL OUTER JOIN uitgevoerd van webtabellen met formulierinvoer 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
FROM crm_user_table t
FULL OUTER JOIN web_form_submitted d
OP (t.email = d.email
OF t.phone = d.phone)
Het is ook aan te raden om een logica voor de matchingscore te definiëren, voor het geval er meerdere formulieren met hetzelfde e-mailadres of telefoonnummer worden ingediend. 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 crm_client_id worden geleverd per websleutel (td_canonieke_id) uit de stamtabel die in stap 2 is gemaakt. Dit betekent dat als gebruikers een formulier op een website hebben ingediend en zij een e-mailadres of telefoonnummer hebben opgegeven, wij hen in de CRM database kunnen identificeren als bekende klanten (als zij al klant zijn van het bedrijf). Als gevolg daarvan kunnen we zeggen dat de bezoeken aan webpagina's met dezelfde cookie-ID als het ingediende webformulier ook bij de geïdentificeerde CRM-klant horen.
uit web_pagina_bezoeken t
left join master_table d
on t.td_canonical_id = d.td_canonical_id
en d.rn_web_key = 1
rn_web_key is als volgt gedefinieerd:
partitie door td_canonical_id
gerangschikt op match_score,
tijd desc) 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 overeenkomst 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 een audience tabel die het profiel van alle tabellen bevat
Nu alle tabellen een profiel-id hebben, is het tijd om een Master Segment aan te maken. Mastersegment (Moedersegment) 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-query's 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 audience-tabel is om alle profielen te hebben - online en offline. En de tabel zal alleen profile_id bevatten, omdat dit genoeg zou moeten zijn om de tabel te koppelen aan 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.
