Meilleures pratiques pour la modélisation des données

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.

Prise en main

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.

Résumé des bonnes pratiques

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 :

1. Identifiez les cas d’utilisation commerciale de vos données.
2. Identifier les sources de données Principales qui doivent être intégrées à Platform pour traiter ces cas d'utilisation.
3. Identifiez toutes les sources de données secondaires qui pourraient également présenter un intérêt. Par exemple, si, pour l'instant, une seule unité opérationnelle de votre organisation souhaite transférer ses données à Platform, une unité opérationnelle similaire pourrait également souhaiter transférer des données similaires à l'avenir. La prise en compte de ces sources secondaires permet de normaliser le modèle de données dans l’ensemble de votre organisation.
4. Créez un diagramme de relations d’entité de haut niveau (ERD) pour les sources de données qui ont été identifiées.
5. Convertissez l’ERD de haut niveau en ERD centré Platform (y compris les profils, les Événements d’expérience et les entités de recherche).

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.

Créer un ERD de haut niveau

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.

Tri des entités en catégories de profil, de recherche et de événement

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.

Considérations relatives au tri des entités

Les sections ci-dessous fournissent d'autres conseils sur la manière de trier vos entités en fonction des catégories ci-dessus.

Attributs du client

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 :

• Des informations personnelles telles que le nom, la date de naissance, le sexe et le ou les ID de compte.
• Informations sur l’emplacement, telles que les adresses et les informations GPS.
• Coordonnées, telles que numéros de téléphone et adresses électroniques.

Suivi des données au fil du temps

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

Cas d’utilisation de la segmentation

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 :

• "Or" et "Platine" représentent les états de fidélité applicables à un client individuel. Puisque la logique de segment ne concerne que l’état actuel de fidélité des clients, ces données peuvent être modélisées dans le cadre d’un schéma de profil. Si vous souhaitez suivre les modifications de l’état de fidélité au fil du temps, vous pouvez également créer un schéma de événement supplémentaire pour les modifications de l’état de fidélité.
• Les achats sont des événements qui se produisent à un moment donné et la logique de segment concerne les événements d'achat dans une période spécifiée. Ces données doivent donc être modélisées en tant que schéma de événement.

Cas d’utilisation des Activations

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.

Valeurs agrégées

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.

Cardinalité

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.

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.

Avantages et inconvénients de différentes classes d'entités

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 :

1. Utiliser des attributs de profil
2. Utiliser des entités de événement

Approche 1 : Utiliser les attributs de profil

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

• La segmentation est possible pour le cas d’utilisation prévu.
• Le schéma ne conserve que les derniers enregistrements d'abonnement pour un client.

Cons

• La baie entière doit être redémarrée chaque fois que des modifications sont apportées à un champ de la baie.
• Si différentes sources de données ou unités opérationnelles alimentent des données dans la baie, il sera difficile de synchroniser la baie la plus récente sur tous les canaux.

Approche 2 : Utiliser des entités de événement

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

• Les règles de segmentation peuvent être plus flexibles (par exemple, trouver tous les clients qui ont modifié leurs abonnements au cours des 30 derniers jours).
• Lorsque le statut d'abonnement d'un client change, vous n'avez plus à mettre à jour une baie longue et potentiellement complexe dans les attributs de profil du client. Cela s’avère particulièrement utile si des modifications simultanées de la liste d’abonnement du client proviennent de plusieurs sources.

Cons

• La segmentation devient plus complexe pour le cas d’utilisation prévu d’origine (identifiant l’état des abonnements les plus récents des clients). Le segment a désormais besoin d’une logique supplémentaire pour marquer le dernier événement d’abonnement d’un client afin de vérifier son état.

Créer des schémas en fonction de vos entités catégorisées

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 :

• Les entités de profil doivent utiliser la classe XDM Individual Profile.
• Les entités de événement doivent utiliser la classe XDM ExperienceEvent.
• Les entités de recherche doivent utiliser des classes XDM personnalisées définies par votre organisation.

Les sections ci-dessous fournissent des conseils généraux sur la construction de schémas en fonction de votre DRE.

Adopter une approche de modélisation itérative

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.

Champs d’identité

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.

Mélanges d'applications d'Adobe

Experience Platform fournit plusieurs mixins XDM prêts à l’emploi pour la capture de données liées aux applications d’Adobe suivantes :

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

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.

Étapes suivantes

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 :

• Utilisez une approche descendante en triant vos tableaux de données en catégories de profil, de recherche et de événement avant de construire vos schémas.
• Il existe souvent de multiples approches et options lorsqu'il s'agit de concevoir des schémas à des fins différentes.
• Votre modèle de données doit prendre en charge les cas d’utilisation de votre entreprise, tels que la segmentation ou l’analyse du parcours client.
• Rendez vos schémas aussi simples que possible et ajoutez uniquement de nouveaux champs quand cela est absolument nécessaire.

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.