Adobe Real-Time CDP Developer Expert cheat sheet

XDM schemas are JSON Schema-based classes plus field groups; classes (e.g., XDM Individual Profile, XDM ExperienceEvent) define the base structure and field groups add reusable, versioned fields.

Schema field types are immutable after data lands; changing a type requires a new field or dataset, so validate types before enabling ingestion.

Batch ingestion accepts JSON/Parquet/CSV via the Data Ingestion API or sources connectors; streaming ingestion uses the Streaming Ingestion API or Edge Network and is near real-time.

Dataset IDs are the unit of ingestion, access control, and data lifecycle; a schema can back multiple datasets, but each dataset has one schema.

Identity fields must be mapped to an identityMap or primary identity in the schema; a field marked as identity gets an associated identity namespace.

Upsert semantics for Profile-enabled datasets require an identity descriptor and a primary identity; without them records cannot be stitched into profiles.

Dataflow runs report success/failure per batch; failed batches can be retried, and partial ingestion errors are surfaced in the dataflow run details.

Schema registry supports unions and relationships; a union schema aggregates fields across datasets sharing a class and is what Profile queries against.

Identity namespaces (e.g., ECID, Email, CRM ID) are declared in the schema; the identity graph links namespaces into a single profile via the identity service.

Real-Time Customer Profile merges records by identity: identities resolve to one profile, and merge policies decide which attribute values win when sources conflict.

Merge policies: default timestamp-ordered (latest wins), dataset precedence, or attribute-based merge; the default merge policy applies unless a schema/segment overrides it.

Profile fragment: each ingested record is a fragment; the profile is the union of fragments across datasets, stitched by identity graph edges.

Identity graph edges are established from identityMap fields on ingested records; a record with multiple identities creates links between them.

Profile lookup APIs (entities, edge projections) return merged attributes; previewing a profile shows the merge policy applied and the winning values.

Profile data is not queryable in real time for arbitrary SQL; use Profile query/export or destination activation to move profile attributes.

Identities are private per sandbox; the same namespace value in different sandboxes does not resolve to the same profile.

Segment definitions are evaluated by the segmentation service against the Profile union schema; streaming segments evaluate on ingest, batch segments on a schedule.

Segment qualification states: realized (entered), exited (left), and existing; streaming segments emit qualification events to downstream destinations in near real-time.

Destination types: profile export (file/stream to cloud storage), streaming (e.g., edge), and connection destinations; each requires a dataflow and mapping of source fields to target schema.

Activation mapping maps XDM profile attributes to destination fields; identity namespaces must be selected to export the correct identifier.

Segment membership is stored as a segmentMembership object on the profile; destinations read from it or from a segment export job.

Batch destinations export segment membership as files (CSV/Parquet) to cloud storage; streaming destinations push qualification events continuously.

Destination dataflow runs can be scheduled or event-triggered; failed runs are visible in monitoring, and mappings can be edited without recreating the destination.

Segment evaluation requires the segment's criteria to reference fields present in the union schema; missing fields cause the segment to evaluate as empty.

Data usage labels (e.g., C1-C12, I1-I2, S1-S2) are applied to schema fields and datasets; policies enforce restrictions on how labeled data can be used in destinations and segments.

Consent policies evaluate against the consent field group (e.g., collect.val, share.val); destinations and segments respect consent at activation time.

Adobe Experience Platform Privacy Service handles access and delete requests by identity; delete requests remove data from datasets and Profile, subject to dataset type.

Data lifecycle (TTL/expiration) can be set on datasets to delete records after a retention period; expiration jobs run on a schedule and are irreversible.

Policy enforcement points include segmentation, destination activation, and dataset queries; a policy violation blocks the action and surfaces an error.

Dataset-level access control uses attribute-based access control (ABAC) with labels and roles; field-level labels can restrict PII visibility.

Audit logs record governance actions (label changes, policy edits, access) and are retained for compliance review.

Privacy requests require identity namespace and value; the request is submitted to Privacy Service and tracked by job ID across the platform.