پوش صف‌شده بعد از خروج از جرنی: همچنان ارسال می‌شود در برابر لغو با خروج

صف‌ای که بعد از Exit زنده می‌ماند (survive-exit) یعنی پوش/پیامی که به‌خاطر Frequency Capping قبلاً وارد صف تحویل شده، حتی بعد از خروج مخاطب از جرنی (مثلاً با خرید) ممکن است هنوز ارسال شود؛ لغو با خروج (cancel-on-exit) یعنی با تمام‌شدن سفر، پیام‌های pending همان مسیر هم می‌میرند—و سؤال «خریدم، چرا هنوز نudge آمد؟» دقیقاً به انتخاب همین مدل برمی‌گردد.

Survive-exit و cancel-on-exit دقیقاً چه فرقی دارند؟

سناریوی کلاسیک رشد ایرانی:

1. کاربر سبد را رها می‌کند → وارد جرنی می‌شود؛
2. به‌خاطر سقف فرکانس، پوش «سبدت منتظرته» صف می‌شود نه حذف؛
3. کاربر می‌خرد → Exit on conversion؛
4. چند دقیقه/ساعت بعد پوش صف‌شده می‌رسد یا نمی‌رسد؟

دو مدل:

1. Survive-exit queuing: Exit جرنی صف کانال را عطف بماسبق خالی نمی‌کند. پیام از قبل queued بوده؛ Exit سفر را تمام می‌کند نه لزوماً صف push را. (الگوی گزارش‌شده در برخی docs سبک MoEngage برای Push queued)
2. Cancel-on-exit: با خروج، هر pending همان journey لغو می‌شود—ذهنیت رایج تیم‌های محصول («اگر Exit شد دیگر چیزی نرود»).

این را با صف تأخیری زیر سقف فرکانس در برابر حذف پیام قاطی نکنید: آنجا سؤال صف در برابر Drop هنگام برخورد به FC است؛ اینجا سؤال بعد از Exit، تکلیف پیام ازقبل‌صف‌شده چیست.

همچنین با خروج با تبدیل در برابر معیار خروج سراسری و گلوگاه لوله ارسال در برابر سقف پیام برای شخص لایه‌های جدا هستند.

جدول مقایسه

توالی گام‌به‌گام (cart + FC)

اگر تیم فقط Exit on conversion گذاشته و فرض کرده «دیگر هیچی نمی‌رود»، ولی موتور survive-exit است، تیکت پشتیبانی می‌آید.

مثال ایرانی: پوش سبد فروشگاه اپ

اپ مد:

• Frequency Cap: حداکثر ۲ پوش بازاریابی / روز؛
• کاربر صبح ۲ پوش کمپین گرفته؛ عصر سبد رها می‌کند؛ پوش cart صف می‌شود؛
• شب خرید می‌کند و Exit می‌شود؛
• فردا صبح با آزاد شدن سقف، پوش «سبدت...» می‌رسد در حالی که سفارش ثبت شده.

راه‌حل عملی حتی بدون سوئیچ محصول:

• روی محتوای پوش شرط/سگمنت «سفارش باز»؛
• یا suppress بعد از خرید؛
• یا قبول کنید cancel-on-exit را در بریف بخواهید و در QA اثبات کنید.

مثال دوم: پوش آنبوردینگ بعد از فعال‌سازی

اگر پوش «گام ۲ را تمام کن» صف شده و کاربر همان روز فعال و Exit شده:

• Survive-exit ممکن است پوش آموزشی بی‌ربط بفرستد؛
• برای onboarding گاهی پیام بعدی هنوز مفید است—پس cancel همیشه درست نیست؛
• بریف باید per-journey باشد نه قانون سراسری کور.

نگاشت صادقانه به Leadara

در Leadara با journeys، مفاهیم frequency، exit on conversion، و کانال‌های web push / ایمیل / پیامک می‌توانید:

• Exit روی خرید برای cart بگذارید؛
• قبل از Send، شرط «هنوز سبد/هدف برقرار است» بگذارید تا حتی اگر چیزی در صف بماند، محتوای منسوخ نرود؛
• سقف فرکانس را از Exit جدا بفهمید—FC زمان/اجازه ارسال است، Exit وضعیت سفر است؛
• برای پیامک کاوه‌نگار همان منطق gate را روی قدم Send اعمال کنید.

ادعای API صف survive/cancel مخصوص یک رقیب را به‌عنوان فیچر بومی Leadara نکنید. صادق بمانید: با Exit + شرط پیش از ارسال + QA خرید-بعد-از-queue نزدیک‌ترین الگوی امن را بسازید.

AI Chat لیدارا دستیار داخلی تیم است، نه ربات پاسخ‌گوی مشتری در Live Chat. Live Chat پشتیبانی انسانی است.

کی Survive، کی Cancel؟

گام‌های عملی

1. بریف: «بعد از خرید هیچ نudge cart نرود—حتی اگر FC صف کرده.»
2. Exit on conversion را قفل کنید.
3. روی Send/push شرط سفارش‌باز بگذارید.
4. QA: پروفایل با FC پر → queue → خرید → ببینید پیام می‌رسد یا نه.
5. لاگ «delivered after exit» را یک هفته مانیتور کنید.
6. متن پوش را طوری ننویسید که بعد از خرید توهین‌آمیز باشد.
7. Rate limit لوله را با FC شخصی قاطی نکنید.

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

• فرض اینکه Exit همیشه صف کانال را پاک می‌کند؛
• یکی دانستن FC-queue-vs-drop با exit×queue؛
• نداشتن شرط محتوا بعد از تبدیل؛
• تست نکردن ترتیب queue سپس purchase؛
• سرکوب کل کانال به‌جای اصلاح منطق جرنی.

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

خرید کردم—چرا پوش صف‌شده هنوز آمد؟

احتمالاً مدل survive-exit یا نبودن gate روی محتوا. Exit سفر را تمام کرده؛ صف کانال جدا بوده.

آیا صف FC همان لغو با Exit است؟

خیر. FC تصمیم می‌گیرد صف شود یا Drop شود؛ Exit تصمیم می‌گیرد سفر تمام شود. تقاطع‌شان مقالهٔ جدا می‌خواهد—همین مطلب.

پوش آنبوردینگ باید Survive کند یا Cancel؟

وابسته به مفید بودن پیام بعد از هدف. برای cart معمولاً Cancel/gate؛ برای آموزش گاهی Survive.

پیامک هم همین است؟

ایده یکی است: pending در برابر وضعیت جرنی. کانال هرچه باشد، بریف و QA باید صریح باشد.

Rate limiting چطور وارد می‌شود؟

Rate limiting لوله ارسال را کند می‌کند؛ ممکن است صف طولانی‌تر شود و شانس survive-after-exit بیشتر دیده شود. با rate limiting vs FC فرق دارد.

آیا Live Chat لیدارا این را به مشتری می‌گوید؟

Live Chat پشتیبانی انسانی است؛ AI Chat دستیار داخلی است.

چطور در QA ثابت کنم؟

پروفایل با سقف پر، اجبار به queue، سپس خرید، سپس صبر تا نوبت ارسال. نتیجه را اسکرین/لاگ کنید.

خلاصه برای مدیر محصول؟

«Exit سفر را می‌بندد؛ مگر ثابت کنید صف کانال هم لغو می‌شود—برای cart همیشه شرط سفارش‌باز بگذار.»

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

روی جرنی سبد، یک تست queue→purchase→deliver اجرا کنید. اگر پوش بعد از خرید رسید، یا cancel را در موتور پیدا کنید یا gate محتوا را اجباری کنید—قبل از اسکیل کمپین جمعه.

چک‌لیست صف×Exit

1. آیا FC در این مسیر queue می‌کند یا drop؟
2. بعد از Exit، docs دربارهٔ queued push چه می‌گوید؟
3. شرط پیش از ارسال چیست؟
4. QA سه‌گامی بالا پاس شد؟
5. متریک delivered-after-exit مانیتور می‌شود؟

هماهنگی با رشد و پشتیبانی

یک جمله به پشتیبانی بدهید: «اگر بعد از خرید پوش cart آمد، بپرسید آیا همان روز به سقف فرکانس خورده بود—اغلب صف×Exit است.»

معیار موفقیت

• delivered-after-exit / کل ارسال cart (نزدیک صفر)؛
• تیکت‌های پس از خرید؛
• نرخ queue برای مسیر cart.

لایهٔ سوم: انقضای محتوا در برابر لغو صف

حتی اگر موتور survive-exit باشد، می‌توانید ریسک را با انقضای محتوا کم کنید:

1. پوش cart فقط تا ۲ ساعت بعد از رها کردن سبد معتبر باشد؛
2. اگر صف طولانی‌تر شد، ارسال‌کننده محتوا را دور بریزد (TTL)؛
3. این با cancel-on-exit فرق دارد ولی برای مشتری نتیجهٔ مشابه امن‌تری می‌دهد.

در بریف بنویسید: «اگر cancel صف نداریم، حداقل TTL محتوا اجباری است.»

ماتریس تصمیم سریع برای رشد

مطالب مرتبط

• صف تأخیری زیر سقف فرکانس در برابر حذف پیام: نگه داشتن تا آزاد شدن سقف در برابر دور انداختن
• خروج با تبدیل در برابر معیار خروج سراسری: قطع مسیر با هدف در برابر بیرون‌انداختن با پراپرتی
• گلوگاه لوله ارسال در برابر سقف پیام برای شخص