Adobe Real-Time CDP Developer Expert common mistakes
Adobe Real-Time CDP Developer Expert · Understand the traps and how to avoid them.
Choosing the wrong field type for a timestamp or date field (e.g., using a string instead of a date-time type) and then finding that time-based segmentation and freshness logic don't work.
Candidates treat schema design as a naming exercise and pick the type that 'looks right' rather than the type the platform needs for comparisons and time windows.
What to do instead
Before creating the schema, map each source field to a concrete data type and confirm that any field you'll filter or compare on time uses a date/date-time type, not a string.
Marking an identity field as a primary identity only, or setting the wrong identity namespace, so profiles that should merge stay split.
Candidates confuse 'this is an ID' with 'this is the namespace used for stitching' and don't check that the namespace matches the actual identifier (email, ECID, CRM ID).
What to do instead
For each identity field, explicitly record the namespace and whether it is primary; verify with a small test batch that two records sharing the secondary identity merge into one profile.
Building a segment on a field that is not identity-stitched or is only present on one source, then wondering why the audience count is far lower than the source row count.
Candidates assume the profile is a union of all ingested rows, forgetting that segmentation evaluates the merged profile, not raw records.
What to do instead
Trace the field back to its schema and identity namespace; confirm the field lands on the merged profile and test the segment against a known small cohort before scaling.
Publishing an audience to a destination without checking the destination's required identity and mapping, so activation fails or sends partial data.
Candidates focus on segment logic and treat destination setup as a formality, skipping the identity/attribute mapping step.
What to do instead
For every destination, list the required identity namespace and attributes, map them explicitly, and run a test activation to a small sandbox audience first.
Assuming a segment refreshes continuously, then reporting stale membership because the evaluation schedule was never set.
Candidates conflate 'segment exists' with 'segment is live' and don't check the evaluation cadence or streaming vs. batch mode.
What to do instead
After creating a segment, confirm and record its evaluation method and schedule, and validate membership changes after the next scheduled run.
Applying a data usage label to a dataset but not to the schema field, so downstream policy enforcement doesn't block the field as expected.
Candidates think labels are dataset-level only and don't realize field-level labels drive many policy decisions.
What to do instead
Set labels at the field level where the sensitive data lives, then test a policy that should deny that field to confirm enforcement fires.
Deleting a dataset or profile and assuming the data is gone everywhere, when derived audiences, exports, or destination copies still hold it.
Candidates treat deletion as a single action rather than a lifecycle spanning ingestion, profile, segments, and activation.
What to do instead
Map the data's full path (dataset → profile → segment → destination) and verify deletion or expiry at each hop, including destination-side retention.
Ingesting a batch with duplicate records and no deduplication key, inflating profile counts and skewing segment sizes.
Candidates assume the platform deduplicates automatically and don't define or verify a primary key for the batch.
What to do instead
Define the primary key for each batch dataset, verify uniqueness in a sample, and re-run a known batch to confirm counts stay stable.
Mixing consent or opt-out attributes into a general profile field without wiring them to policy, so opted-out users still receive activations.
Candidates treat consent as just another attribute and don't connect it to governance policy or destination suppression.
What to do instead
Model consent as a dedicated field with a usage label, attach a policy that blocks activation for non-consenting profiles, and test with a known opted-out profile.
Creating an audience with a broad OR condition that unintentionally includes nearly everyone, then only discovering it after activation.
Candidates build complex boolean logic without testing intermediate conditions and don't preview counts at each step.
What to do instead
Build the segment incrementally, previewing the count after each condition, and compare against an expected baseline before publishing.