AEP - Schema building blocks

An XDM schema is constructed from four main building blocks, which determine its structure, purpose, and the type of data it will contain. You can think of these as a hierarchy, from the most general to the most specific, working together to model your customer data.

Here's an overview of these components, starting from the top of the schema:

Building Block	Purpose & Function
1. Behavior	Defines the fundamental type of data the schema handles. There are two types: Record (for describing entities, like a person) and Time-series (for describing events that happened, like a website click).
2. Class	Required for every schema. Defines what the schema represents (e.g., a person, a product, a website event). Each class has a specific Behavior (Record or Time-series) and comes with a set of essential, built-in fields for that category of data.
3. Field Groups	The primary mechanism for adding most fields to a schema. These are reusable collections of fields and data types that model a specific concept (like "personal contact details"). They are tied to a specific Class.
4. Data Types & Fields	Data Types are logical groupings of multiple fields (e.g., "email address," which includes the address, its type, and status). Fields are the most granular elements that hold individual pieces of data.

📐 How These Blocks Work Together

Schema = Class + Field Groups. You can think of building a schema this way:

1. Choose a Class: First, select a class (e.g., "XDM Individual Profile" with Record behavior, or "XDM ExperienceEvent" with Time-series behavior). This sets the schema's core purpose and provides essential base fields.
2. Add Field Groups: Then, add relevant field groups to include all the specific data points you need. For example, add a "Demographic Details" field group to a profile class.
3. Fields and Data Types: Within the chosen class and field groups, you will find all the necessary data types and individual fields. You can also create custom data types and field groups.

Key Standard Classes Explained

These two classes handle 90% of customer data use cases:

📇 XDM Individual Profile (Record Behavior)

Think of this as a digital dossier or customer ID card.

• For: Data about who a customer is
• Data Pattern: Singular & updatable (one profile per customer that changes over time)
• Examples:
  • Name, birthday, loyalty tier
  • Contact info (email, phone)
  • Lifetime value, segment memberships
• Analogy: A customer database row that gets updated

⏱️ XDM ExperienceEvent (Time-series Behavior)

Think of this as a detailed activity log or customer diary.

• For: Data about what a customer does
• Data Pattern: Multiple & immutable (many events per customer, added over time)
• Examples:
  • Website page view (timestamp, page URL)
  • "Add to cart" action (product, quantity)
  • Purchase transaction (amount, items, payment method)
  • Email open, call center interaction
• Analogy: A stream of timestamped events that can't be changed, only added to

Real-World Example: A Coffee Shop App

Let's see how these work together for "CoffeeCo's" loyalty app:

Profile Schema (XDM Individual Profile)

• Class: XDM Individual Profile
• Field Groups:
  • Demographic Details → Name, birth date
  • Personal Contact Details → Email, mobile number
  • Loyalty Details → Member ID, points balance, tier (Gold)

Event Schemas (XDM ExperienceEvent)

• Class: XDM ExperienceEvent
• Field Groups (varies by event):
  • App Interaction → Opened app, viewed menu
  • Commerce Details → Ordered latte ($5.50), used 50 points
  • Location Details → Visited "CoffeeCo Downtown" store

The Magic: The platform automatically links all events to the correct profile using a shared identifier (like email or loyalty ID), building a complete customer journey.

---

Quick-Reference Cheat Sheet

	XDM Individual Profile	XDM ExperienceEvent
Purpose	The WHO (Customer Identity)	The WHAT/WHEN (Customer Actions)
Behavior	Record	Time-series
Data Type	Entity Data (Snapshot)	Event Data (Stream)
Example	Customer's email, loyalty tier	Purchase at 2:30 PM, page view
Updates	Editable (change phone number)	Append-only (can't change past events)
Analogy	Digital ID Card	Activity Log/Timeline

---

💡 Remember This

1. Start with your question: Need to track attributes? Use Profile. Need to track actions? Use ExperienceEvent.
2. They work together: Profiles are built from events. A profile without events is just a static record.
3. Use field groups: Don't build from scratch—use Adobe's pre-built field groups whenever possible.
4. Think in timelines: A complete customer view = Profile (who they are) + ExperienceEvents (what they've done over time).

This structure allows Adobe Experience Platform to unify data from all sources (web, app, store, call center) into a single, actionable customer profile for personalization and analytics.