DLO (Data Lake Objects) et DMO (Data Model Objects)
Dans Salesforce Data 360, les données provenant du CRM, d’un site e-commerce, d’un outil marketing ou d’une plateforme externe ne peuvent pas être exploitées efficacement tant qu’elles restent organisées selon des structures différentes.
Les Data Lake Objects, ou DLO, et les Data Model Objects, ou DMO, interviennent à deux étapes distinctes de cette organisation.
Le DLO accueille les données issues d’une source. Le DMO leur donne ensuite une structure commune afin qu’elles puissent être rapprochées et utilisées dans Data 360.
Qu’est-ce qu’un Data Lake Object ?
Un Data Lake Object, généralement abrégé en DLO, est un objet utilisé pour accueillir les données ingérées ou fédérées dans Salesforce Data 360.
Salesforce le présente comme un conteneur fondamental dans lequel les données sont d’abord conservées avant d’être associées à un modèle harmonisé.
Lorsqu’une source est connectée à Data 360, un Data Stream organise l’arrivée des données. Les informations correspondantes sont ensuite représentées dans un ou plusieurs DLO.
Le DLO conserve une structure proche de celle de la source d’origine.
Par exemple, une plateforme e-commerce peut transmettre les champs suivants :
-
customer_id; -
customer_email; -
first_order_date; -
total_order_value.
Ces champs peuvent être conservés dans un DLO correspondant aux données clients de la plateforme e-commerce.
Quel est le rôle d’un DLO ?
Le DLO permet à Data 360 de recevoir et de rendre accessibles des données provenant de systèmes différents.
Il constitue une première couche entre la source et le modèle de données unifié.
Un DLO peut notamment contenir :
-
des données issues de Salesforce CRM ;
-
des commandes provenant d’un site e-commerce ;
-
des interactions marketing ;
-
des données de navigation ;
-
des tickets de support ;
-
des données provenant d’un entrepôt externe ;
-
des données accessibles par Zero Copy.
À ce stade, chaque source peut conserver ses propres noms de champs, formats et règles de structuration.
Deux systèmes peuvent donc représenter la même information différemment.
Un CRM peut utiliser le champ Email, tandis qu’un outil e-commerce utilise customer_email. Les deux informations ont la même signification métier, mais ne possèdent pas encore une structure commune.
Qu’est-ce qu’un Data Model Object ?
Un Data Model Object, ou DMO, est un objet qui organise les données selon un modèle harmonisé.
Salesforce définit le DMO comme un regroupement harmonisé de données provenant de Data Streams, d’insights ou d’autres sources. Les données d’un DLO sont standardisées en associant ses champs à ceux d’un DMO.
Le DMO permet donc de donner une signification commune aux données, indépendamment du système dont elles proviennent.
Plusieurs DLO peuvent être associés au même DMO.
Les données provenant du CRM, du site e-commerce et du service client peuvent, par exemple, être associées à des objets correspondant à une personne, un point de contact ou un engagement.
Quelle est la différence entre un DLO et un DMO ?
La différence principale réside dans leur rôle.
| DLO | DMO |
|---|---|
| Accueille les données provenant d’une source | Organise les données selon un modèle commun |
| Reste proche de la structure d’origine | Utilise une structure harmonisée |
| Constitue une couche technique d’arrivée | Apporte une signification exploitable dans Data 360 |
| Peut contenir des noms de champs propres à la source | Utilise des objets et des relations standardisés ou personnalisés |
| Est mappé vers un ou plusieurs DMO | Peut recevoir des données provenant de plusieurs DLO |
Une formulation simple permet de retenir la différence : Le DLO représente la manière dont la donnée entre dans Data 360. Le DMO représente la manière dont Data 360 comprend et organise cette donnée.
Exemple concret de passage d’un DLO à un DMO
Imaginons une entreprise qui utilise trois systèmes.
Dans le CRM
Le contact est identifié avec :
-
ContactId; -
FirstName; -
LastName; -
Email.
Dans la plateforme e-commerce
Le client est identifié avec :
-
customer_id; -
customer_name; -
customer_email.
Dans l’outil de support
L’utilisateur est identifié avec :
-
requester_id; -
requester_email; -
ticket_number.
Chaque système alimente un DLO différent.
Les champs Email, customer_email et requester_email peuvent ensuite être associés à un champ harmonisé représentant l’adresse e-mail d’un point de contact.
Les données restent issues de trois sources différentes, mais Data 360 dispose désormais d’une structure cohérente pour les exploiter.
Comment les DLO sont-ils associés aux DMO ?
L’association entre un DLO et un DMO est appelée mapping.
Le mapping consiste à indiquer quel champ de la source correspond à quel champ du modèle de données.
Par exemple :
| Champ du DLO | Champ du DMO |
|---|---|
customer_id |
Party Identification Number |
customer_email |
Email Address |
first_name |
First Name |
last_name |
Last Name |
Cette étape exige une bonne compréhension des données.
Deux champs portant des noms différents peuvent avoir la même signification. À l’inverse, deux champs portant un nom similaire peuvent correspondre à des informations différentes.
Un mauvais mapping peut provoquer :
-
des profils incorrectement rapprochés ;
-
des données placées dans le mauvais objet ;
-
des segments incomplets ;
-
des analyses erronées ;
-
des activations marketing inadaptées.
Qu’est-ce que le Customer 360 Data Model ?
Le Customer 360 Data Model est le modèle standard proposé par Salesforce pour organiser les données dans Data 360.
Il contient différents objets et relations permettant de représenter notamment :
-
les personnes ;
-
les comptes ;
-
les coordonnées ;
-
les produits ;
-
les commandes ;
-
les engagements ;
-
les consentements ;
-
les interactions.
Les DMO standards facilitent l’utilisation de fonctionnalités communes à Data 360.
Une entreprise peut également créer des DMO personnalisés lorsqu’une donnée métier ne correspond pas correctement au modèle standard.
Où se situent les DLO et DMO dans le fonctionnement de Data 360 ?
Le parcours peut être résumé ainsi : Source de données → connecteur ou Zero Copy → Data Stream → DLO → mapping → DMO → unification → segmentation → activation
1. Connexion de la source
L’entreprise connecte une source telle qu’un CRM, un site e-commerce ou un entrepôt de données.
2. Création du Data Stream
Le Data Stream définit la manière dont les données sont récupérées et actualisées.
3. Création ou alimentation du DLO
Les données sont représentées dans un Data Lake Object selon une structure proche de leur source.
4. Mapping vers les DMO
Les champs du DLO sont associés aux objets et champs du modèle harmonisé.
5. Utilisation des données
Les DMO peuvent ensuite être exploités pour l’unification des profils, les insights, la segmentation ou l’activation.
Salesforce indique que les données ingérées sont stockées dans les DLO selon leur schéma initial avant d’être associées aux DMO du modèle Customer 360.
Pourquoi cette distinction est-elle importante ?
Comprendre la différence entre DLO et DMO permet d’éviter une confusion fréquente : connecter les données ne signifie pas qu’elles sont immédiatement prêtes à être utilisées.
Le DLO rend les données disponibles dans Data 360, mais le DMO leur apporte une structure cohérente.
Sans harmonisation, les mêmes notions peuvent rester réparties entre plusieurs champs ou plusieurs objets. Il devient alors difficile de :
-
rapprocher les identités ;
-
construire des segments fiables ;
-
analyser le parcours d’un client ;
-
utiliser les données dans un agent IA ;
-
activer les informations dans les autres outils.
Les erreurs fréquentes avec les DLO et les DMO
Mapper les champs uniquement selon leur nom
Le nom d’un champ ne permet pas toujours de comprendre son usage réel. Il faut également examiner son format, sa source et sa signification métier.
Créer trop de DMO personnalisés
Les objets personnalisés sont utiles, mais doivent répondre à un besoin qui ne peut pas être couvert correctement par le modèle standard.
Confondre harmonisation et unification
Le mapping vers un DMO harmonise la structure des données. Il ne détermine pas automatiquement si deux enregistrements correspondent à la même personne.
L’unification intervient ensuite, grâce à des règles de résolution d’identité.
Négliger les identifiants
Les clés primaires et les relations entre objets doivent être correctement définies. Une mauvaise gestion des identifiants peut créer des doublons ou rompre les relations entre les données.
Commencer le mapping sans modèle métier
Avant de configurer Data 360, l’entreprise doit déterminer ce que représentent ses données et comment elle souhaite les utiliser.
Questions fréquentes sur les DLO et les DMO
Un DLO est-il une base de données ?
Un DLO est un objet de stockage ou de représentation des données dans Data 360. Il ne doit pas être assimilé à une base de données indépendante.
Un DMO contient-il directement les données ?
Un DMO fournit une vue physique ou virtuelle des données harmonisées sous-jacentes, selon la manière dont la donnée a été connectée et configurée.
Plusieurs DLO peuvent-ils alimenter le même DMO ?
Oui. Plusieurs sources peuvent être associées à une structure harmonisée commune.
Un DLO peut-il être associé à plusieurs DMO ?
Selon la structure et les besoins de modélisation, les données d’un DLO peuvent servir à alimenter différents objets du modèle.
Le mapping fusionne-t-il automatiquement les profils ?
Non. Le mapping harmonise les données. La fusion ou le rapprochement des profils dépend ensuite des règles de résolution d’identité.
Faut-il toujours utiliser les DMO standards ?
Il est préférable de les utiliser lorsqu’ils correspondent au besoin. Des DMO personnalisés peuvent être créés pour les concepts métier qui ne trouvent pas leur place dans le modèle standard.
Pour aller plus loin
Vous souhaitez approfondir ce sujet ? Découvrez nos articles consacrés dans lesquels nous expliquons comment cette notion s’applique concrètement aux projets et aux enjeux des entreprises :