Principes de base de la composition des schémas

Ce document présente les Experience Data Model schémas (XDM) et blocs de création, principes et bonnes pratiques pour la composition de schémas à utiliser dans Adobe Experience Platform. Pour obtenir des informations générales sur XDM et son utilisation dans Platform, voir 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 conserve cette normalisation sémantique à l’aide de 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 au sein d’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. Consultez les sections sur objets incorporés et Big Data dans l’annexe de ce document pour plus d’informations sur la manière dont XDM effectue cette opération.

Workflows basés sur des schémas 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 créé, appelé XDM System, facilite les workflows basés sur des schémas et inclut la variable Schema Registry, Schema Editor, les métadonnées de schéma et les schémas de consommation de service. Pour plus d’informations, consultez la présentation du système XDM.

L’utilisation des schémas dans offre plusieurs avantages clés Experience Platform. Tout d’abord, les schémas permettent une meilleure gouvernance des données et une réduction au minimum des données, ce qui est particulièrement important avec les réglementations de confidentialité. Ensuite, la création de schémas avec les composants standard d’Adobe permet d’obtenir des informations d’usine et d’utiliser les services AI/ML avec un minimum de personnalisations. Enfin, les schémas fournissent une infrastructure pour le partage de 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

Données destinées à être utilisées dans Experience Platform est regroupé en deux types de comportements :

• 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 objet d’enregistrement.

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 objet tiré des champs marqués comme « Identité » décrit à la section suivante.

Identité

Les schémas sont utilisés pour ingérer 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. Il est donc important, lors de la réflexion sur les schémas, de réfléchir aux identités des clients et aux champs qui peuvent être utilisés pour identifier un sujet, quel que soit l’origine des données.

Pour faciliter ce processus, les champs clés de vos schémas peuvent être marqués comme identités. Lors de l’ingestion des données, les données de ces champs sont insérées dans leGraphique d’identités" pour cette personne. Les données du graphique sont ensuite accessibles par Real-Time Customer Profile et autres Experience Platform services pour offrir une vue d’ensemble de chaque client.

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

Il est important de réfléchir aux identités client lors de la phase de planification du schéma afin de vous assurer que les données sont rassemblées pour créer le profil le plus robuste possible. Consultez la présentation sur Service Adobe Experience Platform Identity pour en savoir plus sur la manière dont les informations d’identité peuvent vous aider à fournir des expériences numériques à vos clients.

Il existe deux manières d’envoyer des données d’identité à Platform :

1. Ajout de descripteurs d’identité à des champs individuels, soit par l’intermédiaire de la fonction Interface utilisateur de l’éditeur de schémas ou en utilisant la variable API Schema Registry
2. Utilisation d’une identityMap field

identityMap

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

L’inconvénient principal de l’utilisation de identityMap est que les identités sont incorporées dans les données et deviennent ainsi moins visibles. Si vous ingérez des données brutes, vous devez définir des champs d’identité individuels dans la structure réelle du schéma à la place.

Cependant, les cartes d’identité peuvent s’avérer particulièrement utiles si vous rassemblez des données provenant de sources qui stockent les identités (telles que Airship ou Adobe Audience Manager) ou lorsqu’il existe un nombre variable d’identités pour un schéma. En outre, les cartes d’identité sont requises si vous utilisez la variable SDK Adobe Experience Platform Mobile.

Voici un exemple de carte d’identité simple :

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

Comme le montre l’exemple ci-dessus, chaque clé du identityMap représente un espace de noms d’identité. La valeur de chaque clé est un tableau d’objets, représentant les valeurs d’identité (id) pour l’espace de noms correspondant. Voir Identity Service documentation pour un liste des espaces de noms d’identité standard reconnu par les applications Adobe.

Principes d’évolution des schémas

Étant donné que la nature des expériences digitales 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.

Le maintien de la compatibilité descendante étant essentiel pour l’évolution des schémas, Experience Platform applique un principe de contrôle de version purement additif. Ce principe garantit 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.

Le tableau suivant répertorie les modifications prises en charge lors de la modification des schémas, des groupes de champs et des types de données :

*Reportez-vous à la section ci-dessous pour obtenir des informations importantes concernant définition de nouveaux champs obligatoires.

Champs obligatoires

Les champs de schéma individuels peuvent être marqué comme requis, ce qui signifie que tout enregistrement ingéré doit contenir des données dans ces champs pour passer la validation. Par exemple, la définition du champ d’identité principal d’un schéma selon les besoins peut vous aider à vous assurer que tous les enregistrements ingérés participeront à Real-time Customer Profile, tout en définissant un champ d’horodatage selon les besoins, ce qui garantit que tous les événements de série temporelle sont préservés chronologiquement.

Définition des champs requis après l’ingestion

Si un champ a été utilisé pour ingérer des données et qu’il n’a pas été initialement défini comme requis, il peut avoir une valeur nulle pour certains enregistrements. Si vous définissez ce champ comme étant obligatoire après l’ingestion, tous les enregistrements ultérieurs doivent contenir une valeur pour ce champ, même si les enregistrements historiques peuvent être nuls.

Lorsque vous définissez un champ précédemment facultatif selon les besoins, gardez à l’esprit les points suivants :

1. Si vous interrogez des données historiques et écrivez les résultats dans un nouveau jeu de données, certaines lignes échouent car elles contiennent des valeurs nulles pour le champ requis.
2. Si le champ participe à Profil client en temps réel et si vous exportez des données avant de les définir selon les besoins, la valeur peut être nulle pour certains profils.
3. Vous pouvez utiliser l’API Schema Registry pour afficher un journal des modifications horodaté pour toutes les ressources XDM dans Platform, y compris les nouveaux champs obligatoires. Consultez le guide sur la point d’entrée du journal d’audit pour plus d’informations.

Schémas et ingestion de données

Pour ingérer 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 création de la transformation et du suivi des données pour Catalog Service, et représentent généralement des tableaux ou des fichiers qui contiennent des données ingéré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 + Groupe de champs de schéma* = Schéma XDM

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

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.

La classe d’un schéma détermine les groupes de champs qui pourront être utilisés dans ce schéma. Cela est décrit plus en détail dans la section section suivante.

Adobe fournit plusieurs classes XDM standard ("core"). Deux de ces classes, XDM Individual Profile et XDM ExperienceEvent, sont requis pour la plupart des processus Platform en aval. En plus de ces classes de base, vous pouvez créer vos propres classes personnalisées afin de décrire des cas d’utilisation plus spécifiques à votre organisation. Les classes personnalisées sont définies par une organisation lorsqu’aucune classe principale définie par l’Adobe n’est 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 Platform. Comme l’exemple de schéma présenté ne contient aucun groupe de champs, tous les champs affichés sont fournis par la classe du schéma (XDM Individual Profile).

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

Groupe de champs

Un groupe de champs est un composant réutilisable qui définit un ou plusieurs champs qui implémentent certaines fonctions telles que les détails personnels, les préférences d’hôtel ou l’adresse. Les groupes de champs sont destinés à être inclus dans le cadre d’un schéma qui met en oeuvre une classe compatible.

Les groupes de champs 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 groupes de champs ne sont pas disponibles pour toutes les classes.

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

Par exemple, pour capturer des détails tels que "Prénom" et "Adresse du domicile" pour votre "Loyalty Members", vous pouvez utiliser des groupes de champs standard qui définissent ces concepts communs. Toutefois, les concepts plus spécifiques à votre organisation (tels que les détails du programme de fidélité personnalisés ou les attributs de produit) qui peuvent ne pas être couverts par les groupes de champs standard. Dans ce cas, vous devez définir votre propre groupe de champs pour capturer ces informations.

N’oubliez pas que les schémas sont composés de groupes de champs "zéro ou plus", ce qui signifie que vous pouvez composer un schéma valide sans utiliser aucun groupe de champs.

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

Pour obtenir la liste la plus récente des groupes de champs XDM standard disponibles, reportez-vous à la section référentiel XDM officiel. Vous pouvez également vous reporter au guide sur la exploration des composants XDM si vous préférez afficher les 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. Ils peuvent définir plusieurs sous-champs de la même manière que les groupes de champs, mais la principale différence est que les types de données peuvent être inclus n’importe où dans un schéma en l’ajoutant comme "type de données" d’un champ. Bien que les groupes de champs ne soient compatibles qu’avec certaines classes, les types de données peuvent être inclus dans n’importe quelle classe parent ou groupe de champs.

Experience Platform fournit un certain nombre de types de données courants dans le cadre du Schema Registry pour prendre en charge l’utilisation de modèles standard pour la description de structures de données courantes. Cela est expliqué plus en détail dans la section Schema Registry des tutoriels, où il devient plus clair 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 Platform. Un des champs fournis par la variable Détails démographiques Le groupe de champs utilise le paramètre "Objet" type de données, comme indiqué par le texte qui suit la barre verticale (|) en regard du nom du champ. Ce type de données particulier fournit plusieurs sous-champs relatifs au nom d’une personne, un 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, reportez-vous à la section référentiel XDM officiel. Vous pouvez également vous reporter au guide sur la exploration des composants XDM si vous préférez afficher les 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

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

Exemple de composition

Les schémas représentent le format et la structure des données qui seront ingérées dans Platformet sont créés à l’aide d’un modèle de composition. Comme mentionné précédemment, ces schémas sont composés d’une classe et de zéro ou plusieurs groupes de champs 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 magasin". Le schéma met en oeuvre le XDM ExperienceEvent Combinée avec la classe standard Commerce groupe de champs et défini par l’utilisateur Informations sur le produit groupe de champs.

Un autre schéma qui suit le trafic sur le site web peut être appelé "Visites web". Il met également en oeuvre les XDM ExperienceEvent , mais cette fois-ci combine les Web groupe de champs.

Le diagramme ci-dessous montre ces schémas et les champs fournis par chaque groupe de champs. Il contient également deux schémas basés sur la variable XDM Individual Profile , y compris leLoyalty Membersschéma mentionné précédemment dans ce guide.

Union

while Experience Platform permet de composer des schémas pour des cas d’utilisation spécifiques, mais aussi d’afficher 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 XDM Individual Profile classe . L’union, illustrée ci-dessous, regroupe 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 des attributs du client ainsi qu’un compte horodaté de chaque événement que le client a eu sur n’importe quel système intégré à Platform. Profile utilise la vue d’union pour représenter ces données et fournir une vue d’ensemble de chaque client.

Pour plus d’informations sur l’utilisation de Profile, voir Présentation de Real-Time Customer Profile.

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

Tous les fichiers de données ingérés dans Experience Platform doit être conforme à 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’ingestion de fichiers de données dans Experience Platform, voir Présentation de l’ingestion par lots.

Schémas pour les audiences externes

Si vous intégrez des audiences provenant de systèmes externes dans Platform, vous devez utiliser les composants suivants pour les capturer dans vos schémas :

• Définition de segment class: utilisez cette classe standard pour capturer les attributs clés d’une définition de segment externe.
• Détails de l’adhésion au segment groupe de champs: ajoutez ce groupe de champs à votre XDM Individual Profile afin d’associer des profils client à des audiences spécifiques.

Étapes suivantes

Maintenant que vous comprenez les principes de base de la composition des schémas, vous êtes prêt à commencer à explorer et à créer des schémas à l’aide du Schema Registry.

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

• XDM Individual Profile
• XDM ExperienceEvent

La variable Schema Registry est utilisé pour accéder à la variable Schema Library dans Adobe Experience Platform et fournit une interface utilisateur et une API RESTful à partir desquelles toutes les ressources de bibliothèque disponibles sont accessibles. La variable Schema Library contient les ressources du secteur définies par Adobe, ressources du fournisseur définies par Experience Platform partenaires, classes, groupes de champs, types de données et schémas 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 la variable Schema Registry API, commencez par lire la Guide de développement de l’API Schema Registry. 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 supplé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 intégré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 pouvant être autorisés dans votre hiérarchie de schémas.

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 et champs de forme libre

Lors de la conception de vos schémas, vous devez tenir compte de certains facteurs clés lors du choix d’objets plutôt que de champs de forme libre :

Objets

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

Avantages:

• Il est préférable d’utiliser les 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.

Inconvénients:

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

Champs de forme libre

Les avantages et inconvénients de l’utilisation de champs de forme libre par rapport aux 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), augmentation de la visibilité.
• Les chaînes de référence pour les champs de forme libre ont tendance à être plus courtes lors de l’utilisation de Query Service.

Inconvénients:

• 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émas. Cela peut rendre les schémas moins structurés, et des champs de forme libre similaires peuvent se révéler très séparés en fonction de leurs noms.