Principes de base de la composition des schémas

Ce document présente les schémas Experience Data Model (XDM) ainsi que les éléments de base, les principes et les meilleures pratiques pour composer des schémas à utiliser dans Adobe Experience Platform. Pour obtenir des informations générales sur XDM et son utilisation dans Platform, consultez la Présentation du système XDM.

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 en utilisant des schémas. Les schémas sont la manière standard de décrire les données dans Experience Platform, ce qui permet à toutes les données conformes aux schémas d'être réutilisées dans une organisation sans conflit, voire partagées entre plusieurs organisations.

Les schémas XDM sont idéaux pour stocker de grandes quantités de données complexes dans un format autonome. Pour plus d'informations sur la façon dont XDM effectue cette opération, consultez les sections objets incorporés et big data dans l'annexe du présent document.

Workflows basés sur le schéma dans 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 construit, appelée XDM System, facilite les workflows basés sur le schéma et inclut les Schema Registry, Schema Editor, les mé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 clés à la construction et à l'utilisation de schémas dans Experience Platform. 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.

Comportements de données dans Experience Platform

Les données destinées à être utilisées dans Experience Platform sont regroupées en deux types de comportement :

  • 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é

Les schémas sont utilisés pour importer des données dans 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. Lors de l’assimilation des données, les données contenues dans ces champs sont insérées dans le "graphique d’identité" de cette personne. Les données graphiques peuvent ensuite être consultées par Real-time Customer Profile et d'autres services Experience Platform afin de fournir une vue groupée de chaque client.

Les champs généralement marqués comme "Identité" sont les suivants : adresse électronique, numéro de téléphone, Experience Cloud ID (ECID), ID de gestion de la relation client ou autres champs d’ID uniques. Vous devez également tenir compte de tous les identifiants uniques propres à votre organisation, car ils peuvent également être de bons champs "Identité".

Il est important de réfléchir à l'identité des clients au cours de la phase de planification du schéma afin de veiller à ce que les données soient rassemblées pour créer le profil le plus robuste possible. Consultez la présentation du Service d'identité de Adobe Experience Platform pour en savoir plus sur la manière dont les informations d'identité peuvent vous aider à fournir des expériences numériques à vos clients.

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'objet identityMap 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 documentation Identity Service 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 une identité Principale (primary) peut également être fournie pour chaque valeur d'identité. Les identités Principal doivent uniquement être définies pour les schémas destinés à être utilisés dans Real-time Customer Profile. Pour plus d'informations, consultez la section schémas d'union.

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.

Étant donné que le maintien de la compatibilité ascendante est essentiel pour l'évolution du schéma, Experience Platform applique un principe de versioning purement additif pour s'assurer que toute révision du schéma n'entraîne que des mises à jour et des modifications non destructives. 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

Si un schéma n'a pas encore été utilisé pour importer des données dans Experience Platform, vous pouvez introduire une modification de rupture à ce schéma. Cependant, une fois que le schéma a été utilisé dans Platform, il doit respecter la politique de versioning additive.

Schémas et ingestion de données

Pour importer des données dans Experience Platform, un jeu de données doit d'abord être créé. Les jeux de données sont les blocs de construction pour la transformation des données et le suivi de Catalog Service et représentent généralement les tables ou les fichiers qui contiennent des données imbriquées. 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 plusieurs classes XDM standard ("core"). Deux de ces classes, XDM Individual Profile et XDM ExperienceEvent, sont requises pour presque tous les processus de plateforme en aval. 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.

La capture d’écran suivante montre comment les classes sont représentées dans l’interface utilisateur de la plate-forme. Comme l'exemple de schéma illustré ne contient aucun mixin, tous les champs affichés sont fournis par la classe de schéma (Profil individuel XDM).

Pour obtenir la liste la plus récente des classes XDM standard disponibles, consultez le référentiel XDM officiel. Vous pouvez également vous reporter au guide sur l'exploration des composants XDM si vous préférez vue des ressources dans l'interface utilisateur.

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.

Par exemple, pour capturer des détails tels que "Prénom" et "Adresse du domicile" pour votre schéma "Membres de fidélité", vous pouvez utiliser des mixins standard qui définissent ces concepts communs. Cependant, les concepts spécifiques à des cas d’utilisation moins courants (tels que "Niveau de Programme de fidélité") n’ont souvent pas de mixin prédéfini. 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.

La capture d’écran suivante montre comment les mixins sont représentés dans l’interface utilisateur de la plate-forme. Un mixin unique (Détails démographiques) est ajouté à un schéma dans cet exemple, qui fournit un regroupement de champs à la structure du schéma.

Pour obtenir la liste la plus récente des mixins XDM standard disponibles, consultez le référentiel XDM officiel. Vous pouvez également vous reporter au guide sur l'exploration des composants XDM si vous préférez vue des ressources dans l'interface utilisateur.

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.

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. Vous trouverez des informations plus détaillées à ce sujet dans les didacticiels Schema Registry, qui s'affichent plus clairement lorsque vous parcourez les étapes de définition des types de données.

La capture d’écran suivante montre comment les types de données sont représentés dans l’interface utilisateur de la plate-forme. L'un des champs fournis par le mixin Détails démographiques utilise le type de données "Nom de personne", comme indiqué par le texte qui suit le caractère de barre verticale (|) en regard du nom du champ. Ce type de données fournit plusieurs sous-champs relatifs au nom d'une personne, concept qui peut être réutilisé pour d'autres champs où le nom d'une personne doit être capturé.

Pour obtenir la liste la plus récente des types de données XDM standard disponibles, consultez le référentiel XDM officiel. Vous pouvez également vous reporter au guide sur l'exploration des composants XDM si vous préférez vue des ressources dans l'interface utilisateur.

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. Ainsi, en plus de définir le "type de données" d'un champ comme l'un des types de données définis dans le Registre, Experience Platform prend en charge les types scalaires de base tels que :

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

Voir l'annexe pour plus d'informations 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

Outre les champs de base et la possibilité de définir vos propres types de données, XDM fournit un ensemble standard de champs et de types de données qui sont implicitement compris par les services Experience Platform et offrent une plus grande cohérence lorsqu'ils sont utilisés dans les composants Platform.

Ces champs, tels que "Prénom" et "Adresse électronique", contiennent des connotations supplémentaires au-delà des types de champs scalaires de base, indiquant à Platform que tout champ partageant le même type de données XDM se comporte de la même manière. Ce comportement peut être considéré comme cohérent, quel que soit l'endroit d'où proviennent les données ou le service Platform dans lequel les données sont utilisées.

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

Les schémas représentent le format et la structure des données qui seront ingérées dans Platform et qui sont créées à l'aide d'un modèle de composition. 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.

Par exemple, un schéma décrivant les achats effectués dans un magasin de détail peut être appelé "Transactions de stockage". Le schéma implémente la classe XDM ExperienceEvent associée au mixin standard Commerce et à un mixin Product Info défini par l'utilisateur.

Un autre schéma qui suit le trafic du site Web peut être appelé "Visites Web". Il implémente également la classe XDM ExperienceEvent, mais cette fois combine le mixin standard Web.

Le graphique ci-dessous montre ces schémas et les champs fournis pour chaque mixin. Il contient également deux schémas basés sur la classe XDM Individual Profile, y compris le schéma "Membres de fidélité" mentionné précédemment dans ce guide.

Union

Bien que Experience Platform vous permette de composer des schémas pour des cas d'utilisation particuliers, il vous permet également de voir une "union" de schémas pour un type de classe spécifique. Le diagramme précédent présente deux schémas basés sur la classe XDM ExperienceEvent et deux schémas basés sur la classe XDM Individual Profile. L’union, illustrée ci-dessous, agrégat les champs de tous les schémas qui partagent la même classe (XDM ExperienceEvent et XDM Individual Profile, respectivement).

En activant un schéma à utiliser avec Real-time Customer Profile, il sera inclus dans l'union pour ce type de classe. 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.

Pour plus d'informations sur l'utilisation de Profile, consultez la Présentation du Profil client en temps réel.

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

Tous les fichiers de données assimilés à Experience Platform doivent être conformes à la structure d'un schéma XDM. 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. Pour obtenir des informations générales sur l'assimilation de fichiers de données dans Experience Platform, consultez la présentation de l'assimilation par lot.

Schémas pour les segments externes

Si vous amenez des segments à partir de systèmes externes dans la plate-forme, vous devez utiliser les composants suivants pour les capturer dans vos schémas :

  • Classe de définition de segment: Utilisez cette classe standard pour capturer les attributs clés d'une définition de segment externe.
  • Segmenter le mixin des détails de l'adhésion : Ajoutez ce mixin à votre schéma de profil individuel XDM afin d’associer des profils clients à des segments spécifiques.

Étapes suivantes

Maintenant que vous comprenez les bases de la composition des schémas, vous êtes prêt à commencer à explorer et à construire des schémas à l'aide du 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 :

Schema Registry est utilisé pour accéder à Schema Library dans Adobe Experience Platform et fournit une interface utilisateur et une API RESTful à partir de laquelle toutes les ressources de bibliothèque disponibles sont accessibles. Schema Library contient les ressources du secteur définies par l'Adobe, les ressources du fournisseur définies par les partenaires Experience Platform, ainsi que les classes, mixins, types de données et schémas qui ont été composés par des membres de votre organisation.

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.

Pour commencer à utiliser l'API Schema Registry, début en lisant le guide du développeur de l'API de registre de Schémas. 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

Les sections suivantes contiennent des informations complémentaires sur les principes de la composition des schémas.

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.

Objets versus champs de forme 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

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now