Perché serve la data unification

In Dynamics 365 Customer Insights - Data i dati di un cliente arrivano frammentati da decine di sistemi: CRM, e-commerce, ERP, loyalty, form web. Ognuno rappresenta la stessa persona con chiavi e formati diversi. La data unification riconcilia questi frammenti in un unified customer profile: un unico record consolidato per cliente, con un identificatore stabile. Questo profilo è la base su cui poi costruisci segments, measures ed enrichment, e che l’analyst usa per alimentare le esperienze in Sales, Customer Service e le journey di Customer Insights - Journeys.

La pipeline segue tre fasi obbligatorie e ordinate: Map → Match → Merge.

Map

Nella fase Map selezioni le tabelle sorgente e definisci per ciascun campo un semantic type (es. Person.FullName, Identity.Email, Location.PostalCode) e una primary key univoca. La mappatura semantica non è cosmetica: guida la normalizzazione automatica usata nel matching (numeri, telefoni, indirizzi) e abilita gli enrichment. Una chiave primaria mal scelta o non univoca fa fallire l’intera unification a valle.

Match

Nella fase Match definisci come le tabelle si collegano tra loro. Qui contano due decisioni architetturali:

  • L’ordine delle tabelle: la prima tabella è la primary source e diventa il tronco a cui le altre vengono agganciate a coppie. Metti come primaria la sorgente più affidabile e completa (tipicamente il CRM/Dataverse).
  • L’ordine delle match rule: le regole si eseguono in sequenza. Ogni rule confronta una coppia di campi con un livello di precisione (Basic: Low/Medium/High/Exact, o Custom con normalizzazione e soglie). Le regole più precise (es. email exact) vanno prima; le regole fuzzy (nome + CAP) dopo, come fallback. L’ordine è decisivo perché la deduplica è progressiva: ciò che una regola precedente ha già unito condiziona ciò che vedono le successive.

Merge

Nella fase Merge i record considerati “stessa persona” vengono fusi in un solo profilo. Quando due sorgenti hanno valori in conflitto per lo stesso attributo, interviene la conflict resolution. Le policy disponibili sono:

  • Importance / source ranking: vince il valore della sorgente più in alto nell’ordine (default basato sull’ordine delle tabelle).
  • Most recent / Least recent: richiede un campo timestamp di riferimento.
  • Most filled: privilegia il valore non nullo/più completo.

Puoi impostare la policy globalmente e poi override per singolo attributo. È qui che decidi, per esempio, che l’email vince dal CRM ma l’indirizzo di spedizione vince dall’ERP.

Fonti dati e connettori

L’ingestione avviene tramite i Power Query connectors (oltre 100: SQL, Salesforce, Blob/ADLS Gen2, Synapse, API, file). Con la convergenza su Microsoft Fabric, Customer Insights può leggere dati già presenti in OneLake senza duplicarli. Le tabelle di Dataverse (dove risiede Dynamics 365 Sales) sono una sorgente nativa e privilegiata: account e contact entrano nell’unification come qualsiasi altra tabella, ma con affidabilità tipicamente alta.

Unified customer profile e customer ID

L’output è la tabella CustomerProfile, con un customerId generato da Customer Insights. Questo ID è diverso da contactid/accountid di Sales: è la chiave dell’entità analitica unificata. Il sistema mantiene le alternate keys verso i record sorgente, così puoi sempre risalire dai frammenti originali al profilo consolidato e viceversa.

Relazione con Dataverse e i record di Sales

Il punto più frainteso: l’unified profile non sostituisce account e contact di Sales. In Sales, account = azienda e contact = persona sono record operativi/transazionali su cui i seller lavorano. Il CustomerProfile è un record analitico e in sola consultazione, che aggrega quei record con molte altre fonti. Segments, measures e insight possono essere riesportati verso Dataverse/Sales (es. una card “Customer Insights” sul contact), ma restano un arricchimento: non modificano la natura del contact né ne diventano la master copy.

Trappole tipiche d’esame

  • Scenario: due match rule, una email-exact e una nome+città-fuzzy, danno risultati diversi a seconda dell’ordine → risposta: riordina mettendo la regola più precisa (email) per prima; l’ordine delle rule cambia la deduplica progressiva.
  • Scenario: dopo il merge il numero di telefono arriva dalla sorgente sbagliata → risposta: imposta una merge policy per-attributo (source ranking o Most recent), non cambiare l’intera unification.
  • Scenario: “quale record rappresenta il cliente in Sales?” → risposta: il contact/account in Dataverse, non il CustomerProfile, che è analitico e read-only.
  • Scenario: serve la sorgente più affidabile come base dell’unione → risposta: impostala come primary table nella fase Match.
  • Scenario: un attributo non normalizza in matching → risposta: verifica il semantic type assegnato in fase Map, non la match rule.