شرط پیام در Wait-until: «هرگز ارسال شده» در برابر «بعد از ورود به Wait ارسال میشود»
Has-ever با رسید کهنه Wait را skip میکند؛ is-after-entry فقط ارسال بعد از ورود را میشمارد. تایملاین، جدول، نگاشت Leadara.
نیلوفر کریمی
جایگاهیابی محصول، پیامگذاری و تولید محتوا برای رشد محصول؛ هماهنگی با تیم محصول و فروش.
۸ مهر ۱۴۰۵ · 6 دقیقه مطالعه
نسخه دیگر English
شرط has-ever میتواند با سابقه قدیمی Wait را همان لحظه رد کند؛ شرط is-after-entry فقط وقتی resolve میشود که همان پیام بعد از ورود شخص به Wait ارسال شود—پس رسید تراکنشی ماه قبل نباید مسیر follow-up را تصادفی باز کند.
شرط پیام در Wait-until دقیقاً چه میگوید؟
قدم Wait until … message sent / delivered را تصور کنید: میخواهید بعد از اینکه ایمیل «راهنمای شروع» رفت، ۲۴ ساعت بعد پیامک یادآوری بفرستید—یا شاخه «اگر همان ایمیل رفت» را باز کنید.
دو تفسیر رایج از «پیام ارسال شده»:
- Has-ever (هرگز/قبلاً در تاریخچه): اگر آن پیام (یا کمپین/قالب همنام) هر زمانی در گذشته برای این مخاطب ارسال شده باشد، شرط همین حالا true است و Wait ممکن است فوراً skip شود.
- Is-after-entry (بعد از ورود به Wait): فقط ارسالهایی که بعد از رسیدن شخص به این قدم Wait رخ دهند شمرده میشوند. رسید ماه قبل بیاثر است.
اگر has-ever را برای follow-up آموزشی بعد از سفارش بگذارید، کسی که ماه پیش رسید خرید گرفته ممکن است امروز Wait را رد کند و SMS آموزش را بدون ایمیل تازه بگیرد—یا بدتر، مسیر را با سیگنال کهنه باز کند.
مرتبط: صبر تا رویداد در برابر تأخیر ثابت، صبر با سقف زمانی، و رویداد باید داخل Delay رخ بدهد.
جدول مقایسه
| بعد | Has-ever | Is-after-entry |
|---|---|---|
| سابقه ماه قبل | میتواند کافی باشد | نادیده گرفته میشود |
| Skip فوری Wait | رایج اگر تاریخچه مثبت باشد | فقط اگر همان لحظه بعد از ورود ارسال شود |
| مناسب برای | «اگر تا به حال این آموزش را گرفته…» | «صبر کن تا همین ایمیل این مسیر ارسال شود» |
| ریسک | باز شدن مسیر با سیگنال کهنه | اگر Send قبل از Wait باشد و دیگر تکرار نشود، ممکن است گیر کنید |
| QA لازم | پروفایل با ارسال قدیمی | پروفایل تمیز + پروفایل با ارسال قدیمی |
تایملاین: رسید سفارش در برابر ایمیل آموزش
| زمان | رویداد | Has-ever روی «ایمیل رسید» | Is-after-entry روی «ایمیل آموزش onboarding» |
|---|---|---|---|
| ۱ مرداد | رسید سفارش ارسال شد | تاریخچه مثبت | — |
| ۱ شهریور | ورود به جرنی آموزش بعد از خرید دوم | Wait فوراً skip میشود اگر شرط روی رسید باشد | صبر میکند |
| ۱ شهریور ۱۰:۰۵ | ایمیل آموزش این مسیر ارسال میشود | — | شرط true → ادامه |
| ۱ شهریور فردا | SMS یادآوری آموزش | ممکن است بدون ایمیل تازه برود | بعد از ایمیل تازه میرود |
درس: برای follow-up وابسته به همین ارسال، is-after-entry (یا معادل «باید داخل پنجره Wait رخ دهد») را بخواهید—نه has-ever روی قالب رسید.
مثال دوم: پیامک OTP در برابر پیامک پرومو
اگر Wait را روی «هر SMS ارسالشده» با has-ever بگذارید، OTP دیروز ممکن است شرط را true کند. دامنه شرط را به همان message/template مسیر محدود کنید و ترجیحاً after-entry.
چرا تیمها گیج میشوند؟
- UI فقط میگوید «message sent» بدون scope زمانی؛
- نام قالب با کمپین قدیمی یکی است و has-ever کل تاریخچه را میبیند؛
- Send قبل از Wait قرار گرفته و با is-after-entry دیگر آتش نمیگیرد—ترتیب قدمها مهم است؛
- قاطی کردن با «event must occur while in delay» برای رویدادهای رفتاری غیرپیام.
نگاشت صادقانه به Leadara
با Leadara journeys، events و ایمیل/پیامک:
- Wait-until را روی رویداد/وضعیت مرتبط با ارسال یا engagement پیام طراحی کنید؛
- در بریف صریح بنویسید: «سابقه تاریخی کافی است یا فقط ارسال بعد از ورود به Wait»؛
- برای مسیرهای post-purchase آموزشی، از سیگنال کهنه رسید برای باز کردن follow-up استفاده نکنید؛
- با سقف زمانی Wait (مطلب time-capped) ترکیب کنید تا has-ever غلط باعث گیر ابدی یا skip اشتباه نشود.
اگر موتور رقیب برچسب has ever / is را دارد و Leadara همان لیبل را ندارد، الگوی عملی را با رویدادهای scoped و ترتیب Send→Wait مستند کنید—ادعای سوئیچ یکبهیک نکنید.
AI Chat لیدارا دستیار داخلی است. Live Chat پشتیبانی انسانی است.
کی has-ever، کی after-entry؟
| سناریو | پیشنهاد |
|---|---|
| Follow-up فقط بعد از ایمیل همین مسیر | Is-after-entry |
| شاخه «قبلاً این سری را دیده» | Has-ever (عمدی) |
| بعد از رسید تراکنشی ماهها پیش | Has-ever خطرناک است |
| Send قبل از Wait در همان مسیر | ترتیب را درست کنید؛ after-entry به Send بعد از ورود نیاز دارد |
| تردید در docs موتور | هر دو پروفایل QA را اجباری کنید |
گامهای عملی
- در بریف یک خط: «Wait برای پیام X = after entry / has-ever».
- مشخص کنید X کدام template/campaign است—نه «هر ایمیلی».
- ترتیب قدم: ورود → (اختیاری delay) → Send X → Wait until X after entry → Send Y.
- QA: پروفایل با ارسال قدیمی X؛ پروفایل تمیز؛ پروفایل که X بعد از ورود میگیرد.
- لاگ skip فوری Wait را بعد از لانچ بخوانید.
- Quiet hours را جدا ثبت کنید تا با skip شرطی قاطی نشود.
- اگر has-ever لازم است، در کپی داخلی مسیر بنویسید «عمداً تاریخی».
اشتباههای رایج
- has-ever پیشفرض بدون خواندن docs؛
- شرط روی «هر پیام» بهجای همان قالب؛
- Send را بعد از Wait گذاشتن و انتظار after-entry بدون ارسال؛
- نادیده گرفتن پروفایل با تاریخچه تراکنشی سنگین (فروشگاههای پرتکرار سفارش).
سؤالات پرتکرار
چرا مخاطب Wait «ایمیل ارسال شد» را skip کرد؟
احتمالاً has-ever با ارسال قدیمی true شده، یا ترتیب قدمها باعث شده شرط از قبل برقرار باشد.
آیا Wait-until شرط پیام، ارسالهای تاریخی را میشمارد؟
بستگی به scope دارد: has-ever بله؛ is-after-entry خیر. در بریف قفل کنید.
کی has-ever و کی is-sent after entry؟
Follow-up وابسته به ارسال همین مسیر → after-entry. شاخه «قبلاً دیده» → has-ever عمدی.
اگر ایمیل قبل از رسیدن به Wait ارسال شده باشد؟
برای after-entry معمولاً کافی نیست مگر دوباره ارسال شود. ترتیب Send و Wait را اصلاح کنید.
این همان «رویداد باید داخل Delay رخ بدهد» است؟
ایده خویشاوند است؛ آنجا بیشتر رویداد رفتار کاربر است، اینجا scope ارسال پیام.
آیا Live Chat لیدارا این را توضیح میدهد؟
Live Chat پشتیبانی انسانی است. طراحی Wait کار تیم شماست؛ AI Chat فقط دستیار داخلی است.
با سقف زمانی چه کنیم؟
اگر شرط after-entry هرگز true نشود، از Wait time-capped برای مسیر جایگزین استفاده کنید.
معیار موفقیت؟
نزدیکصفر بودن skip ناشی از رسید کهنه، و اینکه SMS یادآوری فقط بعد از ایمیل تازه همان مسیر برود.
گام بعدی چیست؟
یک جرنی post-purchase که Wait روی پیام دارد باز کنید. دو پروفایل بسازید: یکی با رسید قدیمی، یکی تمیز. ببینید Wait skip میشود یا نه. نتیجه را در بریف بهعنوان has-ever یا after-entry قفل کنید و ترتیب Send را درست کنید.
