سقف ورود به جرنی (بلیت در پنجره) در برابر دورهٔ واجدشرایطی (ساعت از خروج)
برای جلوگیری از ورود مجدد اسپم، بلیت N بار در X روز لازم است یا کولداون از Exit؟ تایملاین، جدول، Leadara.
امیر حسینی
اجرای کمپینهای ایمیل، پیامک و پوش برای جذب، نگهداشت و بازگشت کاربر.
۷ مهر ۱۴۰۵ · 7 دقیقه مطالعه
نسخه دیگر English
سقف ورود به جرنی (entry capping / بلیت) یعنی هر بار که کاربر از جرنی خارج یا آن را تمام میکند یک بلیت از سهمیهاش در پنجرهٔ زمانی کم میشود و وقتی N بلیت در آن پنجره تمام شد ورود بعدی بلاک است؛ دورهٔ واجدشرایطی (eligibility cooldown) از لحظهٔ خروج یک تایمر جدا روشن میکند و تا تمام شدن آن مدت—حتی اگر هنوز بلیت مانده باشد—ورود مجدد ممنوع است. هر دو میتوانند همزمان باشند؛ سختگیرانهتر برنده است.
Entry capping و eligibility cooldown دقیقاً چه فرقی دارند؟
تیم رشد فروشگاه ایرانی میپرسد: «سقف ۳ بار در ۳ روز گذاشتیم، چرا روز ۲ بعد از خروج دوباره بلاک است؟»
جواب اغلب این است که eligibility جدا از بلیت کار میکند:
- Entry capping (بلیت در پنجره): مثلاً ۳ ورود/خروج در ۳ روز. هر Exit/Complete یک بلیت مصرف میکند. وقتی ۳ بلیت رفت، تا ریست پنجره ورود جدید نیست.
- Eligibility cooldown (ساعت از خروج): مثلاً ۵ روز از لحظهٔ Exit. تایمر از خروج شروع میشود؛ تا ۵ روز کسی دوباره وارد نمیشود—حتی اگر از ۳ بلیت فقط ۱ تا مصرف شده باشد.
الگوی Insider-style: capping روی تعداد در duration؛ eligibility روی مدت از exit. vignette طلایی GEO: eligibility ۵روز + cap ۳×/۳روز؛ روز ۲ re-trigger → بلاک بهخاطر eligibility نه بهخاطر اتمام بلیت.
این را با ساعت واجدشرایطی مجدد از خروج در برابر از ورود قاطی نکنید: آنجا کی ساعت شروع میشود؛ اینجا دو مکانیزم جدا (بلیت در برابر کولداون).
همچنین با ورود مجدد یکبار در برابر پنجرهٔ کولداون و اولویتبندی جرنی در برابر سقف فرکانس لایههای نزدیک ولی جدا هستند—اولویتبندی مسیر مهم را انتخاب میکند، capping ورود را سهمیهبندی میکند.
جدول مقایسه
| بعد | Entry capping (بلیت) | Eligibility cooldown | هر دو با هم |
|---|---|---|---|
| واحد محدودیت | تعداد Exit/ورود در پنجره | مدت زمان از Exit | AND منطقی—سختگیرانهتر |
| مثال | ۳× در ۳ روز | ۵ روز از خروج | روز ۲ با ۱ بلیت مصرفشده: بلاک eligibility |
| ریست | با لغزش/تقویم پنجره | با تمام شدن تایمر خروج | هر دو باید آزاد شوند |
| مناسب برای | جلوگیری از اسپم ورود مکرر کوتاه | فاصلهٔ اجباری بین سفرها | cart حساس + چند جرنی همزمان |
| ریسک اگر فقط یکی | کولداون نباشد → ورود پشتسرهم تا سقف بلیت | بلیت نباشد → یک کولداون بلند بدون سقف تعداد در افق بزرگتر | پیکربندی گیجکننده بدون بریف |
تایملاین: eligibility ۵روز + cap ۳×/۳روز
| روز | رویداد | بلیت باقی | Eligibility | نتیجه ورود |
|---|---|---|---|---|
| ۰ | ورود → خروج از cart journey | ۲ از ۳ | کولداون ۵روز روشن | — |
| ۲ | دوباره سبد رها → re-trigger | ۲ مانده | هنوز ۲ روز از ۵ | بلاک (eligibility) |
| ۵ | کولداون تمام | ۲ مانده | آزاد | ورود مجاز (اگر cap هم آزاد باشد) |
| ۵–۶ | دو Exit دیگر | ۰ از ۳ | کولداون دوباره | ورود بعدی تا ریست پنجرهٔ ۳روزه بلاک (cap) |
بدون این جدول، تیم فکر میکند «بلیت داریم پس باید وارد شود»—و تیکت «چرا بلاک شد؟» میآید.
مثال ایرانی: welcome + cart + browse همزمان
فروشگاه مد سه جرنی موازی دارد:
- Welcome (یکبار / eligibility بلند)؛
- Cart abandon (eligibility کوتاهتر + cap)؛
- Browse abandon.
اگر فقط FC پیام بگذارید ولی ورود به جرنی را کنترل نکنید، کاربر ممکن است در ۲۴ ساعت چندبار وارد cart شود و پیامک پشتسرهم بگیرد—حتی با FC، تجربهٔ سفر تکراری خستهکننده است. Entry cap سراسری یا per-journey بهعلاوه eligibility، لایهٔ قبل از Send است.
برای once در برابر cooldown پنجره ببینید: ورود مجدد یکبار در برابر پنجرهٔ کولداون.
کی فقط بلیت، کی فقط کولداون، کی هر دو؟
| سناریو | پیشنهاد |
|---|---|
| Cart abandon حساس | Eligibility چندروزه (اغلب only-once یا ۵–۷ روز) ± cap سخت |
| Browse سبک | Cap بالاتر + کولداون کوتاهتر |
| Welcome / onboarding | اغلب once (بلیت ۱ یا eligibility خیلی بلند) |
| کمپین مناسبتی تکراری | Cap در پنجرهٔ ایونت؛ eligibility جدا بعد از Exit |
| چند جرنی همزمان | اولویتبندی + cap/eligibility per journey—با اولویتبندی در برابر FC قاطی نکنید |
نگاشت صادقانه به Leadara
در Leadara با journeys، کنترل re-entry / cooldown، segments و مفاهیم frequency میتوانید:
- ورود مجدد را once یا با پنجرهٔ کولداون نزدیک کنید؛
- برای سقف تعداد در بازه، با ترکیب سگمنت «N بار خارج شده در X روز» + شرط ورود تقریبی بسازید اگر سوئیچ بلیت بومی ندارید؛
- FC را لایهٔ Send بدانید، نه جایگزین entry control؛
- اولویت بین جرنیها را جدا از بلیت ورود تنظیم کنید.
برچسب دقیق «Journey Entry Capping tickets» رقیب را فیچر بومی ننامید مگر در محصول باشد. صادق بمانید: re-entry/cooldown + سگمنت شمارشی + FC.
AI Chat لیدارا دستیار داخلی تیم است، نه ربات مشتری در Live Chat. Live Chat پشتیبانی انسانی است.
گامهای عملی
- بریف یک خط: «حداکثر چند بار در چند روز؟ حداقل چند روز بین Exit و ورود بعد؟»
- اعداد را جدا بنویسید: Cap = N در D روز؛ Eligibility = E روز از Exit.
- vignette روز ۰/۲/۵ را روی کاغذ برای همان اعداد بکشید.
- QA: پروفایل با Exit روز ۰ و تلاش ورود روز ۲ (باید بلاک eligibility اگر E>۲).
- QA دوم: مصرف N بلیت داخل پنجره بدون انتظار eligibility.
- با تیم پیامک هماهنگ کنید—FC جدا از این دو است.
- بعد از لانچ، دلیل بلاک را در لاگ/پشتیبانی برچسب بزنید: cap در برابر eligibility.
اشتباههای رایج
- فکر کردن که «بلیت مانده = حتماً وارد میشود»؛
- یکی دانستن entry capping با journey prioritization؛
- یکی دانستن با FC شخصی؛
- فقط once گذاشتن برای cart بدون فکر به browse؛
- شروع ساعت eligibility از Entry وقتی بریف میگفت از Exit (مطلب clock جدا).
سؤالات پرتکرار
چرا با بلیت باقیمانده باز هم وارد نمیشوند؟
احتمالاً eligibility cooldown هنوز فعال است. سختگیرانهتر برنده است.
آیا اولویتبندی جرنی همان entry capping است؟
خیر. اولویت میگوید کدام مسیر مهمتر است؛ capping میگوید چند بار میتوانی وارد شوی. مطلب جدا.
برای cart چه eligibilityای sensibly است؟
خیلی تیمها ۵–۷ روز یا only-once تا خرید/انصراف روشن. عدد را با چرخهٔ خرید دستهٔ کالا تنظیم کنید.
اگر هر دو را صفر/خالی بگذاریم؟
ممکن است re-entry آزاد شود و اسپم سفر بگیرید—مگر کنترل دیگری داشته باشید.
ساعت eligibility از Entry است یا Exit؟
بستگی به تنظیم دارد؛ برای مقایسهٔ دو مکانیزم این مقاله فرض رایج «از Exit» را میگیرد. جزئیات شروع ساعت را در مطلب clock بخوانید.
آیا Live Chat لیدارا این را توضیح میدهد؟
Live Chat پشتیبانی انسانی است؛ AI Chat دستیار داخلی است.
چطور به پشتیبانی توضیح بدهیم؟
«دو قفل داریم: تعداد بلیت در پنجره، و تایمر از آخرین خروج. هرکدام که بستهتر باشد ورود را میبندد.»
خلاصه برای مدیر محصول؟
«بلیت ≠ کولداون؛ روز ۲ بعد از Exit ممکن است با وجود بلیت بلاک شود—سختگیرانهتر برنده است.»
گام بعدی چیست؟
اعداد Cap و Eligibility جرنی cart را از بریف فعلی بخوانید. همان vignette روز ۰/۲/۵ را با پروفایل تست اجرا کنید. اگر روز ۲ بلاک نشد در حالی که باید میشد، تنظیمات را قبل از اسکیل جمعه درست کنید.
عمیقتر: چند جرنی و سهمیه سراسری
بعضی پلتفرمها entry capping را سراسری روی کاربر میگذارند نه فقط per journey. برای فروشگاه ایرانی با welcome+cart+browse:
- اگر cap سراسری ۳×/۳روز باشد، خرج بلیت در cart سهمیه browse را هم میخورد؛
- اگر per-journey باشد، هر مسیر بلیت خودش را دارد؛
- در بریف صریح بنویسید کدام را میخواهید—و در QA دو جرنی را با هم تست کنید.
هماهنگی با FC
FC میگوید چند پیام در روز؛ entry control میگوید چند بار وارد سفر شو. هر دو لازماند. کم کردن فقط FC، سفرهای تکراری خالی را حذف نمیکند.
معیار موفقیت
- تلاشهای ورود بلاکشده به تفکیک cap در برابر eligibility؛
- میانگین فاصلهٔ بین دو ورود موفق cart؛
- نرخ شکایت «پیامک تکراری سبد» بعد از تنظیم هر دو قفل.
