Study guide
7.1 Experience Data Model (XDM) Foundations for Journey Optimizer
Adobe Certified Professional - Adobe Journey Optimizer Business Practitioner AD0-E607
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Structure & Journey Fundamentals
1.1 AD0-E607 Exam Logistics, Scope, and Adobe Journey Optimizer Architecture 1.2 Journey Lifecycle States and Canvas Management 1.3 Unitary Journeys vs Business Journeys
2 Chapter 2: Journey Triggers & Event Modeling
2.1 Audience-Based Entry with Read Audience & Audience Qualification 2.2 Unitary Event Triggers & Schema Requirements 2.3 Business Events & Audience Broadcast Execution
3 Chapter 3: Journey Orchestration, Timing & Logic
3.1 Condition Activities and Branching Logic 3.2 Wait Activities and Timing Modulation 3.3 Action Nodes and the Jump Activity
4 Chapter 4: Journey Testing, Execution & Operational Reporting
4.1 Validation, Simulation, Test Mode, and Dry Run Execution 4.2 Live & All-Time Reporting Dashboards 4.3 Error Handling, Discards, and Operational Governance
5 Chapter 5: Multi-Channel Content Design & Personalization
5.1 The Email Designer & Multi-Channel Canvas Structure 5.2 Personalization Syntax & Expression Editor 5.3 In-App Messaging & Web In-Browser Delivery
6 Chapter 6: Reusable Assets, Fragments & Content Experiments
6.1 Visual Fragments vs Expression Fragments 6.2 Assets Essentials Management and Content Templates 6.3 Content Experimentation and Pre-Deployment Proofing
7 Chapter 7: XDM Schemas, Ingestion & Real-Time Customer Profiles
7.1 Experience Data Model (XDM) Foundations for Journey Optimizer 7.2 Datasets, Profile Enablement & Ingestion Troubleshooting 7.3 Real-Time Customer Profile & Profile Merge Policies
8 Chapter 8: Identity Resolution, Segmentation & Data Governance
8.1 Identity Service, Namespaces & Identity Graphs 8.2 Segmentation Methods: Streaming, Batch, Edge & Sequential Logic 8.3 Data Usage Labeling & Enforcement (DULE), Consent, and Privacy
9 Chapter 9: Decision Management, Offer Rules & Ranking Policies
9.1 Decision Management Architecture & Offer Library Components 9.2 Offer Eligibility Rules, Constraints & Capping 9.3 Decision Policies, Ranking & Channel Integration
7.1 Experience Data Model (XDM) Foundations for Journey Optimizer
Key Takeaways Explain This Topic AI
XDM Individual Profile models current record-like attributes; XDM ExperienceEvent models time-series occurrences.
A schema combines a class with field groups and descriptors, while a dataset is the storage and ingestion boundary created from that schema.
ExperienceEvent data includes an occurrence ID and timestamp; profile-enabled data also needs an appropriate primary identity.
Custom fields are namespaced for the organization to avoid collisions with standard XDM fields.
Choose the class from whether the fact describes who the person is now or something that happened at a point in time.
Last updated: October 2026
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
- Business fact Class Why
- Current loyalty tier XDM Individual Profile Present record attribute
- Product view at 10:04 UTC XDM ExperienceEvent Occurrence at a time
- Current email preference XDM Individual Profile Current preference state
- Email clicked XDM ExperienceEvent Behavioral event
- Current preferred store XDM Individual Profile Present attribute
- Order completed XDM ExperienceEvent Transactional occurrence
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:
- confirm class and field group;
- inspect exact path and datatype;
- confirm identity and namespace;
- determine whether the source dataset is Profile-enabled;
- verify ingestion populates the expected values;
- inspect the combined profile and event history;
- confirm the field is available in the journey or personalization selector;
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.
Tip
Ask one question: Is this a current fact, or did it happen at a time? The answer usually identifies Individual Profile or ExperienceEvent.
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.