Principes de base de la composition des schémas

This document provides an introduction to Experience Data Model (XDM) schemas and the building blocks, principles, and best practices for composing schemas to be used in Adobe Experience Platform. For general information on XDM and how it is used within Platform, see the XDM System overview.

Compréhension des schémas

Un schéma est un jeu de règles qui représente et valide la structure et le format des données. À un niveau élevé, les schémas fournissent une définition abstraite d’un objet du monde réel (une personne, par exemple) et indiquent les données à inclure dans chaque instance de cet objet (comme le prénom, le nom, l’anniversaire, etc.).

Outre la description de la structure des données, les schémas appliquent des contraintes et des attentes aux données de manière à ce qu’elles puissent être validées lorsqu’elles sont déplacées d’un système à l’autre. Ces définitions standard permettent d’interpréter les données de manière cohérente, quelle que soit leur origine, et éliminent la nécessité d’une traduction entre les applications.

Experience Platform maintient cette normalisation sémantique grâce à l’utilisation de schémas. Schemas are the standard way of describing data in Experience Platform, allowing all data that conforms to schemas to be reusable without conflicts across an organization and even to be sharable between multiple organizations.

Tableaux relationnels et objets intégrés

Lorsque vous travaillez avec des bases de données relationnelles, les bonnes pratiques consistent à normaliser les données ou à prendre une entité et à la diviser en éléments individuels qui sont ensuite affichés sur plusieurs tableaux. Pour pouvoir lire les données dans leur ensemble ou mettre à jour l’entité, des opérations de lecture et d’écriture doivent être effectuées sur plusieurs tableaux individuels à l’aide de la fonction REJOINDRE.

Grâce aux objets incorporés, les schémas XDM peuvent représenter directement des données complexes et les stocker dans des documents autonomes avec une structure hiérarchique. L’un des principaux avantages de cette structure est qu’elle vous permet d’effectuer des requêtes sur des données sans avoir à reconstruire l’entité par des liaisons onéreuses sur plusieurs tableaux dénormalisés. Il n'existe aucune restriction stricte quant au nombre de niveaux de hiérarchie de votre schéma.

Schémas et Big Data

Les systèmes numériques modernes génèrent une grande quantité de signaux comportementaux (données de transaction, journaux web, Internet des objets, affichage, etc.). Le Big Data offre des opportunités extraordinaires d’optimiser des expériences, mais les utiliser représente un véritable défi en raison de leur échelle et de la diversité des données. Pour tirer parti des données, vous devez normaliser leur structure, leur format et leurs définitions afin de les traiter de manière cohérente et efficace.

Les schémas permettent de résoudre ce problème en permettant l’intégration des données à partir de diverses sources, l’uniformisation au moyen de structures et de définitions communes et le partage entre les solutions. Cela permet aux processus et aux services suivants de répondre à tout type de questions posées sur les données, en s’éloignant de l’approche traditionnelle de la modélisation des données dans laquelle toutes les questions posées sur les données sont connues à l’avance et les données sont modélisées pour être conformes à ces attentes.

Schema-based workflows in Experience Platform

La normalisation est un concept clé derrière Experience Platform. XDM, piloté par Adobe, vise à normaliser les données d’expérience client et à définir des schémas standard pour la gestion de l’expérience client.

L’infrastructure sur laquelle Experience Platform est construite, appelée XDM System"infrastructure", facilite les workflows basés sur le schéma et inclut les Schema RegistrySchema Editormétadonnées de schéma et les schémas de consommation de services. Pour plus d’informations, consultez la présentation du système XDM.

Il y a plusieurs avantages essentiels à la construction et à l'utilisation de schémas dans Experience Platformle secteur. Tout d'abord, les schémas permettent une meilleure gouvernance des données et une meilleure minimisation des données, ce qui est particulièrement important avec la réglementation sur la protection des renseignements personnels. Deuxièmement, la création de schémas avec des composants standard de l'Adobe permet d'obtenir des informations prêtes à l'emploi et d'utiliser les services AI/ML avec un minimum de personnalisations. Enfin, les schémas fournissent une infrastructure pour le partage des données et une orchestration efficace.

Planification de votre schéma

La première étape de la conception d’un schéma consiste à déterminer le concept ou l’objet dans le monde réel que vous essayez de capturer au sein du schéma. Une fois que vous avez identifié le concept que vous essayez de décrire, vous pouvez commencer à planifier votre schéma en réfléchissant à des éléments comme le type de données, les champs d’identité potentiels et la manière dont le schéma peut évoluer dans le futur.

Data behaviors in Experience Platform

Data intended for use in Experience Platform is grouped into two behavior types:

  • Enregistrer les données : fournit des informations sur les attributs d’un sujet. Un sujet peut être une organisation ou un individu.
  • Données de série temporelle : fournissent un instantané du système au moment où une action a été entreprise directement ou indirectement par un sujet enregistré.

Tous les schémas XDM décrivent des données pouvant être catégorisées en tant qu’enregistrement ou série temporelle. Le comportement des données d’un schéma est défini par la classe du schéma attribuée à celui-ci lorsqu’il est créé pour la première fois. Les classes XDM sont décrites en détail par la suite dans ce document.

Les schémas d’enregistrement et de série temporelle contiennent tous deux une carte des identités (xdm:identityMap). Ce champ contient la représentation de l’identité d’un sujet tiré des champs marqués comme « Identité » décrit à la section suivante.

Identité

Schemas are used for ingesting data into Experience Platform. Ces données sont finalement utilisées par plusieurs services pour créer une vue unique et unifiée d’une entité individuelle. Par conséquent, il est important, lors de la réflexion sur les schémas, de penser aux identités des clients et de déterminer les champs qui peuvent être utilisés pour identifier un sujet, quel que soit l'endroit d'où proviennent les données.

Pour faciliter ce processus, les champs clés de vos schémas peuvent être marqués comme identités. Upon data ingestion, the data in those fields is inserted into the "Identity Graph" for that individual. The graph data can then be accessed by Real-time Customer Profile and other Experience Platform services to provide a stitched-together view of each individual customer.

Fields that are commonly marked as "Identity" include: email address, phone number, Experience Cloud ID (ECID), CRM ID, or other unique ID fields. You should also consider any unique identifiers specific to your organization, as they may be good "Identity" fields as well.

Il est important de réfléchir aux identités client au cours de la phase de planification des schémas afin de vous assurer que les données sont rassemblées pour créer le profil le plus complet possible. See the overview on Adobe Experience Platform Identity Service to learn more about how identity information can help you deliver digital experiences to your customers.

xdm:identityMap

xdm:identityMap est un champ de type carte qui décrit les différentes valeurs d’identité d’un individu, ainsi que les espaces de nommage qui lui sont associés. Ce champ peut être utilisé pour fournir des informations d'identité à vos schémas, au lieu de définir des valeurs d'identité dans la structure du schéma lui-même.

Voici un exemple de carte d’identité simple :

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

Comme l'exemple ci-dessus le montre, chaque clé de l' identityMap objet représente un espace de nommage d'identité. La valeur de chaque clé est un tableau d'objets représentant les valeurs d'identité (id) de l'espace de nommage respectif. Consultez la Identity Service documentation pour obtenir une liste d'espaces de nommage d'identité standard reconnus par les applications d'Adobe.

Remarque

Une valeur booléenne indique si la valeur est ou non une Principale identité (primary) peut également être fournie pour chaque valeur d'identité. Les identités Principal ne doivent être définies que pour les schémas destinés à être utilisés dans Real-time Customer Profile. See the section on union schemas for more information.

Principes d’évolution des schémas

Étant donné que la nature des expériences numériques continue à évoluer, les schémas utilisés pour les représenter le doivent aussi. Un schéma bien conçu est donc capable de s’adapter et d’évoluer si nécessaire sans provoquer des modifications destructives aux versions précédentes du schéma.

Since maintaining backwards compatibility is crucial for schema evolution, Experience Platform enforces a purely additive versioning principle to ensure that any revisions to the schema only result in non-destructive updates and changes. En d’autres termes, les modifications entraînant des ruptures ne sont pas prises en charge.

Modifications prises en charge Modifications entraînant une rupture (non prises en charge)
  • Ajouter des nouveaux champs à un schéma existant
  • Rendre un champ obligatoire facultatif
  • Supprimer des champs définis précédemment
  • Introduire de nouveaux champs obligatoires
  • Renommer ou redéfinir des champs existants
  • Supprimer ou limiter des valeurs de champ précédemment prises en charge
  • Déplacer des attributs vers un autre emplacement de l’arborescence
Remarque

If a schema has not yet been used to ingest data into Experience Platform, you may introduce a breaking change to that schema. However, once the schema has been used in Platform, it must adhere to the additive versioning policy.

Schémas et ingestion de données

In order to ingest data into Experience Platform, a dataset must first be created. Datasets are the building blocks for data transformation and tracking for Catalog Service, and generally represent tables or files that contain ingested data. Tous les jeux de données sont basés sur des schémas XDM existants qui fournissent des contraintes sur ce que les données ingérées doivent contenir et sur la manière dont elles doivent être structurées. Pour plus d’informations, consultez la présentation d’Adobe Experience Platform Data Ingestion.

Blocs de création d’un schéma

Experience Platform utilise une approche de composition dans laquelle des blocs de création standard sont associés pour créer des schémas. Cette approche favorise la réutilisation de composants existants et conditionne la normalisation dans le secteur pour soutenir les schémas et les composants fournisseurs dans Platform.

Les schémas sont composés à l’aide de la formule suivante :

Classe + Mixin* = Schéma XDM

*Un schéma est composé d’une classe et de zéro, un ou plusieurs mixins. Cela signifie que vous pouvez composer un schéma du jeu de données sans utiliser de mixins.

Classe

La composition d’un schéma commence par l’attribution d’une classe. Les classes définissent les aspects comportementaux des données que le schéma contiendra (enregistrements ou séries temporelles). En outre, les classes décrivent le plus petit de nombres de propriétés communes que tous les schémas basés sur cette classe doivent inclure et fournir une manière de fusionner plusieurs jeux de données compatibles.

Une classe de schéma détermine quels mixins seront admissibles à l'utilisation dans ce schéma. Cette question est traitée plus en détail dans la section suivante.

Adobe fournit deux classes XDM standard ("core") : XDM Individual Profile et XDM ExperienceEvent. Outre ces classes de base, vous pouvez également créer vos propres classes personnalisées afin de décrire des cas d’utilisation plus spécifiques pour votre entreprise. Les classes personnalisées sont définies par une organisation lorsqu'il n'existe aucune classe de base définie par Adobe disponible pour décrire un cas d'utilisation unique.

Mixin

Un mixin est un composant réutilisable qui définit un ou plusieurs champs qui mettent en œuvre certaines fonctionnalités comme les détails personnels, les préférences d’hôtel ou les adresses. Les mixins sont destinés à être inclus dans le cadre d’un schéma qui met en œuvre une classe compatible.

Les mixins définissent la ou les classes avec lesquelles ils sont compatibles en fonction du comportement des données qu’ils représentent (enregistrement ou série temporelle). Cela signifie que tous les mixins ne peuvent pas être utilisés pour toutes les classes.

Experience Platform inclut de nombreux mixins d’Adobe standard tout en permettant aux fournisseurs de définir des mixins pour leurs utilisateurs et aux utilisateurs individuels de définir des mixins pour leurs propres concepts spécifiques.

For example, to capture details such as "First Name" and "Home Address" for your "Loyalty Members" schema, you would be able to use standard mixins that define those common concepts. However, concepts that are specific to less-common use cases (such as "Loyalty Program Level") often do not have a pre-defined mixin. Dans ce cas, vous devez définir vos propres mixins pour capturer ces informations.

N’oubliez pas que les schémas sont composés de « zéro, un ou plusieurs » mixins, ce qui signifie que vous pouvez composer un schéma valide sans utiliser de mixins du tout.

Pour une liste de tous les mixins standard actuels, consultez le référentiel XDMofficiel.

Type de données

Les types de données sont utilisés comme types de champ de référence dans des classes ou des schémas de la même manière que des champs littéraux de base. La principale différence réside dans le fait que les types de données peuvent définir plusieurs sous-champs. Tout comme un mixin, un type de données permet l’utilisation cohérente d’une structure à champs multiples, mais avec plus de flexibilité qu’un mixin, car un type de données peut être inclus n’importe où dans un schéma en l’ajoutant comme « type de données » d’un champ.

Remarque

Voir l' annexe pour plus d'informations sur les différences entre les mixins et les types de données, ainsi que sur les avantages et les inconvénients de l'utilisation de l'un par rapport à l'autre pour des cas d'utilisation similaires.

Experience Platform fournit un certain nombre de types de données courants dans le Schema Registry cadre de la prise en charge de l’utilisation de modèles standard pour décrire des structures de données communes. This is explained in more detail in the Schema Registry tutorials, where it will become more clear as you walk through the steps to define data types.

Champ

Un champ est le bloc de création le plus basique d’un schéma. Les champs apportent des contraintes concernant le type de données qu’ils peuvent contenir en définissant un type de données spécifique. Ces types de données de base définissent un champ unique, tandis que les types de données mentionnés précédemment vous permettent de définir plusieurs sous-champs et de réutiliser la même structure à champs multiples sur plusieurs schémas. So, in addition to defining a field's "data type" as one of the data types defined in the registry, Experience Platform supports basic scalar types such as:

  • Chaîne
  • Entier
  • Double
  • Booléen
  • Tableau
  • Objet
ASTUCE

Consultez l’ annexe pour en savoir plus sur les avantages et les inconvénients de l’utilisation de champs de forme libre par rapport aux champs de type d’objet.

Les plages valides de ces types scalaires peuvent être limitées davantage à certains motifs, formats, minimums/maximums ou valeurs prédéfinies. Grâce à ces contraintes, il est possible de représenter une large plage de types de champ spécifiques, notamment :

  • Enum
  • Long
  • Short
  • Byte
  • Date
  • Date-time
  • Map
Remarque

Le type de champ « map » permet des données de paires clé-valeur, y compris plusieurs valeurs pour une clé unique. Les cartes ne peuvent être définies qu’au niveau du système, ce qui signifie que vous pouvez rencontrer une carte dans un schéma de secteur ou de fournisseur, mais celle-ci ne peut pas être utilisée dans les champs que vous définissez. Le guide de développement de l’API Schema Registry contient plus d’informations sur la définition des types de champ.

Certaines opérations de données utilisées par des services et des applications en aval imposent des contraintes sur certains types de champs. Les services concernés incluent, sans s’y limiter :

Avant de créer un schéma à utiliser dans les services en aval, veuillez consulter la documentation appropriée de ces services afin de mieux comprendre les exigences et les contraintes de champ pour les opérations de données auxquelles le schéma est destiné.

Champs XDM

In addition to basic fields and the ability to define your own data types, XDM provides a standard set of fields and data types that are implicitly understood by Experience Platform services and provide greater consistency when used across Platform components.

These fields, such as "First Name" and "Email Address" contain added connotations beyond basic scalar field types, telling Platform that any fields sharing the same XDM data type will behave in the same way. This behavior can be trusted to be consistent regardless of where the data is coming from, or in which Platform service the data is being used.

Consultez le dictionnaire des champs XDM pour obtenir une liste complète des champs XDM disponibles. Nous vous recommandons d’utiliser les champs XDM et les types de données dès que possible pour aider à la cohérence et à la standardisation dans Experience Platform.

Exemple de composition

Schemas represent the format and structure of data that will be ingested into Platform, and are built using a composition model. Comme mentionné précédemment, ces schémas se composent d’une classe et de zéro, un ou plusieurs mixins compatibles avec cette classe.

For example, a schema describing purchases made at a retail store might be called "Store Transactions". The schema implements the XDM ExperienceEvent class combined with the standard Commerce mixin and a user-defined Product Info mixin.

Another schema which tracks website traffic might be called "Web Visits". It also implements the XDM ExperienceEvent class, but this time combines the standard Web mixin.

Le graphique ci-dessous montre ces schémas et les champs fournis pour chaque mixin. It also contains two schemas based on the XDM Individual Profile class, including the "Loyalty Members" schema mentioned previously in this guide.

Union

While Experience Platform allows you to compose schemas for particular use cases, it also allows you to see a "union" of schemas for a specific class type. The previous diagram shows two schemas based on the XDM ExperienceEvent class and two schemas based on XDM Individual Profile class. The union, shown below, aggregates the fields of all schemas that share the same class (XDM ExperienceEvent and XDM Individual Profile, respectively).

By enabling a schema for use with Real-time Customer Profile, it will be included in the union for that class type. Profile fournit des profils robustes et centralisés d'attributs du client ainsi qu'un compte horodaté de chaque événement que le client a eu dans tout système intégré à Platform. Profile utilise la vue d’union pour représenter ces données et fournir une vue holistique de chaque client.

For more information on working with Profile, see the Real-time Customer Profile overview.

Mappage des fichiers de données à des schémas XDM

All datafiles that are ingested into Experience Platform must conform to the structure of an XDM schema. Pour plus d’informations sur la manière de formater les fichiers de données pour se conformer aux hiérarchies XDM (ainsi que des fichiers d’exemple), consultez le document sur les exemples de transformations ETL. For general information about ingesting datafiles into Experience Platform, see the batch ingestion overview.

Étapes suivantes

Now that you understand the basics of schema composition, you are ready to begin exploring and building schemas using the Schema Registry.

Pour examiner la structure des deux classes XDM de base et de leurs mixins compatibles couramment utilisés, consultez la documentation de référence suivante :

The Schema Registry is used to access the Schema Library within Adobe Experience Platform, and provides a user interface and RESTful API from which all available library resources are accessible. The Schema Library contains Industry resources defined by Adobe, Vendor resources defined by Experience Platform partners, and classes, mixins, data types, and schemas that have been composed by members of your organization.

Pour commencer à composer un schéma à l’aide de l’interface utilisateur, suivez le tutoriel de l’éditeur de schémas pour créer le schéma « Loyalty Members » mentionné tout au long de ce document.

To begin using the Schema Registry API, start by reading the Schema Registry API developer guide. Après avoir lu le guide de développement, suivez les étapes décrites dans le tutoriel Création d’un schéma à l’aide de l’API Schema Registry.

Annexe

La section suivante contient des renseignements supplémentaires sur les principes de la composition des schémas.

Objets par rapport aux champs de formulaire libre

Lors de la conception de vos schémas, certains facteurs clés doivent être pris en compte lors du choix des objets par rapport aux champs de forme libre :

Objets Champs de formulaire libre
Augmente l’imbrication Imbrication moindre ou aucune
Crée des regroupements de champs logiques Les champs sont placés dans des emplacements ad hoc.

Objets

Les avantages et les inconvénients de l’utilisation d’objets par rapport aux champs de formulaire libre sont répertoriés ci-dessous.

Avantages:

  • Il est préférable d’utiliser des objets lorsque vous souhaitez créer un regroupement logique de certains champs.
  • Les objets organisent le schéma de manière plus structurée.
  • Les objets aident indirectement à créer une bonne structure de menus dans l’interface utilisateur du créateur de segments. Les champs regroupés dans le schéma sont directement reflétés dans la structure de dossiers fournie dans l’interface utilisateur du créateur de segments.

Contre:

  • Les champs deviennent plus imbriqués.
  • Lorsque vous utilisez Adobe Experience Platform Requête Service, des chaînes de référence plus longues doivent être fournies aux champs de requête imbriqués dans des objets.

Champs de formulaire libre

Les avantages et les inconvénients de l’utilisation de champs de forme libre sur des objets sont répertoriés ci-dessous.

Avantages:

  • Les champs de forme libre sont créés directement sous l’objet racine du schéma (_tenantId), ce qui augmente la visibilité.
  • Les chaînes de référence pour les champs de formulaire libre tendent à être plus courtes lors de l’utilisation de Requête Service.

Contre:

  • L’emplacement des champs de forme libre dans le schéma est ad hoc, ce qui signifie qu’ils apparaissent dans l’ordre alphabétique dans l’éditeur de Schéma. Cela peut rendre les schémas moins structurés et des champs de forme libre similaires peuvent se retrouver très séparés selon leurs noms.

Sur cette page