Weekly live AEP workshops every Friday - reserve your seat →
AEP schemas

AEP schemas: designing XDM schemas step by step

How to design Adobe Experience Platform XDM schemas: classes, field groups, identity fields, Profile enablement, examples and a design checklist.

Quick answer

An AEP schema is an Experience Data Model (XDM) definition of how data is structured. Each schema is built from a class (usually XDM Individual Profile for attributes or XDM ExperienceEvent for time-stamped events) plus field groups. Mark identity fields, choose a primary identity, and enable the schema for Profile only when the data should feed Real-Time Customer Profile.

Key concepts

Class
Defines the behaviour of the data: record (profile attributes) or time-series (events).
Field group
A reusable set of fields added to a schema, either Adobe-provided or custom.
Data type
A reusable object structure (for example an address) used inside field groups.
Identity field
A field tagged with an identity namespace so Identity Service can link records.
Union schema
The combined view of all Profile-enabled schemas of the same class.

Step-by-step: design a schema

  1. Start from the business use case and list the attributes and events it needs.
  2. Pick the class: XDM Individual Profile for CRM-style attributes, XDM ExperienceEvent for web, app, transaction and interaction events.
  3. Reuse standard field groups first; create custom field groups under your tenant namespace only for what is missing.
  4. Identify identity fields (email, CRM ID, ECID, phone) and set one primary identity per schema where required.
  5. Review naming, types and required fields with data owners before creating datasets.
  6. Enable for Profile only when you are sure — Profile-enabled schemas can only have additive changes afterwards.

Example: retail purchase event

A purchase event schema typically uses the XDM ExperienceEvent class with the Commerce Details field group, an Environment Details field group for web context, and identity fields for ECID and a hashed customer ID. Order totals, product SKUs and quantities sit in standard commerce fields so that Customer Journey Analytics and Journey Optimizer can use them without custom mapping.

Best practices checklist

  • Design for use cases, not for every column in the source system.
  • Keep custom fields under one tenant object with consistent naming.
  • Avoid storing personal data you do not need; apply data usage labels.
  • Separate profile attributes from events — never put frequently changing events into profile records.
  • Version and document schemas; treat breaking changes as a new schema.
  • Validate sample payloads against the schema before production ingestion.

Who this guide is for

This guide is written for beginners, students and career switchers who want a clear mental model, and for developers, data engineers, implementation specialists, consultants, architects, marketers, agencies and enterprise teams who need practical, step-by-step detail they can apply on real projects.

Frequently asked questions

Can I change a schema after enabling it for Profile?

Only additive (non-breaking) changes are allowed once a schema is enabled for Profile and used. Removing or renaming fields requires a new schema.

What is the difference between a schema and a dataset?

The schema defines structure; a dataset is the storage container that holds data conforming to one schema.

Last updated:

Ready to move your Adobe MarTech program forward?

Consulting for enterprise teams, training for professionals. Tell us where you are today.

WhatsApp