Nozioni di base sulla composizione dello schema

Questo documento fornisce un’introduzione agli schemi Experience Data Model (XDM) e ai blocchi predefiniti, ai principi e alle best practice per la composizione degli schemi da utilizzare in Adobe Experience Platform. Per informazioni generali su XDM e su come viene utilizzato in Platform, consulta la Panoramica del sistema XDM.

Informazioni sugli schemi

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

Experience Platform mantiene questa normalizzazione semantica utilizzando gli schemi. Gli schemi sono il modo standard per descrivere i dati in Experience Platform, consentendo il riutilizzo di tutti i dati conformi agli schemi in un'organizzazione senza conflitti o anche condivisi tra più organizzazioni.

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

Flussi di lavoro basati su schema in Experience Platform

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

L'infrastruttura su cui è generato Experience Platform, nota come XDM System, agevola i flussi di lavoro basati su schema e include i pattern di consumo del servizio 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 presenta diversi vantaggi principali. 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 componenti standard di Adobe consente di ottenere informazioni predefinite e l’utilizzo di servizi AI/ML con personalizzazioni minime. Infine, gli schemi forniscono un’infrastruttura per la condivisione dei dati insights 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 tentando di descrivere, è possibile iniziare a pianificare lo schema pensando a elementi quali il tipo di dati, i campi di identità potenziali e l'evoluzione dello schema in futuro.

Comportamenti dei dati in Experience Platform

I dati destinati a essere utilizzati in Experience Platform sono raggruppati in due tipi di comportamento:

  • Dati record: Fornisce informazioni sugli attributi di un oggetto. Un soggetto potrebbe essere un'organizzazione o un individuo.
  • Dati delle 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 quando viene creato per la prima volta. Le classi XDM sono descritte più avanti in questo documento.

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

Identità

Gli schemi vengono utilizzati per acquisire i dati in Experience Platform. Questi dati possono essere utilizzati in più servizi per creare una singola visualizzazione unificata di una singola entità. Pertanto, è importante, quando pensi agli schemi, pensare alle identità dei clienti e a quali campi può essere utilizzato per identificare un soggetto indipendentemente da dove i dati potrebbero provenire.

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

I campi comunemente 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 dell'organizzazione, in quanto potrebbero essere validi anche i campi "Identity".

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

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

  1. Aggiunta di descrittori di identità ai singoli campi tramite l' interfaccia utente dell'Editor di schema o utilizzando l' API del Registro di sistema dello schema
  2. Utilizzo di un campo identityMap

identityMap

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

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

NOTA

Uno schema che utilizza identityMap può essere utilizzato come schema di origine in una relazione, ma non come schema di destinazione. Questo perché tutti gli schemi di destinazione devono avere un'identità visibile che può essere mappata in un campo di riferimento all'interno dello schema di origine. Per ulteriori informazioni sui requisiti degli schemi di origine e destinazione, consulta la guida all’interfaccia utente su relazioni .

Tuttavia, le mappe di identità possono risultare particolarmente utili se si inseriscono dati provenienti da origini che memorizzano le identità insieme (ad esempio Airship o Adobe Audience Manager) o se è presente un numero variabile di identità per uno schema. Inoltre, le mappe di identità sono necessarie se utilizzi l' SDK di Adobe Experience Platform Mobile.

Un esempio di mappa di identità semplice è simile al seguente:

"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’oggetto identityMap rappresenta uno spazio dei nomi di identità. Il valore di ciascuna chiave è una matrice di oggetti che rappresenta i valori di identità (id) per il rispettivo namespace. Consulta la documentazione Identity Service relativa a un elenco di spazi dei nomi di identità standard riconosciuti dalle applicazioni Adobe.

NOTA

Per ogni valore di identità è inoltre possibile specificare un valore booleano che indica se il valore è un'identità primaria (primary). È necessario impostare le identità principali solo per gli schemi destinati a essere utilizzati in Real-time Customer Profile. Per ulteriori informazioni, consulta la sezione sugli schemi di unione .

Principi di evoluzione dello schema

Poiché 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 evolvere 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. Questo principio assicura che qualsiasi revisione dello schema si traduca solo in aggiornamenti e modifiche non distruttivi. In altre parole, le modifiche di interruzione non sono supportate.

NOTA

Se uno schema non è ancora stato utilizzato per acquisire i dati in Experience Platform e non è stato abilitato per l’utilizzo in Profilo cliente in tempo reale, puoi introdurre una modifica di interruzione a tale schema. Tuttavia, una volta che lo schema è stato utilizzato in Platform, deve rispettare i criteri di controllo delle versioni aggiuntive.

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

Modifiche supportate Interruzione delle modifiche (non supportata)
  • Aggiunta di nuovi campi alla risorsa
  • Impostazione di un campo obbligatorio come facoltativo
  • Modifica del nome visualizzato e della descrizione della risorsa
  • Abilitazione dello schema per partecipare al profilo
  • Rimozione di campi definiti in precedenza
  • Introduzione di nuovi campi obbligatori
  • Ridenominazione o ridefinizione dei campi esistenti
  • Rimozione o limitazione dei valori di campo supportati in precedenza
  • Spostamento di campi esistenti in una posizione diversa nella struttura
  • Eliminazione dello schema
  • Disabilitazione dello schema dalla partecipazione al profilo

Schemi e acquisizione 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 Service e 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 devono essere strutturati. Per ulteriori informazioni, consulta la panoramica su Acquisizione dati Adobe Experience Platform .

Blocco di uno schema

Experience Platform utilizza 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 in tutto il settore per supportare schemi e componenti dei fornitori in Platform.

Gli schemi sono composti con la seguente formula:

Classe + Schema Field Group* = 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

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 numero più piccolo 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 saranno idonei per essere utilizzati in tale schema. Questo è 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 della piattaforma a valle. Inoltre, puoi creare classi personalizzate per descrivere casi d’uso più specifici per la tua organizzazione. Le classi personalizzate sono definite da un'organizzazione quando non sono disponibili classi principali definite da Adobi 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 mostrato non contiene gruppi di campi, tutti i campi visualizzati sono forniti dalla classe dello schema (Profilo individuale XDM).

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

Gruppo di campi

Un gruppo di campi è un componente riutilizzabile che definisce uno o più campi che implementano determinate funzioni quali dettagli personali, preferenze alberghiere o indirizzo. I gruppi di campi devono essere inclusi come parte di uno schema che implementa una classe compatibile.

I gruppi di campi 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 gruppi di campi sono disponibili per l'uso con tutte le classi.

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

Ad esempio, per acquisire dettagli quali "Nome" e "Indirizzo iniziale" per lo schema "Membri fedeltà", puoi utilizzare gruppi di campi standard che definiscono tali concetti comuni. Tuttavia, i concetti specifici dei casi di utilizzo meno comuni (come "Livello di programma fedeltà") spesso non dispongono di un gruppo di campi predefinito. In questo caso, è necessario definire un proprio gruppo di campi per acquisire queste informazioni.

NOTA

È consigliabile utilizzare i gruppi di campi standard ogni volta che è possibile negli schemi, in quanto questi campi vengono implicitamente compresi dai servizi Experience Platform e assicurano una maggiore coerenza quando vengono utilizzati tra i componenti Platform.

I campi forniti dai componenti standard (come "Nome" e "Indirizzo e-mail") contengono connotazioni aggiunte oltre ai tipi di campi scalari di base, indicando a Platform che tutti i campi che condividono lo stesso tipo di dati si comportano allo stesso modo. Tale comportamento può essere considerato coerente indipendentemente da dove provengono i dati o in cui vengono utilizzati i dati Platform.

Gli schemi sono composti da gruppi di campi "zero o più", pertanto è possibile 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, consulta l' archivio XDM ufficiale. In alternativa, se preferisci visualizzare le risorse nell’interfaccia utente, puoi consultare la guida sull’ esplorazione dei componenti XDM .

Tipo di dati

I tipi di dati vengono utilizzati come tipi di campi di riferimento in classi o schemi allo stesso modo dei campi letterali di base. La differenza principale consiste nel fatto che i tipi di dati possono definire più campi secondari. Analogamente a un gruppo di campi, un tipo di dati consente l’utilizzo coerente di una struttura a più campi, ma offre una flessibilità maggiore rispetto a un gruppo di campi, in quanto un tipo di dati può essere incluso in qualsiasi punto di uno schema, aggiungendolo come "tipo di dati" di un campo.

Experience Platform fornisce una serie di tipi di dati comuni come parte del Schema Registry per supportare l'uso di pattern standard per descrivere le strutture di dati comuni. Questo è spiegato più dettagliatamente nelle Schema Registry esercitazioni, dove diventerà più chiaro man mano che segui i passaggi per definire i tipi di dati.

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

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

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 menzionati in precedenza consentono di definire più campi secondari 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 tipi scalari di base come:

  • Stringa
  • Intero
  • Doppio
  • Booleano
  • Array
  • Oggetto
SUGGERIMENTO

Per informazioni sui pro e i contro dell’utilizzo di campi modulo liberi rispetto ai campi di tipo oggetto, consultare l’ appendice .

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

  • Enum
  • Lunga
  • Breve
  • Byte
  • Data
  • Data e ora
  • Mappa
NOTA

Il tipo di campo "map" consente la creazione di dati con coppia chiave-valore, inclusi più valori per una singola chiave. Le mappe possono essere definite solo a livello di sistema, il che significa che è possibile incontrare una mappa 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 sistema dello schema contiene ulteriori informazioni sulla definizione dei tipi di campo.

Esempio di composizione

Gli schemi rappresentano il formato e la struttura dei dati che verranno acquisiti in Platform e vengono generati utilizzando un modello di composizione. Come accennato 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 negozio al dettaglio potrebbe essere denominato "Archivia transazioni". 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 a cui contribuiscono 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

Sebbene Experience Platform ti consenta di comporre schemi per casi d’uso particolari, 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, come illustrato 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, verrà 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 visualizzazione olistica di ogni singolo cliente.

Per ulteriori informazioni sulle operazioni con Profile, consulta la Panoramica sul profilo cliente in tempo reale.

Mappatura di file di dati su schemi XDM

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 conformarsi alle gerarchie XDM (inclusi i file di esempio), consulta il documento sulle trasformazioni ETL di esempio. Per informazioni generali sull’acquisizione di file di dati in Experience Platform, consulta la panoramica sull’acquisizione batch.

Schemi per segmenti esterni

Se porti segmenti da sistemi esterni in Platform, devi utilizzare i seguenti componenti per acquisirli negli schemi:

  • Classe di definizione del segmento: Utilizza questa classe standard per acquisire gli attributi chiave di una definizione di segmento esterna.
  • Gruppo di campi dettagli appartenenza al segmento: Aggiungi questo gruppo di campi al tuo schema Profileschema individuale XDM per associare i profili dei clienti a segmenti specifici.

Passaggi successivi

Ora che conosci le nozioni di base della composizione dello schema, sei pronto per iniziare a esplorare e creare schemi utilizzando il Schema Registry.

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

L’ Schema Registry viene utilizzato per accedere a Schema Library all’interno di Adobe Experience Platform e fornisce un’interfaccia utente e un’API RESTful da cui sono accessibili tutte le risorse della libreria disponibili. Il Schema Library contiene le risorse di 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 che sono stati composti da membri dell'organizzazione.

Per iniziare a comporre lo schema utilizzando l'interfaccia utente, segui insieme all' tutorial Editor di schema per creare lo schema "Membri fedeltà" menzionato in questo documento.

Per iniziare a utilizzare l'API Schema Registry, leggi la Guida per gli sviluppatori dell'API del Registro di sistema . Dopo aver letto la guida per gli sviluppatori, segui i passaggi descritti nell'esercitazione su creazione di uno schema utilizzando l'API del Registro di sistema dello schema.

Appendice

Le sezioni seguenti contengono informazioni aggiuntive relative ai principi di composizione dello schema.

Tabelle relazionali e oggetti incorporati

Quando si lavora con database relazionali, le best practice prevedono la normalizzazione dei dati o la suddivisione di un’entità in parti discrete che vengono quindi visualizzate su 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 archiviarli in documenti indipendenti con 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 vi sono restrizioni difficili al numero di livelli possibili nella gerarchia dello schema.

Schemi e big data

I sistemi digitali moderni generano una grande quantità di segnali comportamentali (dati delle transazioni, registri web, Internet di cose, visualizzazione e così via). Questi big data offrono straordinarie opportunità di ottimizzazione delle esperienze, ma sono difficili da utilizzare a causa della scala e della varietà dei dati. Al fine di trarre 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ù fonti, standardizzati attraverso strutture e definizioni comuni e condivisi tra le soluzioni. Ciò 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, in cui tutte le domande che verranno poste sui dati sono note in anticipo e i dati sono modellati per conformarsi a tali aspettative.

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 in formato libero
Aumenta la nidificazione Minore o nessuna nidificazione
Crea raggruppamenti di campi logici I campi sono posizionati in posizioni ad hoc

Oggetti

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

Pro:

  • Gli oggetti vengono utilizzati al meglio quando si desidera creare un raggruppamento logico di determinati campi.
  • Gli oggetti organizzano lo schema in modo più strutturato.
  • Gli oggetti contribuiscono indirettamente alla creazione di una buona struttura di menu nell’interfaccia utente del Generatore di segmenti. I campi raggruppati all’interno dello schema si riflettono direttamente nella struttura delle cartelle fornita nell’interfaccia utente del Generatore di segmenti.

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 in formato libero

Di seguito sono elencati i pro e i contro dell’uso dei campi modulo libero sugli oggetti.

Pro:

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

Cons:

  • La posizione dei campi in formato libero all’interno dello schema è ad hoc, il che significa che vengono visualizzati in ordine alfabetico all’interno dell’Editor di schema. In questo modo gli schemi possono essere meno strutturati e campi modulo gratuiti simili possono risultare molto separati a seconda dei loro nomi.

In questa pagina