Nozioni di base sulla composizione dello schema

Questo documento fornisce un'introduzione agli schemi Experience Data Model (XDM) e ai blocchi costitutivi, ai principi e alle procedure ottimali per la composizione degli schemi da utilizzare in Adobe Experience Platform. Per informazioni generali su XDM e come viene utilizzato all'interno Platform, consultate la panoramica di sistemaXDM.

Informazioni sugli schemi

Uno schema è un insieme di regole che rappresentano e convalidano la struttura e il formato dei dati. A un livello elevato, gli schemi forniscono una definizione astratta di un oggetto reale (ad esempio una persona) e delineano quali dati includere in ciascuna 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 man mano che si spostano tra i sistemi. Queste definizioni standard consentono l'interpretazione coerente dei dati, indipendentemente dall'origine, e rimuovono la necessità di una traduzione tra le applicazioni.

Experience Platform mantiene questa normalizzazione semantica attraverso l'uso di schemi. Gli schemi sono il modo standard per descrivere i dati in Experience Platform, consentendo a tutti i dati conformi agli schemi di essere riutilizzabili senza conflitti all'interno di un'organizzazione e persino di essere condivisibili tra più organizzazioni.

Tabelle relazionali e oggetti incorporati

Quando si utilizzano i database relazionali, le best practice prevedono la normalizzazione dei dati o la suddivisione di un'entità in parti distinte che vengono visualizzate in più tabelle. Per leggere i dati nel loro insieme o aggiornare l'entità, le operazioni di lettura e scrittura devono essere eseguite in più singole tabelle utilizzando JOIN.

Utilizzando gli oggetti incorporati, gli schemi XDM possono rappresentare direttamente dati complessi e archiviarli in documenti indipendenti 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 a più tabelle denormalizzate. Non esistono vincoli rigidi per il numero di livelli possibili per la gerarchia dello schema.

Schemi e grandi dati

I sistemi digitali moderni generano una vasta quantità di segnali comportamentali (dati sulle transazioni, registri web, Internet di cose, visualizzazione e così via). Questi grandi dati offrono straordinarie opportunità di ottimizzare le esperienze, ma sono difficili da utilizzare a causa della scala e della varietà dei dati. Al fine di ottenere valore dai dati, la struttura, il formato e le definizioni devono essere standardizzati in modo che possano essere elaborati in modo coerente ed efficiente.

Gli schemi risolvono questo problema consentendo l'integrazione dei dati da più fonti, standardizzati attraverso strutture e definizioni comuni e condivisi tra soluzioni. Questo consente ai processi e ai servizi successivi di rispondere a qualsiasi tipo di domanda posta sui dati, allontanandosi dall'approccio tradizionale alla modellazione dei dati, dove tutte le domande che verranno poste sui dati sono note in anticipo e i dati sono modellati per conformarsi a tali aspettative.

Flussi di lavoro basati su schema in Experience Platform

La standardizzazione è un concetto chiave dietro Experience Platform. XDM, guidato da Adobe, è uno sforzo per standardizzare i dati sull'esperienza cliente e definire schemi standard per la gestione dell'esperienza cliente.

L'infrastruttura su cui Experience Platform viene creata, nota come XDM System, facilita i flussi di lavoro basati su schemi e include i pattern di utilizzo dei servizi, Schema Registry, Schema Editori metadati dello schema e i relativi pattern. See the XDM System overview for more information.

Ci sono diversi vantaggi chiave per costruire e utilizzare schemi in Experience Platform. In primo luogo, gli schemi consentono una migliore governance dei dati e una minimizzazione dei dati, che è particolarmente importante con le normative sulla privacy. In secondo luogo, la creazione di schemi con Adobe componenti standard consente di ottenere informazioni dettagliate e l'utilizzo dei servizi AI/ML con personalizzazioni minime. Infine, gli schemi forniscono infrastrutture per la condivisione dei dati e un'orchestrazione efficiente.

Pianificazione dello schema

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. Una volta identificato il concetto che si sta cercando di descrivere, è possibile iniziare a pianificare lo schema pensando a cose come il tipo di dati, campi di identità potenziali e come lo schema potrebbe evolvere in futuro.

Comportamenti dei dati in Experience Platform

I dati destinati all'uso in Experience Platform sono raggruppati in due tipi di comportamento:

  • Record data: Fornisce informazioni sugli attributi di un oggetto. Un soggetto potrebbe essere un'organizzazione o un individuo.
  • Dati serie temporali: Fornisce un'istantanea del sistema al momento in cui un'azione è stata eseguita direttamente o indirettamente da un soggetto del record.

Tutti gli schemi XDM descrivono i 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 sua prima creazione. Le classi XDM sono descritte in dettaglio più avanti in questo documento.

Gli schemi di record e di serie temporali contengono una mappa di identità (xdm:identityMap). Questo campo contiene la rappresentazione di identità di un oggetto, ricavata dai campi contrassegnati come "Identità" come descritto nella sezione successiva.

Identity

Gli schemi vengono utilizzati per assimilare i dati in Experience Platform. Questi dati possono essere utilizzati tra più servizi per creare una singola vista unificata di una singola entità. Pertanto, è importante, quando si pensa agli schemi, pensare alle identità dei clienti e ai campi che possono essere utilizzati per identificare un oggetto, a prescindere da dove i dati provengano.

Per facilitare questo processo, i campi chiave negli schemi possono essere contrassegnati come identità. Al momento dell'inserimento dei dati, i dati contenuti in tali campi vengono inseriti nel campo "Identity Graph" di tale individuo. I dati del grafico sono quindi accessibili da Real-time Customer Profile e da altri Experience Platform servizi per fornire una visualizzazione unita di ogni singolo cliente.

I campi generalmente contrassegnati come "Identity" includono: indirizzo e-mail, numero di telefono, Experience Cloud ID (ECID), ID CRM o altri campi ID univoci. È inoltre necessario considerare eventuali identificatori univoci specifici della propria organizzazione, in quanto possono essere buoni anche "Identity" campi.

È importante considerare le identità dei clienti durante la fase di pianificazione dello schema, in modo da garantire che i dati vengano uniti per creare il profilo più affidabile possibile. Consulta la panoramica su Adobe Experience Platform Identity Service per ulteriori informazioni su come le informazioni sull'identità possono aiutarti a fornire esperienze digitali ai tuoi clienti.

xdm:identityMap

xdm:identityMap è un campo del tipo di 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 di identità per gli schemi, invece di definire valori di identità all'interno della struttura dello schema stesso.

Esempio di mappa identità semplice:

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

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

Nota

È possibile specificare un valore booleano per specificare se il valore è un'identità primaria (primary) anche per ciascun valore di identità. Le identità primarie devono essere impostate solo per gli schemi destinati a essere utilizzati in Real-time Customer Profile. Per ulteriori informazioni, vedere la sezione sugli schemi di unione.

Principi di evoluzione dello schema

Mentre la natura delle esperienze digitali continua ad evolversi, devono evolversi anche gli schemi utilizzati per rappresentarle. Uno schema ben progettato è quindi in grado di adattarsi ed evolversi in base alle esigenze, senza causare modifiche distruttive alle versioni precedenti dello schema.

Poiché il mantenimento della compatibilità con le versioni precedenti è fondamentale per l'evoluzione dello schema, Experience Platform applica un principio di controllo delle versioni puramente additivo, in modo da garantire che qualsiasi revisione dello schema produca solo aggiornamenti e modifiche non distruttivi. In altre parole, le modifiche di interruzione non sono supportate.

Modifiche supportate Interruzione delle modifiche (non supportata)
  • Aggiunta di nuovi campi a uno schema esistente
  • Impostazione di un campo obbligatorio come facoltativo
  • Rimozione di campi definiti in precedenza
  • Introduzione di nuovi campi obbligatori
  • Ridenominazione o ridefinizione di campi esistenti
  • Rimozione o limitazione di valori di campo supportati in precedenza
  • Spostamento degli attributi in una diversa posizione nella struttura
Nota

Se uno schema non è ancora stato utilizzato per assimilare i dati in Experience Platform, è possibile introdurre una modifica di interruzione nello schema. Tuttavia, una volta utilizzato in Platform, lo schema deve rispettare i criteri di controllo delle versioni aggiuntivi.

Schemi e acquisizione dei dati

Per acquisire i dati in Experience Platform, è necessario creare prima un set di dati. I set di dati sono gli elementi costitutivi della trasformazione e del tracciamento dei dati per Catalog Servicee generalmente rappresentano tabelle o file contenenti dati acquisiti. Tutti i set di dati si basano sugli schemi XDM esistenti, che forniscono vincoli per ciò che i dati acquisiti devono contenere e per come dovrebbero essere strutturati. Per ulteriori informazioni, consulta la panoramica su Adobe Experience Platform Data Ingestion .

Creazione di blocchi di uno schema

Experience Platform utilizza un approccio di composizione in cui i blocchi di generazione standard vengono combinati per creare schemi. Questo approccio promuove la riutilizzabilità dei componenti esistenti e favorisce la standardizzazione in tutto il settore per supportare schemi e componenti dei fornitori in Platform.

Gli schemi sono composti utilizzando la seguente formula:

Classe + Mixin* = Schema XDM

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

Class

La composizione di uno schema inizia con l'assegnazione di 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 l'unione di più set di dati compatibili.

La classe di uno schema determina quali mixin saranno utilizzabili in tale schema. Questo argomento viene discusso più dettagliatamente nella sezionesuccessiva.

Adobe fornisce due classi XDM standard ("core"): XDM Individual Profile e XDM ExperienceEvent. Inoltre, è possibile creare classi personalizzate per descrivere casi d'uso più specifici per l'organizzazione. Le classi personalizzate sono definite da un'organizzazione quando non sono disponibili classi di base definite dal Adobe per descrivere un caso d'uso univoco.

Mixin

Un mixin è un componente riutilizzabile che definisce uno o più campi che implementano determinate funzioni come i dati personali, le preferenze alberghiere o l'indirizzo. Le mixine sono destinate ad essere incluse come parte di uno schema che implementa una classe compatibile.

Le combinazioni definiscono le classi con cui sono compatibili in base al comportamento dei dati che rappresentano (record o serie temporali). Ciò significa che non tutti i mixin sono disponibili per l'uso con tutte le classi.

Experience Platform include molti mixer standard Adobe, consentendo al contempo ai fornitori di definire mixin per i propri utenti e ai singoli utenti di definire mixin base ai propri concetti specifici.

Ad esempio, per acquisire dettagli quali "First Name" e "Home Address" per lo schema "Loyalty Members", potreste utilizzare mixin standard che definiscono questi concetti comuni. Tuttavia, i concetti specifici per casi di utilizzo meno comuni (come "Loyalty Program Level") spesso non hanno un mixin predefinito. In questo caso, per acquisire queste informazioni dovete definire un mixin personalizzato.

Tenere presente che gli schemi sono composti da "zero o più" mixin, pertanto è possibile comporre uno schema valido senza utilizzare alcun mixin.

Per un elenco di tutti i mixin standard correnti, fare riferimento al repository XDMufficiale.

Data type

I tipi di dati sono utilizzati come tipi di campi di riferimento in classi o schemi allo stesso modo dei campi letterali di base. La differenza principale sta nel fatto che i tipi di dati possono definire più sottocampi. Analogamente a un mixin, un tipo di dati consente l'uso coerente di una struttura multi-campo, ma offre maggiore flessibilità rispetto a un mixin, perché un tipo di dati può essere incluso in qualsiasi punto dello schema aggiungendo il tipo di dati "tipo" di un campo.

Nota

Per ulteriori informazioni sulle differenze tra i mixini e i tipi di dati, vedere l' appendice , e sui pro e contro dell'uso uno sull'altro per casi d'uso simili.

Experience Platform fornisce una serie di tipi di dati comuni come parte del Schema Registry supporto all'uso di pattern standard per la descrizione di strutture di dati comuni. Questo è spiegato più dettagliatamente nelle Schema Registry esercitazioni, dove diventerà più chiaro man mano che si passano i passaggi per definire i tipi di dati.

Campo

Un campo è il blocco predefinito più basilare 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 indicati consentono di definire più sottocampi e di riutilizzare la stessa struttura multi-campo in vari schemi. Pertanto, oltre a definire il "tipo di dati" di un campo come uno dei tipi di dati definiti nel registro, Experience Platform supporta tipi scalari di base come:

  • Stringa
  • Intero
  • Doppio
  • Booleano
  • Matrice
  • Oggetto
SUGGERIMENTO

Per informazioni sui vantaggi e gli svantaggi dell’uso dei campi a forma libera nei campi di tipo oggetto, vedere l’appendice .

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:

  • Enum
  • Long
  • Breve
  • Byte
  • Data
  • Data-ora
  • Mappa
Nota

Il tipo di campo "map" consente la creazione di dati con coppie chiave-valore, inclusi più valori per una singola chiave. Le mappe possono essere definite solo a livello di sistema, il che significa che è possibile che una mappa venga visualizzata in uno schema definito dal settore o dal fornitore, ma non è disponibile per l'uso nei campi definiti dall'utente. La guida per gli sviluppatori API del Registro di schema contiene ulteriori informazioni sulla definizione dei tipi di campo.

Alcune operazioni di dati utilizzate dai servizi e dalle applicazioni a valle impongono vincoli su tipi di campo specifici. I servizi interessati includono, tra l'altro:

Prima di creare uno schema da utilizzare nei servizi a valle, consultare la documentazione appropriata per tali servizi al fine di comprendere meglio i requisiti di campo e i vincoli per le operazioni di dati a cui lo schema è destinato.

Campi XDM

Oltre ai campi di base e alla possibilità di definire i propri tipi di dati, XDM fornisce un set standard di campi e tipi di dati che vengono implicitamente compresi dai Experience Platform servizi e che assicurano una maggiore coerenza quando vengono utilizzati tra Platform i componenti.

Questi campi, come "Nome" e "Indirizzo e-mail" contengono connotazioni aggiunte oltre i tipi di campi scalari di base, a indicare Platform che tutti i campi che condividono lo stesso tipo di dati XDM si comportano allo stesso modo. Questo comportamento può essere considerato coerente, indipendentemente da dove provengano i dati, o in quale Platform servizio vengono utilizzati i dati.

Per un elenco completo dei campi XDM disponibili, consultate il dizionario dei campi XDM. Si consiglia di utilizzare i campi e i tipi di dati XDM laddove possibile per supportare coerenza e standardizzazione in tutti Experience Platform.

Esempio di composizione

Gli schemi rappresentano il formato e la struttura dei dati che verranno assimilati Platforme creati utilizzando un modello di composizione. Come già detto, questi schemi sono composti da una classe e da zero o più mixin compatibili con tale classe.

Ad esempio, uno schema che descrive gli acquisti effettuati in un negozio al dettaglio potrebbe essere denominato "Store Transactions". Lo schema implementa la XDM ExperienceEvent classe combinata con il Commerce mixin standard e un Product Info mixin definito dall'utente.

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

Il diagramma seguente mostra questi schemi e i campi che contribuiscono a ciascun mixin. Contiene inoltre due schemi basati sulla XDM Individual Profile classe, incluso lo schema "Loyalty Members" menzionato in precedenza in questa guida.

Unione

Anche se Experience Platform consente di comporre schemi per casi di utilizzo particolari, è anche possibile visualizzare una "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 XDM Individual Profile classe. L'unione, come illustrato di seguito, aggrega i campi di tutti gli schemi che condividono la stessa classe (XDM ExperienceEvent e, rispettivamente, XDM Individual Profile).

Abilitando uno schema da utilizzare con Real-time Customer Profile, esso sarà incluso nell'unione per quel tipo di classe. Profile fornisce profili affidabili e centralizzati degli attributi del cliente e un account con marca temporale di 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 visione olistica di ciascun cliente.

Per ulteriori informazioni sull'utilizzo Profile, consulta la panoramica Profilo clientein tempo reale.

Mappatura dei file di dati agli schemi XDM

Tutti i file di dati acquisiti Experience Platform devono essere conformi alla struttura di uno schema XDM. Per ulteriori informazioni su come formattare i file di dati per conformarsi alle gerarchie XDM (inclusi i file di esempio), consultate il documento sulle trasformazioni ETL diesempio. Per informazioni generali sull’assimilazione di file di dati in Experience Platform, consultate la panoramica sull’assimilazionebatch.

Passaggi successivi

Ora che si conoscono le nozioni di base della composizione dello schema, è possibile iniziare a esplorare e a creare schemi utilizzando l' Schema Registry.

Per esaminare la struttura delle due classi XDM di base e i rispettivi mixin compatibili comunemente utilizzati, consulta la seguente documentazione di riferimento:

L' Schema Registry interfaccia viene utilizzata per accedere all' Schema Library interno di Adobe Experience Platform e fornisce un'interfaccia utente e un'API RESTful da cui sono accessibili tutte le risorse libreria disponibili. Il Schema Library contiene risorse del settore definite da Adobe, risorse del fornitore definite dai Experience Platform partner e classi, mixin, tipi di dati e schemi che sono stati composti da membri dell'organizzazione.

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

Per iniziare a utilizzare l' Schema Registry API, iniziare leggendo la guida per lo sviluppatore di API del Registro di schema. Dopo aver letto la guida per gli sviluppatori, segui i passaggi descritti nell'esercitazione sulla creazione di uno schema tramite l'APIdel Registro di sistema dello schema.

Appendice

La sezione seguente contiene informazioni aggiuntive sui principi della composizione dello schema.

Oggetti e campi a forma libera

Durante la progettazione degli schemi, è necessario tenere in considerazione alcuni fattori chiave nella scelta degli oggetti rispetto ai campi a forma libera:

Oggetti Campi per modulo libero
Aumenta la nidificazione Minore o nessuna nidificazione
Crea raggruppamenti di campi logici I campi vengono inseriti in posizioni ad hoc

Oggetti

Di seguito sono elencati i pro e i contro dell'uso degli oggetti nei campi a forma libera.

Pros:

  • Gli oggetti sono utili per creare un raggruppamento logico di determinati campi.
  • Gli oggetti organizzano lo schema in modo più strutturato.
  • Gli oggetti facilitano indirettamente la creazione di una buona struttura di menu nell’interfaccia utente di Generatore di segmenti. I campi raggruppati nello schema si riflettono direttamente nella struttura di cartelle fornita nell’interfaccia utente di Segment Builder.

Cons:

  • I campi diventano più nidificati.
  • Quando si utilizza Adobe Experience Platform Query Service, è necessario fornire stringhe di riferimento più lunghe ai campi di query nidificati negli oggetti.

Campi per modulo libero

Di seguito sono elencati i pro e i contro dell'utilizzo di campi a forma libera sugli oggetti.

Pros:

  • I campi a forma libera vengono creati direttamente sotto l'oggetto principale dello schema (_tenantId), aumentando la visibilità.
  • Le stringhe di riferimento per i campi a forma libera tendono ad essere più corte quando si utilizza il servizio Query.

Cons:

  • La posizione dei campi a forma libera all'interno dello schema è ad hoc, ovvero sono visualizzati in ordine alfabetico nell'Editor di schema. In questo modo gli schemi potrebbero risultare meno strutturati e campi gratuiti simili potrebbero risultare molto separati a seconda dei nomi.

In questa pagina