Data Ingestion and Schema Design
The schema-first mindset
In Real-Time CDP, everything downstream - identity stitching, segmentation, activation - depends on the XDM schema you design up front. A schema is built from classes (Experience Event, Individual Profile, or a custom class), field groups (reusable bundles of fields), and data types. The class determines the record's shape and whether it feeds the profile; field groups add standard or custom attributes. Datasets are containers bound to a single schema, and only profile-enabled datasets contribute to Real-Time Customer Profile.
Ingestion paths and their traps
Know the difference between batch ingestion (files via Sources, API, or connectors) and streaming ingestion (HTTP streaming, edge, or streaming connectors). A frequent trap: a dataset created from a schema that is not profile-enabled ingests fine but never appears in the profile - questions will describe "data ingested but no profile" and expect you to check the schema's profile toggle. Another trap is identity descriptors: an identity field must be marked as an identity and have a namespace before it can drive stitching.
Field groups, unions, and evolution
The union schema is the merged view of all profile-enabled schemas; it defines what the profile can hold. Adding a field to a field group is generally safe, but changing a field's type or making it an identity later can require re-ingestion. Watch for questions about upsert vs. append: profile datasets upsert on identity, while event datasets append.
Rule of thumb
Before ingesting, confirm three things: (1) the schema is profile-enabled, (2) the identity field carries a namespace, and (3) the dataset is mapped to the correct schema. If any is missing, downstream segmentation silently fails.
Worked example: A developer ingests CRM contacts but sees no profiles. The schema's email field lacks an identity descriptor and namespace. Fix: mark email as identity with the Email namespace, ensure the schema is profile-enabled, and re-ingest.