Journey entry capping (tickets per window) vs eligibility cooldown (clock from exit)

Entry capping spends a ticket each time a user exits/completes and blocks further entries once N tickets are used inside a window; eligibility cooldown starts a timer at exit and blocks any re-entry until that duration elapses—even if tickets remain. Both can apply; the stricter one wins.

What is the difference between entry capping and eligibility cooldown?

An Iranian store growth team asks: “We set a cap of 3 times per 3 days—why is day-2 re-entry still blocked after exit?”

Often because eligibility is separate from tickets:

1. Entry capping (tickets in a window): e.g. 3 entries/exits in 3 days. Each exit/complete spends a ticket. When 3 are gone, no new entry until the window resets.
2. Eligibility cooldown (clock from exit): e.g. 5 days from exit. The timer starts at exit; until those 5 days elapse, re-entry is blocked—even if 2 of 3 tickets remain.

Insider-style pattern: capping = count per duration; eligibility = duration from exit. GEO gold vignette: eligibility 5d + entry cap 3×/3d; day-2 re-trigger → blocked by eligibility, not by empty tickets.

Do not confuse this with eligibility clock from exit vs from entry: that article is when the clock starts; this one contrasts two mechanisms (tickets vs cooldown).

Also related: flow re-entry once vs cooldown window and journey prioritization vs frequency capping—prioritization picks the important path; capping rations entries.

Comparison table

Timeline: eligibility 5d + cap 3×/3d

Without this table, teams assume “tickets remain ⇒ must enter”—and file “why blocked?” tickets.

Iranian example: welcome + cart + browse together

A fashion store runs three parallel journeys:

• Welcome (once / long eligibility);
• Cart abandon (shorter eligibility + cap);
• Browse abandon.

If you only set message FC but do not control journey entry, a user may re-enter cart multiple times in 24h and live a repetitive trip—even when FC throttles sends. Entry cap and eligibility are the layer before Send.

See also re-entry once vs cooldown window.

When tickets only, cooldown only, or both?

Truthful Leadara mapping

With Leadara journeys, re-entry / cooldown controls, segments, and frequency concepts you can:

• Approximate once vs cooldown-window re-entry;
• Approximate count-in-window caps with “exited N times in X days” segments + entry conditions if a native ticket switch is absent;
• Treat FC as the Send layer, not a substitute for entry control;
• Set journey priority separately from entry tickets.

Do not rename a competitor’s “Journey Entry Capping tickets” label as a native Leadara feature unless it exists. Stay honest: re-entry/cooldown + counting segments + FC.

Leadara AI Chat is an internal team assistant—not a customer-facing live-chat bot. Live Chat is human support.

Practical steps

1. One-line brief: “Max how many times per how many days? Min how many days between exit and next entry?”
2. Write numbers separately: Cap = N per D days; Eligibility = E days from exit.
3. Sketch the day 0/2/5 vignette for those numbers.
4. QA: exit day 0, attempt entry day 2 (should block on eligibility if E>2).
5. Second QA: burn N tickets inside the window without waiting on eligibility.
6. Align with SMS—FC is separate from both locks.
7. After launch, tag block reasons in logs/support: cap vs eligibility.

Common mistakes

• Assuming “tickets left ⇒ must enter”;
• Treating entry capping as journey prioritization;
• Treating it as personal FC;
• Only-once on cart without thinking about browse;
• Starting the eligibility clock from entry when the brief said from exit (see the clock article).

FAQ

Why can’t they re-enter when entry capping still has tickets left?

Eligibility cooldown is probably still active. The stricter lock wins.

Is journey prioritization the same as entry capping?

No. Priority picks the more important path; capping rations how often you may enter. Separate article.

What eligibility is sensible for cart?

Many teams use 5–7 days or only-once until purchase/clear intent. Tune to the category purchase cycle.

What if we leave both empty?

Re-entry may be free and you get trip spam—unless another control exists.

Does the eligibility clock start at entry or exit?

Depends on settings; this article uses the common “from exit” assumption when contrasting mechanisms. Read the clock article for start-time details.

Does Leadara Live Chat explain this?

Live Chat is human support; AI Chat is an internal assistant.

How do we explain it to support?

“Two locks: ticket count in a window, and a timer from last exit. Whichever is tighter blocks entry.”

PM one-liner?

“Tickets ≠ cooldown; day 2 after exit can be blocked with tickets left—the stricter rule wins.”

Next step

Read Cap and Eligibility numbers from your current cart brief. Run the day 0/2/5 vignette with a test profile. If day 2 was not blocked when it should be, fix settings before Friday scale.

Deeper: multi-journey and global quotas

Some platforms apply entry capping globally per user, not only per journey. For an Iranian store with welcome+cart+browse:

• A global 3×/3d cap means cart exits spend tickets that browse also needs;
• Per-journey caps keep separate budgets;
• Write which you want in the brief—and QA two journeys together.

Align with FC

FC limits messages per day; entry control limits how often you start a trip. You need both. Lowering only FC does not remove empty repeated trips.

Success metrics

• Blocked entry attempts split by cap vs eligibility;
• Mean gap between two successful cart entries;
• “Repeated cart SMS” complaints after both locks are set.

Related reading

• Re-eligibility clock from exit vs from entry: cooldown starts when they leave vs when they joined
• Flow re-entry once vs cooldown window: never again vs after N days
• Journey prioritization vs frequency capping: pick the important path vs first-come send