Why Most AJO Implementations Stall After Launch
The journey builder isn't the bottleneck — your data layer is. Here's how to identify and fix schema-level issues before they cascade.
The Real Bottleneck Isn't the Journey Builder
Most teams blame journey logic when campaigns underperform after launch. The journey canvas looks right. The conditions make sense. But messages aren't sending, or they're sending to the wrong people, at the wrong time, at the wrong volume.
The bottleneck is almost always upstream — in the data layer. Here's how to identify it before it cascades into something that takes weeks to unwind.
Root Cause 1 — XDM Schema Drift
Your journey references fields that existed when it was built. Over time, data engineering teams rename fields, change data types, or deprecate attributes without notifying the marketing or CRM team running AJO.
| Symptom | Likely Cause |
|---|---|
| Personalisation tokens rendering blank | Field path changed or deprecated |
| Condition branches never triggering | Data type mismatch (string vs integer) |
| Journey entry working, but actions failing | Schema version conflict in the event payload |
Common Mistake: Assuming that because a journey worked in UAT, the schema is stable in production. UAT datasets are often on different schema versions than production streams.
How to confirm it:
- Open the field group in AEP Schema Editor
- Cross-reference every field your journey conditions and personalisation tokens reference
- Pull a raw event from the production stream and inspect the actual payload
- Compare field names and data types — not just the schema definition
Root Cause 2 — Dataset Priority Conflicts in the Merge Policy
AJO reads profile attributes from the Real-Time Customer Profile. That profile is assembled from multiple datasets — CRM, web behavioural, loyalty, offline transaction. The merge policy determines which dataset wins when the same attribute exists in two sources.
If the wrong dataset takes priority, your segmentation logic is running on stale or incorrect data — even when the journey conditions look correct.
| Merge Policy Setting | Risk |
|---|---|
| Dataset precedence: CRM first | Web behavioural attributes overwritten by weekly CRM batch |
| Timestamp ordered | Most recent write wins — could be a data pipeline error |
| No custom policy set | AJO uses the default, which may not match your use case |
Best Practice: Define a named merge policy for each major use case (email engagement, transactional, loyalty) and explicitly assign it to your segments. Never rely on the default merge policy in production.
Root Cause 3 — Event Routing Misconfiguration
Event-triggered journeys depend on AEP receiving the right event, with the right identity, on the right dataset, with the right schema. Each of those four conditions needs to be true simultaneously.
The most common failure: the event arrives, AEP ingests it, but the identity resolution fails — so it creates a new anonymous profile instead of enriching the existing one. The journey never fires because the qualified profile never received the event.
Diagnostic steps:
- Go to AEP → Monitoring → Streaming ingestion
- Find the event in the ingestion log — confirm it was received
- Check the identity namespace on the incoming event
- Open the profile for the expected identity — check the identity graph
- Confirm the event appears in the profile's event timeline
- If it doesn't appear, the namespace on the event doesn't match the namespace on the profile
Root Cause 4 — Journey Version Conflicts
AJO doesn't let you edit a live journey. Teams create new versions — but old versions sometimes stay active without anyone realising. Profiles enter the old version, get suppressed by frequency capping, and never qualify for the new one.
Common Mistake: Publishing version 3 of a journey without closing version 2. Profiles already in version 2 will complete that path. New profiles may enter either version depending on which one AJO evaluates first.
How to audit this:
- Go to Journeys → filter by journey name
- Check how many versions have status "Live"
- Close any versions that should no longer be accepting entries
- Check the entry counter on each version to understand current volume
Root Cause 5 — Frequency Capping Applied at the Wrong Layer
AJO has two distinct capping mechanisms: journey-level re-entry rules and rule set-based frequency caps. They operate independently and can both suppress a profile simultaneously — with no consolidated view of why.
| Capping Type | Where It's Configured | What It Blocks |
|---|---|---|
| Journey re-entry | Journey properties | Re-entry into the same journey |
| Rule set capping | Administration → Rule sets | Cross-journey message frequency |
| Channel surface limits | Channel configuration | Messages per channel per day |
A profile can be blocked by any one of these — or all three at once — and the suppression logging for each is in a different place.
The Audit Sequence That Works
Before assuming the journey logic is wrong, run this check in order:
- Confirm schema field paths match the current production schema version
- Audit the merge policy assigned to your segments
- Verify event routing with a test event and trace it to the profile
- Check for multiple live journey versions
- Cross-reference capping rules at all three layers
The teams that stabilise AJO fastest are the ones who treat the data layer as the first suspect — not the last.
Dealing with this in production right now? I can audit your specific setup — schema, merge policy, event routing — and tell you exactly where the block is. Book a session →