Skip to main content

Mapping DLOs to DMOs — Data 360 how-to

How meaning gets assigned in Data 360: the flow from Data Lake Object fields to Data Model Object attributes, the transformations available on the way, and the mapping mistakes that produce silent wrong data downstream.

How-to·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Mapping is the step where raw ingested data becomes meaningful: you connect a Data Lake Object's fields to a Data Model Object's attributes. It is the single most consequential decision in the model and the least visible — a wrong mapping throws no error, it just produces wrong or empty values everywhere downstream.

The mapping flow

  1. Ingest — a Data Stream lands data in a DLO.
  2. Choose the target DMO — a standard DMO where possible (Individual, Contact Point Email), a custom one only when defensible.
  3. Map fields to attributes — connect each DLO field to the DMO attribute that carries its meaning. Match on meaning, not just on a similar column name.
  4. Set the primary key and relationships — tell Data 360 (formerly Data Cloud) what identifies a row and how it relates to other DMOs.
  5. Validate — confirm values land in the right attributes against real sample data before anything downstream reads them.

Reference:

What survives in production

Map on meaning, not on column name

A source field called state might hold a US state, a process status, or a country code depending on the system. Mapping it to the DMO attribute that matches the name rather than the meaning is how a state field ends up mapped to country. Read what the field actually contains in the source before you map it.

Never leave a required attribute unmapped

An unmapped required attribute doesn't error — it produces blanks that ripple into every segment and insight. Treat the required attributes of each DMO as a checklist that has to be fully satisfied before the mapping is done.

Normalize on the way in

Mapping is the natural place to normalize: trim whitespace, lowercase email addresses, standardize country codes. Normalizing once at the mapping layer beats every downstream consumer normalizing differently — the same "compute once" logic that makes a Calculated Insight trustworthy.

Review mappings as a deliverable

A mapping is code: it deserves a reviewer who checks each field against the source's real semantics. The cost of skipping the review is silent data corruption discovered weeks later in a mis-targeted campaign.

Common mapping mistakes

  • Wrong attribute — state mapped to country, created mapped to modified. Silent, and wrong everywhere.
  • Type mismatch — a date stored as text in the source mapped to a date attribute; it either fails to parse or coerces unpredictably.
  • Unmapped required field — blanks downstream, no warning.
  • Mapping a DLO one-to-one to a DMO without harmonizing — relocates the source's mess instead of modeling it.

Related