CDP e identity resolution

Un utente visita da mobile, compra da desktop, apre email su account aziendale e appare come tre profili diversi. Se la CDP unisce troppo poco, sprechi audience; se unisce troppo, rischi privacy, errori di targeting e metriche gonfiate. CDP e identity resolution lavora su questo equilibrio operativo.

Una scena da cui partire

Leggi questa lezione come una scelta di fiducia tra identità, consenso e attivazione. Ogni regola di matching deve spiegare cosa unisce, cosa lascia separato, quale rischio introduce e quali campagne potranno usare il profilo risultante.

• Contesto: Quale identificatore è abbastanza stabile per unire profili?
• Metodo: Quale controllo distingue match affidabili da collisioni rischiose?
• Applicazione: Quale audience attiveresti solo dopo una verifica di consenso?

La Frammentazione dell’Identità Digitale: Il Problema alla Radice

Per comprendere la necessità di una CDP, dobbiamo prima analizzare la natura intrinsecamente frammentata dell’identità digitale di un cliente. Ogni interazione che un utente ha con un’azienda genera un identificatore, spesso unico per quel canale o dispositivo. Questa proliferazione di ID è la causa principale della visione distorta che molte aziende hanno dei loro clienti. Consideriamo un tipico customer journey:

1. Esposizione Pubblicitaria: Un utente visualizza un annuncio su Facebook. Il pixel di Meta registra questa interazione associandola a un fbp_id (un identificatore legato al cookie di Facebook).
2. Visita al Sito Web: L’utente clicca sull’annuncio e atterra sul sito. Il sistema di web analytics (come Google Analytics 4 o Snowplow) assegna un client_id o anonymous_id, memorizzato in un cookie di prima parte nel browser. In questa fase, l’utente è ancora anonimo.
3. Iscrizione alla Newsletter: Interessato, l’utente si iscrive alla newsletter. Ora abbiamo un nuovo identificatore, l’indirizzo email, che viene inviato alla piattaforma di email marketing (es. Braze, Mailchimp).
4. Download e Uso dell’App: Settimane dopo, l’utente scarica l’app mobile. Al primo avvio, il sistema operativo assegna un device_id (come l’IDFA su iOS o il GAID su Android).
5. Creazione Account e Acquisto: Infine, l’utente crea un account sull’app e fa un acquisto. A questo punto, il sistema gestionale (CRM o backend) genera un customer_id univoco e stabile.

Senza un processo di unificazione, per i sistemi aziendali questo singolo utente appare come cinque entità separate: un prospect su Facebook, un visitatore anonimo del sito, un contatto email, un utente dell’app e un cliente pagante. Di conseguenza, le domande più basilari diventano impossibili da rispondere: “Quale campagna Facebook ha portato al primo acquisto?” o “Quanti punti di contatto ha avuto questo cliente prima di convertirsi?”.

L’identity resolution è il processo tecnico che risolve questa frammentazione. Si basa su due metodologie principali:

• Matching Deterministico: Questo approccio si fonda su legami certi e inequivocabili tra identificatori, tipicamente basati su Personally Identifiable Information (PII) fornite dall’utente. Quando un utente effettua il login sul sito, possiamo legare in modo definitivo il suo anonymous_id (dal cookie) al suo customer_id (dal backend). Allo stesso modo, se si iscrive alla newsletter con la stessa email associata al suo account, possiamo collegare la sessione web all’identità del cliente. Questo metodo ha un’accuratezza superiore al 99% ed è la spina dorsale di qualsiasi grafo di identità affidabile.
• Matching Probabilistico: Quando mancano legami deterministici, si può ricorrere a inferenze statistiche. Questo metodo utilizza segnali non-PII come l’indirizzo IP, la configurazione del browser (user-agent, risoluzione dello schermo, plugin installati - il cosiddetto “device fingerprinting”), e pattern comportamentali (orari di navigazione, tipo di contenuti visitati) per calcolare la probabilità che due identificatori anonimi appartengano alla stessa persona. Sebbene possa essere utile per arricchire profili anonimi, la sua accuratezza varia (tipicamente tra il 70% e il 90%) ed è sempre più ostacolato dalle restrizioni sulla privacy (es. ITP di Apple, deprecazione dei cookie di terze parti) che ne limitano l’efficacia e la conformità al GDPR.

Un sistema maturo utilizza il matching deterministico come fondamento per costruire il “grafo delle identità” e ricorre a quello probabilistico solo per scopi di analisi aggregata o arricchimento a basso rischio, mai per definire l’identità canonica di un cliente.

Costruire il Grafo delle Identità: Architetture a Confronto

Il cuore tecnico di una CDP è il grafo delle identità (identity graph). Contrariamente a quanto il nome possa suggerire, non è necessariamente una base di dati a grafo (come Neo4j), ma più comunemente una tabella o un set di tabelle in un data warehouse che mappa ogni identificatore conosciuto (anonymous_id, email, device_id, etc.) a un unico, stabile e canonico unified_customer_id. La creazione e la manutenzione di questo grafo è il compito primario della CDP. Esistono due approcci architettonici dominanti per implementare questa funzionalità: il CDP SaaS e il Composable CDP.

1. CDP Software-as-a-Service (SaaS) Piattaforme come Segment, mParticle o Treasure Data rappresentano la prima generazione di CDP. Offrono una soluzione “chiavi in mano”:

• Funzionamento: Si installano i loro SDK (Software Development Kit) su siti web e app. Questi SDK raccolgono gli eventi e li inviano ai server della CDP. La piattaforma si occupa internamente dell’ingestione, della validazione, dell’identity resolution (spesso con logiche “black box”) e della creazione dei profili utente. Questi profili possono poi essere segmentati tramite un’interfaccia visuale e inviati a centinaia di destinazioni pre-integrate (es. Facebook Ads, Google Ads, Braze).
• Vantaggi: L’implementazione iniziale è rapida. Le interfacce user-friendly consentono ai team di marketing di operare in autonomia senza dipendere costantemente dal team di data. La vasta libreria di integrazioni pronte all’uso semplifica l’attivazione dei dati.
• Svantaggi: Il principale svantaggio è il vendor lock-in. I dati dei clienti risiedono nell’infrastruttura del fornitore, e la logica di unificazione dell’identità non è trasparente né personalizzabile. Il modello di prezzo, tipicamente basato sui Monthly Tracked Users (MTU), può diventare proibitivo per aziende con un grande volume di traffico anonimo. Un sito di e-commerce con 10 milioni di visitatori unici al mese, di cui solo 200.000 sono clienti registrati, pagherebbe per 10 milioni di MTU, con un costo che può facilmente superare i 50.000€ al mese.

2. Composable CDP (Warehouse-Native) Questo è l’approccio moderno, emerso con la maturità dei data warehouse cloud come Snowflake, BigQuery e Redshift. Invece di acquistare una piattaforma monolitica, si “compongono” le funzionalità di una CDP utilizzando strumenti specializzati che operano direttamente sul proprio data warehouse.

• Funzionamento:
  1. Ingestion: Gli eventi vengono raccolti da fonti come Snowplow o Rudderstack (un’alternativa open-source a Segment) e caricati direttamente in una tabella grezza (raw_events) nel data warehouse.
  2. Modellazione e Identity Resolution: Il team di data engineering utilizza uno strumento come dbt (data build tool) per scrivere trasformazioni SQL che puliscono i dati, li modellano e, soprattutto, costruiscono il grafo delle identità. La logica è scritta in SQL, è versionata con Git, testata e completamente trasparente.
  3. Attivazione: Una volta creato il profilo cliente unificato (la vista customer_360), uno strumento di Reverse ETL (es. Hightouch, Census) si occupa di sincronizzare questi dati arricchiti con gli strumenti operativi (CRM, piattaforme di marketing, etc.).
• Vantaggi: Flessibilità e controllo totali. La logica di business è esplicita e personalizzabile. I costi sono più prevedibili e legati all’uso del data warehouse, eliminando la “tassa MTU”. I dati non lasciano mai l’infrastruttura dell’azienda, migliorando la governance e la sicurezza.
• Svantaggi: Richiede competenze tecniche interne (data engineering, analytics engineering). Il tempo di setup iniziale è maggiore rispetto a una soluzione SaaS.

Ecco un esempio di come la logica per un grafo di identità potrebbe essere implementata in SQL all’interno di un modello dbt, mostrando un approccio più robusto rispetto a un semplice join:

-- models/marts/identity_graph.sql
WITH all_identifiers AS (
    -- Raccoglie tutte le coppie di identificatori noti da diverse fonti
    SELECT anonymous_id, user_id FROM {{ ref('stg_web_events') }} WHERE user_id IS NOT NULL
    UNION ALL
    SELECT device_id AS anonymous_id, user_id FROM {{ ref('stg_app_events') }} WHERE user_id IS NOT NULL
    UNION ALL
    SELECT c.anonymous_id, u.user_id
    FROM {{ ref('stg_web_events') }} c
    JOIN {{ ref('stg_crm_users') }} u ON LOWER(c.user_email) = LOWER(u.email)
    WHERE c.user_email IS NOT NULL AND u.user_id IS NOT NULL
),

-- Crea "edge" tra gli identificatori che appartengono allo stesso utente
edges AS (
    SELECT anonymous_id AS id1, user_id AS id2 FROM all_identifiers
    UNION ALL
    SELECT user_id AS id1, anonymous_id AS id2 FROM all_identifiers
),

-- Algoritmo di Connected Components per trovare tutti gli ID collegati
-- (Questo è uno pseudo-algoritmo; le implementazioni reali usano loop o UDF)
-- Per semplicità, qui usiamo un approccio di "collapsing" tramite window function
final_graph AS (
    SELECT
        anonymous_id,
        user_id,
        -- Assegna un ID unificato a ogni gruppo di identificatori connessi
        FIRST_VALUE(user_id) OVER (PARTITION BY anonymous_id ORDER BY event_timestamp ASC) AS unified_customer_id
    FROM all_identifiers
)

SELECT
    unified_customer_id,
    anonymous_id AS identifier,
    'anonymous_id' AS identifier_type
FROM final_graph
UNION ALL
SELECT
    unified_customer_id,
    user_id AS identifier,
    'user_id' AS identifier_type
FROM final_graph
GROUP BY 1, 2, 3;

Questo codice, sebbene semplificato, illustra come la logica di unificazione, che in un CDP SaaS è una scatola nera, diventi un asset di codice trasparente, testabile e di proprietà dell’azienda nell’approccio Composable.

Dal Grafo al Profilo Unificato: Il Caso Studio di Zalando

Zalando, il colosso europeo dell’e-commerce di moda, rappresenta un caso di studio emblematico sull’applicazione su larga scala dei principi di identity resolution per alimentare la personalizzazione. Con oltre 50 milioni di clienti attivi in 25 mercati, un catalogo di migliaia di brand e interazioni che avvengono su web, app iOS e app Android, la frammentazione dell’identità non è un problema teorico, ma un ostacolo diretto alla crescita. Un cliente può cercare scarpe sull’app durante il tragitto casa-lavoro, aggiungere un paio alla wishlist, e poi completare l’acquisto dal laptop dell’ufficio. Senza un profilo unificato, l’esperienza sarebbe discontinua: i prodotti visti sull’app non apparirebbero nella sezione “Visti di recente” sul web, e le raccomandazioni sarebbero basate solo su una frazione del suo comportamento reale.

Per risolvere questa sfida, Zalando ha investito massicciamente in una piattaforma dati interna costruita su un data lake e un data warehouse cloud. Questa piattaforma agisce di fatto come un Composable CDP su misura.

• Il Problema: Prima di questo sforzo di unificazione, i dati dei clienti erano siloed. Il team di CRM vedeva la cronologia degli acquisti, il team di web analytics vedeva i clickstream anonimi, e il team di marketing vedeva le performance delle campagne per canale. Ogni team aveva una tessera del puzzle, ma nessuno vedeva l’immagine completa. Questo portava a campagne di marketing generiche e a una personalizzazione inefficace. Ad esempio, un utente poteva ricevere un’email di “carrello abbandonato” per un prodotto che aveva già acquistato tramite l’app poche ore prima.
• La Soluzione: Il primo passo è stato centralizzare tutti i flussi di eventi (click, visualizzazioni, aggiunte al carrello, acquisti) in un unico repository. Successivamente, il team di data engineering ha costruito e affinato un sofisticato grafo di identità. La loro logica segue una gerarchia di affidabilità:
  1. Il customer_id, generato al momento della creazione dell’account, è la chiave primaria e la fonte di verità.
  2. L’indirizzo email (hashato per privacy) è il principale legame deterministico per collegare le sessioni pre-login o le interazioni su altri canali.
  3. Gli identificatori di dispositivo (device_id) vengono mappati a un customer_id quando l’utente effettua il login dall’app.
  4. Gli identificatori anonimi dei cookie (anonymous_id) vengono associati quando un utente si logga o inserisce la sua email.
• L’Impatto e le Metriche: La creazione di una vista customer_360 unificata ha sbloccato un valore di business misurabile. Il motore di personalizzazione, alimentato da questo profilo completo, ha potuto generare raccomandazioni più pertinenti. Zalando ha riportato che l’implementazione di algoritmi di personalizzazione avanzati, resi possibili da questi dati unificati, ha contribuito ad aumentare il Gross Merchandise Volume (GMV) per sessione. Sebbene non abbiano rilasciato un numero esatto, analisti del settore stimano che una personalizzazione efficace possa portare a un incremento del 5-15% nel valore medio dell’ordine. Inoltre, l’efficienza operativa è migliorata drasticamente. Il tempo necessario per creare un segmento di pubblico complesso per una campagna multicanale (es. “clienti che hanno visualizzato stivali sull’app negli ultimi 7 giorni ma non hanno acquistato e hanno un valore storico superiore a 500€”) è passato da un processo manuale di giorni che coinvolgeva più team a un’operazione che richiede poche ore e una singola query SQL sulla vista customer_360. Questo ha permesso di ridurre i costi operativi del marketing di un stimato 10-12% grazie a un targeting più preciso e alla riduzione degli sprechi.

Activation e Orchestrazione: Il Caso Studio di Netflix

Se Zalando dimostra il valore di un profilo unificato per l’e-commerce, Netflix esemplifica come l’identity resolution sia la spina dorsale di un’esperienza di prodotto digitale in tempo reale. Per Netflix, ogni interazione è un dato prezioso che affina la comprensione dell’utente, e questa comprensione deve essere attivata istantaneamente su qualsiasi dispositivo l’utente scelga di usare. Il concetto di “sessione” quasi scompare, sostituito da un’interazione continua e coerente con il servizio.

• Il Problema: La proposta di valore di Netflix si basa su un’esperienza fluida e iper-personalizzata. Se un utente guarda 30 minuti di “The Crown” sulla sua Smart TV la sera, si aspetta di poter riprendere la visione esattamente da quel punto sul suo smartphone durante il viaggio in treno del mattino seguente. La home page che vede sul suo tablet deve riflettere la sua cronologia di visione su tutti gli altri dispositivi. Questa sincronizzazione in tempo reale su una base di oltre 200 milioni di abbonati, ognuno con profili multipli all’interno di un account, è una sfida ingegneristica monumentale.
• La Soluzione: L’architettura di Netflix è, in essenza, un gigantesco Composable CDP in tempo reale. Ogni account è ancorato a un member_id univoco. Ogni azione — play, pausa, ricerca, aggiunta alla lista, valutazione — è un evento che viene inviato ai loro sistemi centrali e associato a questo member_id.
  1. Identity Graph Implicito: Il grafo di identità è relativamente semplice perché l’esperienza è quasi interamente autenticata. Ogni dispositivo da cui un utente effettua il login viene associato al member_id, creando un legame deterministico.
  2. Profilo Utente in Tempo Reale: I dati non vengono solo archiviati in un data warehouse per analisi batch. Vengono elaborati da pipeline di streaming (utilizzando tecnologie come Apache Flink) che aggiornano costantemente lo “stato” del profilo di ogni utente. Questo stato include la cronologia di visione, le preferenze inferite, i titoli in “Continua a guardare”, etc.
  3. Activation (Attivazione): Qui sta la magia. Il “Reverse ETL” di Netflix non è un job notturno che sincronizza i dati con Salesforce. È un processo continuo in cui i risultati dei loro algoritmi di raccomandazione (che girano sui profili utente aggiornati) vengono inviati ai microservizi che compongono l’interfaccia utente. Quando apri l’app di Netflix, il tuo dispositivo fa una chiamata a questi servizi, che restituiscono un payload JSON con l’esatta disposizione della griglia, le immagini di anteprima (artwork) personalizzate e le raccomandazioni su misura per te in quel preciso momento.
• L’Impatto e le Metriche: L’impatto di questo sistema è totalizzante. Secondo dichiarazioni passate di ingegneri di Netflix, il sistema di raccomandazione influenza oltre l’80% dei contenuti guardati sulla piattaforma. La capacità di personalizzare non solo quali titoli mostrare, ma anche quale artwork utilizzare per ciascun titolo (es. mostrare un’immagine con i personaggi romantici a chi guarda molte commedie, e una con i personaggi d’azione a chi guarda film di quel genere) ha portato a un aumento misurabile dell’engagement, con un lift nei click-through sulle raccomandazioni che in alcuni test A/B ha superato il 20%. Questa profonda personalizzazione, basata su un profilo utente perfettamente unificato e attivato in tempo reale, è uno dei principali motori della loro altissima retention, che storicamente si attesta sopra il 90% anno su anno, un valore di riferimento per l’intero settore dello streaming.

Laboratorio Pratico: Costruiamo un Identity Graph Semplificato

Dopo aver esaminato la teoria e i casi di studio di giganti come Zalando e Netflix, è il momento di applicare questi concetti. In questo laboratorio, simuleremo il lavoro di

Laboratorio ed esercizi

Metti in pratica quanto appreso con esercizi a difficoltà crescente. Lavora su un dataset reale — se non hai accesso al tuo data warehouse aziendale, usa dataset pubblici come Google Analytics Sample su BigQuery o il dataset E-Commerce di Kaggle.

Esercizio 1 — Implementazione base. Riproduci la query o il modello descritto nella lezione, adattandolo al tuo dataset. Verifica che i risultati siano coerenti con le metriche attese: se il totale non quadra con una query di controllo, c’è un problema di grain.

Esercizio 2 — Estensione. Aggiungi una dimensione di analisi non coperta nella lezione: segmenta per paese, per device, per fascia oraria o per coorte. Dove emergono pattern inattesi? Cosa implicano per le decisioni operative?

Esercizio 3 — Automazione. Trasforma la query in una vista o in un modello dbt con test di integrità (unique, not_null) e documenta le colonne. Se il tuo stack lo permette, configura un alert che notifichi quando la metrica esce da 2 deviazioni standard dalla media mobile.

Errori frequenti e come evitarli

Anche gli analisti esperti cadono in trappole prevedibili quando lavorano con questo tipo di analisi. Conoscerle in anticipo riduce il tempo di debugging e aumenta la fiducia nei risultati.

Errore 1 — Confondere correlazione e causalità. Solo perché due metriche si muovono insieme non significa che una causi l’altra. Un A/B test o un’analisi controfattuale sono l’unico modo per stabilire causalità. Qualsiasi dashboard di correlazione va presentata con un disclaimer esplicito.

Errore 2 — Ignorare la stagionalità. Confrontare novembre con dicembre senza correggere per l’effetto festività produce insight fuorvianti. Usa sempre un confronto anno-su-anno o una media mobile destagionalizzata quando la metrica ha componenti stagionali note.

Errore 3 — Non validare il grain della query. La causa più comune di risultati errati è un grain sbagliato: un JOIN che duplica righe, un filtro applicato troppo tardi, una finestra definita sul dataset sbagliato. Prima di interpretare qualsiasi numero, verifica il conteggio delle righe a ogni step della query.

Problema reale

Nel lavoro su marketing analytics, CDP e identity resolution serve a risolvere un problema concreto: trasformare budget, canali, creativita e audience in decisioni misurabili senza confondere volume, attribuzione e incrementalita. La domanda non è se il concetto sia interessante in astratto, ma quale decisione migliora quando lo applichi con dati affidabili e con una soglia di errore esplicita.

Questa lezione va studiata come uno strumento operativo: entro la fine devi saper Comprendere il problema analitico e il contesto decisionale; Applicare esempi, metriche e controlli a casi reali. Se non riesci a collegare il concetto a una scelta reale, la conoscenza resta decorativa e non diventa competenza.

Modello concettuale

flowchart LR
    A["Domanda di business"]
    B["Ipotesi misurabile"]
    C["Dato affidabile"]
    D["Analisi incrementale"]
    E["Decisione di budget"]
    A --> B
    B --> C
    C --> D
    D --> E

Il modello mentale e sequenziale: prima si formula la domanda, poi si traduce in unità osservabili, quindi si valuta la qualità del dato e solo alla fine si decide. Saltare un passaggio produce analisi eleganti ma fragili.

Passaggio	Domanda guida	Output atteso
Framing	Quale decisione deve cambiare?	Una scelta concreta, non una curiosità
Misura	Quale segnale rappresenta il fenomeno?	Metrica, fonte e granularità
Confronto	Rispetto a quale baseline interpreto il risultato?	Benchmark o controfattuale plausibile
Azione	Che cosa faccio se il segnale supera la soglia?	Decisione, owner e prossimo controllo

Formalizzazione rigorosa

Formalizza CDP e identity resolution come una relazione tra quattro elementi: unità di analisi, segnale, baseline e decisione. Nel contesto di questa lezione l’unità principale e campagna, coorte, touchpoint o segmento cliente. Il segnale da osservare deve essere collegato a margine incrementale, CAC payback, conversion rate corretto, lift o retention generata, mentre la baseline deve essere scelta tra periodo precedente, gruppo holdout, mercato comparabile o benchmark storico.

Una formulazione robusta segue questa logica:

Elemento	Definizione operativa per questa lezione
Unità	campagna, coorte, touchpoint o segmento cliente
Segnale	margine incrementale, CAC payback, conversion rate corretto, lift o retention generata
Baseline	periodo precedente, gruppo holdout, mercato comparabile o benchmark storico
Decisione	spostare risorse, cambiare messaggio, fermare una tattica o scalare un esperimento
Rischio	Confondere correlazione, qualità del dato e causalità decisionale

La regola pratica e semplice: una misura e utile solo se riduce l’incertezza su una decisione specifica. Se non cambia una scelta, e documentazione; se cambia una scelta senza controlli, e rischio.

Esempio o caso studio

Un team growth deve decidere se aumentare il budget su un canale che mostra CPA basso ma vendite marginali deboli. La lezione aiuta a separare il segnale utile dal rumore operativo, collegando metrica, modello mentale e decisione economica.

Applicando CDP e identity resolution, il team costruisce una lettura in tre colonne: cosa sappiamo, cosa assumiamo e quale decisione prendiamo. Questo formato impedisce di presentare un numero come se fosse una conclusione autosufficiente.

Evidenza	Interpretazione prudente	Decisione conseguente
Segnale positivo ma non isolato	Il fenomeno esiste, ma la causa e ancora incerta	Cercare baseline o holdout
Segmento con risposta diversa	L’effetto medio nasconde eterogeneita	Analizzare coorti o sottogruppi
Costo operativo crescente	Il risultato va valutato sul margine	Applicare soglie economiche

Lab / esercizio

Livello base

Prendi una decisione reale collegata a CDP e identity resolution e scrivi in cinque righe: obiettivo, metrica primaria, baseline, rischio principale e azione prevista. Non usare più di una metrica primaria.

Livello intermedio

Costruisci una tabella con almeno tre segmenti o scenari. Per ciascuno indica segnale, possibile spiegazione alternativa e controllo necessario prima di decidere.

Livello research-grade

Disegna un piano di validazione: ipotesi, dati necessari, criterio di esclusione, soglia decisionale e controllo post-decisione. Specifica anche che cosa ti farebbe cambiare idea.

Dataset e materiali consigliati

Usa export campagne, costi media, eventi web o app, CRM, transazioni, survey brand e log di consenso. Se non hai dati reali, crea un dataset sintetico con 200-500 righe e almeno una colonna temporale, una colonna segmento, una metrica di outcome e una variabile di esposizione.

Errore tipico da evitare

L’errore più frequente e trattare CDP e identity resolution come una definizione da ricordare invece che come un protocollo decisionale. In pratica succede quando si presenta una metrica senza baseline, un grafico senza ipotesi, o una raccomandazione senza costo dell’errore.

Un controllo utile è chiedersi: “se questo risultato fosse falso o instabile, quale decisione sbaglierei?”. Se la risposta non è chiara, la lezione non è ancora stata applicata davvero.

Quiz o checkpoint

1. Qual è la decisione concreta che questa lezione dovrebbe migliorare?
2. Quale baseline rende interpretabile il risultato?
3. Quale assunzione, se sbagliata, cambierebbe la conclusione?
4. Quale controllo minimo useresti prima di presentare la raccomandazione?

Riepilogo operativo

CDP e identity resolution e una competenza utile quando collega concetto, dato e decisione. Studiala partendo da un problema reale, formalizza il segnale, cerca una baseline credibile, costruisci un esempio e chiudi con un controllo pratico. Categoria: Tecnico. Difficoltà: advanced. Tempo stimato: 22 min.