Adobe Journey Optimizer Developer Expert common mistakes
Adobe Journey Optimizer Developer Expert · Understand the traps and how to avoid them.
Building a journey that re-enters the same profile on every qualifying event by leaving re-entrance enabled, then wondering why profiles receive duplicate messages.
Candidates treat re-entrance as a cosmetic setting and never reason about the profile's journey lifecycle across multiple qualifying events.
What to do instead
Decide re-entrance policy explicitly per journey (allow, disallow, or allow with a wait period) and test by sending two qualifying events for the same profile to confirm the second event is or is not admitted.
Placing a wait activity and expecting the journey to continue for a profile whose qualifying event attribute is later changed, without accounting for how the journey stores the event payload.
Candidates assume journey activities read live profile data at each step rather than the event context captured when the profile entered.
What to do instead
Identify which attributes come from the triggering event versus the unified profile, and use profile-lookup or explicit data reads when current values are required after a wait.
Configuring a segment with an event-based rule but no time window, then expecting the segment to reflect only recent behavior.
Candidates conflate 'has ever done X' with 'did X in the last N days' and do not add a time constraint to the event rule.
What to do instead
Add an explicit time window to event-based segment rules and validate membership counts before and after the window to confirm evaluation behaves as intended.
Assuming a newly created or edited segment is immediately available for journey activation and building a journey against it the same day.
Candidates underestimate batch segment evaluation cadence and the dependency between segment refresh and journey audience resolution.
What to do instead
Confirm the segment's evaluation schedule and expected refresh timing, and plan journey launch or test audiences around the next evaluation rather than assuming real-time availability.
Mapping a custom event field to a profile or identity field without matching data types, then debugging delivery failures caused by ingestion rejection.
Candidates focus on field names and skip type compatibility and identity namespace requirements in the schema and dataset configuration.
What to do instead
Verify XDM field types, identity descriptors, and namespace assignments before publishing the schema, and inspect ingestion errors after sending a test event.
Sending a proof or test message to a seed address and concluding the channel works, without checking that the production surface, identity, and consent path are configured.
Candidates validate message rendering but not the delivery prerequisites (channel surface, sender identity, consent policy, IP/warm-up state).
What to do instead
Run an end-to-end test through the actual journey and channel surface with a profile that has the correct consent and identity, and confirm the message is delivered and tracked.
Configuring an email or push action without accounting for the profile's consent or subscription status, then reporting delivery failures as a platform defect.
Candidates treat consent as an after-the-fact filter rather than a gating condition evaluated at send time.
What to do instead
Check the consent and subscription fields on the test profile, confirm the channel's consent policy is applied, and verify the message is suppressed or sent as expected for each consent state.
Building a personalized message with a fallback that is never exercised, then discovering blank or default content in production for profiles missing the attribute.
Candidates test personalization only with fully populated profiles and never validate the fallback branch of the expression.
What to do instead
Test the message with a profile lacking the personalization attribute to confirm the fallback renders, and explicitly define fallback values for every dynamic field.
Configuring an offer decision with eligibility rules and a ranking strategy but expecting a specific offer to be returned without verifying collection and placement constraints.
Candidates understand eligibility but overlook how collections, placements, and ranking interact to determine the final selected offer.
What to do instead
Trace the decision from placement to collection to eligibility to ranking, and test with profiles that exercise each eligibility branch to confirm the selected offer.
Diagnosing a journey that stops for some profiles by changing the journey configuration rather than inspecting the profile's event history, identity graph, and execution logs.
Candidates jump to configuration changes without using the available diagnostic surfaces (journey reports, execution logs, event ingestion records).
What to do instead
Reproduce with a known test profile, inspect the journey execution log and event history for that profile, and confirm the root cause before altering any configuration.