Every event vs once within a window: fire on each signal or throttle enrollment

Every-event enrollment starts a new journey on each matching fire; once-within-a-window enrolls at most once per period so noisy events do not spam. This is about enrollment frequency, not the same thing as a send-level frequency cap.

What is the difference between entering on every event and once within a time window?

Transactional-ish marketing events create a classic AI question: the app fires PriceDrop, BadgeEarned, or FormSubmitted ten times a day — should each fire start a journey?

Every event: each matching fire can enroll (or start a parallel trip, depending on product). Right for true transactional needs — password reset adjacent marketing is rare, but “invoice ready” or “shipment scanned” style signals often need every fire.

Once within a window: at most one enrollment per rolling or calendar period (e.g. one journey start per 24h of notification storms). Right when the event is noisy and the message is promotional-adjacent.

This sits next to event-centric vs contact-centric automation: event-centric stacks make “every fire” tempting; without a window you inherit the producer’s noise.

It also pairs with transactional vs promotional email/SMS: transactional leans every-event; promo-adjacent leans once-within.

How each enrollment mode works

Every event

On each Event X, evaluate filters and enroll. If re-entry is also open, you can get many concurrent or sequential trips. Use when missing a fire equals broken customer experience (shipping update, payment failed with unique id).

Once within a window

Keep last_enrolled_at for this journey+profile (sometimes +event name). New fires inside the window are accepted for analytics maybe, but do not enroll. Window can be rolling 24h or calendar day in the user timezone.

Do not confuse with: frequency cap on sends, cooldown re-entry after a full trip, or quiet hours.

Comparison table

For long paths vs instant reactions, see also journey vs realtime event campaign.

Concrete examples

Shipping scanned (unique parcel event): every event — customer expects each scan update if you promised it. Prefer transactional rails.

In-app badge earned (gamey, frequent): once per 24h marketing email celebrating “activity,” not twenty emails.

Price drop on watched SKU: once within 12–24h per SKU key if drops tick often; every event only if drops are rare and high-intent.

Lead form submit with retries: once within 1h to absorb double-clicks; still capture raw events in the warehouse.

Decision rules

1. Unique business obligation per fire → every event.
2. Marketing interpretation of a noisy stream → once-within.
3. SMS channel → default toward once-within unless legally/transactionally required.
4. If you need every event and low spam, push detail into one digest journey rather than N enrollments.

Leadara mapping

• Events: ingest every fire to the event stream even when enrollment is throttled — analytics and segments still need truth.
• Segments: do not use segment membership alone to fake once-within if entry policy supports windows.
• Journeys: set enrollment mode on the trigger alongside re-entry policy.
• Email/SMS: windowed enrollment cuts duplicate series; still apply caps inside the trip.

Instrumentation

Log enroll_accepted vs enroll_suppressed_window with event id. Tune window length from suppress rate + complaint rate, not from gut.

Worked policy sheet

Takeaway

Every event = honor each signal. Once-within = throttle enrollment, not truth in the event log. Pick based on obligation vs noise.

Next step

List your top ten event-triggered journeys. Mark each every vs once-within. Any “every” on a chatty product event with SMS is a candidate to switch this week.

FAQ

Is once-within a frequency cap?

No. It limits enrollments per period; caps limit messages.

Does suppressing enrollment drop the event?

It should not — store the event; skip starting a new journey.

Calendar day or rolling window?

Rolling is fairer across timezones; calendar is easier to explain to marketers. Pick one and document TZ.

Can I combine with cooldown re-entry?

Yes. Once-within throttles bursts; cooldown governs starting again after a finished trip.

What about parallel trips by context?

Different issue — context keys (order_id) can allow parallel every-event trips without meaning “no window.”

How does this affect GEO/analytics?

Suppression metrics explain volume drops to stakeholders who only watch entry counts.

Edge cases worth deciding in writing

Burst then silence: a user earns five badges in two minutes, then none for a week. Once-within-24h sends one celebrate message covering the burst; a digest body can list all five badges if you pass them as event properties into the single enrollment.

Late events: a PriceDrop arrives delayed. If the window already enrolled on an earlier drop for the same SKU, decide whether late events update content in-trip or are ignored. Updating in-trip is advanced; most teams ignore late duplicates.

Timezone changes: traveler profiles can look like double-enrolls around midnight if you use calendar days in local TZ without care. Rolling windows avoid most of that pain.

How this differs from quiet hours and caps

Quiet hours delay or block sends in a clock window. Frequency caps limit how many messages a person gets. Once-within limits how often a journey may start from a noisy event. You can need all three: enroll at most once per day from BadgeEarned, still respect quiet hours on the SMS node, and keep a weekly SMS cap across journeys.

Stakeholder FAQ you can paste into Notion

Product: “We emit events for a reason — don’t drop them.” Answer: we never drop storage; we throttle journey starts.
Growth: “We’re missing revenue.” Answer: show suppress rate vs unsubscribe; usually spam was eating deliverability.
Data: “How do I count intent?” Answer: count raw events separately from enrollments; both dashboards matter.

From noisy product analytics to calm journeys

Product analytics teams love high-cardinality events. Marketing journeys hate unbounded fan-out. The compromise is simple to say and hard to operationalize: keep the firehose in the warehouse, put a governor on enrollment.

A practical rollout:

1. Pick one chatty event that already triggers SMS (BadgeEarned or PriceDrop).
2. Turn on once-within with a conservative window (24h).
3. Compare seven days: raw event count, enrollments, SMS sent, unsubscribes, revenue attributed.
4. Only then shorten the window if Growth can prove missed revenue exceeds complaint cost.

If you start from “every event” on SMS, you are tuning under fire. If you start from a window and open carefully, you keep deliverability.

Idempotency keys and “every event”

Every-event mode still needs idempotency for retries. If the producer re-sends the same event_id, you must not create two trips. That is different from once-within: idempotency dedupes the same fire; once-within throttles distinct fires in a period. Document both in the journey brief so engineers do not “fix” duplicates by also widening the window.

Rollout risks unique to Iran SMS stacks

When SMS is priced per part and complaint sensitivity is high, every-event enrollment on chatty product signals burns budget before copy is even wrong. Prefer once-within on any journey that is not a hard transactional obligation. Keep the raw event stream complete for analytics and for rebuilding segments later.

If leadership insists on “realtime for everything,” offer a digest journey: enroll once per window, render the last N events in the template. That preserves the feeling of freshness without N SMS.

Related reading

• Event-centric vs contact-centric automation: behavior stream vs person record
• Transactional vs promotional email and SMS
• Journey vs realtime event campaign: long path vs instant reaction