Auteur
In dit artikel lichten we de uitdagingen van ID-afstemming toe en laten we zien hoe wij te werk gaan om een uniforme profiel-ID te creëren in Data Customer Data , met name Treasure Data.
Data verzameld uit een offline Data en via online websitetracking.
Klantgegevens Data
Met Data Customer Data (CDP) kunnen bedrijven data verschillende bronnen op een uniforme en gecentraliseerde manier verzamelen, beheren en analyseren. Het doel van een CDP is om een uitgebreid en samenhangend beeld van elke klant te creëren door data meerdere contactpunten, zoals websites, mobiele apps, sociale media, e-mailcontacten en meer, samen te voegen.
Treasure Data
Treasure Data een cloud Customer Data . Hieronder volgen enkele veelvoorkomende zakelijke toepassingen van Treasure Data:
ID-afstemming
ID-afstemming is een proces waarbij data een persoon in verschillende systemen of databases worden vergeleken en op elkaar worden afgestemd om de nauwkeurigheid, consistentie en een uniform beeld van die persoon te waarborgen.
Dit is met name van belang in situaties waarin meerdere systemen of data informatie over dezelfde personen opslaan, maar de data onvolledig of inconsistent data zijn.
De uitdaging van het afstemmen van identiteitsgegevens
Het afstemmen van ID’s gaat gepaard met talrijke uitdagingen, met name bij omvangrijke datasets en uiteenlopende informatiebronnen. Deze uitdagingen omvatten onder meer inconsistente data , kwaliteitsproblemen die tot valse overeenkomsten leiden, en het beheer van dubbele records als gevolg van fouten of systeemwijzigingen. De grootste uitdaging is het ontbreken van een unieke ID die de gebruiker in alle verschillende informatiebronnen, tabellen en databases vertegenwoordigt.
Organisaties pakken deze uitdagingen aan door te investeren in geavanceerde data zoals Treasure Data.
Implementatie van ID-afstemming
We hebben voor een van onze klanten ID-afstemming geïmplementeerd met behulp van de Data functionaliteit Data Treasure Data . In dit artikel willen we onze aanpak en implementatielogica met u delen.
Uitgangspunt: in de CDP-databases waren tabellen beschikbaar met informatie over het gebruikerspad op de website, evenals klantgegevens uit de CRM-database (Customer Relationship Management) in data .
Het doel is om in elke CDP-tabel een unieke profiel-ID te hebben. Hierdoor kunnen we een master-segment aanmaken met een 360-gradenoverzicht van de klant en zijn klanttraject.
data online data : het aantal weergaven van webpagina’s, ingevulde formulieren op de website en andere websitespecifieke informatie, zoals gegevens van productpagina’s die in een aparte tabel zijn opgeslagen.
Offline data : data het data .
Overzicht van de stappen voor het aanmaken van een unieke profiel-ID:
Samenvoeging van webtabellen
Om data te consolideren, maken data gebruik van de Data van Treasure Data . Hiervoor moeten de brontabellen en de kolommen die moeten worden geconsolideerd, worden gedefinieerd in een configuratiebestand in YAML-formaat. Een stapsgewijze handleiding voor het implementeren van consolidatie in Treasure Data vinden in Data Treasure Data .
Hierdoor wordt in elke tabel die bij het samenvoegen wordt gebruikt een canonieke ID aangemaakt. Het doel van een canonieke ID is om een ID te creëren die elke webgebruiker vertegenwoordigt. Dit is nuttig bij data, waar het lastig is om gebruikerssessies te identificeren en data verschillende sessies samen te voegen.
We hebben bepaald dat de canonieke ID gebaseerd is op de volgende samenvoegingssleutels:
– naam: td_canonical_id
merge_by_keys: [e-mail, telefoonnummer, td_client_id] bron_tabellen: [web_form_submitted, web_product_detail, web_page_visits]
De volgorde van de samenvoegingssleutels bepaalt de prioriteit. De eerste samenvoegingssleutel identificeert alle data hetzelfde e-mailadres (e-mailadressen die zijn opgegeven in het via de website verzonden webformulier) als afkomstig van dezelfde gebruiker.
De tweede prioriteit is het telefoonnummer (ingevoerd door bezoekers op de website): data hetzelfde telefoonnummer worden ook herkend als afkomstig van dezelfde gebruiker. De derde prioriteit is td_client_id — First-Party . Het First-Party blijft binnen dezelfde domeinen behouden. Verschillende domeinen hebben een verschillend td_client_id. Het td_client_id verandert als de bezoeker van de website de cookies wist.
Het resultaat van de samenvoeging wordt in de onderstaande voorbeelden weergegeven.
Voorbeeld 1: Treasure Data deze drie invoergegevens als dezelfde gebruikers-ID (td_canonical_id) Data , omdat ze hetzelfde e-mailadres hebben. Verschillende telefoonnummers hebben geen invloed op het resultaat, omdat we hebben bepaald dat het e-mailadres voorrang heeft op het telefoonnummer:
Voorbeeld 2: wanneer er geen e-mailadres is opgegeven, staat hetzelfde telefoonnummer gelijk aan dezelfde gebruikers-ID (td_canonical_id):
Voorbeeld 3: wanneer er geen velden met een hogere prioriteit zijn gedefinieerd, wordt de ID van de first-party cookie gebruikt. Dezelfde td_client_id = dezelfde gebruikers-ID (td_canonical_id). Dergelijke niet-geïdentificeerde bezoekers zonder persoonlijk identificeerbare informatie (PII) komen vaak voor in tabellen met websitebezoekers. Td_client_id is niet volledig betrouwbaar omdat het kan veranderen na het wissen van cookies, maar bij gebrek aan data is het de beste optie die we hebben.
Als we ervan uitgaan dat alleen het invullen van een formulier op een website e-mailadressen en formuliergegevens bevat, wat gebeurt er dan met de tabellen waarin geen persoonsgegevens beschikbaar zijn, zoals bijvoorbeeld ` web_page_visits`? Laten we aannemen dat websitebezoeken alleen First-Party bevatten: `td_client_id`. In het eerste voorbeeld zal de tabel web_page_visits met die td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' en '567-tyu-ghj-234' de td_canonical_id = 'abcd1234' hebben. Aangezien in de tabel web_form_submitted al is gedefinieerd dat deze 3 cookie-ID's bij dezelfde gebruiker horen, zal web_page_visits op deze informatie vertrouwen bij gebrek aan e-mail of telefoonnummer.
Dezelfde redenering geldt voor andere data die geen data bevatten.
Maak een hoofdtabel waarin online en offline data worden samengevoegd
Nu data onderling data samengevoegd, is het tijd om online (web) en offline data samen te voegen. Met offline data bedoelen data data persoonsgegevens bevatten. Uit data online data halen data data e-mail, telefoonnummer) uit de tabel `web_form_submitted`.
In het ideale geval kunnen data een CRM-tabel toevoegen aan een YML-bestand voor gegevenssamenvoeging, maar we hebben een situatie gehad waarin de eisen van de klant voor het samenvoegen van online en offline data complexer data dan wat automatische samenvoeging kan bieden. Daarom maken we hier gebruik van de kracht van SQL.
We hebben een FULL OUTER JOIN uitgevoerd tussen de webtabellen met data uit ingevulde formulieren data de CRM-tabellen op basis van e-mailadres of telefoonnummer. Voor- en achternamen zijn niet uniek en daarom onbetrouwbaar.
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)
Het is ook raadzaam om een logica voor het toekennen van scores vast te stellen, voor het geval er meerdere formulieren worden ingediend met hetzelfde e-mailadres of telefoonnummer. Zo krijgen webformulieren waarbij de voor- en achternaam overeenkomen met de namen van klanten in het CRM-systeem voorrang boven formulieren waarbij dat niet het geval is.
Voeg de `profile_id` toe aan andere tabellen
In dit gedeelte definiëren we de definitieve profile_id die uniek is voor elke gebruiker, zowel geregistreerde als niet-geregistreerde.
Kortom: profile_id = COALESCE(crm_client_id, td_canonical_id).
Voor webtabellen wordt de crm_client_id per websleutel (td_canonical_id) uit de in stap 2 aangemaakte hoofdtabel verstrekt. Dit betekent dat als gebruikers een formulier op een website hebben ingevuld en daarbij hun e-mailadres of telefoonnummer hebben opgegeven, we hen in de CRM-database kunnen identificeren als bekende klanten (voor zover ze al klant zijn van de organisatie). Daardoor kunnen we stellen dat die webpagina-bezoeken met dezelfde cookie-ID als het ingediende webformulier ook behoren tot de geïdentificeerde CRM-klant.
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 is als volgt gedefinieerd:
partition by td_canonical_id
order by match_score,
time desc) as rn_web_key
De functie ervan is te voorkomen dat er dubbele records in de doeltabel ontstaan, aangezien alle webtabellen veel-op-veel-relaties hebben. Bovendien deelt deze tabel de crm_client_id met het profiel dat de beste overeenkomst vertoont tussen offline en online data. Voor elke td_canonical_id wordt de waarde met de hoogste overeenkomstscore gekozen; als de overeenkomstscores gelijk zijn, wordt de nieuwste vermelding gekozen.
Maak audience aan die de profielen uit alle tabellen bevat
Nu alle tabellen een profiel-id hebben, is het tijd om een Master Segment aan te maken. Een Master Segment (of Parent Segment) is een functie van Treasure Data alle informatie over de gebruiker samenbrengt, inclusief de interactie van de gebruiker met de website en het product. Hiermee kunnen bedrijfsanalisten, marketeers en andere gebruikers in Audience alle geïdentificeerde en niet-geïdentificeerde profielen bekijken en daaruit verschillende segmenten samenstellen zonder dat ze daarvoor SQL-query’s hoeven te schrijven.
Om een Master Segment aan te maken, hebben we een audience nodig waarmee alle attribuut- en gedragstabellen kunnen worden gekoppeld. Het doel van de audience is om alle profielen te bevatten – zowel online als offline. Deze tabel bevat alleen de profile_id, aangezien dat voldoende zou moeten zijn om deze met alle andere tabellen te koppelen (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
De implementatie is heel eenvoudig: het gaat om het samenvoegen van alle tabellen die een `profile_id` bevatten, en het verwijderen van dubbele `profile_ids`.
