XDM Individual Profile vs ExperienceEvent: which class your data belongs in
Record or time-series? How to choose between the XDM Individual Profile and ExperienceEvent classes, with a simple rule of thumb.
Why this matters
This decision matters because wrong placement leads to data loss. If events like purchases are stored in an Individual Profile, each new value overwrites the previous one, erasing the full history of user actions. This makes it impossible to analyze behavior over time or identify patterns in user journeys.
Using the wrong class also misaligns analytics and personalization efforts. For example, if a marketer asks “what did this user buy last week?” and the data is in a profile, the answer will only show the most recent purchase—never the full timeline. The timestamp in ExperienceEvent ensures accurate timing, while the record structure of Individual Profile preserves current state. Without this clarity, insights are incomplete, and decisions based on inaccurate data risk poor campaign performance and user experience.
The key ideas
Every data source in AEP must belong to one XDM class: either Individual Profile or ExperienceEvent. The Individual Profile class stores record data — facts about a person like name, email, or loyalty tier — where the most recent value is what matters. This class is used when you're asking "what is true about this person now?" For example, a customer’s current preferences or subscription status.
In contrast, ExperienceEvent is for time-series data — things that happen at a specific time, like a page view, purchase, or email open. Each event must include a unique _id and a timestamp in ISO 8601 format. This class is used when the question is "what did they do, and when?" Storing events like purchases in an Individual Profile schema causes the history to be lost, as each new value overwrites the previous one.
The key rule is simple: use Individual Profile when you want the current state of a person. Use ExperienceEvent when you need to track what happened and when. Misusing these classes leads to data loss or inaccuracies. Always ask the right question to decide which class fits your data.
How to apply it
Start by asking whether the data describes a person’s current state or a specific action at a point in time. If the answer is "current state"—like name, email, or loyalty level—use XDM Individual Profile. This class holds static attributes where the latest value is meaningful, and updates replace older values.
If the data captures an event—like a page view, click, or purchase—use XDM ExperienceEvent. Each such record must include an _id and a timestamp in ISO 8601 format. The timestamp ensures you can track when the event occurred. These records are time-series, meaning the history of events is preserved, not overwritten.
A common error is placing events, such as purchases, into a profile schema. This overwrites past values and loses event history. Instead, follow the rule of thumb: if the question is "what is true about this person now," use Individual Profile. If the question is "what did they do, and when," use ExperienceEvent. This distinction ensures accurate data modeling and supports downstream analytics and personalization.
Mistakes to avoid
A common mistake is storing events like purchases in an Individual Profile schema. Each new value overwrites the previous one, so the history of actions is lost. This means you can no longer track when a user made a purchase or how many times they’ve bought over time. To avoid this, always use ExperienceEvent for such events. The schema must include a timestamp in ISO 8601 format and an _id to identify the event uniquely.
Another error is assigning record-based fields to time-series data. For example, storing a user’s current loyalty tier in ExperienceEvent fails because it doesn’t reflect a persistent state. Always ask: “What is true about this person now?” If the answer is a static attribute, use Individual Profile. If the question is “What did they do, and when?” then ExperienceEvent is correct. This rule ensures data integrity and supports accurate journey analysis.
Quick checklist
- Is the data describing a person’s attributes, such as name, email, or preferences? If yes, use Individual Profile.
- Is the data describing a specific action at a point in time, like a page view or purchase? If yes, use ExperienceEvent.
- Does the data include a timestamp? If not, it must be added to the ExperienceEvent schema.
- Does the data represent a single value that updates over time, like a loyalty tier? If yes, it belongs in Individual Profile.
- Does the data require historical tracking of events, such as when a user made a purchase? If yes, it must be in ExperienceEvent.
- Are there fields that are only relevant to events, such as page URL or click time? If yes, they belong in ExperienceEvent.
- Is the question about the current state of a person, like "what is their current preference"? If yes, use Individual Profile.
Try it on a live AEP sandbox
Reading gets you the concept; doing it is what sticks. On the Lab plan you get your own AEP workspace, the linked CJA and journey sandboxes, and missions that check your work automatically.
AdsBot is independent and not affiliated with Adobe. Adobe product names are used only to describe the skills practised.
Want a hand putting this into practice?
AdsBot builds and runs the martech systems behind campaigns like this one.
See Our Services Talk to Us