Why Profiles Qualify for Your Audience But Never Enter Your Journey
The audience shows qualified profiles. The journey is live. Entry conditions look correct. And yet — the entry counter is at zero. This is the most common production failure in AJO, and it almost never has one cause. Here's how to find it.
The Problem Is Almost Never What It Looks Like
When profiles stop entering a journey, the instinct is to check the entry condition rule. That's usually the last place the problem lives. The actual cause is almost always upstream — in how the audience was built, how evaluation ran, or how the profile was assembled before it ever reached journey orchestration logic.
There are five failure points that account for the vast majority of these cases. Understanding them in order will save hours of diagnostic dead-ends.
Failure Point 1 — Audience Evaluation Mode Mismatch
This is the most common root cause and the least understood. In AEP, every audience segment has an evaluation method — streaming, batch, or edge. The evaluation method determines when profile qualification is updated, and it must match the journey's entry trigger.
| Evaluation Method | When It Updates | Journey Trigger Compatibility |
|---|---|---|
| Streaming | Near real-time as events arrive | Event-triggered journeys ✓ |
| Batch | Once daily, on a scheduled run | Audience-based scheduled journeys ✓ |
| Edge | On-device, at the point of interaction | Web/app personalisation journeys ✓ |
Common Mistake: Triggering a journey on a batch-evaluated audience using an event-based entry condition. The profile qualifies in the segment, but qualification hasn't propagated to the Profile Service yet when the event fires — so the entry condition check fails silently.
Diagnostic check: Navigate to Audiences → select the segment → check the Evaluation method tab. If it says Batch, and your journey entry trigger is an event (not a scheduled read), you have a timing gap — not an entry condition problem.
Failure Point 2 — "Read" vs "Evaluated" Audience Entry
Inside the journey canvas, when you configure an audience-based entry, AJO gives you two options that look almost identical in the UI but behave completely differently:
- Evaluated: Only profiles that newly qualify for the segment since the last run will enter. Profiles already in the segment are excluded.
- Read: All profiles currently in the segment are eligible to enter on each scheduled run, subject to re-entry rules.
If a journey was configured with Evaluated but the intention was to reach the full existing audience — or if the segment was already populated before the journey went live — zero profiles will enter. The segment is populated, but no profile is "new" to it from AJO's perspective.
Real-World Pattern: A campaign is built, the segment is tested and validated days before launch. The journey goes live. Entry count: 0. The segment had already evaluated every qualifying profile before the journey existed — there are no "new" qualifications to trigger entry.
Failure Point 3 — Identity Namespace Resolution Failure
Journey entry requires that AJO can resolve the triggering identity to a profile in the Profile Service. If the namespace used in the entry event doesn't match the namespace the profile was ingested with, AJO cannot stitch the event to the profile — and the entry fails without a visible error on the journey canvas.
The most common version of this: an event arrives with a CRMID namespace, but the profile in the system was built using Email as the primary identity with no CRMID mapping established. AJO looks for the profile, finds nothing, discards the event.
Where to look:
- Check the identity graph for a sample profile in the Identity Service viewer — confirm which namespaces are attached
- Verify the namespace in the entry event payload matches what's in the graph
- Check if a dataset merge policy is excluding the dataset that contains the relevant namespace linkage
Failure Point 4 — Merge Policy Excluding the Right Dataset
Merge policies control how AEP assembles a unified profile from multiple datasets. A misconfigured merge policy can exclude the dataset that contains the attribute or identity the journey entry condition is checking against.
The result: the profile exists in AEP, the attribute exists in a dataset — but the merge policy used at runtime doesn't include that dataset. The entry condition evaluates against an incomplete profile and fails.
This failure is particularly hard to diagnose because the profile looks correct in the UI — depending on which merge policy the viewer uses to render it.
Diagnostic Step: Navigate to Profiles → find the profile → toggle the merge policy in the profile viewer. Check whether the attribute you're conditioning on disappears under the merge policy the journey is using vs. the default viewer policy.
Failure Point 5 — Re-Entry Rules Silently Blocking Return Profiles
If a journey does not allow re-entry, AJO will block any profile that has previously entered — regardless of whether they exited cleanly, timed out, or were suppressed partway through. There is no error. The profile just doesn't enter again.
This is most common in recurring campaigns where the same audience base is targeted weekly or monthly. The first run populates as expected. Subsequent runs show dramatically lower entry counts — because returning profiles are being silently excluded.
Check: Journey properties → Re-entry → confirm whether re-entry is permitted and what the re-entry window is. If re-entry is off entirely, each profile can only ever enter once across the lifetime of the journey.
The Diagnostic Order That Actually Works
Step-by-Step: Journey Entry Failure Checklist
- Check segment evaluation method — does it match the journey trigger type?
- Check audience entry mode in the journey canvas — is it Read or Evaluated? Was the segment already populated before the journey went live?
- Pull a sample profile that should have entered — check their identity graph for namespace consistency
- Toggle merge policies on the profile — verify the entry-condition attribute is present under the journey's merge policy
- Check re-entry settings — confirm whether these profiles have entered the journey previously
- Check journey execution logs and entry event monitoring — look for discard events or identity resolution failures
Best Practice: Before any journey goes live, run this check: pull 3–5 profiles that should qualify and manually validate each one against all five failure points above. Document the evaluation method, entry mode, namespace, merge policy, and re-entry status for each. This takes 20 minutes before launch and eliminates the most common class of post-launch failures entirely. If something breaks, you already have a baseline to compare against — which cuts diagnostic time from hours to minutes.