Experience Data Model (XDM) è il framework principale che standardizza i dati sull’esperienza del cliente, fornendo strutture e definizioni comuni da utilizzare nei servizi Adobe Experience Platform a valle. Aderendo agli standard XDM, tutti i dati sulla customer experience possono essere incorporati in una rappresentazione comune che consente di ottenere informazioni preziose dalle azioni dei clienti, definire il pubblico dei clienti attraverso i segmenti ed esprimere gli attributi dei clienti a scopo di personalizzazione.
Poiché XDM è estremamente versatile e personalizzabile dalla progettazione, è importante seguire le best practice per la modellazione dei dati durante la progettazione degli schemi. Questo documento descrive le decisioni chiave e le considerazioni da fare durante la mappatura dei dati sulla customer experience in XDM.
Prima di leggere questa guida, consulta Panoramica del sistema XDM per un’introduzione di alto livello a XDM e al suo ruolo all’interno di Experience Platform.
Inoltre, questa guida si concentra esclusivamente su considerazioni chiave relative alla progettazione dello schema. Si consiglia pertanto vivamente di fare riferimento al nozioni di base sulla composizione dello schema per una spiegazione dettagliata dei singoli elementi dello schema menzionati in questa guida.
L’approccio consigliato per la progettazione del modello dati da utilizzare in Experience Platform può essere riassunto come segue:
I passaggi relativi all’identificazione delle origini dati applicabili necessari per eseguire i casi di utilizzo aziendali variano da organizzazione a organizzazione. Mentre il resto delle sezioni di questo documento si concentrano sugli ultimi passaggi di organizzazione e costruzione di un ERD dopo l'identificazione delle origini dati, le spiegazioni dei vari componenti del diagramma possono orientare le decisioni su quali delle origini dati migrare Platform.
Una volta determinate le origini dati da inserire in Platform, crea un ERD di alto livello per guidare il processo di mappatura dei dati sugli schemi XDM.
L’esempio seguente rappresenta un’ERD semplificata per un’azienda che desidera inserire dati in Platform. Il diagramma evidenzia le entità essenziali che devono essere ordinate in classi XDM, inclusi account cliente, hotel, indirizzi e diversi eventi di e-commerce comuni.
Dopo aver creato un ERD per identificare le entità essenziali da inserire in Platform, queste entità devono essere ordinate in categorie di profilo, ricerca ed eventi:
Categoria | Descrizione |
---|---|
Entità profilo | Le entità profilo rappresentano attributi relativi a una singola persona, in genere un cliente. Le entità che rientrano in questa categoria devono essere rappresentate da schemi basati su XDM Individual Profileclasse. |
Entità di ricerca | Le entità di ricerca rappresentano concetti che possono essere correlati a una singola persona, ma non possono essere utilizzati direttamente per identificare l’individuo. Le entità che rientrano in questa categoria devono essere rappresentate da schemi basati su classi personalizzate e sono collegati a profili ed eventi tramite relazioni tra schemi. |
Entità evento | Le entità evento rappresentano concetti relativi alle azioni che un cliente può intraprendere, agli eventi di sistema o a qualsiasi altro concetto in cui si desidera tenere traccia delle modifiche nel tempo. Le entità che rientrano in questa categoria devono essere rappresentate da schemi basati su XDM ExperienceEventclasse. |
Le sezioni seguenti forniscono ulteriori indicazioni su come ordinare le entità in base alle categorie sopra indicate.
Un modo principale di ordinare tra le categorie di entità consiste nel determinare se i dati acquisiti sono mutabili o meno.
Gli attributi appartenenti a profili o entità di ricerca sono in genere mutabili. Ad esempio, le preferenze di un cliente potrebbero cambiare nel tempo e i parametri di un piano di abbonamento possono essere aggiornati a seconda delle tendenze di mercato.
Al contrario, i dati dell’evento sono in genere immutabili. Poiché gli eventi sono associati a una marca temporale specifica, lo "snapshot di sistema" fornito da un evento non cambia. Ad esempio, un evento può acquisire le preferenze di un cliente durante il pagamento di un carrello e non cambia anche se le preferenze del cliente finiscono per cambiare in un secondo momento. I dati evento non possono essere modificati dopo la registrazione.
Per riepilogare, i profili e le entità di ricerca contengono attributi mutabili e rappresentano le informazioni più recenti sui soggetti che acquisiscono, mentre gli eventi sono record immutabili del sistema in un momento specifico.
Se un’entità contiene attributi relativi a un singolo cliente, è molto probabilmente un’entità profilo. Esempi di attributi del cliente includono:
Se desideri analizzare il modo in cui determinati attributi all’interno di un’entità cambiano nel tempo, è molto probabile che si tratti di un’entità evento. Ad esempio, l’aggiunta di elementi di prodotto a un carrello può essere tracciata come evento aggiuntivo al carrello in Platform:
Customer ID | Tipo | ID prodotto | Quantità | Marca temporale |
---|---|---|---|---|
1234567 | Add | 275098 | 2 | 1 ott 10:32 |
1234567 | Rimuovi | 275098 | 1 | 1 ott 10:33 |
1234567 | Add | 486502 | 1 | 1 ott 10:41 |
1234567 | Add | 910482 | 5 | 3 ottobre, 14:15 |
Quando categorizzi le entità, è importante considerare i segmenti di pubblico che potresti voler creare per affrontare casi di utilizzo aziendali specifici.
Ad esempio, un’azienda vuole conoscere tutti i membri "Gold" o "Platinum" del proprio programma fedeltà che hanno effettuato più di cinque acquisti nell’ultimo anno. In base a questa logica di segmento, è possibile trarre le seguenti conclusioni in merito a come dovrebbero essere rappresentate le entità rilevanti:
Oltre alle considerazioni relative ai casi di utilizzo della segmentazione, è necessario esaminare anche i casi di utilizzo dell’attivazione per tali segmenti al fine di identificare ulteriori attributi rilevanti.
Ad esempio, un’azienda ha creato un segmento di pubblico in base alla regola che country = US
. Quindi, quando attiva quel segmento in determinati target a valle, l’azienda vuole filtrare tutti i profili esportati in base allo stato predefinito. Pertanto, un state
L'attributo deve essere acquisito anche nell'entità profilo applicabile.
In base al caso d’uso e alla granularità dei dati, è necessario decidere se alcuni valori devono essere preaggregati prima di essere inclusi in un profilo o in un’entità evento.
Ad esempio, un’azienda desidera creare un segmento in base al numero di acquisti effettuati nel carrello. Puoi scegliere di incorporare questi dati con la granularità più bassa includendo ogni evento di acquisto con marca temporale come propria entità. Tuttavia, a volte questo può aumentare esponenzialmente il numero di eventi registrati. Per ridurre il numero di eventi acquisiti, puoi creare un valore aggregato numberOfPurchases
in un periodo di una settimana o di un mese. Altre funzioni di aggregazione come MIN e MAX possono essere applicate a queste situazioni.
Experience Platform al momento non esegue l’aggregazione automatica dei valori, anche se questa operazione è pianificata per le versioni future. Se si sceglie di utilizzare valori aggregati, è necessario eseguire i calcoli esternamente prima di inviare i dati a Platform.
Le cardinalità stabilite nella ERD possono anche fornire alcuni indizi su come categorizzare le entità. Se esiste una relazione uno-a-molti tra due entità, l’entità che rappresenta il "molti" sarà probabilmente un’entità evento. Tuttavia, ci sono anche casi in cui "molti" è un set di entità di ricerca che vengono fornite come array all’interno di un’entità profilo.
Poiché non esiste un approccio universale per adattarsi a tutti i casi d’uso, è importante considerare i pro e i contro di ogni situazione quando si categorizzano le entità in base alla cardinalità. Consulta la sezione successiva per ulteriori informazioni.
La tabella seguente illustra alcune relazioni di entità comuni e le categorie che possono essere derivate da esse:
Relazione | Cardinalità | Categorie di entità |
---|---|---|
Clienti e carrello Pagamenti | Da uno a molti | Un singolo cliente può avere molti checkout nel carrello, che sono eventi che possono essere tracciati nel tempo. I clienti sarebbero quindi un’entità profilo, mentre Cart Checkouts sarebbe un’entità evento. |
Clienti e account fedeltà | Uno a uno | Un singolo cliente può avere un solo account fedeltà e viceversa. Poiché la relazione è uno a uno, sia Clienti che Conti fedeltà rappresentano entità profilo. |
Clienti e abbonamenti | Da uno a molti | Un singolo cliente può avere molti abbonamenti. Poiché l’azienda si occupa solo degli abbonamenti correnti di un cliente, Clienti è un’entità profilo, mentre Abbonamenti è un’entità ricerca. |
Sebbene la sezione precedente abbia fornito alcune linee guida generali per decidere come categorizzare le entità, è importante comprendere che spesso ci possono essere pro e contro nella scelta di una categoria di entità rispetto a un’altra. Il seguente caso di studio ha lo scopo di illustrare come considerare le opzioni in queste situazioni.
Un’azienda tiene traccia degli abbonamenti attivi per i propri clienti, dove un cliente può avere molti abbonamenti. L’azienda desidera inoltre includere gli abbonamenti per i casi di utilizzo della segmentazione, ad esempio per trovare tutti gli utenti con abbonamenti attivi.
In questo scenario, l’azienda ha due potenziali opzioni per rappresentare gli abbonamenti di un cliente nel suo modello di dati:
Il primo approccio consiste nell’includere un array di abbonamenti come attributi all’interno dell’entità profilo per i clienti. Gli oggetti in questa matrice conterrebbero campi per category
, status
, planName
, startDate
, e endDate
.
Pro
Contro
Il secondo approccio consiste nell’utilizzare gli schemi evento per rappresentare gli abbonamenti. Ciò comporta l’acquisizione degli stessi campi di abbonamento del primo approccio, con l’aggiunta di un ID di abbonamento, un ID cliente e una marca temporale indicante quando si è verificato l’evento di abbonamento.
Pro
Contro
Dopo aver ordinato le entità in categorie di profilo, ricerca ed eventi, puoi iniziare a convertire il modello dati in schemi XDM. A scopo dimostrativo, il modello dati di esempio mostrato in precedenza è stato suddiviso nelle categorie appropriate nel diagramma seguente:
La categoria in cui è stato ordinato un’entità deve determinare la classe XDM su cui si basa il relativo schema. Per ribadire:
Anche se le entità evento saranno quasi sempre rappresentate da schemi separati, le entità nelle categorie di profilo o di ricerca possono essere combinate insieme in un singolo schema XDM, a seconda della loro cardinalità.
Ad esempio, poiché l'entità Clienti ha una relazione uno-a-uno con l'entità Conti fedeltà, lo schema per l'entità Clienti potrebbe includere anche un LoyaltyAccount
per contenere i campi fedeltà appropriati per ciascun cliente. Se la relazione è uno a molti, tuttavia, l’entità che rappresenta il "molti" potrebbe essere rappresentata da uno schema separato o da un array di attributi di profilo, a seconda della complessità.
Le sezioni seguenti forniscono indicazioni generali sulla creazione di schemi basati sulla ERD.
Il regole di evoluzione dello schema Stabiliscono che solo le modifiche non distruttive possono essere apportate agli schemi una volta implementati. In altre parole, una volta aggiunto un campo a uno schema e i dati sono stati acquisiti in base a tale campo, il campo non può più essere rimosso. È quindi essenziale adottare un approccio di modellazione iterativa quando si creano per la prima volta gli schemi, a partire da un’implementazione semplificata che aumenta progressivamente la complessità nel tempo.
Se non sei sicuro se un particolare campo sia necessario da includere in uno schema, la best practice consiste nell’escludere tale campo. Se in seguito viene stabilito che il campo è necessario, può sempre essere aggiunto nella successiva iterazione dello schema.
Ad Experience Platform, i campi XDM contrassegnati come identità vengono utilizzati per unire informazioni su singoli clienti provenienti da più origini dati. Anche se uno schema può avere più campi contrassegnati come identità, è necessario definire una singola identità primaria affinché lo schema possa essere abilitato per l’utilizzo in Real-Time Customer Profile. Consulta la sezione su campi di identità nelle nozioni di base sulla composizione dello schema, per informazioni più dettagliate sul caso d’uso di questi campi.
Durante la progettazione degli schemi, eventuali chiavi primarie nelle tabelle del database relazionale saranno probabilmente candidate per le identità primarie. Altri esempi di campi di identità applicabili sono gli indirizzi e-mail dei clienti, i numeri di telefono, gli ID account e ECID.
L’Experience Platform fornisce diversi gruppi di campi di schema XDM predefiniti per l’acquisizione di dati relativi alle seguenti applicazioni di Adobe:
Ad esempio, il Modello Adobe Analytics ExperienceEvent gruppo di campi consente di mappare Analyticscampi specifici per gli schemi XDM. A seconda delle applicazioni di Adobe con cui stai lavorando, dovresti utilizzare questi gruppi di campi forniti dall’Adobe nei tuoi schemi.
Adobe di gruppi di campi dell’applicazione che assegnano automaticamente un’identità primaria predefinita tramite l’utilizzo di identityMap
è un oggetto generato dal sistema e di sola lettura che mappa i valori di identità standard per un singolo cliente.
Per Adobe Analytics, ECID è l’identità primaria predefinita. Se un valore ECID non viene fornito da un cliente, per impostazione predefinita l’identità primaria sarà AAID.
Quando si utilizzano i gruppi di campi dell’applicazione Adobe, nessun altro campo deve essere contrassegnato come identità primaria. Se esistono proprietà aggiuntive che devono essere contrassegnate come identità, questi campi devono essere assegnati come identità secondarie.
Questo documento illustra le linee guida generali e le best practice per la progettazione del modello dati, ad Experience Platform. Per riepilogare:
Quando sei pronto, consulta l’esercitazione su creazione di uno schema nell’interfaccia utente per istruzioni dettagliate su come creare uno schema, assegna la classe appropriata per l’entità e aggiungi campi a cui mappare i dati.