Migration › Knowledge Base › Schema & XDM
Schema & XDM
A schema is the blueprint of your data. Like an architect's drawing of a house, it holds nothing itself; there's no furniture in a blueprint, yet it decides where every room and doorway goes, and once built, you live inside those decisions every day.
In Experience Platform, the schema defines the exact shape every event must take before the Edge will accept it: which fields exist, what type each is, and where each value belongs. XDM (Experience Data Model) is the shared vocabulary those fields are drawn from, the standard that lets Analytics, CJA, and AEP all read the same structure.
Concretely: you pick the Experience Event class (time-series behaviour), then add field groups that contribute fields. The Edge rejects, drops, any payload that doesn't conform, which is why validation later leans so heavily on schema checks.
For your migration: a clean, well-structured schema is what makes today's Analytics effortless and tomorrow's CJA a "connect the dataset" job rather than a re-instrumentation. The schema is the contract every event signs.
Use the Experience Event class. Keep the schema clean and minimal, treat every field as a long-term commitment, and never enable Profile until validated.
Class, then field groups
An XDM schema is built in two layers. First a class sets the fundamental behaviour: Experience Event for time-series things that happen at a moment (page views, clicks, purchases) or Individual Profile for slow-changing attributes about a person. Web analytics is overwhelmingly event data, so you choose Experience Event. Then field groups contribute the actual fields, reusable bundles you snap onto the class like pre-drawn room templates onto a floor plan.
The field group that does the work
For an Analytics migration the load-bearing field group is the Adobe Analytics ExperienceEvent Full Extension[3]. It contributes the entire _experience.analytics structure, eVars, props, list props, events, hierarchies, and the Edge knows how to translate those fields straight into your Analytics variables with no processing rules. Add it and most mapping is drag-and-drop; omit it and you hand-wire every variable later.
The a.x. escape hatch
Anything you model in a custom field group of your own does not auto-map. It arrives in Analytics as a context-data variable prefixed a.x., for example a custom field surfaces as a.x.<tenant>.<field>, and the ECID shows up at a.x.identitymap.ecid.0.id[36]. You then place it into a variable with a processing rule. This is occasionally exactly what you want, but for standard eVars and events it's avoidable work.
The schema is a contract
Validation is strict: the Edge drops any payload that violates the schema, and Assurance will name the offending field. That strictness is a feature; it's what guarantees clean data downstream, but it means schema design and validation are tightly linked. And remember the Profile toggle on the schema root: leave it off until you've validated for weeks, because enabling it locks the schema permanently.