Data Model Objects (DMO) : mapper vos données correctement

Les Data Model Objects (DMO) forment la couche sémantique de Data Cloud : c'est le modèle de données harmonisé vers lequel toutes vos sources hétérogènes convergent. Là où un Data Stream représente la donnée telle qu'elle arrive de la source (un objet Salesforce, un fichier CSV, un flux d'événements), un DMO représente cette même donnée une fois normalisée dans un vocabulaire commun, permettant à l'Identity Resolution, aux Calculated Insights et aux Segments de fonctionner indépendamment de la source d'origine.

DMO standards vs DMO custom

Data Cloud livre un socle de DMO standards inspirés du modèle Customer 360 Data Model : Individual (une personne physique), Contact Point Email, Contact Point Phone, Party Identification, Sales Order, Product, Engagement, etc. Ces objets standards existent pour maximiser la compatibilité avec les fonctionnalités prêtes à l'emploi (Identity Resolution, segments prédéfinis, connecteurs d'activation). Quand une donnée source n'a pas d'équivalent standard pertinent (un score de risque métier propre à votre secteur, un attribut produit spécifique), vous créez un DMO custom depuis Data Cloud > Data Model > New Data Model Object.

• Privilégiez toujours un DMO standard existant si le concept correspond, même approximativement : cela évite de recréer des règles d'Identity Resolution et de perdre les intégrations prêtes à l'emploi.
• Un DMO custom doit avoir une Primary Key explicite et, si pertinent, des relations déclarées vers d'autres DMO.
• Nommez vos DMO et champs custom avec une convention cohérente dès le départ : renommer après un déploiement en production impacte tous les Calculated Insights et Segments qui en dépendent.

Le mapping : de l'objet source au DMO

Une fois le Data Stream créé, l'étape Data Stream > Data Model Mapping permet d'associer chaque champ source à un champ de DMO cible. Pour les objets CRM standards (Contact, Account), Data Cloud propose un mapping automatique raisonnable, mais il doit systématiquement être vérifié champ par champ :

1. Ouvrez l'onglet Mapping du Data Stream.
2. Pour chaque champ source, vérifiez le DMO et le champ cible proposés.
3. Corrigez les mappings incorrects ou manquants (un champ custom source n'a jamais de mapping automatique).
4. Pour un champ sans équivalent dans le DMO standard, ajoutez-le comme champ custom sur le DMO, ou créez un DMO custom relié si le concept est trop éloigné.

Un mapping mal fait est la cause numéro un des problèmes en aval : un champ email mappé vers le mauvais Contact Point, ou un identifiant source mappé comme attribut au lieu de clé, fausse toute la résolution d'identité sans qu'aucune erreur explicite ne remonte.

Relations entre DMO

Les DMO se relient entre eux via des relationships déclarées explicitement (équivalent conceptuel des lookups Salesforce), visibles dans le Data Model Canvas (Data Cloud > Data Model > Canvas). Ce canvas est l'outil le plus utile au quotidien pour un consultant : il donne une vue graphique de tout le modèle, DMO standards et custom confondus, avec leurs relations. Avant toute création de Calculated Insight ou de Segment complexe, ouvrez systématiquement le canvas pour vérifier que le chemin de relation entre les DMO que vous voulez croiser existe réellement — sinon la requête échouera ou nécessitera un DMO intermédiaire.

Category : Profile, Engagement, Other

Chaque DMO hérite d'une Category définie au niveau du Data Stream source : Profile pour les données décrivant une entité (un client, un compte), Engagement pour les données événementielles horodatées (achats, clics, appels), et Other pour le reste (référentiels produits, données de configuration). Cette catégorisation détermine notamment quels DMO sont éligibles à l'Identity Resolution (seuls les DMO Profile le sont) et comment les Engagement sont gérés en termes de rétention et de volumétrie.

Ne mappez jamais un DMO Engagement comme s'il s'agissait d'un DMO Profile pour "simplifier" un cas d'usage. Les volumes d'Engagement grandissent vite (un événement par clic, par vue de page) et un mauvais typage peut faire exploser inutilement votre consommation de stockage et de crédits de traitement.

Bonnes pratiques de gouvernance du modèle

Sur un projet avec plusieurs contributeurs, documentez votre modèle de données en dehors de l'interface (un tableau simple suffit au début) : quel DMO standard est utilisé pour quel concept métier, quels DMO custom existent et pourquoi, quelles relations sont critiques. Cette documentation devient rapidement indispensable car le Data Model Canvas, aussi utile soit-il, ne remplace pas une vision métier du "pourquoi" de chaque choix de modélisation. Enfin, limitez la prolifération de DMO custom redondants : avant de créer un nouveau DMO, vérifiez toujours qu'un DMO existant ne peut pas être étendu avec un champ custom, ce qui simplifie considérablement la maintenance à long terme.