Experience Data Model (XDM), a shared schema framework that standardizes how data is defined and stored. XDM is essentially a library of schema “building blocks” (classes and field groups) that describe customer attributes and events. By modeling your data in XDM schemas, you ensure all incoming data fits a consistent structure.

Experience Data Model (XDM)

Adobe’s XDM class structure defines how customer data is stored and merged.

Primary Entity Classes

The Individual Profile class captures static traits (record-oriented attributes of a person), while the ExperienceEvent class captures time-series behaviors (timestamped events or actions). Profile schemas merge incoming records by identity into one unified profile; by contrast, ExperienceEvent schemas append each event as a new record (and only de-duplicate based on the event’s unique _id).

In both cases, the row-level _id is simply a record key and not a personal identity. Adobe’s docs note that _id identifies the event or profile record itself – actual person identity must come from designated identity fields, not the record _id.

Every Profile or Event schema must define one primary identity field (e.g. an email or CRM ID). Real-Time Customer Profile uses that primary identity as the source of truth when stitching data fragments together. The schema’s class also imposes certain fields and behavior: for example, all ExperienceEvent schemas require a timestamp field (since events are time-series).

Under the hood, AEP ingests all source data (online events, offline transactions, CRM records, etc.) into a central profile store. Real-Time Customer Profile merges this data into one unified, timestamped view of each person. In practice, the system consumes both the “traits” from Individual Profile schemas and the “behaviors” from ExperienceEvents.

Streaming pipelines (via APIs/SDKs) and batch loads feed into Adobe’s Identity Service and Segmentation engines. These produce a central profile and related audiences that can be queried in real time. For example, segments built on that profile can be activated directly in personalization engines and CRM campaigns.

Supporting Entities: Lookup and B2B Classes

In addition to the primary “person” entity, XDM supports auxiliary classes for richer context. Lookup (dimensional) schemas provide reference or classification data — think of Analytics-style classification tables that enrich a profile without creating new profiles.

B2B schemas capture account relationships (e.g. linking a person to a company or opportunity). These lookup and B2B entities connect to the primary profile via schema relationships (one-to-one for lookup, many-to-one for B2B). They are mainly used for segmentation and reporting (often in batch) and do not inflate the real-time profile weight.

Summary

XDM improves overall data quality and flexibility. Because all data follows the schema, marketing and data science teams can build segments or ML models without guessing field meanings. And if requirements change, you can extend or create XDM schemas in the UI, without re-tagging every site. In short, XDM underpins the Web SDK’s data streams: any event the SDK sends will ultimately map to XDM fields, so AEP knows how to handle it.