Best practice per la modellazione dei dati
Experience Data Model (XDM) è il framework di base 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 e utilizzati per ottenere informazioni preziose dalle azioni dei clienti, definire il pubblico dei clienti 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 sull’esperienza del cliente su XDM.
Introduzione
Prima di leggere questa guida, controlla Panoramica del sistema XDM per un'introduzione di alto livello a XDM e al suo ruolo nell'Experience Platform.
Poiché questa guida si concentra esclusivamente su considerazioni chiave relative alla progettazione dello schema, si consiglia vivamente di leggere le nozioni di base sulla composizione dello schema per le spiegazioni dettagliate dei singoli elementi dello schema menzionati in questa guida.
Riepilogo delle best practice summary
L’approccio consigliato per la progettazione del modello dati da utilizzare in Experience Platform può essere riassunto come segue:
- Comprendi i casi d’uso aziendali per i tuoi dati.
- Identificare le origini dati primarie da inserire in Platform per risolvere questi casi d'uso.
- 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 Platform, anche una simile business unit potrebbe essere interessata a trasferire dati simili in futuro. L’analisi di queste origini secondarie consente di standardizzare il modello dati dell’intera organizzazione.
- Creare un diagramma di relazione tra entità (ERD) di alto livello per le origini dati identificate.
- Convertire l'ERD di alto livello in un ERD incentrato su Platform (inclusi profili, eventi di 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 dell'organizzazione e della costruzione di un'ERD dopo l'identificazione delle origini dati, le spiegazioni dei vari componenti del diagramma potrebbero orientare le decisioni su quali origini dati migrare a Platform.
Creare un ERD di alto livello create-an-erd
Dopo aver determinato le origini dati da inserire in Platform, crea un ERD di alto livello per guidare il processo di mappatura dei dati agli 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 sort-entities
Dopo aver creato un ERD per identificare le entità essenziali che si desidera inserire in Platform, è necessario ordinare queste entità in categorie di profilo, ricerca ed eventi:
Considerazioni sull’ordinamento delle entità considerations
Le sezioni seguenti forniscono ulteriori indicazioni su come ordinare le entità in base alle categorie sopra indicate.
Dati mutabili e immutabili mutable-and-immutable-data
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 customer-attributes
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 track-data
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 eventi aggiuntivi al carrello in Platform:
Casi di utilizzo della segmentazione segmentation-use-cases
Quando categorizzi le entità, è importante considerare i tipi di pubblico che puoi creare per affrontare casi d’uso 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 segmentazione, è 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 di segmentazione 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 determinato momento e la logica di segmentazione riguarda gli eventi di acquisto entro un intervallo di tempo specificato. Questi dati devono quindi essere modellati come schema di eventi.
Casi di utilizzo dell’attivazione activation-use-cases
Oltre alle considerazioni relative ai casi di utilizzo della segmentazione, è necessario esaminare i casi di utilizzo dell’attivazione per tali tipi di pubblico per identificare attributi rilevanti aggiuntivi.
Ad esempio, un'azienda ha creato un pubblico in base alla regola che country = US. Quindi, quando attiva il pubblico su determinati target a valle, l’azienda vuole filtrare tutti i profili esportati in base allo stato dell’abitazione. Pertanto, un attributo state deve essere acquisito anche nell'entità profilo applicabile.
Valori aggregati aggregated-values
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 pubblico 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 scegliere di creare un valore aggregato numberOfPurchases per un periodo di una settimana o di un mese. Altre funzioni di aggregazione come MIN e MAX possono essere applicate a queste situazioni.
Cardinalità cardinality
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à, è probabile che l’entità che rappresenta il "molti" sia 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à pros-and-cons
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:
Approccio 1: utilizzare gli attributi del profilo profile-approach
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 mantiene 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, diventa difficile mantenere sincronizzato l'array aggiornato più recente su tutti i canali.
Approccio 2: utilizzare entità evento event-approach
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 pubblico ora ha bisogno di una logica aggiuntiva per contrassegnare l’ultimo evento di abbonamento affinché un cliente possa verificarne lo stato.
- Gli eventi hanno un rischio maggiore di scadere automaticamente ed essere eliminati dall’archivio dei profili. Per ulteriori informazioni, consulta la guida su Scadenze evento esperienza.
Creare schemi in base alle entità categorizzate schemas-for-categorized-entities
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 la classe XDM Individual Profile.
- Le entità evento devono utilizzare la classe XDM ExperienceEvent.
- 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.
LoyaltyAccount che contiene i campi fedeltà appropriati per ogni 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.
Adottare un approccio di modellazione iterativa iterative-modeling
Le regole dell'evoluzione dello schema prevedono che solo le modifiche non distruttive possano 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à identity-fields
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. Per informazioni più dettagliate sul caso d'uso di questi campi, consulta la sezione sui campi di identità nelle nozioni di base sulla composizione dello schema.
Durante la progettazione degli schemi, eventuali chiavi primarie nelle tabelle del database relazionale sono 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 adobe-application-schema-field-groups
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, puoi utilizzare il gruppo di campi 🔗 del modello Adobe Analytics ExperienceEvent per mappare campi specifici di Analytics agli 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 i gruppi di campi applicazione assegnano automaticamente un'identità primaria predefinita tramite l'utilizzo del campo identityMap, che è 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, l’identità primaria utilizza per impostazione predefinita AAID.
Campi di convalida dei dati data-validation-fields
Quando si acquisiscono i dati nel data lake, la convalida dei dati viene applicata solo per i campi vincolati. Per convalidare un particolare campo durante un’acquisizione batch, è necessario contrassegnare il campo come vincolato nello schema XDM. Per evitare che dati errati vengano acquisiti in Platform, ti consigliamo di definire i criteri per la convalida a livello di campo quando crei gli schemi.
Per impostare vincoli per un campo specifico, selezionare il campo dall'Editor schema per aprire la barra laterale Proprietà campo. Per una descrizione esatta dei campi disponibili, consulta la documentazione sulle proprietà dei campi specifiche per tipo.
Suggerimenti per mantenere l'integrità dei dati data-integrity-tips
Di seguito è riportata una raccolta di suggerimenti per mantenere l'integrità dei dati durante la creazione di uno schema.
- Considera le identità primarie: ad Adobe, prodotti come Web SDK, Mobile SDK, Adobe Analytics e Adobe Journey Optimizer, il campo
identityMapspesso funge da identità primaria. Evita di designare campi aggiuntivi come identità primarie per tale schema. - Evita di utilizzare
_idcome identità: evita di utilizzare il campo_idnegli schemi Experience Event come identità. Ha lo scopo di garantire l'univocità dei record e non di utilizzarli come identità. - Imposta vincoli di lunghezza: è consigliabile impostare lunghezze minime e massime nei campi contrassegnati come identità. Un avviso viene attivato se si tenta di assegnare uno spazio dei nomi personalizzato a un campo di identità senza soddisfare i vincoli di lunghezza minima e massima. Queste limitazioni contribuiscono a mantenere la coerenza e la qualità dei dati.
- Applica pattern per valori coerenti: se i valori di identità seguono un pattern specifico, è necessario utilizzare l'impostazione Pattern per applicare questo vincolo. Questa impostazione può includere solo regole come cifre, lettere maiuscole o minuscole o combinazioni di caratteri specifiche. Utilizza espressioni regolari per far corrispondere i pattern nelle stringhe.
- Limita le eVar negli schemi di Analytics: in genere, uno schema di Analytics deve avere un solo eVar designato come identità. Se intendi utilizzare più di un eVar come identità, devi verificare nuovamente se la struttura dati può essere ottimizzata.
- Assicurare l'univocità di un campo selezionato: il campo scelto deve essere univoco rispetto all'identità primaria nello schema. In caso contrario, non contrassegnarlo come identità. Ad esempio, se più clienti possono fornire lo stesso indirizzo e-mail, lo spazio dei nomi non è un’identità adatta. Questo principio si applica anche ad altri spazi dei nomi di identità come i numeri di telefono.
- I vincoli attivano gli avvisi per i campi dello spazio dei nomi personalizzato: imposta i vincoli per attivare un avviso quando un campo dello schema è contrassegnato con uno spazio dei nomi personalizzato senza specificare la lunghezza minima e la lunghezza massima. L’avviso funge da importante avvertimento per mantenere l’integrità dei dati. Consulta la documentazione sulle proprietà dei campi specifiche per il tipo per informazioni su come impostare vincoli su un particolare campo.
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 il 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, assegnare la classe appropriata per l'entità e aggiungere campi a cui mappare i dati.