Exit OR-groups vs AND subconditions in 30 days: any group wins, all sub-filters must land in one window

Top-level exit conditions are OR'd—any one group can eject the user; inside a group, sub-conditions are AND'd and must all become true within a rolling ~30-day window or the group never fires.

What are exit OR-groups vs AND subconditions in a 30-day window?

When you write global exit criteria for a journey, you usually have several legitimate “stop this trip” reasons: purchased, became VIP, unsubscribed, opened a critical ticket. Many platforms model those reasons as OR-groups: if any group becomes true, the user exits.

Inside a single group the logic is stricter: sub-conditions are AND'd, and they often must all be true inside a rolling ~30-day window. If one sub-condition falls outside that window, the whole group never wins—even if each condition was true “sometime.”

That is exactly where teams say “exit is broken” when they actually misunderstood the group’s timing policy.

How does each layer work?

Top-level OR groups

• Group A: order_completed
• Group B: unsubscribe or complaint
• Group C: property plan = enterprise and flag onboarding_done

If A or B or C holds → exit. Groups do not all need to be true together. Read with exit on conversion vs global exit criteria: conversion is often one simple OR group; global criteria can hold many groups.

AND subconditions inside a group + ~30-day window

Suppose group C means: “entered VIP segment and at least one purchase in the last 30 days and opened the welcome email.” All three must overlap inside the rolling window. If VIP happened 60 days ago and purchase was yesterday, whether the group fires depends on “current property vs event-inside-window” definitions.

Concrete examples

Beauty ecommerce — leave cart nurture

OR groups: (1) order_completed, (2) unsubscribe/complaint, (3) AND compound: cart_value > threshold and support_ticket_open within 30d → hand to humans. If you treat group 3 as OR, heavy tickets without purchase keep getting spam nurture.

SaaS — leave trial onboarding

ORs: paid conversion, trial cancel, account delete. AND group: activation_score >= 80 and team_seat_invited within 30d → stop sales-pressure emails because they are product-active. If the invite was 45 days ago and score rose today, the AND group may not fire—and pressure continues. Not a platform bug; window definition.

Seller marketplace — leave new-seller education

OR: first successful sale, or seller_suspended. AND: KYC complete and 10 listings uploaded within 30d. Without AND+window literacy, a seller who finished KYC last month and uploads today may never exit education.

When to use which

1. Independent opposing reasons (purchase vs cancel) → separate OR groups.
2. One compound scenario that only makes sense with simultaneous signals → one AND group with an explicit window.
3. More than three OR groups → merge first; exit reports get noisy.
4. Do not blindly accept a 30-day default; cart may need 7d, onboarding 14–30, VIP sometimes 60.
5. Actual drop timing may differ via exit mark immediate vs delay-step complete—flagged now, fully gone when the wait ends.

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

• Events: stable names and trustworthy timestamps for every event subcondition.
• Segments / properties: for stateful checks (VIP, plan), clarify “current state” vs “changed inside window.”
• Journeys: model global exits as OR groups; write AND + window into the product ticket for compound groups.
• Email / SMS: cut nurture after exit; keep transactional separate. If you need re-route instead of stop, see adaptive journey vs rule-based journey.

Common mistakes

• Writing three subconditions and assuming OR inside one group.
• Ignoring the 30-day window and blaming “missed exits.”
• Mixing lifetime properties with in-window events without stating which.
• Ten overlapping OR groups with no exit-reason logging.
• Marking exit but expecting SMS to stop mid-delay immediately.
• Never testing order: condition 2 then condition 1 inside the window.

One-line takeaway

OR across groups = any independent reason is enough; AND inside a group + ~30-day window = every subcondition must be true inside one overlapping window.

Next step

Open exit criteria on a live journey. For each group write: OR or AND? How many days is the window? Build a test profile that fires subconditions 35 days apart and check whether you wrongly expected an exit.

FAQ

Why ~30 days?

Many tools default compound subcondition windows near one month. It is configurable—not magic.

Only one subcondition in a group?

Then it behaves like a simple OR-level reason; keep the group flat.

A VIP property true for two years—inside the window?

If defined as current state, usually yes; if defined as vip_upgraded event inside the window, no unless the upgrade is recent. State it in the ticket.

OR exit vs if/else branch?

Branches change path; exits usually end the trip. For in-flight re-routing, read adaptive vs rule-based.

Priority among OR groups?

Often unnecessary because each fully exits; still log exit reason for analytics.

SMS mid-delay after exit mark?

It may still send until the wait step completes—configure immediate mark vs delay-complete separately.

How to debug?

Draw a per-profile timeline: each subcondition time, window edges, which group was closest. Without a timeline you are guessing.

Step-by-step

1. List legitimate exit reasons in plain language.
2. Each independent reason → one OR group.
3. Each compound scenario → one AND group with a numeric window.
4. Implement in Leadara; permute timing across ten test profiles.
5. Align “exit reason” reporting with support.
6. Freeze per-group exit share for two weeks post-launch.

Programmer-shaped sketch

def should_exit(profile, now):
  for group in exit_groups:          # OR across groups
    if all(cond_true(c, profile, window=group.window or 30d, now=now)
           for c in group.conditions):  # AND inside group
      return True, group.id
  return False, None

Guards: write the window explicitly; separate current state from in-window events; log exit reason.

Metrics

• Exit share per group
• Mean time-to-exit
• “Should not have exited” support rate
• Sends after exit mark (near zero if immediate policy)

PM language

Say “the AND group required three conditions inside 30 days; they arrived 35 days apart,” not “exit is broken.”

Acceptance tests before publishing exit criteria

1. Profile A only converts → must exit via the conversion OR group.
2. Profile B hits all AND subconditions inside 25 days → compound group fires.
3. Profile C hits the same three 35 days apart → compound group must not fire (unless current-state semantics say otherwise).
4. Profile D gets exit-marked mid-SMS-delay → log immediate vs delay-complete behavior.
5. Exit reason in reports must be human-readable for support (group name, not internal code).

Versus holdout and versus branches

Holdout intentionally withholds messages for measurement; exit ends the trip. If/else changes path without necessarily killing the journey. Mixing the three in one ticket creates fake “exit is broken” bugs.

AND-group writing checklist

• Each subcondition: event or current property?
• Numeric window length and anchor (since enroll vs rolling from now)?
• If one subcondition arrives late, wait or fail the group?
• After fire: stop nurture or jump to another journey?

One-line engineering ticket

exit = OR( order_completed , unsubscribe , AND(vip_status_current, purchase_in_30d, welcome_opened_in_30d) ); mark=immediate_on_delay_steps=complete_at_timer_end

Related reading

• Exit on conversion vs global exit criteria: goal kill-switch vs property/behavior eject
• Exit mark immediate vs delay-step complete: flagged now, fully gone when the wait ends
• Adaptive journey vs rule-based journey: in-flight re-route vs fixed if/then