Back to agent
Operational Taskoperational-task.configure-xdm-schemas-and-profile-datasets

Configure XDM schemas and profile-enabled datasets

Design XDM schemas for both profile and event data by selecting appropriate field groups, defining primary and secondary identity fields with namespace assignments, enabling schemas for profile ingestion, and creating linked datasets that hydrate the real-time customer profile.

confidence 85%v2reviewed May 19, 2026xdm, schema, datasets, field-groups, identity-namespaces, profile-activation, data-modeling, data-ingestion

Configure XDM schemas and profile-enabled datasets

This task produces two reusable schemas — one for identity-bearing profile attributes, one for timestamped behavioral events — and a pair of datasets linked to those schemas that feed the real-time customer profile. The output is an operational data model that all downstream tasks (streaming ingestion, batch ingestion, segmentation, query service) can reference by name. Getting this right at design time avoids costly schema migrations later and ensures that all ingested data can be unified into a single profile view.

Schema class selection. The XDM Individual Profile class is appropriate for records that represent a persistent entity: CRM records, loyalty profiles, consent preferences. The XDM ExperienceEvent class is appropriate for time-stamped interaction records: page views, product views, purchases, call-center interactions. Both classes can coexist in the same profile store — the identity graph links them by shared identity namespaces.

Identity namespace hierarchy. Each schema must designate exactly one Primary Identity field. The choice of primary identity determines how profile fragments are stitched: if different channels use different primary identifiers, the identity graph creates links between them when a shared secondary identifier is observed. For a Profile schema, email is typically primary because it is stable and human-readable; for an ExperienceEvent schema, ECID is typically primary because it is available from the first anonymous page view. Both fields should be present on both schema classes to enable stitching.

Profile activation. Enabling the Profile toggle on a schema is a one-way, irreversible action per schema version. Once enabled, all data ingested against that schema contributes to the Real-time Customer Profile merge tree. Datasets must independently be enabled for profile contribution at the dataset level; a profile-enabled schema does not automatically make every dataset linked to it profile-active.

Parallel viability (high). The pattern — semantic data model + identity key designation + profile store activation — appears in every modern CDP. Segment Protocols defines event and trait schemas; Snowflake schema-on-write defines the identity join keys; Hightouch or Census maps CRM columns to activation audiences. Phase 3 will document equivalent Segment Protocols configuration and Snowflake identity table design.

Sources