صبر تا تاریخ پروفایل در برابر تأخیر نسبی: روز تولد/تمدید در برابر «۳ روز صبر کن»
Wait تا فیلد تاریخ (On/Before/After) یا delay نسبی؟ جدول، مثال تمدید اشتراک ایرانی، شاخهٔ تاریخ خالی و Leadara.
رضا احمدی
بهینهسازی سایت و محتوا برای گوگل؛ افزایش ترافیک ارگانیک و دیدهشدن برند در نتایج جستجو.
۵ مهر ۱۴۰۵ · 6 دقیقه مطالعه
نسخه دیگر English
صبر تا تاریخ پروفایل یعنی اقدام بعدی با یک فیلد تقویم/datetime ذخیرهشده همتراز میشود (همان روز، N روز قبل، یا N روز بعد—با ساعت اختیاری و شاخهٔ تاریخ نامشخص)؛ تأخیر نسبی یعنی همه بهاندازهٔ یکسان N روز/ساعت صبر میکنند، صرفنظر از تولد یا تاریخ تمدید شخصیشان.
صبر تا تاریخ پروفایل و تأخیر نسبی چه فرقی دارند؟
دو ابزار صبر در جرنی که زیاد با هم اشتباه گرفته میشوند:
- Wait until date property: مثلاً
birthday،subscription_ends_at،policy_renewal_date. موتور صبر میکند تا «روز رویداد»، یا ۳ روز قبل، یا ۱ روز بعد—گاهی با time-of-day. اگر فیلد خالی باشد، باید شاخهٔ unknown داشته باشید. - Relative duration: «۳ روز صبر کن» بعد از خرید یا بعد از ایمیل. برای همه یکسان است؛ کاری به تقویم شخصی ندارد.
سؤال کلاسیک: «ایمیل تولد بفرستم یا همان drip سهروزه؟» جواب: تولد = date property؛ drip بعد از خرید = relative.
مرتبط ولی متفاوت: فلو تاریخ پروفایل در برابر فلو رویداد رفتار—آنجا کل تریگر فلو است؛ اینجا قدم Wait داخل جرنی است.
جدول On / Before / After
| حالت | معنی عملی | مثال ایرانی |
|---|---|---|
| On date | روز خودِ فیلد (با یا بدون ساعت) | پیامک تبریک همان روز تولد ساعت ۱۰ |
| Before N days | N روز قبل از فیلد | ۳ روز قبل از پایان اشتراک، ایمیل تمدید |
| After N days | N روز بعد از فیلد | ۱ روز بعد از تمدید، پیام تشکر |
| Unknown / empty | فیلد خالی یا نامعتبر | شاخهٔ «تاریخ بپرس» یا خروج ملایم |
| Timezone | منطقه زمانی مخاطب یا حساب | تهران در برابر مسافر خارج |
تأخیر نسبی را با «فقط روزهای کاری» هم قاطی نکنید—آن بحث جداست و به تأخیر تا روز هفته در برابر N روز ثابت نزدیکتر است. برای صبر روی سیگنال زنده در برابر ساعت ثابت ببینید: صبر تا رویداد در برابر تأخیر ثابت.
مثال بیمه و اشتراک ایرانی
بیمه / اشتراک SaaS: فیلد renewal_date روی پروفایل.
- ۷ روز قبل: ایمیل «تمدید نزدیک است»؛
- ۱ روز قبل: پیامک کاوهنگار یادآوری؛
- روز بعد از تمدید موفق: پیام تشکر؛
- اگر
renewal_dateخالی است: جرنی وارد شاخهٔ «تاریخ را تکمیل کن» میشود، نه اینکه تا ابد صبر کند.
فروشگاه: بعد از خرید، relative wait ۳ روز → درخواست نظر؛ تولد مشتری جدا با date property.
اگر وسط صبر تا تولد، کاربر تاریخ تولد را عوض کند، بعضی موتورها ارسال را جابهجا میکنند و بعضی همان زمان ورود را فریز میکنند—این را در QA بنویسید.
نگاشت به Leadara
در Leadara با پروفایل/سگمنت، journeys و ایمیل/پیامک میتوانید برای تاریخهای ذخیرهشده (تمدید، تولد) و برای تأخیر نسبی بعد از ایونت خرید مسیر جدا طراحی کنید. شاخهٔ تاریخ خالی را فراموش نکنید. AI Chat لیدارا دستیار داخلی تیم است، نه ربات مشتری Live Chat. واتساپ را اختراع نکنید.
کی کدام را انتخاب کنید؟
| هدف | انتخاب |
|---|---|
| تولد، سالگرد، تمدید، سررسید قسط | Date property (On/Before/After) |
| Drip بعد از خرید / بعد از ثبتنام | Relative duration |
| فقط شنبه و دوشنبه ارسال | Weekday delay (مطلب مرتبط) |
| صبر تا کلیک/خرید | Wait until event |
گامهای عملی
- فیلد تاریخ را در پروفایل استاندارد کنید (نام، timezone، فرمت)؛
- برای خالیها شاخه تعریف کنید؛
- On/Before/After و ساعت ارسال تهران را بنویسید؛
- یک تست با تغییر تاریخ وسط Wait؛
- Relative drip را از کمپین تقویمی جدا نگه دارید؛
- خروج روی تمدید موفق را جدا بگذارید تا پیام تکراری نرود؛
- بعد از ماه اول، نرخ «تاریخ خالی» را گزارش کنید.
اشتباههای رایج
- ایمیل تولد با delay ثابت ۳ روز از ورود به سگمنت (همه یک روز میگیرند)؛
- نبود شاخهٔ unknown؛
- فرض اینکه تغییر birthday وسط Wait همیشه reschedule میشود؛
- قاطی کردن business-days با date property؛
- یک جرنی هم relative هم birthday بدون جداسازی متریک.
سناریوی قدمبهقدم تیم رشد
- سگمنت «اشتراک فعال با renewal_date پر»؛
- ورود ۳۰ روز قبل از تمدید (یا Wait until before 7 days اگر مدل Wait دارید)؛
- ایمیل ارزش تمدید؛
- پیامک ۱ روز قبل؛
- اگر تمدید کرد → exit؛
- اگر نکرد → relative wait ۲ روز + پیشنهاد آخر؛
- پایان یا سگمنت follow-up انسانی.
سؤالات پرتکرار
اگر تاریخ پروفایل خالی باشد چه؟
باید شاخهٔ unknown داشته باشید: درخواست تکمیل، خروج، یا مسیر پیشفرض. صبر ابدی ممنوع.
تغییر birthday وسط Wait ارسال را جابهجا میکند؟
پلتفرممحور است. دو پروفایل بسازید—یکی ثابت، یکی تغییر تاریخ—و رفتار را در runbook بنویسید.
کی از business-days-only استفاده کنم؟
وقتی تیم پشتیبانی فقط روزهای کاری پاسخ میدهد یا پیام نباید جمعه شب برود؛ این جایگزین date property تولد نیست.
Timezone چطور فریز میشود؟
بعضی موتورها timezone را در ورود به Delay قفل میکنند. برای مخاطب مسافر تست کنید.
Relative و date را پشتسرهم بگذارم؟
بله: مثلاً بعد از خرید ۳ روز relative، بعد جداگانه جرنی تولد سالانه با date property.
برای قسط وام کدام؟
Date property سررسید + Before N برای یادآوری؛ relative فقط برای پیگیری بعد از نپرداختن ایونت.
پیامک تبریک ساعت چند؟
On date با time-of-day (مثلاً ۱۰:۰۰ تهران) بهتر از نیمهشب است—quiet hours را رعایت کنید.
خلاصه برای مدیر؟
«تولد و تمدید را به فیلد تاریخ میبندیم؛ drip خرید را با تأخیر نسبی. تاریخ خالی شاخهٔ جدا دارد.»
گام بعدی چیست؟
یک فیلد renewal_date یا birthday را پاکسازی کنید، شاخهٔ unknown بسازید، و یک جرنی On/Before را با relative drip بعد از خرید مقایسه و جدا منتشر کنید.
پاکسازی داده قبل از جرنی تقویمی
قبل از روشن کردن Wait روی birthday یا renewal_date:
- درصد پروفایلهای با تاریخ خالی را اندازه بگیرید؛
- فرمتهای درهم (رشته، timestamp، شمسی/میلادی) را یکی کنید؛
- تاریخهای غیرواقعی (۱۱۹۰ یا سال آیندهٔ اشتباه) را فیلتر کنید؛
- timezone پیشفرض تهران را مستند کنید؛
- مالک داده (پشتیبانی، خودکار از درگاه پرداخت) را مشخص کنید.
بدون این پاکسازی، جرنی تقویمی بیشتر از آنکه بفروشد، پشتیبانی میسازد.
دو جرنی جدا، دو داشبورد جدا
جرنی تولد/تمدید را از drip نسبی بعد از خرید جدا نگه دارید. متریکها قاطی میشوند اگر یک نفر همان هفته هم پیام «۳ روز بعد از خرید» بگیرد هم «۷ روز تا تمدید». در گزارش هفتگی دو ردیف جدا: Calendar waits در برابر Relative drips.
متن پیامک نمونه (کاوهنگار)
- Before 3 days: «اشتراکت سه روز دیگه تموم میشه—تمدید از لینک…»
- On date birthday: «تولدت مبارک؛ یک هدیه کوچک داخل حسابته»
- Relative +3 after purchase: «اگر از خریدت راضی بودی، یک جمله برامون بنویس»
ساعت ارسال را با quiet hours هماهنگ کنید؛ تبریک نیمهشب تجربه را خراب میکند.
