رویداد باید داخل Delay رخ بدهد در برابر سابقه قبلی کافی است: صبر برای رخداد تازه در برابر قبول تاریخچه
در Wait-until-event آیا فقط ایونت وسط Delay شمرده میشود یا سابقهٔ قبل از ورود هم کافی است؟ جدول حقیقت، مثال سبد و دمو، و نگاشت به Leadara.
رضا احمدی
بهینهسازی سایت و محتوا برای گوگل؛ افزایش ترافیک ارگانیک و دیدهشدن برند در نتایج جستجو.
۵ مهر ۱۴۰۵ · 7 دقیقه مطالعه
نسخه دیگر English
در بسیاری از موتورهای جرنی (سبک HubSpot)، مرحلهٔ «صبر تا رویداد» فقط وقتی رها میشود که رویداد همانطور که مخاطب داخل Delay نشسته fire شود؛ ثبتنام دیروز، باز کردن ایمیل قبلی یا page view قبل از ورود به این قدم، این صبر را راضی نمیکند. طراحی مخالف، تاریخچهٔ قبلی را قبول میکند و اگر شرط از قبل برقرار بوده، صبر را skip میکند.
رویداد باید داخل Delay رخ بدهد یعنی چه؟
وقتی در جرنی بعد از ایمیل یا پیامک مینویسید «صبر کن تا خرید کند / فرم را بفرستد / لینک را باز کند»، دو معنای کاملاً متفاوت ممکن است:
- فقط رخداد تازه داخل Delay: مخاطب وارد مرحلهٔ صبر میشود؛ ساعت شروع بهکار میکند؛ فقط ایونتی که بعد از ورود به این قدم ثبت شود او را جلو میبرد. اگر دیروز فرم را پر کرده و امروز وارد این Delay شده، هنوز باید دوباره (یا فعلاً) عمل کند—مگر timeout یا شاخهٔ جایگزین داشته باشید.
- سابقه قبلی کافی است (prior counts): در لحظهٔ ورود به قدم، سیستم چک میکند آیا شرط همین الان برقرار است (مثلاً
form_submitted=trueیا آخرین خرید در ۷ روز اخیر). اگر بله، Delay را رد میکند و میرود مرحلهٔ بعد.
سؤال پرتکرار تیمهای ایرانی: «دیروز فرم لندینگ را پر کرده—چرا هنوز روی Wait گیر کرده؟» جواب معمولاً همین است: موتور شما رویداد-در-حین-صبر است، نه شرط-از-قبل-برقرار.
جدول حقیقت: prior / new / timeout
| وضعیت مخاطب | موتور «باید داخل Delay رخ بدهد» | موتور «سابقه قبلی کافی است» |
|---|---|---|
| فرم را دیروز فرستاده، امروز وارد Wait شده | میماند تا رخداد تازه یا timeout | معمولاً بلافاصله رد میشود |
| وارد Wait شده، بعد فرم میفرستد | آزاد میشود | آزاد میشود (اگر هنوز چک کند) |
| هیچوقت فرم نمیفرستد | بعد از سقف زمانی به شاخهٔ timeout | وابسته به طراحی؛ اغلب همان شاخهٔ «شرط برقرار نیست» |
| فرم را وسط Delay میفرستد ولی بعد exit روی خرید | آزاد + ممکن است همزمان exit بخورد | مشابه |
این را با صبر تا رویداد در برابر تأخیر ثابت قاطی نکنید: آنجا سیگنال در برابر ساعت است. اینجا سؤال این است که آیا سیگنالِ قبل از نشستن روی صندلی Delay هم شمرده میشود یا نه.
مثال ایرانی: رها کردن سبد بعد از پیامک کاوهنگار
فرض کنید فروشگاه مد:
- تریگر:
cart_updatedبا مبلغ بالای X و بدون خرید در ۳۰ دقیقه؛ - پیامک کاوهنگار: «سبدت منتظرته—کد ۱۰٪»؛
- قدم بعدی: Wait until
order_completedبا سقف ۴۸ ساعت؛ - اگر خرید کرد → خروج از جرنی روی conversion؛
- اگر نکرد → ایمیل یادآوری ملایم، بعد پایان.
اگر موتور شما رویداد باید داخل Delay باشد و مشتری قبل از ورود به Wait (مثلاً در همان صفحهٔ سبد، قبل از پیامک) خرید کرده باشد ولی ایونت خرید دیرتر به CRM رسیده—یا برعکس، دیروز خرید کرده و امروز دوباره وارد سگمنت سبد شده—رفتار با چیزی که مارکتر «منطقی» میداند فرق میکند. برای جلوگیری از گیر کردن الکی:
- سقف زمانی شفاف بگذارید (صبر با سقف در برابر نامحدود)؛
- شاخهٔ timeout را برای «هنوز نخریده» طراحی کنید، نه سکوت؛
- خروج روی خرید را جدا از Wait تعریف کنید تا کسی که خریده دوباره nurture نبیند.
SaaS ایرانی: ورکشاپ دمو بعد از ایمیل
تیم B2B SaaS ایمیل «لینک رزرو دمو» میفرستد و بعد Wait until demo_booked.
- اگر فروش قبل از ایمیل، در کالتواکشن لندینگ، دمو را رزرو کرده و بعد وارد جرنی شده: در مدل داخل Delay ممکن است تا timeout بماند مگر دوباره رزرو کند یا شرط جداگانه «اگر از قبل demo_booked است → skip» داشته باشید.
- مدل prior counts برای «اگر همین الان رزرو دارد، برو شاخهٔ آمادهسازی» مناسبتر است.
پس قبل از ساخت، یک جمله در بریف محصول بنویسید: «Wait فقط رخداد تازه را میپذیرد» یا «اگر شرط از قبل true است skip کن».
این همان already-meets-wait نیست؟
نزدیک است ولی زاویه فرق دارد:
- already meets → skip معمولاً صریح میگوید: در لحظهٔ ورود، اگر شرط برقرار است Delay را رد کن.
- event must occur while in delay صریح میگوید: فقط fire داخل بازهٔ نشستن روی Delay قبول است؛ تاریخچهٔ قبلی عمداً بیاثر است.
بعضی پلتفرمها هر دو را با یک سوئیچ پیاده میکنند؛ بعضی فقط یکی را. مهم این است که تیم شما بداند کدام را خریدهاید.
نگاشت صادقانه به Leadara
در Leadara با events، journeys، و کانالهای ایمیل/پیامک (از طریق اتصال کاوهنگار یا نیکالاین خودتان) میتوانید:
- بعد از ارسال، Wait until روی ایونت رفتار (خرید، ثبتنام، کلیک معنادار) بگذارید؛
- سقف زمانی برای Wait تعریف کنید تا مخاطب ابدی گیر نکند؛
- Exit روی conversion جداگانه بگذارید؛
- سگمنت را برای ورود و گزارش نگه دارید.
AI Chat لیدارا دستیار داخلی تیم داخل داشبورد است—نه ربات پاسخگوی مشتری در Live Chat. Live Chat برای پشتیبانی انسانی است. واتساپ یا کانکتورهای فهرستنشده را در این طراحی فرض نکنید.
برای تمایز زمانِ داخل ایونت تریگر در برابر صبر روی رفتار بعدی، ببینید: صبر تا زمان داخل Event در برابر صبر تا شرط.
کی کدام را انتخاب کنید؟
| هدف کمپین | پیشنهاد |
|---|---|
| تأیید اقدام تازه بعد از پیام (کلیک، خرید، رزرو) | رویداد باید داخل Delay |
| «اگر از قبل VIP / خریدار / رزرو شده است، مسیر کوتاه» | prior counts یا شاخهٔ Audience قبل از Wait |
| جلوگیری از گیر کردن کسانی که دیروز فرم پر کردهاند | یا prior counts، یا قبل از Wait یک شرط «اگر فرم در N روز اخیر» |
| تست پذیرش QA | دو پروفایل بسازید: یکی با ایونت قبل از ورود، یکی با ایونت بعد از ورود |
گامهای عملی قبل از انتشار جرنی
- بریف یکخطی بنویسید: فقط رخداد تازه یا تاریخچه هم قبول است؟
- دو مخاطب آزمایشی بسازید (prior event / new event).
- سقف زمانی و شاخهٔ timeout را مشخص کنید.
- Exit روی خرید/هدف را جدا از Wait تنظیم کنید.
- متن پیامک/ایمیل را طوری بنویسید که اگر باید «دوباره» اقدام کنند، شفاف باشد.
- لاگ ایونتها را از کاوهنگار/سایت تا CRM چک کنید تا تأخیر ingestion باعث اشتباه نشود.
- بعد از انتشار، گزارش «مدت ماندن روی Wait» را هفتهای یکبار ببینید.
اشتباههای رایج
- فرض اینکه «کاربر دیروز فرم را پر کرده پس باید آزاد شود» بدون خواندن docs موتور؛
- Wait بدون timeout روی ایونتی که نرخ fire پایینی دارد؛
- قاطی کردن تأخیر ثابت ۳ روز با Wait until event؛
- نداشتن شاخه برای کسانی که هرگز ایونت نمیفرستند؛
- تغییر معنای Wait وسط کمپین بدون ریتست دو پروفایل آزمایشی.
سؤالات پرتکرار
اگر کسی قبل از enrollment فرم را پر کرده، Wait-until-form او را آزاد میکند؟
در مدل «باید داخل Delay رخ بدهد» معمولاً خیر—مگر رخداد تازه بعد از ورود به Delay بیاید یا شما شاخهٔ skip-if-already-true جدا داشته باشید.
چطور timeout را با Wait ترکیب کنم؟
سقف زمانی بگذارید (مثلاً ۴۸ ساعت). اگر ایونت نیامد، به شاخهٔ «یادآوری» یا «پایان ملایم» بروید؛ مخاطب را بیصدا رها نکنید.
این همان «already meets wait → skip» است؟
خیر لزوماً. Skip-if-already-true عمداً تاریخچه/وضعیت فعلی را قبول میکند؛ must-occur-while-in-delay عمداً آن را رد میکند تا فقط اقدام تازه شمرده شود.
خرید قبل از پیامک ولی ایونت دیر رسیده چه میشود؟
اگر ایونت بعد از ورود به Delay برسد، در مدل تازه-رخداده آزاد میشود؛ اگر قبل از ورود رسیده و دیگر fire نشود، ممکن است تا timeout بماند. کیفیت زمانبندی ingestion مهم است.
برای OTP یا پیام تراکنشی چه؟
معمولاً اصلاً وارد این بحث نشوید: OTP را با Ignore FC / مسیر تراکنشی جدا بفرستید، نه با Wait nurture.
میشود قبل از Wait یک شرط «اگر از قبل خرید کرده» بگذارم؟
بله—و اغلب بهترین الگوی ترکیبی است: Audience/شرط وضعیت فعلی، بعد Wait برای کسانی که هنوز اقدام نکردهاند.
اگر وسط Delay، Exit روی خرید بخورد چه؟
مخاطب باید از nurture خارج شود؛ Wait دیگر معنا ندارد. Exit را جدی پیکربندی کنید.
گزارش به مدیر محصول را چطور خلاصه کنم؟
یک جمله: «Wait ما فقط ایونت بعد از نشستن روی Delay را میشمارد؛ دیروز فرمپرکنها تا رخداد تازه یا timeout میمانند.»
گام بعدی چیست؟
روی یک جرنی واقعی (سبد یا دمو) دو پروفایل آزمایشی prior/new بسازید، Wait را با سقف زمانی روشن کنید، و قبل از اسکیل، جدول حقیقت بالا را با تیم محصول امضا کنید. بعد سراغ تنظیم exit و پیامهای timeout بروید.
