Define XDM schema requirements for event capture
Identify which field groups are required for a given event type, add the mandatory SDK mixin, configure identity fields, enable the schema for the real-time profile store, and validate payload shape using a browser debugger.
This task produces a validated, profile-enabled ExperienceEvent schema that can accept Web SDK payloads without ingestion errors. The schema defines which attributes are collected, how identity fields are declared, and whether events contribute to the real-time profile store. Getting this right at design time prevents downstream mapping errors in datasets, segment definitions, and query-service tables.
Mandatory fields and field groups. Any schema receiving Web SDK (alloy.js) payloads must include the AEP Web SDK ExperienceEvent Mixin. This mixin adds the minimally required fields (_id, timestamp, and the SDK context object) that the Edge Network validates on every inbound event. Domain-specific field groups — Web Details, Commerce Details, Environment Details — layer additional structured attributes on top of the base mixin. Custom field groups scoped to a tenant namespace hold proprietary identifiers (ECID, email, loyalty ID) configured as identity fields with explicit namespace assignments.
Identity configuration choices. ExperienceEvent schemas typically use ECID as the primary identifier because anonymous visitors do not yet have authenticated identifiers. Setting ECID as primary ensures that pre-authentication events are recorded and later stitched to the authenticated profile when a known identifier (email, CRM ID) is supplied. Secondary identifiers on an event schema can be declared but are not required to be primary — only one primary identity field is permitted per schema.
Validation loop. The AEP Debugger browser extension inspects live Edge Network interact requests and displays the parsed XDM payload. This enables a schema designer to confirm that tag-layer data elements are mapping to the correct XDM paths before committing to a production publish. Validation should be repeated after any field-group change.
Parallel viability (high). Every CDP and data warehouse implements a semantic data contract equivalent to XDM (Segment Protocols, Snowflake schema-on-write models, dbt source YAML). The practitioner skill — identifying required fields, declaring identity keys, enabling downstream consumption — transfers directly. Phase 3 will document Segment Protocols schema definitions and Snowflake ExperienceEvent table design as parallel implementations.
Side-by-side implementations
Parallel implementation not yet available.
Parallel implementation not yet available.
In Hightouch, the equivalent of an XDM schema definition is the Hightouch Model — a SQL SELECT statement that specifies which columns from a warehouse table are included in the activation model. Column naming follows whatever convention was established in dbt (snake_case with semantic names), and Hightouch inherits the schema from the warehouse. Hightouch's Field Mapping UI maps warehouse column names to destination-specific field names (e.g., email_address → "Email" for Salesforce) — the functional equivalent of XDM dot-notation path mappings. Schema validation is enforced upstream by dbt schema.yml tests (not_null, accepted_values, relationships) rather than at the ingestion endpoint. Identity fields (userId, email, phone) are declared via the Hightouch Model's primary key designation, which determines how the sync tool matches and deduplicates records at the destination.
Capability: Identity Resolution
Task-level sources
- technical-training/module1/index.md
- technical-training/module1/ex4.md
- technical-training/module1/ex7.md
How is this implementation?
Sign-in-gated. Tomorrow morning's curriculum-ingestor consumes your feedback: "Inaccurate" queues the task for re-review, "needs update" queues it for a refresh, and "one vendor panel is wrong" re-drafts just that panel.