Nozioni di base sulla composizione dello schema

Scopri gli schemi Experience Data Model (XDM) e gli elementi di base, i principi e le best practice per la composizione di schemi in Adobe Experience Platform. Per informazioni generali su XDM e sul suo utilizzo in Platform, consulta la Panoramica del sistema XDM.

Informazioni sugli schemi understanding-schemas

Uno schema è un set di regole che rappresentano e convalidano la struttura e il formato dei dati. A un livello avanzato, gli schemi forniscono una definizione astratta di un oggetto reale (ad esempio una persona) e delineano quali dati includere in ogni istanza di tale oggetto (ad esempio nome, cognome, compleanno e così via).

Oltre a descrivere la struttura dei dati, gli schemi applicano vincoli e aspettative ai dati in modo che possano essere convalidati durante gli spostamenti tra sistemi diversi. Queste definizioni standard consentono di interpretare i dati in modo coerente, indipendentemente dall’origine, ed eliminano la necessità di traduzione tra le applicazioni.

Experience Platform mantiene questa normalizzazione semantica utilizzando gli schemi. Gli schemi sono il metodo standard per descrivere i dati in Experience Platform che consentono il riutilizzo di tutti i dati conformi agli schemi in un’organizzazione senza conflitti o anche la condivisione tra più organizzazioni.

Gli schemi XDM sono ideali per memorizzare grandi quantità di dati complessi in un formato autonomo. Consulta le sezioni su oggetti incorporati e big data nell'appendice di questo documento per ulteriori informazioni su come XDM esegue questa operazione.

Flussi di lavoro basati su schema in Experience Platform schema-based-workflows

La standardizzazione è un concetto chiave alla base dell'Experience Platform. XDM, guidato da Adobe, è un tentativo di standardizzare i dati sulla customer experience e definire schemi standard per la gestione della customer experience.

L'infrastruttura su cui viene generato l'Experience Platform, nota come XDM System, semplifica i flussi di lavoro basati su schema e include Schema Registry, Schema Editor, i metadati dello schema e i modelli di consumo del servizio. Per ulteriori informazioni, consulta la Panoramica del sistema XDM.

L’utilizzo degli schemi in Experience Platform offre diversi vantaggi chiave. In primo luogo, gli schemi consentono una migliore governance dei dati e la loro minimizzazione, il che è particolarmente importante con le normative sulla privacy. In secondo luogo, la creazione di schemi con i componenti standard di Adobe consente di ottenere informazioni predefinite e l’utilizzo di servizi AI/ML con personalizzazioni minime. Infine, gli schemi forniscono l’infrastruttura necessaria per condividere informazioni approfondite sui dati e orchestrare in modo efficiente.

Pianificazione dello schema planning

Il primo passaggio nella creazione di uno schema consiste nel determinare il concetto, o oggetto reale, che si sta tentando di acquisire all’interno dello schema. Dopo aver identificato il concetto che si sta tentando di descrivere, iniziare a pianificare lo schema pensando ad aspetti quali il tipo di dati, i potenziali campi di identità e l'evoluzione futura dello schema.

Comportamenti dei dati in Experience Platform data-behaviors

I dati da utilizzare in Experience Platform sono raggruppati in due tipi di comportamento:

Tutti gli schemi XDM descrivono dati che possono essere classificati come record o serie temporali. Il comportamento dei dati di uno schema è definito dalla classe dello schema, che viene assegnata a uno schema al momento della creazione. Le classi XDM sono descritte più avanti in questo documento.

Sia gli schemi record che le serie temporali contengono una mappa di identità (xdm:identityMap). Questo campo contiene la rappresentazione dell’identità di un soggetto, tratta dai campi contrassegnati come "Identità" come descritto nella sezione successiva.

Identità identity

Gli schemi vengono utilizzati per acquisire i dati in Experience Platform. Questi dati possono essere utilizzati in più servizi per creare una singola vista unificata di una singola entità. Pertanto, durante la progettazione di schemi per le identità dei clienti, è importante considerare quali campi possono essere utilizzati per identificare un soggetto, indipendentemente da dove possono provenire i dati.

Per facilitare questo processo, i campi chiave all’interno degli schemi possono essere contrassegnati come identità. Al momento dell'acquisizione dei dati, i dati contenuti in tali campi vengono inseriti nel "grafo identità" dell'utente. È quindi possibile accedere ai dati del grafico da Real-Time Customer Profile e da altri servizi di Experience Platform per fornire una visualizzazione combinata di ogni singolo cliente.

I campi comunemente contrassegnati come "Identità" includono: indirizzo e-mail, numero di telefono, Experience Cloud ID (ECID), ID CRM o altri campi ID univoci. Considera eventuali identificatori univoci specifici dell'organizzazione, in quanto potrebbero essere validi anche per i campi "Identity".

È importante considerare le identità dei clienti durante la fase di pianificazione dello schema per garantire che i dati vengano raccolti per creare il profilo più solido possibile. Per ulteriori informazioni su come le informazioni sulle identità possono aiutarti a fornire esperienze digitali ai tuoi clienti, consulta la Panoramica del servizio Identity. Consulta il documento sulle best practice per la modellazione dati per suggerimenti sull'utilizzo delle identità durante la creazione di uno schema.

Esistono due modi per inviare dati di identità a Platform:

identityMap identityMap

identityMap è un campo di tipo mappa che descrive i vari valori di identità di un individuo, insieme ai relativi spazi dei nomi associati. Questo campo può essere utilizzato per fornire informazioni sull’identità per gli schemi, anziché definire valori di identità all’interno della struttura dello schema stesso.

L'inconveniente principale dell'utilizzo di identityMap è che le identità diventano incorporate nei dati e di conseguenza meno visibili. Se acquisisci dati non elaborati, devi invece definire singoli campi di identità all’interno della struttura dello schema effettiva.

Tuttavia, le mappe di identità possono essere utili se per uno schema è presente un numero variabile di identità o se si desidera inserire dati da origini che memorizzano le identità (ad esempio Airship o Adobe Audience Manager). Inoltre, le mappe di identità sono necessarie se si utilizza Adobe Experience Platform Mobile SDK.

Di seguito è riportato un esempio di mappa di identità semplice:

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": true
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "CRMID": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": false
    }
  ]
}

Come illustrato nell'esempio precedente, ogni chiave nell'oggetto identityMap rappresenta uno spazio dei nomi di identità. Il valore di ogni chiave è una matrice di oggetti che rappresenta i valori di identità (id) per il rispettivo spazio dei nomi. Consulta la documentazione di Identity Service per un elenco di spazi dei nomi di identità standard riconosciuti dalle applicazioni Adobe.

Principi di evoluzione dello schema evolution

Con l’evolversi della natura delle esperienze digitali, devono evolversi anche gli schemi utilizzati per rappresentarle. Uno schema ben progettato è quindi in grado di adattarsi ed evolvere secondo necessità, senza causare modifiche distruttive alle versioni precedenti dello schema.

Poiché mantenere la compatibilità con le versioni precedenti è fondamentale per l’evoluzione dello schema, Experience Platform applica un principio di controllo delle versioni puramente additivo. Questo principio garantisce che eventuali revisioni allo schema risultino solo in aggiornamenti e modifiche non distruttivi. In altre parole, le modifiche che causano interruzioni non sono supportate.

La tabella seguente suddivide le modifiche supportate durante la modifica di schemi, gruppi di campi e tipi di dati:

*Fare riferimento alla sezione seguente per importanti considerazioni relative all'impostazione di nuovi campi obbligatori.

Campi obbligatori

I singoli campi dello schema possono essere contrassegnati come obbligatori, il che significa che qualsiasi record acquisito deve contenere i dati in tali campi per superare la convalida. Ad esempio, l’impostazione del campo di identità principale di uno schema come richiesto può contribuire a garantire che tutti i record acquisiti partecipino a Real-Time Customer Profile. Allo stesso modo, l’impostazione di un campo marca temporale come richiesto garantisce che tutti gli eventi delle serie temporali siano conservati in modo cronologico.

Impostazione dei campi come richiesto dopo l’acquisizione post-ingestion-required-fields

Se un campo è stato utilizzato per acquisire i dati e non è stato originariamente impostato come richiesto, è possibile che per alcuni record sia presente un valore Null. Se imposti questo campo come obbligatorio dopo l’acquisizione, tutti i record futuri devono contenere un valore per questo campo, anche se i record storici possono essere nulli.

Quando imposti un campo precedentemente facoltativo come richiesto, tieni presente quanto segue:

Schemi e acquisizione di dati

Per acquisire i dati in Experience Platform, è necessario prima creare un set di dati. I set di dati sono i blocchi predefiniti per la trasformazione e il tracciamento dei dati per Catalog Service e in genere rappresentano tabelle o file che contengono dati acquisiti. Tutti i set di dati si basano su schemi XDM esistenti, che forniscono vincoli per ciò che i dati acquisiti devono contenere e per come devono essere strutturati. Per ulteriori informazioni, consulta la panoramica su Acquisizione dati Adobe Experience Platform.

Blocchi predefiniti di uno schema schema-building-blocks

In Experience Platform viene utilizzato un approccio di composizione in cui i blocchi predefiniti standard vengono combinati per creare schemi. Questo approccio promuove la riutilizzabilità dei componenti esistenti e favorisce la standardizzazione nel settore per supportare schemi e componenti dei fornitori in Platform.

Gli schemi vengono composti utilizzando la seguente formula:

Gruppo campi classe + schema;ast; = Schema XDM

*Uno schema è composto da una classe e da zero o più gruppi di campi dello schema. Ciò significa che è possibile comporre uno schema di set di dati senza utilizzare affatto i gruppi di campi.

Classe class

La composizione di uno schema inizia assegnando una classe. Le classi definiscono gli aspetti comportamentali dei dati che lo schema conterrà (record o serie temporali). Inoltre, le classi descrivono il minor numero di proprietà comuni che tutti gli schemi basati su tale classe dovrebbero includere e forniscono un modo per unire più set di dati compatibili.

La classe di uno schema determina quali gruppi di campi sono idonei per l’utilizzo in tale schema. Questo argomento viene discusso più dettagliatamente nella sezione successiva.

Adobe fornisce diverse classi XDM standard ("core"). Due di queste classi, XDM Individual Profile e XDM ExperienceEvent, sono necessarie per quasi tutti i processi di Platform downstream. Oltre a queste classi principali, puoi anche creare classi personalizzate per descrivere casi d’uso più specifici per la tua organizzazione. Le classi personalizzate vengono definite da un’organizzazione quando non sono disponibili classi core definite da Adobe per descrivere un caso d’uso univoco.

La schermata seguente illustra come le classi sono rappresentate nell’interfaccia utente di Platform. Poiché lo schema di esempio visualizzato non contiene gruppi di campi, tutti i campi visualizzati vengono forniti dalla classe dello schema (Profilo individuale XDM).

Per l'elenco più aggiornato delle classi XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.

Gruppo di campi field-group

Un gruppo di campi è un componente riutilizzabile che definisce uno o più campi che implementano determinate funzioni come i dati personali, le preferenze di hotel o l’indirizzo. I gruppi di campi sono destinati a essere inclusi come parte di uno schema che implementa una classe compatibile.

I gruppi di campi definiscono con quali classi sono compatibili, in base al comportamento dei dati che rappresentano (record o serie temporali). Ciò significa che non tutti i gruppi di campi sono disponibili per l'utilizzo con tutte le classi.

L'Experience Platform include molti gruppi di campi di Adobe standard, consentendo ai fornitori di definire gruppi di campi per i propri utenti e ai singoli utenti di definire gruppi di campi per concetti specifici.

Ad esempio, per acquisire dettagli quali "Nome" e "Indirizzo principale" per lo schema "Membri fedeltà", è possibile utilizzare gruppi di campi standard che definiscono tali concetti comuni. Tuttavia, concetti più specifici dell’organizzazione (ad esempio dettagli del programma fedeltà personalizzato o attributi di prodotto) che potrebbero non essere coperti dai gruppi di campi standard. In questo caso, è necessario definire un proprio gruppo di campi per acquisire queste informazioni.

Gli schemi sono composti da "zero o più" gruppi di campi, pertanto puoi comporre uno schema valido senza utilizzare alcun gruppo di campi.

La schermata seguente illustra come i gruppi di campi sono rappresentati nell’interfaccia utente di Platform. Un singolo gruppo di campi (Dettagli demografici) viene aggiunto a uno schema in questo esempio, che fornisce un raggruppamento di campi alla struttura dello schema.

Per l'elenco più aggiornato dei gruppi di campi XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.

Tipo di dati data-type

I tipi di dati vengono utilizzati come tipi di campi di riferimento nelle classi o negli schemi allo stesso modo dei campi letterali di base. La differenza fondamentale consiste nel fatto che i tipi di dati possono definire più sottocampi nello stesso modo dei gruppi di campi. La differenza chiave tra di essi è che i tipi di dati possono essere inclusi ovunque in uno schema aggiungendolo come "tipo di dati" di un campo. Mentre i gruppi di campi sono compatibili solo con determinate classi, i tipi di dati possono essere inclusi in qualsiasi classe padre o gruppo di campi.

In Experience Platform sono disponibili diversi tipi di dati comuni come parte di Schema Registry per supportare l'utilizzo di modelli standard per la descrizione di strutture di dati comuni. Questo è spiegato più dettagliatamente nelle esercitazioni del registro degli schemi e diventerà più chiaro man mano che si seguono i passaggi per definire i tipi di dati.

La schermata seguente illustra come i tipi di dati vengono rappresentati nell’interfaccia utente di Platform. Uno dei campi forniti dal gruppo di campi Dettagli demografici utilizza il tipo di dati "Oggetto", come indicato dal testo che segue il carattere barra verticale (|) accanto al nome del campo. Questo particolare tipo di dati fornisce diversi sottocampi che si riferiscono al nome di una singola persona, un costrutto che può essere riutilizzato per altri campi in cui è necessario acquisire il nome di una persona.

Per l'elenco più aggiornato dei tipi di dati XDM standard disponibili, fare riferimento al archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell'interfaccia utente, consulta la guida su esplorazione dei componenti XDM.

Campo field

Un campo è il blocco predefinito più semplice di uno schema. I campi forniscono vincoli relativi al tipo di dati che possono contenere definendo un tipo di dati specifico. Questi tipi di dati di base definiscono un singolo campo, mentre i tipi di dati precedentemente menzionati ti consentono di definire più sottocampi e di riutilizzare la stessa struttura a più campi in vari schemi. Pertanto, oltre a definire il "tipo di dati" di un campo come uno dei tipi di dati definiti nel Registro di sistema, Experience Platform supporta anche i seguenti tipi scalari di base:

Gli intervalli validi di questi tipi scalari possono essere ulteriormente vincolati a determinati pattern, formati, minimi/massimi o valori predefiniti. Utilizzando questi vincoli, è possibile rappresentare un'ampia gamma di tipi di campo più specifici, tra cui:

Esempio di composizione composition-example

Gli schemi vengono creati utilizzando un modello di composizione e rappresentano il formato e la struttura dei dati da acquisire in Platform. Come indicato in precedenza, questi schemi sono composti da una classe e da zero o più gruppi di campi compatibili con tale classe.

Ad esempio, uno schema che descrive gli acquisti effettuati in un punto vendita al dettaglio potrebbe essere denominato "Transazioni store". Lo schema implementa la classe XDM ExperienceEvent combinata con il gruppo di campi Commerce standard e un gruppo di campi Informazioni prodotto definito dall'utente.

Un altro schema che tiene traccia del traffico del sito Web potrebbe essere denominato "Visite Web". Implementa anche la classe XDM ExperienceEvent, ma questa volta combina il gruppo di campi Web standard.

Il diagramma seguente mostra questi schemi e i campi con il contributo di ciascun gruppo di campi. Contiene inoltre due schemi basati sulla classe XDM Individual Profile, incluso lo schema "Membri fedeltà" menzionato in precedenza in questa guida.

Unione union

Experience Platform consente di comporre schemi per casi d’uso specifici, ma ti consente anche di visualizzare un’"unione" di schemi per un tipo di classe specifico. Il diagramma precedente mostra due schemi basati sulla classe ExperienceEvent XDM e due schemi basati sulla classe XDM Individual Profile. L'unione mostrata di seguito aggrega i campi di tutti gli schemi che condividono la stessa classe (XDM ExperienceEvent e XDM Individual Profile, rispettivamente).

Attivando uno schema da utilizzare con Real-Time Customer Profile, viene incluso nell'unione per quel tipo di classe. Profile offre profili solidi e centralizzati degli attributi del cliente e un account con marca temporale per ogni evento che il cliente ha avuto in qualsiasi sistema integrato con Platform. Profile utilizza la visualizzazione unione per rappresentare questi dati e fornire una visualizzazione olistica di ogni singolo cliente.

Per ulteriori informazioni sull'utilizzo di Profile, vedere Panoramica del profilo cliente in tempo reale.

Mappatura dei file di dati su schemi XDM mapping-datafiles

Tutti i file di dati acquisiti in Experience Platform devono essere conformi alla struttura di uno schema XDM. Per ulteriori informazioni su come formattare i file di dati per rispettare le gerarchie XDM (inclusi i file di esempio), consulta il documento su trasformazioni ETL di esempio. Per informazioni generali sull'acquisizione di file di dati in Experience Platform, consulta la panoramica sull'acquisizione batch.

Schemi per tipi di pubblico esterni

Se stai inserendo in Platform tipi di pubblico da sistemi esterni, devi utilizzare i seguenti componenti per acquisirli negli schemi:

Passaggi successivi

Ora che hai compreso le nozioni di base sulla composizione dello schema, puoi iniziare a esplorare e creare schemi utilizzando Schema Registry.

Per esaminare la struttura delle due classi XDM di base e dei relativi gruppi di campi compatibili di uso comune, consulta la seguente documentazione di riferimento:

Schema Registry viene utilizzato per accedere a Schema Library in Adobe Experience Platform e fornisce un'interfaccia utente e un'API RESTful da cui tutte le risorse della libreria disponibili sono accessibili. Schema Library contiene le risorse del settore definite da Adobe, le risorse del fornitore definite dai partner Experience Platform e le classi, i gruppi di campi, i tipi di dati e gli schemi composti dai membri dell'organizzazione.

Per iniziare a comporre lo schema utilizzando l'interfaccia utente, seguire l'esercitazione Schema Editor per creare lo schema "Membri fedeltà" menzionato in questo documento.

Per iniziare a utilizzare l'API Schema Registry, leggere la Guida per gli sviluppatori dell'API del registro degli schemi. Dopo aver letto la guida per gli sviluppatori, segui i passaggi descritti nell'esercitazione su creazione di uno schema tramite l'API Schema Registry.

Appendice

Le sezioni seguenti contengono informazioni aggiuntive sui principi della composizione dello schema.

Tabelle relazionali e oggetti incorporati embedded

Quando si lavora con i database relazionali, le best practice prevedono la normalizzazione dei dati o la suddivisione di un’entità in parti discrete da visualizzare in più tabelle. Per leggere i dati nel loro insieme o aggiornare l'entità, è necessario eseguire operazioni di lettura e scrittura in più tabelle singole utilizzando JOIN.

Utilizzando gli oggetti incorporati, gli schemi XDM possono rappresentare direttamente dati complessi e memorizzarli in documenti autonomi con una struttura gerarchica. Uno dei principali vantaggi di questa struttura è che consente di eseguire query sui dati senza dover ricostruire l’entità tramite join costosi su più tabelle denormalizzate. Non esistono restrizioni rigide sul numero di livelli consentiti per la gerarchia dello schema.

Schemi e big data big-data

I sistemi digitali moderni generano una grande quantità di segnali comportamentali (dati sulle transazioni, registri web, internet delle cose, display e così via). Questi big data offrono opportunità straordinarie per ottimizzare le esperienze, ma sono difficili da utilizzare a causa della scala e della varietà dei dati. Per ottenere valore dai dati, la struttura, il formato e le definizioni devono essere standardizzati in modo da poter essere elaborati in modo coerente ed efficiente.

Gli schemi risolvono questo problema consentendo l’integrazione dei dati da più origini, la standardizzazione attraverso strutture e definizioni comuni e la condivisione tra le diverse soluzioni. Ciò consente ai processi e ai servizi successivi di rispondere a qualsiasi tipo di domanda relativa ai dati. Si allontana dall’approccio tradizionale alla modellazione dei dati, in cui tutte le domande da porre sui dati sono note in anticipo e i dati sono modellati in modo da essere conformi a tali aspettative.

Oggetti e campi in formato libero objects-v-freeform

Durante la progettazione degli schemi è necessario tenere presenti alcuni fattori chiave per la scelta degli oggetti rispetto ai campi in formato libero:

Oggetti

Di seguito sono elencati i pro e i contro dell’utilizzo di oggetti su campi in formato libero.

Pro:

Contro:

Campi in formato libero

Di seguito sono elencati i pro e i contro dell’utilizzo di campi in formato libero sugli oggetti.

Pro:

Contro: