Procedure consigliate per la modellazione dati

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.

Introduzione

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.

Riepilogo delle best practice

L’approccio consigliato per la progettazione del modello dati da utilizzare in Experience Platform può essere riassunto come segue:

1. Comprendi i casi d’uso aziendali per i tuoi dati.
2. Identifica le origini dati primarie da inserire in Platform per risolvere tali casi d’uso.
3. Identifica eventuali fonti di dati secondari che potrebbero essere di interesse. Ad esempio, se attualmente solo una business unit dell’organizzazione è interessata a trasferire i propri dati in PlatformTuttavia, una business unit simile potrebbe essere interessata in futuro anche alla portabilità di dati simili. L’analisi di queste origini secondarie consente di standardizzare il modello dati dell’intera organizzazione.
4. Creare un diagramma di relazione tra entità (ERD) di alto livello per le origini dati identificate.
5. Conversione di ERD di alto livello in un PlatformERD incentrato su (inclusi profili, eventi esperienza ed entità di ricerca).

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.

Creare un ERD di alto livello

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.

Ordinare le entità in categorie di profili, ricerche ed eventi

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:

Considerazioni sull’ordinamento delle entità

Le sezioni seguenti forniscono ulteriori indicazioni su come ordinare le entità in base alle categorie sopra indicate.

Dati mutabili e immutabili

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.

Attributi del cliente

Se un’entità contiene attributi relativi a un singolo cliente, è molto probabilmente un’entità profilo. Esempi di attributi del cliente includono:

• Dettagli personali come nome, data di nascita, genere e ID account.
• Informazioni sulla posizione come indirizzi e informazioni GPS.
• Informazioni di contatto come numeri di telefono e indirizzi e-mail.

Tracciamento dei dati nel tempo

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:

Casi di utilizzo della segmentazione

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:

• "Gold" e "Platinum" rappresentano gli stati di fedeltà applicabili a un singolo cliente. Poiché la logica del segmento riguarda solo lo stato di fedeltà corrente dei clienti, questi dati possono essere modellati come parte di uno schema di profilo. Se desideri tenere traccia delle modifiche allo stato di fedeltà nel tempo, puoi anche creare uno schema di evento aggiuntivo per le modifiche allo stato di fedeltà.
• Gli acquisti sono eventi che si verificano in un momento particolare e la logica del segmento si basa su eventi di acquisto entro un intervallo di tempo specificato. Questi dati devono quindi essere modellati come schema di eventi.

Casi di utilizzo dell’attivazione

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.

Valori aggregati

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.

Cardinalità

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.

La tabella seguente illustra alcune relazioni di entità comuni e le categorie che possono essere derivate da esse:

Pro e contro di diverse classi di entità

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:

1. Utilizzare gli attributi del profilo
2. Utilizzare le entità evento

Approccio 1: utilizzare gli attributi del profilo

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

• La segmentazione è fattibile per il caso d’uso previsto.
• Lo schema manterrà solo i record di abbonamento più recenti per un cliente.

Contro

• L’intero array deve essere ridefinito ogni volta che si verificano modifiche a qualsiasi campo dell’array.
• Se diverse origini dati o unità aziendali inseriscono dati nell'array, sarà difficile mantenere sincronizzato l'array aggiornato più recente su tutti i canali.

Approccio 2: utilizzare entità evento

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

• Le regole di segmentazione possono essere più flessibili (ad esempio, trovare tutti i clienti che hanno modificato i loro abbonamenti negli ultimi 30 giorni).
• Quando lo stato di abbonamento di un cliente cambia, non è più necessario aggiornare un array lungo e potenzialmente complesso all’interno degli attributi di profilo del cliente. Questa funzione è particolarmente utile se si verificano modifiche simultanee all’elenco di abbonamento del cliente da più sorgenti.

Contro

• La segmentazione diventa più complessa per il caso d’uso originale (identificando lo stato degli abbonamenti più recenti dei clienti). Il segmento ora necessita di logica aggiuntiva per contrassegnare l’ultimo evento di abbonamento di un cliente al fine di verificarne lo stato.
• Gli eventi hanno un rischio maggiore di scadere automaticamente ed essere eliminati dall’archivio dei profili. Consulta la guida su Scadenze degli eventi esperienza per ulteriori informazioni.

Creare schemi in base alle entità categorizzate

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:

• Le entità profilo devono utilizzare XDM Individual Profile classe.
• Le entità evento devono utilizzare XDM ExperienceEvent classe.
• Le entità di ricerca devono utilizzare classi XDM personalizzate definite dall’organizzazione. Le entità profilo ed evento possono quindi fare riferimento a tali entità di ricerca attraverso relazioni di schema.

Le sezioni seguenti forniscono indicazioni generali sulla creazione di schemi basati sulla ERD.

Adottare un approccio di modellazione iterativa

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.

Campi di identità

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.

Adobe di gruppi di campi dello schema dell’applicazione

L’Experience Platform fornisce diversi gruppi di campi di schema XDM predefiniti per l’acquisizione di dati relativi alle seguenti applicazioni di Adobe:

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

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.

Passaggi successivi

Questo documento illustra le linee guida generali e le best practice per la progettazione del modello dati, ad Experience Platform. Per riepilogare:

• Prima di creare gli schemi, utilizza un approccio discendente che consiste nell’ordinare le tabelle di dati in categorie di profilo, ricerca ed eventi.
• Spesso esistono diversi approcci e opzioni per la progettazione di schemi per scopi diversi.
• Il modello dati deve supportare i casi di utilizzo aziendali, ad esempio la segmentazione o l’analisi del percorso di clienti.
• Rendi gli schemi più semplici possibile e aggiungi nuovi campi solo se assolutamente necessario.

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.

Risorse Business.Adobe.com