خروج با گروه‌های OR در برابر زیرشرط‌های AND در پنجره ۳۰ روزه

شرط‌های خروج سطح بالا با OR کنار هم می‌نشینند—هر گروه به‌تنهایی می‌تواند کاربر را بیرون بیندازد؛ داخل هر گروه، زیرشرط‌ها AND هستند و باید همه در یک پنجره غلتان حدود ۳۰ روزه true شوند وگرنه آن گروه هرگز fire نمی‌کند.

خروج با گروه‌های OR و زیرشرط‌های AND در پنجره ۳۰ روزه یعنی چه؟

وقتی برای جرنی معیار خروج سراسری می‌نویسی، معمولاً چند «دلیل مشروع برای قطع مسیر» داری: خرید کرد، VIP شد، opt-out زد، تیکت بحرانی باز کرد. در بسیاری از پلتفرم‌ها این دلایل به‌صورت گروه‌های OR مدل می‌شوند: اگر هر کدام از گروه‌ها برقرار شود، کاربر خارج می‌شود.

داخل یک گروه اما منطق سخت‌گیرانه‌تر است: زیرشرط‌ها AND می‌شوند و اغلب باید همگی در یک پنجره غلتان حدود ۳۰ روزه رخ دهند/true باشند. اگر یکی از زیرشرط‌ها خارج از پنجره بیفتد، کل آن گروه هیچ‌وقت برنده نمی‌شود—حتی اگر تک‌تک شرط‌ها «روزی» true شده باشند.

این دقیقاً جایی است که تیم‌ها می‌گویند «خروج کار نمی‌کند» در حالی که سیاست زمانی گروه را نفهمیده‌اند.

هر کدام چطور کار می‌کند؟

گروه‌های OR در سطح بالا

• گروه A: order_completed
• گروه B: unsubscribe یا شکایت
• گروه C: پراپرتی plan = enterprise و فلگ onboarding_done

اگر A یا B یا C برقرار شود → خروج. نیازی نیست همه گروه‌ها با هم true شوند. این را با خروج با تبدیل در برابر معیار خروج سراسری هم‌خوان ببین: تبدیل اغلب یک گروه OR ساده است؛ معیار سراسری می‌تواند چند گروه داشته باشد.

زیرشرط‌های AND داخل گروه + پنجره ~۳۰ روزه

فرض کن گروه C می‌گوید: «سگمنت VIP شده و در ۳۰ روز اخیر حداقل یک خرید و ایمیل خوش‌آمد را باز کرده.» هر سه باید داخل همان پنجره غلتان هم‌پوشان true شوند. اگر VIP شدن ۶۰ روز پیش بوده و خرید دیروز، بسته به تعریف «پراپرتی جاری در برابر ایونت داخل پنجره»، ممکن است گروه fire نشود.

مثال واقعی از فروشگاه و SaaS ایرانی

فروشگاه آرایشی—خروج از nurture سبد

گروه‌های OR:

1. order_completed (تبدیل)
2. unsubscribe / شکایت
3. AND مرکب: cart_value > 2M و support_ticket_open در ۳۰ روز → خروج به مسیر انسانی

اگر فقط خرید را ببینی و گروه ۳ را AND اشتباه OR فرض کنی، تیکت‌های سنگین بدون خرید همچنان nurture اسپم می‌گیرند.

SaaS—خروج از آنبوردینگ تریال

ORها: تبدیل به پلن پولی، لغو تریال، حذف اکانت. گروه AND: activation_score >= 80 و team_seat_invited داخل ۳۰ روز → خروج از ایمیل‌های فشار فروش چون محصولاً «فعال» شده‌اند. اگر دعوت صندلی ۴۵ روز پیش بوده و امتیاز امروز بالا رفته، گروه AND ممکن است fire نشود—و کاربر همچنان فشار فروش بگیرد. این باگ محصول نیست؛ تعریف پنجره است.

مارکت‌پلیس فروشنده—خروج از آموزش فروشنده تازه‌کار

OR: اولین فروش موفق، یا وضعیت seller_suspended. گروه AND: تکمیل KYC و آپلود ۱۰ آگهی داخل ۳۰ روز. بدون فهم AND+پنجره، فروشنده‌ای که KYC را ماه پیش تمام کرده و امروز آگهی می‌گذارد ممکن است از آموزش خارج نشود.

کی OR سطح بالا و کی AND داخل گروه؟

1. دلایل مستقل و متضاد (خرید در برابر لغو) → گروه‌های OR جدا.
2. یک سناریوی مرکب که فقط با چند سیگنال هم‌زمان معنی دارد → یک گروه AND با پنجره صریح.
3. اگر بیش از سه گروه OR داری، اول ادغام کن؛ گزارش خروج شلوغ می‌شود.
4. پنجره ۳۰ روزه پیش‌فرض را کورکورانه قبول نکن؛ برای سبد ۷ روز، برای onboarding ۱۴–۳۰، برای VIP گاهی ۶۰.
5. زمان واقعی بیرون‌افتادن ممکن است با علامت خروج فوری در برابر خروج بعد از اتمام انتظار فرق کند—فلگ الان، خروج کامل بعد از تایمر.

نگاشت به Leadara (events، segments، journeys، email/SMS)

• Events: هر زیرشرط ایونتی را با نام پایدار و timestamp قابل اتکا بفرست.
• Segments / properties: برای شرط‌های وضعیتی (VIP، plan) از پراپرتی/سگمنت استفاده کن و روشن کن «وضعیت جاری» است یا «تغییر داخل پنجره».
• Journeys: معیار خروج سراسری را با گروه‌های OR مدل کن؛ داخل گروه پیچیده، AND و پنجره را در تیکت محصول بنویس.
• Email / SMS: بعد از خروج، کانال nurture را قطع کن؛ تراکنشی جدا بماند. اگر مسیر باید عوض شود نه فقط قطع، به جرنی adaptive در برابر rule-based فکر کن.

اشتباه‌های رایج

• نوشتن سه زیرشرط و فرض OR بودن داخل یک گروه.
• پنجره ۳۰ روزه را ندیدن و گفتن «سیستم خروج را از دست داد».
• مخلوط کردن پراپرتی مادام‌العمر با ایونت داخل پنجره بدون توضیح.
• ده گروه OR هم‌پوشان بدون اولویت گزارش.
• خروج را mark کردن ولی انتظار قطع فوری پیامک در وسط delay—زمان‌بندی خروج را جدا بخوان.
• تست نکردن ترتیب: اول شرط ۲ بعد شرط ۱ داخل پنجره.

جمع‌بندی یک‌خطی برای تیم

OR بین گروه‌ها = هر دلیل مستقل کافی است؛ AND داخل گروه + پنجره ~۳۰روز = همه زیرشرط‌ها باید در یک پنجره هم‌پوشان true شوند.

گام بعدی چیست؟

معیار خروج یک جرنی زنده را باز کن. برای هر گروه بنویس: OR است یا AND؟ پنجره چند روز است؟ یک پروفایل تست بساز که زیرشرط‌ها را با فاصله ۳۵ روز بزند و ببین آیا (نادرست) انتظار خروج داشتی.

سؤالات پرتکرار

چرا ۳۰ روز؟

در بسیاری ابزارها پیش‌فرض پنجره ارزیابی زیرشرط‌های مرکب حدود یک ماه است. قابل تغییر است؛ عدد جادویی نیست.

اگر فقط یک زیرشرط در گروه باشد؟

عملاً همان OR سطح بالاست؛ AND بی‌معنی می‌شود. گروه را ساده نگه دار.

پراپرتی VIP که دو سال است true است داخل پنجره می‌گنجد؟

بستگی به تعریف دارد: اگر «وضعیت جاری» باشد معمولاً بله؛ اگر «رویداد vip_upgraded داخل پنجره» باشد، خیر مگر ارتقا تازه باشد. در تیکت مشخص کن.

خروج OR با شاخه if/else چه فرقی دارد؟

شاخه مسیر را عوض می‌کند؛ خروج معمولاً سفر را تمام می‌کند. برای تغییر مسیر وسط راه، adaptive/rule-based را بخوان.

می‌شود اولویت بین گروه‌های OR گذاشت؟

اغلب نیاز نیست چون هر کدام خروج کامل است؛ برای گزارش، دلیل خروج را لاگ کن.

پیامک وسط delay وقتی exit mark شده؟

ممکن است تا پایان قدم صبر هنوز برود. سیاست mark فوری در برابر تکمیل delay را جدا تنظیم کن.

چطور دیباگ کنیم؟

برای یک پروفایل timeline بکش: زمان هر زیرشرط، مرز پنجره، کدام گروه نزدیک بود. بدون timeline فقط حدس می‌زنی.

سناریوی قدم‌به‌قدم

1. لیست دلایل مشروع خروج را به فارسی بنویس.
2. هر دلیل مستقل = یک گروه OR.
3. هر سناریوی مرکب = یک گروه با AND و پنجره عددی.
4. در Leadara معیار خروج را پیاده کن؛ روی ۱۰ پروفایل فاصله زمانی را جابه‌جا کن.
5. گزارش «exit reason» را با پشتیبانی هماهنگ کن.
6. بعد از go-live دو هفته سهم هر گروه خروج را قفل نگه دار.

طراحی مثل کد

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

گاردها: پنجره را صریح بنویس؛ وضعیت جاری را از ایونت داخل پنجره جدا کن؛ دلیل خروج را لاگ کن.

متریک‌ها

• سهم خروج per گروه
• میانگین زمان تا خروج
• نرخ «نباید خارج می‌شد» از تیکت پشتیبانی
• پیام‌های ارسال‌شده بعد از mark خروج (باید نزدیک صفر باشد اگر سیاست فوری است)

زبان گزارش برای مدیر محصول

به‌جای «خروج خرابه» بگو: «گروه AND سه شرط در پنجره ۳۰روزه می‌خواست؛ شرط‌ها با فاصله ۳۵روز آمده‌اند.»

تست پذیرش قبل از انتشار معیار خروج

1. پروفایل A فقط تبدیل → باید با گروه OR تبدیل خارج شود.
2. پروفایل B سه زیرشرط AND را داخل ۲۵ روز بزند → گروه مرکب fire شود.
3. پروفایل C همان سه زیرشرط را با فاصله ۳۵ روز بزند → گروه مرکب fire نشود (مگر تعریف وضعیت جاری باشد).
4. پروفایل D وسط delay پیامک، exit mark شود → رفتار فوری در برابر تکمیل delay را لاگ کن.
5. دلیل خروج در گزارش برای پشتیبانی خوانا باشد (نام گروه، نه کد داخلی).

تفاوت با هولداوت و با شاخه

هولداوت عمداً پیام را برای اندازه‌گیری نگه می‌دارد؛ خروج مسیر را تمام می‌کند. شاخه if/else مسیر را عوض می‌کند ولی لزوماً سفر را نمی‌کشد. قاطی کردن این سه در یک تیکت باعث می‌شود فکر کنی «خروج کار نمی‌کند» در حالی که هولداوت یا شاخه بوده.

چک‌لیست نوشتن گروه AND

• هر زیرشرط: ایونت است یا پراپرتی جاری؟
• پنجره عددی چند روز است و از کی شروع می‌شود (از enroll یا غلتان از now)؟
• اگر یکی از زیرشرط‌ها دیر بیاید، آیا می‌خواهی صبر کنی یا گروه را fail بدانی؟
• آیا بعد از fire باید nurture قطع شود یا به جرنی دیگر jump؟

زبان یک‌خطی برای تیکت مهندسی

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

مطالب مرتبط

• خروج با تبدیل در برابر معیار خروج سراسری: قطع مسیر با هدف در برابر بیرون‌انداختن با پراپرتی
• علامت خروج فوری در برابر خروج بعد از اتمام انتظار: الان فلگ می‌شود، وقتی تایمر تمام شد واقعاً خارج می‌شود
• جرنی adaptive در برابر rule-based: تغییر مسیر وسط راه در برابر if/then ثابت