Data Ingestion, Schemas, Identities, and Governance
This domain rewards precision about the Experience Data Model (XDM). A schema defines structure; a dataset is a container of data conforming to a schema. Classes (e.g., XDM Individual Profile, XDM ExperienceEvent) define the base record type; field groups add reusable fields; data types define reusable structures. Traps: questions that call a field group a class, or that imply you can change a schema's class after data exists (you generally cannot).
Ingestion methods: batch ingestion (files via sources, APIs, or the UI), streaming ingestion (HTTP API, streaming sources), and source connectors (Adobe apps, cloud storage, CRM, advertising). Know that data landing in the lake must be mapped to XDM before it is usable by the Profile. Identity is the hinge: an identity namespace (e.g., ECID, email, CRM ID, loyalty ID) qualifies each identifier; the identity graph links identifiers across datasets into a unified profile. A common trap is forgetting that only identity fields marked as identity in the schema participate in graph stitching.
Governance is tested heavily. Data Usage Labels (e.g., C, I, S, E categories) describe sensitivity; policies (data usage policies, consent policies) enforce how labeled data may be used; DULE (Data Usage Labeling and Enforcement) is the mechanism. Marketing actions on destinations are matched against policies. Consent (opt-in/opt-out) is captured via the Consent field group and enforced at activation.
Rule of thumb: before any data is activated, ask: Is it mapped to XDM? Does it have an identity? Is it labeled? Does a policy or consent restriction block this marketing action? If any answer is “no” or “blocked,” activation fails or is filtered.