CDP e identity resolution

Il problema: una persona, quattro righe in quattro tabelle

Questa lezione si muove sul binario tabellare: la CDP è un ciclo di tabelle — eventi normalizzati, legami tra identificatori, profili unificati, audience versionate — e ogni passaggio si giudica con metriche di tabella. L’obiettivo è capire come una Customer Data Platform raccoglie eventi, risolve le identità in un profilo unificato e attiva audience misurate con holdout.

Un utente scopre un prodotto da mobile su Instagram, torna sul sito da desktop una settimana dopo, apre la newsletter da un indirizzo diverso e compra dall’app dopo aver fatto login. Per il marketing sono quattro righe in quattro tabelle diverse; per l’azienda è una sola persona con un solo budget di attenzione. Se la Customer Data Platform non ricuce questi frammenti, ogni canale racconta una storia parziale: il retargeting insegue chi ha già comprato, l’email di benvenuto arriva a un cliente da due anni, l’attribuzione premia l’ultimo click perché è l’unico che sa collegare a un nome. Se invece ricuce troppo, fonde due coinquilini che condividono IP e dispositivo in un unico “super-cliente” e da lì in poi ogni lookalike, ogni frequenza, ogni fatturato per utente è sbagliato in modo silenzioso.

L’identity resolution è il punto in cui questa tensione diventa ingegneria: decidere quali segnali bastano per dire “questi due eventi appartengono alla stessa persona”, con quale confidenza, e cosa farci dopo. Non è un problema di volume. È un problema di decisione. Ogni regola di match sposta soldi: tra prospect e cliente, tra audience soppressa e audience colpita, tra un test di incrementalità pulito e uno contaminato.

La sequenza di lavoro in sette passi

Ecco l’ordine con cui si costruisce un impianto di identity resolution che regge:

1. Normalizza eventi, timestamp in UTC e stati di consenso prima di risolvere qualsiasi identità.
2. Lega gli identificatori con match deterministico su chiavi verificate come spina dorsale del grafo.
3. Relega il probabilistico a candidati da confermare, con soglia dichiarata per uso e scadenza da 30 a 90 giorni.
4. Registra per ogni fusione regola, versione, confidenza ed evidenze in una tabella di audit.
5. Definisci ogni audience come codice versionato con finestra temporale e soppressioni incluse.
6. Sincronizza solo i delta filtrati per consenso, alla latenza che l’economia del caso giustifica.
7. Misura match rate scomposto, stabilità degli ID nel tempo e lift contro un holdout del 10%.

Perché un cliente sembra tre persone diverse

La frammentazione non è un bug, è l’architettura del web. Ogni contesto genera il suo identificatore con il suo ciclo di vita: anonymous_id del tracker web, device_id dell’app, cookie di terze parti che muoiono dopo sette giorni su Safari, member_id dopo il login, email hashata nella newsletter, ID dello shop quando l’acquisto avviene da ospite. A questi si aggiungono gli ID delle piattaforme — Meta, Google, TikTok — che per motivi di privacy non restituiscono mai la chiave grezza, solo un aggregato o un match oscurato.

Prendi un caso concreto. Un retailer con 400.000 visite mensili e 25.000 ordini: il 70% del traffico è anonimo, il 30% autenticato. Senza risoluzione, il tasso di conversione per utente è calcolato su una base gonfiata — gli stessi individui contati due o tre volte — e risulta artificialmente basso, diciamo 1,1% invece del 2,4% reale su persone unificate. Il team media legge “il sito non converte” e alza il budget di acquisizione, quando il problema è il denominatore, non la creatività.

Il primo lavoro della CDP è quindi normalizzare gli eventi in un flusso unico: ogni riga ha un timestamp, un tipo di evento, un insieme di identificatori osservati e il contesto di consenso. Solo dopo viene la domanda “chi è?”, mai prima. Chi prova a risolvere l’identità prima di aver pulito timestamp, fusi e consenso costruisce un grafo preciso sopra fondamenta storte.

Come funziona davvero una Customer Data Platform

Il nome confonde: la CDP non è un database né un tool di invio. È un ciclo chiuso in quattro fasi — raccogliere, risolvere, segmentare, attivare — con un vincolo trasversale che le attraversa tutte: il consenso.

La raccolta avviene via SDK web e mobile, API server-side, import batch da CRM ed e-commerce, webhook. Ogni evento porta con sé almeno un identificatore e il contesto: pagina, campagna, prodotto, valore. Una buona strumentazione distingue tre tipi di evento che molti team mescolano: identificazione (identify con email o login), comportamento (track con azione e proprietà) e stato (profile update con attributi lenti come taglia o segmento RFM). Mescolarli significa non sapere più se “taglia M” è qualcosa che l’utente ha fatto o qualcosa che l’utente è.

La risoluzione lega gli identificatori a un unified_customer_id stabile. La segmentazione definisce audience come query versionate sul profilo unificato (“donne 25-34, hanno visto il prodotto X negli ultimi 14 giorni, nessun acquisto negli ultimi 90”). L’attivazione sincronizza quelle audience verso le destinazioni — Meta Custom Audiences, Google Customer Match, ESP, call center — con la frequenza e la latenza giuste per il caso d’uso.

La latenza decide l’architettura. Un abbandono carrello da recuperare via email può aspettare quindici minuti; una personalizzazione on-site deve rispondere in meno di 200 millisecondi; una lookalike su Meta si aggiorna una volta al giorno e tollera ore di ritardo. Chi pretende “tutto in real time” paga complessità di streaming per casi d’uso che non la richiedono. Una regola pratica: batch giornaliero per prospecting e reporting, micro-batch da 5-15 minuti per lifecycle email e SMS, streaming solo dove il ritardo costa soldi misurabili.

Il consenso non è un flag decorativo. Ogni profilo unificato deve sapere, per ogni finalità, se può essere usato per analytics, personalizzazione, advertising. Quando due identificatori si fondono, le rispettive basi giuridiche non si sommano automaticamente: vale la più restrittiva, e la revoca su un canale deve propagarsi alle audience già sincronizzate. Le CDP serie implementano questo come soppressione automatica verso le destinazioni; quelle improvvisate lasciano email revocate dentro Custom Audiences vecchie di mesi.

Deterministico contro probabilistico: dove sta il confine

L’identity resolution usa due famiglie di tecniche con garanzie opposte, e il mestiere sta nel non confonderle.

Il matching deterministico lavora su identificatori verificati: login, email normalizzata e hashata, numero di telefono, tessera fedeltà, ID ordine legato a un pagamento. Se due eventi condividono lo stesso hash email normalizzato (minuscolo, senza spazi, senza alias con +), la probabilità che siano persone diverse è trascurabile — sopra il 99% in dataset puliti. È la spina dorsale del grafo: pochi match, quasi tutti giusti. Il suo limite è la copertura: nella maggior parte degli e-commerce solo il 15-35% del traffico è autenticato, quindi il deterministico da solo lascia fuori la maggioranza dei touchpoint.

Il matching probabilistico lavora su segnali deboli — IP, user agent, fingerprint del dispositivo, orari e pattern di navigazione — e restituisce una probabilità, non un verdetto. Un modello tipico combina questi segnali in uno score $s \in [0, 1]$ e fonde sopra una soglia $\tau$:

$\text{match}(a, b) = 1 \iff P(\text{stessa persona} \mid \text{segnali}) > \tau$

Alzare $\tau$ aumenta la precisione ma riduce il richiamo; abbassarlo fa l’opposto. Con $\tau = 0{,}9$ su traffico europeo desktop-mobile si ottengono precisioni intorno all’85-90% con recall del 30-40%; con $\tau = 0{,}6$ il recall sale al 60% ma la precisione scende verso il 70%. Non esiste una soglia “giusta” in assoluto: esiste la soglia giusta per l’uso. Per la fatturazione e il consenso serve precisione quasi perfetta; per allargare una prospecting audience si può tollerare rumore.

Il quadro normativo europeo sposta ulteriormente l’equilibrio. Fingerprinting invasivo e cross-site tracking senza base giuridica non sono opzioni tecniche, sono rischi legali. Dopo la stretta sui cookie di terze parti e l’ATT di Apple, il probabilistico cross-device ha perso gran parte del segnale su cui viveva. La conseguenza pratica: i team maturi usano il deterministico per l’identità canonica e relegano il probabilistico a due ruoli subordinati — suggerire candidati che un revisore o una regola deterministica conferma, oppure arricchire attributi non critici dove un errore costa poco.

Verdetto: deterministico come identità canonica, probabilistico solo per candidati da confermare o attributi non critici, con soglia dichiarata per uso e scadenza temporale.

Il grafo di identità spiegato sul campo

Il grafo di identità è una struttura semplice da descrivere e delicata da gestire: nodi che rappresentano identificatori (anonymous_id, device_id, email hashata, user_id) e archi che rappresentano evidenze di equivalenza (“questi due ID sono stati osservati nello stesso login”, “questo dispositivo ha usato questa email”). Le componenti connesse del grafo diventano profili unificati, ciascuno con un unified_customer_id.

Il dettaglio che separa un’implementazione seria da un giocattolo è la gerarchia di affidabilità. Non tutti gli archi pesano uguale: un login con email verificata vale più di dieci sessioni dallo stesso IP. Un pattern diffuso assegna a ogni arco un peso e risolve le componenti in ordine di confidenza, così un segnale debole non può mai spezzare un legame forte. Quando due sotto-grafi entrano in conflitto — lo stesso dispositivo usato da due login diversi, tipico di un computer condiviso in famiglia — la regola deve essere esplicita: in genere vince l’identificatore autenticato più recente, e il dispositivo passa al nuovo profilo lasciando una traccia di audit.

In una Composable CDP questo diventa SQL versionato in dbt, non una scatola nera. Lo scheletro è sempre lo stesso: normalizzare gli identificatori, costruire la tabella dei legami, risolvere le componenti:

-- Normalizza le email prima di ogni confronto: maiuscole e spazi
-- producono falsi negativi che gonfiano il conteggio utenti.
WITH normalized AS (
    SELECT
        event_id,
        event_ts,
        anonymous_id,
        device_id,
        user_id,  -- valorizzato solo dopo login o acquisto autenticato
        LOWER(TRIM(email)) AS email_clean
    FROM raw_events
    WHERE event_ts >= CURRENT_DATE - INTERVAL '90 days'
),
-- Legami deterministici: ogni riga è un'evidenza forte
-- tra identificatori osservati nello stesso evento.
deterministic_edges AS (
    SELECT DISTINCT
        COALESCE(user_id, 'sha256:' || SHA256(email_clean)) AS canonical_id,
        anonymous_id AS alias_id
    FROM normalized
    WHERE user_id IS NOT NULL OR email_clean IS NOT NULL
)
-- La risoluzione finale assegna a ogni alias l'ID canonico
-- con priorità al legame autenticato più recente.
SELECT * FROM deterministic_edges;

Il pezzo mancante in molti progetti è la tabella di audit: per ogni fusione, chi ha deciso (regola o modello con versione), con quale confidenza, su quali evidenze. Senza audit non puoi rispondere alla domanda “perché questi due profili sono la stessa persona?” — e senza risposta a quella domanda non puoi né correggere gli errori né difendere il trattamento davanti a un reclamo privacy.

Due metriche tengono il grafo sotto controllo. Il tasso di unificazione — quota di anonymous_id legati a un profilo noto — dice quanta copertura hai; il tasso di collisione — profili con segnali incoerenti come due nomi o due generi dichiarati — dice quanto rumore stai introducendo. Un’unificazione al 45% con collisioni sotto l’1% è sana; una al 75% con collisioni al 6% è un allarme: stai fondendo estranei per inseguire un numero.

Composable contro suite chiusa: costi e controllo

Le CDP SaaS chiuse (Segment, Bloomreach, Insider e simili) raccolgono eventi via SDK e restituiscono profili pronti, con centinaia di connettori verso email, advertising e analytics. Il time-to-value è di settimane: installi, mappi gli eventi, attivi le prime audience. Il prezzo è triplo — lock-in sul formato dei dati, logica di match non ispezionabile, costi per MTU (monthly tracked users) che esplodono quando il traffico anonimo cresce. Un sito con 2 milioni di visite mensili può pagare per 1,8 milioni di MTU anche se i clienti veri sono 80.000, perché ogni bot mal filtrato e ogni rimbalzo conta.

La Composable CDP rovescia lo schema: il warehouse (BigQuery, Snowflake, Databricks) è la fonte di verità, gli eventi arrivano da collector aperti come Snowplow o RudderStack, le trasformazioni vivono in dbt, il Reverse ETL (Hightouch, Census o script dedicati) sincronizza le audience verso l’esterno. Vantaggi: logica trasparente e testabile, costi legati allo storage e al compute — prevedibili e decrescenti per gigabyte — governance unificata con il resto dei dati aziendali. Svantaggi onesti: servono data engineer veri, il setup richiede mesi non settimane, e la latenza real-time va costruita pezzo per pezzo invece di trovarla pronta.

La scelta dipende da dove sta il vincolo. Un team marketing di otto persone senza ingegneri dati ottiene più valore da una suite chiusa ben configurata che da una composable abbandonata a metà. Un’azienda con un warehouse maturo, tre ingegneri analytics e volumi importanti risparmia soldi e guadagna controllo con la composable nel giro di un anno. Il segnale per cambiare strada è quando la fattura MTU cresce più in fretta del fatturato attribuito, o quando il team non riesce a spiegare perché due export dello stesso segmento danno numeri diversi.

In entrambi i casi, tre controlli tecnici evitano i disastri più comuni: deduplica degli eventi a monte (stesso event_id ricevuto due volte per retry di rete), gestione delle cancellazioni GDPR come tombstone che si propagano invece che come DELETE silenziosi, e test di non regressione sul grafo — ogni modifica alle regole deve mostrare quanti profili si fondono, si dividono o cambiano ID prima di andare in produzione.

Verdetto: suite chiusa per team senza ingegneri dati, composable con warehouse maturo e volumi importanti; si cambia strada quando la fattura per utenti tracciati cresce più in fretta del fatturato attribuito.

Dal profilo unificato all’audience che si attiva

Un profilo unificato che nessuno usa è un costo di storage. L’attivazione è il passaggio in cui il grafo diventa soldi: segmenti versionati, sincronizzati con la cadenza giusta, soppressi quando serve.

Una buona audience ha quattro proprietà. È definita come codice versionato, non come click su un’interfaccia che nessuno può revisionare. Ha una finestra temporale esplicita (“ha visitato la pagina prezzo negli ultimi 14 giorni” non “è interessato al prodotto”). Include le soppressioni — acquirenti recenti, reclami aperti, opt-out — come parte della definizione, non come pensiero successivo. E porta metadati operativi: owner, ipotesi (“questi utenti sono indecisi sul prezzo, non sul prodotto”), destinazione e frequenza di sync.

Il Reverse ETL è il muscolo di questa fase. In pratica è un job che calcola il delta — chi è entrato, chi è uscito dal segmento dall’ultimo sync — e lo spedisce alle API di destinazione con retry e idempotenza. Un frammento Python tipico, semplificato ma fedele nella logica:

# Calcola il delta del segmento rispetto all'ultimo sync:
# solo ingressi e uscite viaggiano verso le piattaforme.
def build_delta(current, previous):
    # current / previous: set di unified_customer_id
    entrati = current - previous  # nuovi ingressi da aggiungere
    usciti = previous - current  # da rimuovere (o sopprimere)
    return entrati, usciti

def sync_audience(segmento, entrati, usciti, consenso):
    # Mai sincronizzare chi ha revocato il consenso advertising:
    # il filtro va applicato sul delta, non a valle.
    entrati_ok = {u for u in entrati if consenso.get(u) == "granted"}
    api.add(segmento, entrati_ok)  # aggiunge i nuovi idonei
    api.remove(segmento, usciti)  # pulisce chi non è più eleggibile

La frequenza giusta segue l’economia del caso d’uso. Le Custom Audiences per prospecting si aggiornano bene una volta al giorno: sync più frequenti bruciano chiamate API senza cambiare il risultato perché gli algoritmi delle piattaforme impiegano ore a digerire le liste. Il recupero carrello via email o SMS vuole 15-30 minuti di latenza: sotto i 15 minuti il guadagno marginale raramente copre il costo dello streaming. La personalizzazione on-site è l’unico caso che giustifica davvero il real-time, e solo sulle pagine dove il test A/B ha mostrato che la latenza sposta la conversione.

Misurare se l’unificazione crea valore o rumore

Ogni progetto CDP deve rispondere a una domanda scomoda: come sai che unificare ha migliorato le decisioni invece di aggiungere un passaggio costoso? Tre misure bastano a rendersene conto.

La prima è il match rate scomposto: quota di eventi attribuiti a un profilo noto via deterministico contro via probabilistico, per canale e dispositivo. Se il probabilistico domina sul traffico che converte di più, le analisi su quel segmento ereditano la sua incertezza e vanno presentate con l’intervallo, non con il punto.

La seconda è l’effetto sulle metriche operative. Confronta, prima e dopo l’unificazione, il CAC per cliente unificato (non per cookie), la quota di impression sprecate su acquirenti recenti, e il fatturato per utente unificato. Un retailer che sopprime gli acquirenti degli ultimi 30 giorni dal retargeting si aspetta un calo delle impression del 10-20% e un aumento del ROAS perché il denominatore smette di includere chi avrebbe comprato comunque. Se il ROAS sale ma il fatturato incrementale no, stai solo spostando il merito, non creandolo.

La terza è il test di incrementalità sulle audience attivate: holdout casuale del 10% escluso dalla campagna, confronto del tasso di conversione tra esposti e holdout. Il lift si calcola come:

$\text{lift} = \frac{p_{\text{esposti}} - p_{\text{holdout}}}{p_{\text{holdout}}}$

dove $p$ è il tasso di conversione nel periodo. Senza holdout, ogni “campagna che converte al 4%” è un numero senza controfattuale: forse quegli utenti avrebbero comprato comunque. L’unificazione rende questi test più puliti perché riduce la contaminazione — lo stesso individuo presente sia nel gruppo esposto sia nell’holdout sotto due ID diversi — che altrimenti diluisce il lift verso zero.

Un controllo spesso trascurato: la stabilità degli ID nel tempo. Se il 5% dei unified_customer_id cambia assegnazione ogni mese per via di regole instabili, ogni coorte longitudinale — retention, LTV, payback — è inaffidabile. Congela le regole di match con versionamento e ricalcola le serie storiche solo con migrazioni esplicite e documentate.

Gli errori che gonfiano le metriche e bruciano budget

Il primo errore è la fusione allegra: soglie probabilistiche basse per mostrare un “tasso di unificazione del 90%” nelle slide. Il sintomo è un aumento simultaneo di reach e frequenza strana — gli stessi annunci mostrati troppe volte alle stesse famiglie — e lookalike che convergono verso la media perché addestrate su profili chimera. La correzione è banale da dire e rara da fare: alza la soglia finché le collisioni scendono sotto l’1% e accetta una copertura minore ma vera.

Il secondo è l’opposto: tenere separato ciò che è uguale. Succede quando il team non normalizza gli identificatori — [email protected] e [email protected] trattati come due persone — o quando il login avviene dopo l’acquisto e nessuno lega retrospettivamente la sessione anonima all’ordine. Il costo è il retargeting di chi ha appena comprato e l’attribuzione che premia la SEO per ordini in realtà chiusi dall’email. Un audit trimestrale su un campione di 200 ordini — quanti touchpoint pre-acquisto risultano legati al profilo acquirente — quantifica il buco.

Il terzo è dimenticare che l’identità ha una scadenza. Le email cambiano, i dispositivi si vendono, i cookie muoiono. Un grafo senza decadimento accumula legami fossili: tra un anno il profilo “famiglia Rossi” contiene tre telefoni, due dei quali ormai di estranei. Ogni arco probabilistico dovrebbe avere un TTL — tipicamente 30-90 giorni senza riconferma — oltre il quale decade automaticamente.

Il quarto è tecnico e costoso: eventi duplicati e fusi orari incoerenti. Un retry di rete che invia due volte lo stesso acquisto, contato come due ordini attribuiti a due ID poi fusi, crea un “cliente da due acquisti” che non esiste. Deduplica su event_id a monte, normalizza tutto in UTC all’ingresso, e diffida di ogni picco di conversione che coincide con un deploy del tracking.

Chi tiene insieme questi pezzi — raccolta pulita, match deterministico come spina dorsale, probabilistico confinato e versionato, audience definite come codice con soppressioni, sync alla giusta latenza, holdout per misurare — scopre che la CDP smette di essere un costo di infrastruttura e diventa ciò che promette: meno soldi spesi a inseguire chi ha già comprato, più segnali veri su chi sta per farlo.

Un caso che spiega il valore dell’identità: il sistema di raccomandazione Netflix

Nel 2015 Carlos Gomez-Uribe e Neil Hunt descrivono il sistema di raccomandazione Netflix in un articolo accademico che diventa un riferimento del settore. Il dato centrale è che circa l’80% delle ore guardate passa attraverso contenuti suggeriti dal sistema, tra ranking personalizzato, righe di genere e pagine in evidenza. Il caso funziona perché quasi tutto il traffico è autenticato tramite member_id, quindi il grafo di identità è banale e tutta la complessità sta nell’attivazione. La lezione per gli e-commerce con il 70% di traffico anonimo è opposta e preziosa: senza identità certa, meglio investire nella risoluzione deterministica che copiare l’architettura di chi non ha quel problema.

Domande per metterti alla prova

Prima di chiudere, mettiti alla prova con queste domande:

1. Quando un match probabilistico con soglia bassa diventa più costoso di non unificare affatto?
2. Perché la revoca del consenso su un canale deve propagarsi alle audience già sincronizzate?
3. Quale coppia di metriche distingue una copertura sana da una fusione allegra?
4. Quale latenza di sync basta per il recupero carrello e quale spreco paghi con lo streaming sempre attivo?