CDP and identity resolution

Un utente che visita da mobile, acquista da desktop e apre le email da un account aziendale finisce spesso registrato come tre profili distinti. Se la CDP unisce troppo poco, sprechi audience e perdi pezzi del percorso. Se unisce troppo, ti ritrovi con problemi di privacy, targeting sbagliato e metriche gonfiate. Il mestiere dell’identity resolution è tenere questo equilibrio operativo nel punto giusto.

Il problema da risolvere

Nel marketing analytics, CDP e identity resolution risolvono un problema concreto: trasformare budget, canali, creatività e audience in decisioni misurabili, senza confondere il volume con l’attribuzione e l’attribuzione con l’incrementalità. Non è un concetto astratto, è uno strumento che migliora decisioni reali quando lo applichi con dati affidabili e una soglia di errore dichiarata.

Come ragionare sul problema

flowchart LR
    A["Business question"]
    B["Measurable hypothesis"]
    C["Reliable data"]
    D["Incremental analysis"]
    E["Budget decision"]
    A --> B
    B --> C
    C --> D
    D --> E

Il ragionamento è sequenziale: formuli la domanda, la traduci in unità osservabili, valuti la qualità del dato e solo alla fine decidi. Saltare un passaggio produce analisi eleganti ma fragili.

Step	Guiding question	Expected output
Framing	Which decision needs to change?	A concrete choice, not a curiosity
Measure	Which signal represents the phenomenon?	Metric, source, and granularity
Comparison	Compared to which baseline do I interpret the result?	Benchmark or plausible counterfactual
Action	What do I do if the signal exceeds the threshold?	Decision, owner, and next check

Mettere ordine tra segnale, baseline e decisione

Conviene scrivere CDP e identity resolution come relazione tra quattro elementi: unità di analisi, segnale, baseline e decisione. L’unità può essere una campagna, una coorte, un touchpoint o un segmento cliente. Il segnale deve rappresentare margine incrementale, CAC payback, conversion rate corretto, lift o retention generata. La baseline è un periodo precedente, un gruppo holdout, un mercato comparabile o un benchmark storico. La decisione consiste nello spostare risorse, cambiare messaggio, fermare una tattica o scalare un esperimento.

Element	Operational Definition
Unit	campaign, cohort, touchpoint, or customer segment
Signal	incremental margin, CAC payback, corrected conversion rate, lift, or generated retention
Baseline	previous period, holdout group, comparable market, or historical benchmark
Decision	shift resources, change message, stop a tactic, or scale an experiment
Risk	confusing correlation, data quality, and causal decision-making

Una misura serve solo se riduce l’incertezza su una decisione precisa. Se non cambia nessuna scelta resta documentazione. Se cambia una scelta senza controlli, diventa rischio.

La frammentazione dell’identità digitale

Ogni interazione di un utente con un’azienda genera un identificatore unico per canale o dispositivo. Senza unificazione, una sola persona appare come molte entità diverse: prospect su Facebook, visitatore anonimo del sito, contatto email, utente dell’app e cliente pagante. Così diventano impossibili anche le domande più basilari, tipo “quale campagna Facebook ha portato al primo acquisto?” oppure “quanti touchpoint ha avuto questo cliente prima di convertire?”.

L’identity resolution scioglie questa frammentazione con due metodi. Il matching deterministico lega in modo certo gli identificatori basati su PII, come login o email: ha accuratezza superiore al 99% ed è la base di ogni grafo di identità affidabile. Il matching probabilistico usa invece segnali non-PII, come IP, fingerprinting e pattern comportamentali, per inferire una probabilità di match: qui l’accuratezza scende tra il 70% e il 90% ed è limitata dai vincoli privacy e dal GDPR.

Un sistema maturo usa il deterministico per definire l’identità canonica e tiene il probabilistico solo per arricchimenti a basso rischio.

Costruire il grafo delle identità

Il cuore tecnico di una CDP è il grafo delle identità, che mappa ogni identificatore a un unified_customer_id. Gli approcci principali sono due.

Il primo è la CDP SaaS. Gli SDK raccolgono eventi e li inviano alla piattaforma, che gestisce ingestion, validazione, identity resolution e profili come una scatola nera. Il vantaggio è la rapidità di implementazione, con interfacce comode e molte integrazioni pronte. Lo svantaggio è il vendor lock-in, la logica non personalizzabile e costi MTU che salgono in fretta su grandi volumi anonimi.

Il secondo è la Composable CDP, o warehouse-native. Gli eventi arrivano da strumenti open-source come Snowplow o Rudderstack, vengono caricati nel data warehouse, e da lì le trasformazioni SQL con dbt costruiscono il grafo, mentre il Reverse ETL sincronizza i dati con i sistemi operativi. Qui hai controllo totale, logica trasparente e personalizzabile, costi prevedibili e una governance migliore. In cambio servono competenze tecniche e più tempo di setup.

Scrivere la logica del grafo come SQL in dbt significa sostituire la scatola nera del SaaS con qualcosa di trasparente e testabile.

Caso pratico: Zalando e la vista customer_360

Zalando affronta la frammentazione con un data lake e un warehouse cloud, costruendo un grafo di identità che lega customer_id, email hashata, device_id e anonymous_id con una gerarchia di affidabilità. Prima, i dati siloed impedivano una personalizzazione efficace. Ora la vista customer_360 permette raccomandazioni pertinenti e segmenti complessi in poche ore, riducendo i costi operativi di marketing del 10-12% e aumentando il GMV per sessione.

Activation e orchestrazione: il caso Netflix

Netflix usa un grafo di identità relativamente semplice, perché l’esperienza è quasi interamente autenticata. Ogni azione è associata a un member_id e processata in streaming per aggiornare i profili in tempo reale. Il Reverse ETL qui è un processo continuo che alimenta i microservizi della UI con raccomandazioni personalizzate. Questo sistema influenza oltre l’80% dei contenuti guardati, con un lift nei click-through sulle raccomandazioni superiore al 20% e una retention oltre il 90% annuo.

Esercitarsi sul tema

Comincia con qualcosa di stretto: scrivi in cinque righe una decisione reale legata a CDP e identity resolution, indicando obiettivo, metrica primaria, baseline, rischio principale e azione prevista.

Poi allarga il quadro. Costruisci una tabella con almeno tre segmenti o scenari e, per ciascuno, scrivi il segnale, una spiegazione alternativa plausibile e il controllo che faresti prima di decidere.

Quando te la senti, prova la versione più ambiziosa: un piano di validazione con ipotesi, dati necessari, criterio di esclusione, soglia decisionale e controllo post-decisione, chiudendo con la domanda su cosa ti farebbe cambiare idea.

Per i dati parti da export campagne, costi media, eventi web e app, CRM, transazioni, survey brand e log di consenso. Se non ne hai di reali, costruisci un dataset sintetico di 200-500 righe con una colonna temporale, una colonna segmento, una metrica di outcome e una variabile di esposizione.

Typical mistakes

L’errore di fondo è trattare CDP e identity resolution come definizioni da ricordare invece che come protocollo decisionale. Da lì discendono gli altri: presentare metriche senza baseline, grafici senza ipotesi, raccomandazioni senza il costo dell’errore. La domanda da farsi è sempre la stessa: se questo risultato fosse falso o instabile, quale decisione sbaglierei? Se non sai rispondere, la lezione non è ancora stata applicata davvero, e stai trattando un’evidenza condizionata come se fosse una verità generale.

Verificare di aver capito

Quattro domande per controllare la presa sul tema. Qual è la decisione concreta che dovresti migliorare. Quale baseline rende interpretabile il risultato. Quale assunzione, se sbagliata, ribalterebbe la conclusione. E quale controllo minimo metteresti prima di portare la raccomandazione al tavolo.

Operational Summary

CDP e identity resolution valgono quando tengono insieme concetto, dato e decisione. Affrontale partendo da un problema reale, formalizza il segnale, cerca una baseline credibile, costruisci un esempio concreto e chiudi con un controllo pratico.