Bonnes pratiques relatives à 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 adhérant aux normes XDM, toutes les données d’expérience client peuvent être intégrées à une représentation commune qui vous permet d’obtenir des informations précieuses à partir des actions des clients, de définir des audiences de clients par le biais de segments et d’exprimer les attributs du client à des fins de personnalisation.

XDM étant extrêmement polyvalent et personnalisable par sa conception, il est donc important de suivre les bonnes pratiques de modélisation des données lors de la conception de vos schémas. Ce document couvre les principales décisions et considérations à prendre lors du mappage de vos données d’expérience client à XDM.

Prise en main

Avant de lire ce guide, consultez la présentation du système XDM pour une présentation de haut niveau de XDM et de son rôle dans Experience Platform.

En outre, ce guide se concentre exclusivement sur les considérations clés concernant la conception de schéma. Il est donc vivement recommandé de consulter les bases de la composition des schémas pour obtenir des explications détaillées sur les éléments de schéma individuels mentionnés dans ce guide.

Résumé des bonnes pratiques

L’approche recommandée pour concevoir votre modèle de données à utiliser dans Experience Platform peut être résumée comme suit :

1. Présentation des cas d’utilisation professionnels pour vos données.
2. Identifiez les Principales sources de données qui doivent être introduites dans Platform pour répondre à ces cas d’utilisation.
3. Identifiez toutes les sources de données secondaires susceptibles d’intéresser l’utilisateur. Par exemple, si, pour l’instant, une seule unité opérationnelle de votre entreprise souhaite exporter ses données vers Platform, une unité opérationnelle similaire peut également souhaiter transférer des données similaires à l’avenir. En prenant en compte ces sources secondaires, vous pouvez normaliser le modèle de données dans l’ensemble de votre entreprise.
4. Créez un diagramme de relation 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 un ERD centré sur 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 requises pour exécuter vos cas d’utilisation métier varient 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 une fois les sources de données identifiées, les explications des différents composants du diagramme peuvent vous éclairer sur les décisions à prendre concernant les sources de données à migrer vers Platform.

Création d’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 à guider le processus de mappage de vos données aux schémas XDM.

L’exemple ci-dessous représente un ERD simplifié pour une entreprise qui souhaite importer des données dans Platform. Le diagramme présente les entités essentielles qui doivent être triées en classes XDM, notamment les comptes clients, les hôtels, les adresses et plusieurs événements de commerce électronique courants.

Trier les entités en catégories de profil, de recherche et d’é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 dans les catégories de profil, de recherche et d’événement :

Considérations pour le tri des entités

Les sections ci-dessous fournissent des conseils supplémentaires sur la manière de classer vos entités dans les 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 :

• Informations personnelles telles que le nom, la date de naissance, le sexe et le ou les identifiants de compte.
• Informations de localisation 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 au sein d’une entité changent au fil du temps, il s’agit probablement d’une entité d’événement. Par exemple, l’ajout d’éléments de produit à un panier peut être suivi en tant qu’événements de panier à ajouter dans Platform :

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 d’utilisation professionnels particuliers.

Par exemple, une entreprise souhaite connaître tous les membres "Gold" ou "Platinum" de son programme de fidélité qui ont effectué plus de cinq achats l’année dernière. Sur la base de cette logique de segment, vous pouvez tirer les conclusions suivantes concernant la manière dont les entités pertinentes doivent être représentées :

• "Gold" et "Platine" représentent les états de fidélité applicables à un client individuel. Puisque la logique de segment ne concerne que l’état de fidélité actuel 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 d’é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 fenêtre temporelle spécifiée. Ces données doivent donc être modélisées en tant que schéma d’événement.

Cas d’utilisation de l’activation

Outre les considérations relatives aux cas d’utilisation de la segmentation, vous devez également examiner les cas d’utilisation de l’activation pour ces segments afin d’identifier d’autres attributs pertinents.

Par exemple, une entreprise a créé un segment d’audience basé sur la règle country = US. Ensuite, lors de l’activation de ce segment vers certaines cibles en aval, l’entreprise souhaite filtrer tous les profils exportés en fonction de l’état d’origine. 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écider si certaines valeurs doivent être pré-agrégées avant d’être incluses dans un profil ou une entité d’événement.

Par exemple, une entreprise souhaite créer un segment en fonction du nombre d’achats de panier. Vous pouvez choisir d’incorporer ces données avec la granularité la plus faible en incluant chaque événement d’achat horodaté comme entité propre. Cependant, cela peut parfois augmenter le nombre d’événements enregistrés de manière exponentielle. Pour réduire le nombre d’événements ingérés, vous pouvez choisir de créer une valeur agrégée 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 ERD 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 "nombre" sera probablement une entité d’événement. Cependant, il existe également des cas où le "nombre" est un ensemble d’entités de recherche fournies sous forme de tableau dans une entité de profil.

Le tableau suivant décrit certaines relations d’entité courantes et les catégories qui peuvent en découler :

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

Bien que la section précédente ait fourni quelques instructions générales pour décider comment classer vos entités, il est important de comprendre qu’il peut souvent y avoir des avantages et des inconvénients à choisir une catégorie d’entités plutôt qu’une autre. L’étude de cas suivante a pour but d’illustrer la manière dont vous pouvez envisager vos options dans ces situations.

Une entreprise effectue le suivi des principaux abonnements de ses clients, où un client peut avoir de nombreux abonnements. L’entreprise souhaite également inclure des abonnements pour les cas pratiques de segmentation, comme la recherche de tous les utilisateurs avec 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. Utilisation des attributs de profil
2. Utilisation des entités d’événement

Approche 1 : Utilisation des attributs de profil

La première approche consiste à inclure un tableau d’abonnements en tant qu’attributs au sein de 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 dans le cas d’utilisation prévu.
• Le schéma ne conserve que les derniers enregistrements d’abonnement pour un client.

Inconvénients

• Le tableau entier doit être redémarré chaque fois que des modifications sont apportées à un champ du tableau.
• Si différentes sources de données ou unités opérationnelles alimentent des données dans le tableau, il sera difficile de conserver le dernier tableau mis à jour synchronisé sur tous les canaux.

Approche 2 : Utilisation des entités d’événement

La seconde approche consiste à utiliser des schémas d’événement pour représenter les abonnements. Cela implique l’ingestion des mêmes champs d’abonnement que la première approche, avec un ID d’abonnement, un ID client et un horodatage du moment où l’é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 l’état d’abonnement d’un client change, vous n’avez plus à mettre à jour un tableau long 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’abonnements du client proviennent de plusieurs sources.

Inconvénients

• La segmentation devient plus complexe pour le cas d’utilisation prévu d’origine (identification de l’état des inscriptions les plus récentes des clients). Le segment a désormais besoin d’une logique supplémentaire pour marquer le dernier événement d’abonnement pour 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 d’événement, vous pouvez commencer à convertir votre modèle de données en schémas XDM. À des fins de démonstration, l’exemple de modèle de données illustré 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. Réitération :

• Les entités de profil doivent utiliser la classe XDM Individual Profile .
• Les entités d’é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 création de schémas basés sur votre ERD.

Adopter une approche de modélisation itérative

Les règles d’évolution du schéma stipulent que seules des modifications non destructives peuvent être apportées aux schémas une fois qu’ils ont été implémentés. En d’autres termes, une fois que vous avez ajouté un champ à un schéma et que les données ont été ingérées par rapport à ce champ, le champ ne peut plus être supprimé. Il est donc essentiel d’adopter une approche de modélisation itérative lorsque vous créez vos schémas pour la première fois, 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 l’inclure dans un schéma, la bonne 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 Experience Platform, les champs XDM marqués comme identités sont utilisés pour rassembler des 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 utilisé dans Real-time Customer Profile. Consultez la section Champs d’identité dans les principes de base 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 tableaux de base de données relationnelle sera probablement candidate à des identités Principales. Les adresses électroniques des clients, les numéros de téléphone, les ID de compte et l’ECID sont d’autres exemples de champs d’identité applicables.

Adobe de groupes de champs de schéma d’application

Experience Platform fournit plusieurs groupes de champs de schéma 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 groupe de champs vous permet de mapper des champs Analytics spécifiques à vos schémas XDM. Selon les applications d’Adobe que vous utilisez, vous devez utiliser ces groupes de champs fournis par Adobe dans vos schémas.

Les groupes de champs d’application Adobe attribuent automatiquement une identité Principale par défaut grâce à l’utilisation 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, ECID est l’identité Principale par défaut. Si une valeur ECID n’est pas fournie par un client, l’identité Principale est définie par défaut sur AAID.

Étapes suivantes

Ce document couvrait les directives générales et les bonnes pratiques pour 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 d’événement avant de créer vos schémas.
• Il existe souvent plusieurs 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 vos cas d’utilisation métier, tels que la segmentation ou l’analyse de parcours client.
• Rendez vos schémas aussi simples que possible et ajoutez uniquement de nouveaux champs lorsque cela est absolument nécessaire.

Une fois que vous êtes prêt, consultez le tutoriel sur la 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, affecter la classe appropriée à l’entité et ajouter des champs auxquels mapper vos données.