Experience Data Model (XDM) est le cadre de base qui normalise les données d’expérience client en fournissant des structures et des définitions communes à utiliser dans les services Adobe Experience Platform en aval. En respectant les normes XDM, toutes les données d’expérience client peuvent être intégrées dans une représentation commune qui vous permet d’obtenir des informations précieuses sur les actions client, de définir les audiences client par le biais de segments et d’exprimer les attributs client à des fins de personnalisation.
Comme XDM est extrêmement polyvalent et personnalisable par conception, il est donc important de suivre les meilleures pratiques de modélisation des données lors de la conception de vos schémas. Ce document décrit les principales décisions et considérations à prendre en compte lors de la mise en correspondance des données d’expérience client avec XDM.
Avant de lire ce guide, veuillez consulter l'Présentation du système XDM pour une présentation de haut niveau de XDM et de son rôle dans l'Experience Platform.
En outre, ce guide porte exclusivement sur les considérations clés concernant la conception de schéma. Il est donc fortement recommandé de se reporter aux bases de la composition des schémas pour obtenir des explications détaillées sur les différents éléments de schéma mentionnés dans ce guide.
L’approche recommandée pour la conception de votre modèle de données à utiliser dans l’Experience Platform peut être résumée comme suit :
Les étapes relatives à l'identification des sources de données applicables nécessaires à l'exécution de vos dossiers d'utilisation commerciale varieront d'une organisation à l'autre. Bien que le reste des sections de ce document se concentre sur les dernières étapes d'organisation et de construction d'un ERD après l'identification des sources de données, les explications des différents composants du diagramme peuvent vous éclairer sur les choix de vos sources de données à migrer vers Platform.
Une fois que vous avez déterminé les sources de données que vous souhaitez importer dans Platform, créez un ERD de haut niveau pour vous aider à orienter le processus de mappage de vos données aux schémas XDM.
L'exemple ci-dessous représente une ERD simplifiée pour une société qui souhaite importer des données dans Platform. Le diagramme met en évidence les entités essentielles qui doivent être triées en classes XDM, y compris les comptes clients, les hôtels, les adresses et plusieurs événements de commerce électronique courants.
Une fois que vous avez créé un ERD pour identifier les entités essentielles que vous souhaitez importer dans Platform, ces entités doivent être triées en catégories de profil, de recherche et de événement :
Catégorie | Description |
---|---|
Entités de profil | Les entités de profil représentent des attributs relatifs à une personne, généralement un client. Les entités qui relèvent de cette catégorie doivent être représentées par des schémas basés sur la classe XDM Individual Profile. |
Entités de recherche | Les entités de recherche représentent des concepts qui peuvent se rapporter à une personne, mais qui ne peuvent pas être directement utilisés pour identifier la personne. Les entités qui relèvent de cette catégorie doivent être représentées par des schémas basés sur classes personnalisées. |
Entités de événement | Les entités de événement représentent des concepts liés aux actions qu'un client peut entreprendre, aux événements système ou à tout autre concept dans lequel vous pouvez suivre les modifications au fil du temps. Les entités qui relèvent de cette catégorie doivent être représentées par des schémas basés sur la classe XDM ExperienceEvent. |
Les sections ci-dessous fournissent d'autres conseils sur la manière de trier vos entités en fonction des catégories ci-dessus.
Si une entité contient des attributs liés à un client individuel, il s’agit probablement d’une entité de profil. Voici quelques exemples d’attributs du client :
Si vous souhaitez analyser la manière dont certains attributs d'une entité changent au fil du temps, il s'agit probablement d'une entité événement. Par exemple, l’ajout d’éléments de produit à un panier peut être suivi en tant que événements de panier à ajouts dans Platform :
Customer ID | Type | ID de produit | Quantité | Horodatage |
---|---|---|---|---|
1234567 | Addition | 275098 | 2 | 1er octobre, 10h32 |
1234567 | Supprimer | 275098 | 1 | 1er octobre, 10h33 |
1234567 | Addition | 486502 | 1 | 1er octobre, 10:41 |
1234567 | Addition | 910482 | 5 | 3 octobre, 14:15 |
Lors de la catégorisation de vos entités, il est important de réfléchir aux segments d'audience que vous souhaitez peut-être créer pour répondre à vos cas particuliers d'utilisation commerciale.
Par exemple, une société veut connaître tous les membres "Or" ou "Platine" de son programme de fidélité qui ont fait plus de cinq achats l'année dernière. Sur la base de cette logique de segmentation, on peut tirer les conclusions suivantes concernant la manière dont les entités concernées devraient être représentées :
Outre les considérations relatives aux cas d’utilisation de la segmentation, vous devez également examiner les cas d’utilisation des activations pour ces segments afin d’identifier d’autres attributs pertinents.
Par exemple, une société a créé un segment d’audience basé sur la règle country = US
. Ensuite, lorsque ce segment est activé sur certaines cibles en aval, la société souhaite filtrer tous les profils exportés en fonction de l’état d’accueil. Par conséquent, un attribut state
doit également être capturé dans l'entité de profil applicable.
En fonction du cas d’utilisation et de la granularité de vos données, vous devez déterminer si certaines valeurs doivent être préagrégées avant d’être incluses dans une entité de profil ou de événement.
Par exemple, une société souhaite créer un segment en fonction du nombre d’achats de paniers. Vous pouvez choisir d’incorporer ces données à la granularité la plus faible en incluant chaque événement d’achat horodaté en tant qu’entité propre. Cependant, cela peut parfois augmenter le nombre de événements enregistrés de manière exponentielle. Pour réduire le nombre de événements ingérés, vous pouvez choisir de créer une valeur d’agrégat numberOfPurchases
sur une période d’une semaine ou d’un mois. D'autres fonctions d'agrégat comme MIN et MAX peuvent également s'appliquer à ces situations.
L’Experience Platform n’effectue pas actuellement d’agrégation automatique des valeurs, bien que cette opération soit prévue pour les versions ultérieures. Si vous choisissez d’utiliser des valeurs agrégées, vous devez effectuer les calculs en externe avant d’envoyer les données à Platform.
Les cardinalités établies dans votre DRE peuvent également fournir des indices sur la manière de classer vos entités. S'il existe une relation de type "un à plusieurs" entre deux entités, l'entité qui représente le "plusieurs" sera probablement une entité événement. Cependant, il existe également des cas où "plusieurs" est un ensemble d'entités de recherche fournies sous forme de tableau dans une entité de profil.
Étant donné qu'il n'existe pas d'approche universelle pour tous les cas d'utilisation, il est important de tenir compte des avantages et des inconvénients de chaque situation lorsqu'on classe les entités en fonction de leur cardinalité. Voir la section suivante pour plus d'informations.
Le tableau suivant présente quelques relations d'entité communes et les catégories qui peuvent en découler :
Relation | Cardinalité | Catégories d’entité |
---|---|---|
Clients et passages en caisse | Un à plusieurs | Un client unique peut avoir plusieurs passages en caisse, c'est-à-dire des événements qui peuvent être suivis au fil du temps. Les clients seraient donc une entité de profil, tandis que les passages en caisse seraient une entité de événement. |
Clients et comptes de fidélité | Un à un | Un client unique ne peut avoir qu’un seul compte de fidélité, et vice versa. Dans la mesure où la relation est personnalisée, les clients et les comptes de fidélité représentent tous deux des entités de profil. |
Clients et Abonnements | Un à plusieurs | Un client unique peut avoir plusieurs abonnements. Puisque la société ne concerne que les abonnements actuels d’un client, Clients est une entité de profil, tandis que les Abonnements sont une entité de recherche. |
Bien que la section précédente fournisse quelques lignes directrices générales pour décider comment classer vos entités, il est important de comprendre qu'il peut y avoir souvent des avantages et des inconvénients pour choisir une catégorie d'entité plutôt qu'une autre. L'étude de cas ci-après a pour but d'illustrer comment vous pourriez envisager vos options dans ces situations.
Une société effectue le suivi des abonnements principaux pour ses clients, où un client peut avoir plusieurs abonnements. La société souhaite également inclure des abonnements pour les cas d’utilisation de la segmentation, comme la recherche de tous les utilisateurs ayant des abonnements principaux.
Dans ce scénario, la société dispose de deux options potentielles pour représenter les abonnements d’un client dans son modèle de données :
La première approche consisterait à inclure un tableau d'abonnements en tant qu'attributs dans l'entité de profil pour les clients. Les objets de ce tableau contiendront des champs pour category
, status
, planName
, startDate
et endDate
.
Avantages
Cons
La deuxième approche consisterait à utiliser des schémas de événement pour représenter les abonnements. Cela implique l’importation des mêmes champs d’abonnement que la première approche, avec l’ajout d’un ID d’abonnement, d’un ID de client et d’un horodatage indiquant le moment où le événement d’abonnement s’est produit.
Avantages
Cons
Une fois que vous avez trié vos entités en catégories de profil, de recherche et de événement, vous pouvez début convertir votre modèle de données en schémas XDM. À des fins de démonstration, l’exemple de modèle de données présenté précédemment a été trié en catégories appropriées dans le diagramme suivant :
La catégorie sous laquelle une entité a été triée doit déterminer la classe XDM sur laquelle vous basez son schéma. Pour répéter :
Bien que les entités de événement soient presque toujours représentées par des schémas distincts, les entités du profil ou des catégories de recherche peuvent être combinées dans un seul schéma XDM, selon leur cardinalité.
Par exemple, puisque l'entité Clients entretient une relation personnalisée avec l'entité LoyaltyComptes, le schéma de l'entité Clients peut également inclure un objet LoyaltyAccount
contenant les champs de fidélité appropriés pour chaque client. Cependant, si la relation est de un à plusieurs, l'entité qui représente le "nombre" peut être représentée par un schéma distinct ou un ensemble d'attributs de profil, selon sa complexité.
Les sections ci-dessous fournissent des conseils généraux sur la construction de schémas en fonction de votre DRE.
Les règles de l'évolution des schémas dictent que seuls des changements non destructifs peuvent être apportés aux schémas une fois qu'ils ont été mis en oeuvre. En d’autres termes, une fois que vous avez ajouté un champ à un schéma et que des données ont été ingérées sur ce champ, le champ ne peut plus être supprimé. Il est donc essentiel d'adopter une approche de modélisation itérative lors de la création initiale de vos schémas, en commençant par une mise en oeuvre simplifiée qui gagne progressivement en complexité au fil du temps.
Si vous ne savez pas si un champ particulier est nécessaire pour être inclus dans un schéma, la meilleure pratique consiste à l’exclure. S’il est déterminé par la suite que le champ est nécessaire, il peut toujours être ajouté à la prochaine itération du schéma.
Dans l’Experience Platform, les champs XDM marqués comme identités sont utilisés pour rassembler les informations sur les clients individuels provenant de plusieurs sources de données. Bien qu'un schéma puisse comporter plusieurs champs marqués comme identités, une seule identité Principale doit être définie pour que le schéma puisse être activé pour une utilisation dans Real-time Customer Profile. Consultez la section champs d'identité dans les bases de la composition des schémas pour plus d'informations sur le cas d'utilisation de ces champs.
Lors de la conception de vos schémas, toute clé Principale dans vos tables de base de données relationnelles sera probablement candidate pour des identités Principales. Les autres exemples de champs d'identité applicables sont les adresses électroniques des clients, les numéros de téléphone, les ID de compte et ECID.
Experience Platform fournit plusieurs mixins XDM prêts à l’emploi pour la capture de données liées aux applications d’Adobe suivantes :
Par exemple, le modèle Adobe Analytics ExperienceEvent Mixin permet de mapper des champs Analytics spécifiques à vos schémas XDM. Selon les applications d’Adobe que vous utilisez, vous devez utiliser ces mixins fournis par Adobe dans vos schémas.
Les mixins d'application d'Adobe attribuent automatiquement une identité Principale par défaut à l'aide du champ identityMap
, qui est un objet généré par le système et en lecture seule qui mappe les valeurs d'identité standard d'un client individuel.
Pour Adobe Analytics, l’ECID est l’identité Principale par défaut. Si une valeur ECID n'est pas fournie par un client, l'identité Principale devient AAID par défaut.
Lors de l’utilisation de mixins d’application d’Adobe, aucun autre champ ne doit être marqué comme l’identité Principale. S’il existe d’autres propriétés qui doivent être marquées comme identités, ces champs doivent être attribués en tant qu’identités secondaires à la place.
Ce document décrit les instructions générales et les meilleures pratiques relatives à la conception de votre modèle de données pour Experience Platform. Pour résumer :
Une fois que vous êtes prêt, consultez le didacticiel Création d'un schéma dans l'interface utilisateur pour obtenir des instructions détaillées sur la création d'un schéma, affectez la classe appropriée pour l'entité et ajoutez des champs à lesquels mapper vos données.