7.1 Experience Data Model (XDM) Foundations for Journey Optimizer

7.1 XDM Foundations for Journey Optimizer

Experience Data Model gives Adobe Experience Platform a consistent meaning and structure for data. Business practitioners need to distinguish the two main person-related classes and recognize how schemas, datasets, identity, and Profile fit together.

Record data: XDM Individual Profile

Use XDM Individual Profile for current attributes describing an individual or organization record: name, loyalty tier, preferred store, account status, contact addresses, or current subscription preferences.

Record data represents the latest understood state. When multiple profile-enabled datasets contribute different values for the same attribute, Real-Time Customer Profile uses the selected merge policy to decide which value appears in the combined profile.

Do not use record fields to store an endlessly repeating list of every purchase or click. Those are occurrences and belong in a time-series model.

Time-series data: XDM ExperienceEvent

Use XDM ExperienceEvent for something that happened at a time: page view, checkout, app launch, message click, order, or service incident. Experience events carry an occurrence identifier and timestamp, plus event-specific details.

A unitary journey can listen for an individual ExperienceEvent and use selected payload fields as context. A business event also uses an ExperienceEvent-based schema but a non-people primary identity appropriate to the business signal.

Events form history. They do not automatically overwrite a current profile attribute merely because they contain a similarly named value.

Schema, class, and field groups

A schema is the contract for the data. Its class establishes fundamental behavior, and field groups add reusable sets of fields. Standard field groups support common concepts such as person details, identity, consent, commerce, and web interaction. Custom field groups extend the model for organization-specific needs.

Custom fields are placed under the organization's tenant namespace. That prevents one customer's “loyaltyStatus” from colliding with Adobe standard fields or another customer's extension. Use standard XDM concepts when they fit; create custom fields only when the business meaning is not already represented.

A schema describes structure. A dataset stores data conforming to that schema. One schema can support multiple datasets for different sources or precedence needs.

Identity

A field can be marked as an identity and associated with a namespace such as ECID, email, phone, or a custom CRM ID. A primary identity indicates the main identity context for records in that schema. Identity meaning matters: the same text value under two namespaces is not automatically the same identity.

For Profile use, the schema must have suitable identity configuration and be enabled for Profile. A dataset created from it must also be enabled when its data should contribute to Profile. This is not implied merely by showing data in the Data Lake.

Selection examples

A calculated “lifetime spend” could be stored as a current record attribute when upstream processing maintains it, while each purchase remains an ExperienceEvent. Model meaning, not just datatype.

Schema review for a journey

Before using a field:

1. confirm class and field group;
2. inspect exact path and datatype;
3. confirm identity and namespace;
4. determine whether the source dataset is Profile-enabled;
5. verify ingestion populates the expected values;
6. inspect the combined profile and event history;
7. confirm the field is available in the journey or personalization selector;
8. apply data labels and policy review.

Common modeling errors

• Putting repeating history into a single record field.
• Using an ExperienceEvent for a value that should represent current state without maintaining that state elsewhere.
• Assuming a schema automatically creates or ingests a dataset.
• Treating any field named “email” as an identity without configuration.
• Promising an exact “sub-second” journey result from schema design alone.
• Creating a duplicate custom field when a standard XDM field exists.

Modeling exercise

For a subscription service, model current plan, renewal date, and preferred language as record attributes; model sign-in, plan change, payment, and cancellation request as events. Then identify which event should also update a current status through an upstream process. This separates immutable history from the state that journeys and audiences need to read later.