Autore
In questo articolo spieghiamo le sfide della riconciliazione degli ID e dimostriamo il nostro approccio per creare un ID profilo unificato nella Customer Data Platform, in particolare in Treasure Data.
I dati sono stati raccolti da un Data Warehouse offline e dal monitoraggio online del sito web.
Piattaforma dati clienti
La Customer Data Platform (CDP) consente alle aziende di raccogliere, gestire e analizzare i dati dei clienti provenienti da varie fonti in modo unificato e centralizzato. L'obiettivo di una CDP è creare una visione completa e coesa di ciascun cliente aggregando i dati provenienti da più punti di contatto, come siti web, applicazioni mobili, social media, interazioni via e-mail e altro ancora.
Dati del tesoro
Treasure Data è una piattaforma di dati sui clienti basata sul cloud. Ecco alcuni casi d'uso comuni per Treasure Data:
Riconciliazione ID
La riconciliazione dei documenti d'identità è un processo in cui i dati relativi a una persona vengono confrontati e abbinati tra diversi sistemi o database per garantire l'accuratezza, la coerenza e una visione unificata della persona stessa.
Ciò è particolarmente importante negli scenari in cui più sistemi o fonti di dati memorizzano informazioni sugli stessi individui, ma i dati possono essere incompleti o incoerenti.
La sfida della riconciliazione dei documenti d'identità
La riconciliazione dei documenti d'identità si scontra con numerose sfide, soprattutto con set di dati estesi e fonti di informazioni diverse. Queste sfide includono formati di dati incoerenti, problemi di qualità che portano a false corrispondenze e la gestione di record duplicati dovuti a errori o a modifiche del sistema. La sfida principale è la mancanza di un ID univoco che rappresenti l'utente tra le diverse fonti di informazioni, tabelle e database.
Le organizzazioni affrontano queste sfide investendo in strumenti di dati avanzati come Treasure Data.
Implementazione della riconciliazione ID
Abbiamo implementato la riconciliazione degli ID per uno dei nostri clienti utilizzando la funzionalità di unificazione dei dati di Treasure. In questo articolo vogliamo condividere il nostro approccio e la logica di implementazione.
Condizioni date: nei database CDP erano disponibili tabelle con informazioni sul percorso dell'utente sul sito web, nonché informazioni sui clienti provenienti dal database CRM (Customer Relationship Management) nel data warehouse.
L'obiettivo è avere un identificatore di profilo unico in ogni tabella CDP. Questo ci permetterà di creare un segmento master con una visione a 360 gradi del cliente e del suo percorso.
Dati online disponibili: visualizzazioni delle pagine del sito web, invio di moduli sul sito web, altre informazioni specifiche del sito web, come i dettagli della pagina del prodotto che sono memorizzati in una tabella separata.
Dati offline disponibili: Dati CRM dal data warehouse.
Panoramica dei passaggi per creare un ID profilo univoco:
Unificazione delle tabelle web
Per unificare i dati web si sfrutterà la funzionalità di unificazione dei dati di Treasure. È necessario definire le tabelle di origine e le colonne che devono essere unificate in una configurazione in formato YAML. La guida passo-passo su come implementare l'unificazione in Treasure Data si trova nella Documentazione di Treasure Data.
Di conseguenza, crea un ID canonico in ogni tabella che viene utilizzato per l'unificazione. L'obiettivo dell'ID canonico è creare un ID che rappresenti ogni utente web. È utile quando si applica ai dati web, dove è difficile identificare le sessioni degli utenti e unificare i dati web tra le diverse sessioni.
Abbiamo definito che l'ID canonico si basa sulle seguenti chiavi di fusione:
- nome: td_canonical_id
chiavi_di_fusione: [email, telefono, td_client_id]. tabelle_fonte: [web_form_submitted, web_product_detail, web_page_visits].
L'ordine delle chiavi di fusione definisce la priorità. La prima chiave di fusione identifica tutti i dati web con la stessa e-mail (e-mail fornita nel modulo web inviato nel sito web) come provenienti dallo stesso utente.
La seconda priorità è il numero di telefono (inviato dai visitatori del sito web): i dati con lo stesso numero di telefono vengono identificati come provenienti dallo stesso utente. La terza priorità è td_client_id - ID del cookie di prima parte. L'ID del cookie di prima parte è persistente tra gli stessi domini. Domini diversi avranno td_client_id diversi. Il td_client_id cambia se il visitatore del sito web cancella il browser cookies.
Il risultato dell'unificazione è mostrato negli esempi seguenti.
Esempio 1: Treasure Data ha definito questi 3 input come lo stesso ID utente (td_canonical_id), poiché hanno la stessa email. Numeri di telefono diversi non influiscono sul risultato perché abbiamo definito che l'email ha una priorità maggiore del numero di telefono:
Esempio 2: quando l'e-mail non viene fornita, lo stesso numero di telefono rappresenta lo stesso ID utente (td_canonical_id):
Esempio 3: quando non sono definiti campi di corrispondenza a priorità più alta, viene utilizzato l'ID cookie della prima parte. Stesso td_client_id = stesso ID utente (td_canonical_id). Questi visitatori non identificati senza informazioni personali identificabili (PII) sono comuni nelle tabelle dei visitatori dei siti web. Il td_client_id non è del tutto affidabile, poiché può cambiare dopo la cancellazione dei cookie, ma in assenza di dati PII è la soluzione migliore che abbiamo.
Se ipotizziamo che solo l'invio di un modulo su un sito web contenga e-mail e modulo, cosa succede alle tabelle in cui non sono disponibili PII, ad esempio web_page_visits? Supponiamo che le visite al sito web abbiano solo l'ID del cookie di prima parte - td_client_id. Nel primo esempio, la tabella web_page_visits con i td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' e '567-tyu-ghj-234' avrà il td_canonical_id = 'abcd1234'. Poiché la tabella web_form_submitted ha già definito che questi 3 id cookie appartengono allo stesso utente, web_page_visits si baserà su questa informazione in assenza di e-mail o telefono.
La stessa logica si applica ad altre tabelle di dati web che non contengono dati PII.
Creare una tabella master che unisca i dati online e offline
Ora che i dati web sono unificati tra loro, è il momento di unificare i dati online (web) e offline. Per dati offline intendiamo i dati del CRM che contengono PII. Dai dati online utilizzeremo i dati PII (e-mail, telefono) nella tabella web_form_submitted.
In un caso ideale, gli ingegneri dei dati possono aggiungere una tabella CRM in un file yml di unificazione, ma abbiamo avuto un caso in cui le condizioni del cliente per unificare i dati online e offline erano più complesse di quelle che l'unificazione automatica può fornire. Per questo ci affidiamo alla potenza di SQL.
Abbiamo eseguito una FULL OUTER JOIN tra le tabelle Web con i dati di invio dei moduli e le tabelle CRM su e-mail o telefono. I nomi e i cognomi non sono univoci e quindi non sono affidabili.
SELEZIONARE 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
O t.phone = d.phone)
Si consiglia inoltre di definire una logica per il punteggio di corrispondenza, nel caso in cui vengano inviati più moduli con lo stesso indirizzo e-mail o numero di telefono. Ad esempio, i moduli web il cui nome e cognome sono abbinati ai nomi dei clienti del CRM hanno una priorità maggiore rispetto a quelli che non lo sono.
Arricchire altre tabelle con profile_id
In questa sezione si definisce il profile_id finale che è unico per ogni utente, identificato e non identificato.
In sintesi, profile_id = COALESCE(crm_client_id, td_canonical_id).
Per le tabelle web i crm_client_id sono forniti per chiave web(td_canonical_id) dalla tabella master creata al punto 2. In altre parole, se gli utenti hanno inviato un modulo su un sito web e hanno fornito l'e-mail o il telefono, possiamo identificarli nel database del CRM come clienti noti (nel caso in cui siano già clienti dell'azienda). Di conseguenza, possiamo dire che le visite alle pagine web con lo stesso ID cookie del modulo web inviato appartengono anche al cliente CRM identificato.
da visite_pagina_web t
join sinistro a master_table d
su t.td_canonical_id = d.td_canonical_id
e d.rn_web_key = 1
rn_web_key è definita come segue:
partizione per td_canonical_id
per match_score,
time desc) come rn_web_key
Il suo ruolo è quello di evitare di creare duplicati nella tabella di destinazione, poiché tutte le tabelle web hanno relazioni molti-a-molti. Inoltre, condivide crm_client_id con il profilo che ha la migliore corrispondenza tra i dati offline e online. Per ogni td_canonical_id prende quello con il punteggio di corrispondenza più alto e, nel caso in cui il punteggio di corrispondenza sia lo stesso, la voce più recente.
Creare una tabella del pubblico che contenga i profili di tutte le tabelle
Ora che tutte le tabelle hanno un id profilo, è il momento di creare un Master Segment. Il Master Segment (Parent Segment) è una funzione di Treasure Data che unifica tutte le informazioni relative all'utente, compresa l'interazione dell'utente con il sito web e il prodotto. Consente agli analisti aziendali, ai marketer e ad altri utenti di vedere in Audience Studio tutti i profili identificati e non identificati e di creare vari segmenti con essi senza scrivere alcuna query SQL.
Per creare un segmento master è necessario disporre di una tabella del pubblico che verrà utilizzata per unire tutte le tabelle degli attributi e dei comportamenti. L'obiettivo della tabella audience è quello di avere tutti i profili - online e offline. La tabella conterrà solo l'ID profilo, che dovrebbe essere sufficiente per unirla a tutte le altre tabelle (tabella_utenti, pagine_visite, moduli_inviati, dettagli_prodotto).
L'implementazione è semplice: unione di tutte le tabelle che contengono profile_id e deduplicazione di tutti i profile_id.
