In brief — Customer data modelling is, at its core, designing the schema of the customer profile: the decisions that decide whether that profile holds together, made before any platform is opened. Adobe Experience Platform (XDM field groups) and Salesforce Data 360 (Data Model Objects) both exist to express these decisions, so the schema — not the platform — decides the outcome. This pillar sets out the seven-decision framework, maps it to both platforms, and links each decision to its deeper guide.

The problem: schema design is the decision the platform cannot make for you

Schema design is often treated as a set-up task — accept the vendor’s default profile object, map a few fields, move on. The cost surfaces later, because the schema is the layer that is most expensive to change once data and activations depend on it:

• A default profile object cannot answer household questions it was never modelled for.
• History that was overwritten instead of dated cannot be recovered.
• A field renamed or restructured breaks every audience built on it.

The decisions are platform-agnostic: whether the model is built as Data Model Objects in Data 360 or XDM schemas in Adobe Experience Platform, the same seven questions have to be answered, and the answers are modelling judgements rather than product features. The running example is a multi-channel grocer building one customer profile across till, e-commerce, app and loyalty.

The framework: seven schema-design decisions

The framework is a sequence of seven decisions, each a design question with a recommended default and its trade-off:

1. How to decompose the model — one schema or many.

2. How to separate record data from event data.

3. How to model entities, grain and relationships.

4. How to design attributes to a taxonomy.

5. How to model time.

6. How to embed governance.

7. How to design for change.

Decision 1 — Decompose the model: small linked schemas, not one monolith

The recommended default is modular — domain- and entity-scoped schemas built from small, reusable components and linked by keys, rather than one large profile object.

• A monolith concentrates risk. Every attribute sits in one wide, sparse structure, so any change touches the whole object and the blast radius of a mistake is the entire profile.
• Modular components are governable and reusable. Loyalty attributes, contact attributes and order summary each live in their own component, versioned and reused independently, keeping a change local to what owns it.
• Normalise the model of record; denormalise only for serving. The source of truth is normalised and modular; a wide, denormalised view is built on top for activation and query speed, not used as the source of truth.
• Concession. A modular model is more design work upfront, and for a genuinely small single-channel dataset a flatter schema may be enough.

Decision 2 — Separate the profile record from the event stream

Stable, current-state attributes belong on the record; everything the customer does belongs in an append-only event schema.

• On the record: name, contact details, consent, loyalty tier — attributes that describe the customer now.
• In the events: every time-stamped action, held append-only.
• Not on the record: counters and last-seen fields such as last-order-date or lifetime-order-count — these force in-place mutation and drift, and are derived from events instead.
• Why it matters: for the grocer, a returned item or a delayed till export becomes a new event, not an overwrite, so derived attributes recompute rather than being patched.

Decision 3 — Model entities, grain, and relationships

A customer model is rarely just the individual, and each entity needs a declared grain and explicit relationships.

• Entities: person, the distinction between a person and their multiple profiles, household, and — for business customers — account.
• Grain: one row per person, per household, per order — declared, not assumed.
• Relationships and keys: modelled explicitly with cardinality; these keys are what identity resolution later populates.
• Consequence: a model that recognises only the individual grain cannot answer a household-level question, however good the resolution logic is.

Decision 4 — Design attributes to a taxonomy

Field-level design needs shared conventions so a field means the same thing everywhere.

• Naming and taxonomy: a convention and shared data dictionary, so “email_opt_in” and “marketing_consent” cannot drift into meaning the same thing when they do not.
• Types and vocabularies: controlled vocabularies and enumerations rather than free text where the values are known.
• Multi-valued attributes: several emails or addresses modelled as arrays or child objects, not repeated flat columns.
• Derived vs source: derived attributes marked as distinct from source attributes so their provenance is clear.

Decision 5 — Model time explicitly

Where history has analytical value, the schema represents it rather than overwriting the current value.

• Effective dating: valid-from and valid-to fields on attributes whose history will be queried — a customer’s dietary preference, address or loyalty tier.
• Bi-temporal where needed: separate when a value was true in the world from when the system recorded it, so late-arriving corrections apply without rewriting history.
• Per attribute: the decision is made field by field, against whether its history will ever be queried — not every field warrants it.

Decision 6 — Bake governance into the schema

Governance is a modelling concern, carried in the schema rather than bolted on later.

• PII classification at the field level.
• Consent and preference modelled as first-class fields, not stored in a separate system.
• Provenance / party-of-origin — first-, second- or third-party — carried on the record, so permitted use can be enforced at activation and a third-party attribute is not used where only first-party consent exists.

Decision 7 — Design for evolution

The schema will change, so it is modelled for change from the start.

• Additive and backward-compatible changes, so existing activations do not break.
• Standard before custom: reuse standard schema components before inventing custom ones, for interoperability with destinations.
• Deprecation path defined, rather than deleting fields in place.
• Multi-brand / multi-region: what schema is shared and what is isolated is decided here, not discovered later.

Implementing the framework in Data 360 and AEP

Both platforms express these decisions; only the constructs differ.

Adobe Experience Platform (XDM):

• A schema is assembled from a class (XDM Individual Profile for record data, XDM ExperienceEvent for events) plus reusable field groups; multiple schemas combine into the Real-Time Customer Profile through the union view.
• Field groups are the native answer to Decision 1 — small, reusable components rather than a monolith — and standard field groups exist to be reused before building custom.
• Schema relationships, effective-dating patterns, the Consent and Preference field group and Data Usage Labelling (DULE) express Decisions 3, 5 and 6 directly.

Salesforce Data 360 (DMOs):

• Source Data Lake Objects are mapped to entity- and domain-scoped Data Model Objects related by keys — the modular decomposition of Decision 1 — with the standard Customer 360 data model as reusable starting objects.
• Relationships between DMOs, effective-dating fields, consent DMOs and data-usage policies, and Data Spaces for multi-brand isolation express the entity, time, governance and evolution decisions.

In both, the modelling judgement is the same; the product only decides what the components are called.

The cluster: where each decision goes deeper

This pillar is the map; each decision is expanded in its own guide. The deep-dive guides, published progressively, are:

• Decompose the model → *one big table vs star schema*, and *the customer profile schema* in detail.
• Record vs event → *the event data model*.
• Entities and relationships → *dimensional modelling for marketing*, and *the customer 360 data model*.
• Attributes and taxonomy → *the customer data taxonomy*.
• Model time → *slowly changing dimensions for customer data*.
• Serving and consumption → *the semantic layer for customer data*, and *activation-ready data models*.
• Implementation → *modelling customer data in dbt*, and *the marketing data model* end to end.

Each becomes a linked guide as it is published; until then it names the territory this pillar covers.

Conclusion: the schema is the decision that lasts

Customer data schema design is seven decisions taken deliberately: decompose into small linked schemas, separate record from event, model entities and relationships, design attributes to a taxonomy, model time, embed governance, and design for change. None is made by the platform, and all are expensive to reverse once activations depend on the schema.

The practical starting point is narrow — take the current profile schema and check two things:

• Is it one wide object, or a set of linked components?
• Has behaviour been folded into the profile record as counters?

Those two answers reveal most of the schema debt in an existing model, and both are cheaper to fix before more activations depend on the shape.

Next step

Schema design is one part of a wider stack: the schema defines the target that identity resolution populates, and it sits inside the customer data infrastructure that ingestion, activation and measurement all depend on. A team should start by auditing the current schema against the two checks above, then follow the deep-dive guide for whichever decision the model is weakest on.

Frequently Asked Questions

Should a customer profile use one big schema or several small linked schemas?

Several small, linked schemas is the recommended default. A monolithic schema concentrates every attribute in one wide object, so changes touch everything, reuse is impossible, and the blast radius of a mistake is the whole profile. Modular, domain-scoped components — linked by keys and combined into a unified profile view — are governable, reusable and evolvable, with a denormalised serving view built on top for activation speed.

Is a normalised or denormalised schema better for a customer 360?

The model of record should be normalised and modular; the denormalised, wide form belongs to a serving layer built on top of it. A normalised model keeps behaviour separate from attributes and supports historied fields, which a single wide table forces you to compromise. Denormalising for direct activation is legitimate as a downstream view, but using it as the source of truth reintroduces the mutable-profile problem.

What is the difference between a schema and a data model?

A data model is the whole design — entities, grain, relationships, keys and the rules that connect them — while a schema is the concrete structure of one part of it, such as the profile schema or an event schema. In practice a customer data model is expressed as a set of related schemas; schema design is the act of deciding each schema’s fields, types and relationships within that model.

How do XDM field groups and Data Model Objects relate to schema design?

They are the two platforms’ building blocks for the same decisions. XDM field groups are small, reusable components composed onto a class to form a schema in Adobe Experience Platform; Data Model Objects are the entity- and domain-scoped objects mapped from source data in Data 360. Both are designed to be composed modularly rather than as one monolithic object, which is the recommended schema-design pattern.

How should a schema handle attributes that change over time?

Model history explicitly with effective-dating fields — valid-from and valid-to — on the attributes whose history will be queried, rather than overwriting the current value. For corrections that arrive after the fact, a bi-temporal design separates when a value was true from when it was recorded. Not every field needs this; the decision is made per attribute against whether its history has analytical value.