Action-path first-match vs ranked window: advance on first event or wait and pick the top path

First-match advances the user on the first qualifying event inside the evaluation window; ranked mode holds everyone until the window ends, then routes them down the highest-priority path they still qualify for.

What is the difference between action-path first-match and a ranked window?

When a journey must watch several signals at once—purchased, finished a session, asked for help—you usually build a wait/split block. The real design question is: advance as soon as any signal fires, or wait until the window closes and pick the most valuable path?

That is first-match versus a ranked evaluation window. Both listen to events; they differ in when you decide and who wins if more than one path qualifies.

How does each mode work?

First-match

The user enters the evaluation window. The first event that matches a path advances them immediately and closes the window for that trip. Near-simultaneous events usually resolve by processing order—not by business priority.

Ranked window

The user stays until the window ends—even if a qualifying event arrives early. At the end, the system inspects every still-qualified path and picks the highest configured priority (1, then 2, then 3…). If nothing matched, they take the Everyone Else path.

Read this next to trigger split vs conditional split: that post is about event payload vs profile history; this one is about timing policy and path priority.

Concrete examples

Fashion ecommerce — 24h after cart update

Paths: (1) order_completed → SMS thank-you + receipt email, (2) checkout_started without purchase → payment-help email, (3) re-view same SKU → “still in stock”, (4) Everyone Else → classic cart SMS.

First-match can send path 3 if they browse again before buying. A ranked 24h window lets a later purchase claim path 1 and suppresses the useless reminder.

EdTech SaaS — 7-day onboarding

Paths: profile complete, first lesson, sales-demo request. Short ranked windows (12–48h) often beat first-match so you pick the best progress signal. Cancellations and chargebacks should stay first-match so nurture stops immediately.

When to choose which

1. Late messaging is dangerous → first-match.
2. Several related signals, one clearly more valuable → ranked with explicit priorities.
3. Windows longer than a few days need product/support alignment on “in journey but silent”.
4. Do not reshuffle ranks after go-live without a new version.
5. Always define a safe Everyone Else path.

Leadara mapping (events, segments, journeys, email/SMS)

Build this with Leadara primitives only:

• Events: bind each path to stable event names.
• Journeys: wait/branch that either advances on first event or evaluates at window end.
• Segments: helpers and Everyone Else filters—not a substitute for ranking policy.
• Email / SMS: separate creative per branch; SMS for urgent paths, email for explanatory ones.

If you are still choosing between “wait for a signal” and “wait for a clock”, start with wait until event vs fixed delay.

Common mistakes

• Equal priority for purchase and browse under first-match.
• 31-day cart windows that pollute “in journey” reports.
• Silent rank edits mid-campaign.
• Empty Everyone Else.
• Assuming near-simultaneous events resolve “fairly”.

One-line takeaway

First-match = interrupt on first matched event; ranked = barrier until window end, then max(priority ∩ matched).

Next step

Open a live journey that already ORs several events. Ask: what if the low-value signal arrives first? If that answer is painful, switch to ranked priorities and keep the window short.

FAQ

If they purchase mid-ranked-window, when do they get the purchase message?

Usually after the window ends—unless a separate conversion exit removes them earlier.

Can we change ranks after publish?

Often technically yes; analytically risky. Version the journey.

Is Everyone Else “no events at all”?

Anyone who did not win a priority path by decision time—including people who fired unrelated events.

OTP / transactional SMS?

Do not put sensitive transactional sends in a ranked competition with nurture.

How is this different from multi-branch split shape?

Graph shape vs evaluation-timing policy. Different layer.

Very short windows (5 minutes)?

Behaves like first-match with a small race buffer.

Where do ranked users sit in analytics?

Often in wait/pending until decision; align “entered path” definitions with data.

Step-by-step for growth

1. List three candidate events with plain-language value.
2. Lock priorities 1–3 and Everyone Else.
3. Agree the window with product.
4. Build wait + event branches in Leadara; split email/SMS creatives.
5. Test weird event orders on ten profiles.
6. Freeze path-share and conversion metrics for two weeks post-launch.

Versus a simple conditional split

Conditional splits decide on current profile state. Action-path windows decide on future event streams. Mixing the two is a common root cause of “segment looks broken” tickets.

Metrics to watch

• Path-1 share vs Everyone Else
• Mean time-to-decision (ranked should hug window length)
• Post-purchase junk-message rate
• Support complaints about mistimed sends

Product + data note for the ticket

Write one line: policy=ranked, window=24h, priority=order>checkout>browse, channels=SMS@1 email@2/3. That beats a ten-page debate.

Programmer-shaped priorities

on event in window:
  if mode == first_match:
    advance(first_matching_path(event)); close_window()
  else:
    matched.add(paths_for(event))
on window_end (ranked only):
  advance(max_priority(matched) or everyone_else)

Guards: version rank changes; agree practical window length; always define a safe Everyone Else.

Acceptance tests before publish

1. Profile A only browses → path 3 or Everyone Else as designed.
2. Profile B browses then purchases inside the window → ranked mode must prefer purchase.
3. Profile C fires nothing → Everyone Else.
4. Profile D near-simultaneous events → log processing order under first-match.
5. Review each branch creative for post-purchase embarrassment.

Reporting language for PMs

Say “ranked 24h window intentionally delays so purchase outranks browse,” not “the system is slow.”

## Related reading

• Trigger split vs conditional split: this event’s data vs the profile’s history
• Wait until event vs fixed delay: pause for a signal vs pause for a clock
• Jump-to goal vs if/else branch: skip ahead on outcome vs fork the path

Related reading

• Trigger split vs conditional split: this event’s data vs the profile’s history
• Wait until event vs fixed delay: pause for a signal vs pause for a clock
• Jump-to goal vs if/else branch: skip ahead on outcome vs fork the path