Pourquoi modéliser les données ?

Les entreprises ont leur propre langue pour communiquer sur leur domaine. Les concessionnaires automobiles s'occupent des marques, des modèles et des cylindres. Les compagnies aériennes s'occupent des numéros de vol, de la classe de service et des assignations de sièges. Certains de ces termes sont propres à une entreprise spécifique, d’autres sont partagés entre les secteurs verticaux et d’autres encore sont partagés par presque toutes les entreprises. Pour les termes partagés entre les secteurs verticaux ou même au-delà, vous pouvez commencer à faire des choses puissantes avec vos données en les nommant et en les structurant de manière commune.

Par exemple, de nombreuses entreprises traitent des commandes. Et si, collectivement, ces entreprises décidaient de modéliser une commande de la même manière ? Par exemple, que se passerait-il si le modèle de données était constitué d’un objet avec une propriété priceTotal qui représentait le prix total de la commande ? Que se passerait-il si cet objet avait également des propriétés appelées currencyCode et purchaseOrderNumber ? Peut-être que l’objet de commande contient une propriété nommée payments qui serait un tableau d’objets de paiement. Chaque objet représente un paiement pour la commande. Par exemple, un client a peut-être payé une partie de la commande avec une carte cadeau et le reste avec une carte de crédit. Vous pouvez commencer à créer un modèle qui ressemble à ceci :

{
  "order": {
    "priceTotal": 89.50,
    "currencyCode": "EUR",
    "purchaseOrderNumber": "JWN20192388410012",
    "payments": [
      {
        "paymentType": "gift_card",
        "paymentAmount": 50
      },
      {
        "paymentType": "credit_card",
        "paymentAmount": 39.50
      }
    ]
  }
}

Si toutes les entreprises traitant des commandes décidaient de modéliser leurs données de commande de manière cohérente pour les termes courants dans le secteur, des choses magiques pourraient commencer à se produire. Les informations pourraient être échangées plus facilement à l’intérieur et à l’extérieur de votre organisation au lieu d’interpréter et de traduire constamment les données (props et evars, quelqu’un d’autre ?). Le machine learning pourrait comprendre plus facilement ce que vos données signifient et fournir des informations exploitables. Les interfaces utilisateur permettant d’extraire des données pertinentes pourraient devenir plus intuitives. Vos données peuvent être intégrées de manière transparente avec les partenaires et les fournisseurs qui suivent la même modélisation.

C’est l’objectif d’Adobe modèle de données d’expérience. XDM fournit une modélisation prescriptive pour les données courantes dans le secteur, tout en vous permettant d’étendre le modèle en fonction de vos besoins spécifiques. Adobe Experience Platform est construit autour de XDM et, par conséquent, les données envoyées à Experience Platform doivent être dans XDM. Plutôt que de réfléchir à l’endroit et à la manière de transformer vos modèles de données actuels en XDM avant d’envoyer les données à Experience Platform, envisagez d’adopter XDM de manière plus répandue dans votre entreprise afin que la traduction ait rarement besoin de se produire.

REMARQUE
À des fins de démonstration, les exercices de cette leçon créent un exemple de schéma pour capturer le contenu consulté et les produits achetés par les clients dans le site de démonstration Luma. Bien que vous puissiez utiliser ces étapes pour créer un schéma différent pour vos propres besoins, il est recommandé de suivre d’abord la création de l’exemple de schéma pour découvrir les fonctionnalités de l’éditeur de schémas.

Pour en savoir plus sur les schémas XDM, regardez la liste de lecture Modélisez vos données d’expérience client avec XDM ou consultez la présentation du système XDM.