تأخیر شخصی‌سازی‌شده از Context در برابر مدت ثابت: صبر مخصوص هر کاربر از ویژگی در برابر N روز یکسان برای همه

تأخیر با مدت ثابت یعنی همه بعد از ورود به قدم، دقیقاً همان N ثانیه/دقیقه/ساعت/روز/هفته صبر می‌کنند؛ تأخیر شخصی‌سازی‌شده از Context یعنی برای هر مخاطب از یک ویژگی پروفایل یا متغیر زمینه (مثلاً product_reminder_interval یا Order_filled_time + ۳۰ روز) زمان بیدارشدن ساخته می‌شود و هر نفر روی تقویم خودش جلو می‌رود.

تأخیر شخصی‌سازی‌شده و مدت ثابت دقیقاً چه فرقی دارند؟

وقتی در جرنی بعد از خرید یا ثبت‌نام می‌نویسید «صبر کن بعد پیام بفرست»، دو معنای کاملاً متفاوت ممکن است:

1. مدت ثابت (fixed duration): از لحظهٔ ورود به Delay، تایمر یکسان برای همه شروع می‌شود—۳ روز، ۷۲ ساعت، ۲ هفته. علی و مریم اگر همزمان وارد شوند، همزمان هم بیدار می‌شوند.
2. تأخیر از Context / ویژگی شخصی: موتور از فیلد مخاطب یا متغیر زمینه می‌خواند—مثلاً فاصلهٔ یادآوری مخصوص همان SKU، یا تاریخ پرشدن سفارش به‌علاوهٔ ۳۰ روز—و برای هر نفر Deadline جدا حساب می‌کند. کسی که خمیردندان ۱۴روزه خریده زودتر یادآوری می‌گیرد از کسی که بستهٔ ۹۰روزه خریده.

سؤال پرتکرار تیم‌های ایرانی فروشگاه: «چرا همه ۳ روز بعد از خرید پیام می‌گیرند در حالی که دورهٔ مصرف محصول‌ها فرق دارد؟» جواب معمولاً این است که Delay شما ساعت یکسان است، نه تقویم replenishment.

جدول مقایسه

این را با صبر تا تاریخ پروفایل در برابر تأخیر نسبی قاطی نکنید: آنجا تاریخ ذخیره‌شده در برابر «N روز از الان» است. اینجا سؤال این است که آیا همه یک N می‌گیرند یا هر نفر N/تاریخ خودش را از Context.

همچنین با صبر تا رویداد در برابر تأخیر ثابت فرق دارد: آنجا سیگنال رفتار در برابر ساعت است؛ اینجا هر دو Delay هستند، فقط منبع عدد فرق می‌کند.

مثال ایرانی: داروخانه / consumables روی فروشگاه

فرض کنید فروشگاه مکمل و بهداشت:

1. تریگر: order_completed با خط اقلام خمیردندان / ویتامین؛
2. روی پروفایل یا Context سفارش بنویسید: refill_at = order_date + interval_days (مثلاً ۳۰ یا ۶۰ بر اساس SKU)؛
3. Delay شخصی: صبر تا refill_at؛
4. پیامک کاوه‌نگار: «به‌زودی تموم می‌شه—با کد ۱۰٪ دوباره سفارش بده»؛
5. اگر وسط راه دوباره خرید کرد → Exit روی conversion.

اگر به‌جای Context فقط ۳ روز ثابت بگذارید، پیام برای بستهٔ ۹۰روزه بی‌معنا و برای نمونهٔ کوچک خیلی دیر است. برای زمینهٔ replenishment ببینید: فلو replenishment چیست؟.

SaaS ایرانی: تمدید اشتراک و دورهٔ آزمایشی

تیم B2B:

• دورهٔ آزمایشی بعضی پلن‌ها ۷ روزه است، بعضی ۱۴؛
• مدت ثابت «۱۰ روز بعد از ثبت‌نام» برای هر دو غلط است؛
• Context یا ویژگی trial_ends_at / reminder_offset_hours Delay را درست می‌کند؛
• ایمیل «۲۴ ساعت تا پایان آزمایش» فقط وقتی معنا دارد که Deadline از پروفایل بیاید.

وقتی Context خراب است چه می‌شود؟

پلتفرم‌های بالغ (سبک Braze Personalized Delay) معمولاً برای حالت‌های خراب قانون دارند:

قبل از اسکیل، دو پروفایل بسازید: یکی با refill_at معتبر، یکی با فیلد خالی—و ببینید آیا خاموش می‌مانند یا اشتباه پیام می‌گیرند.

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

در Leadara با events، segments، journeys (تأخیر/صبر/شاخه)، و کانال‌های ایمیل/پیامک (از طریق کاوه‌نگار یا نیکالاین خودتان) می‌توانید:

• بعد از خرید، Wait/Delay نسبی ثابت بگذارید (همان N روز برای همه)؛
• یا صبر تا تاریخ/ویژگی پروفایل را برای یادآوری تقویمی نزدیک کنید (نزدیک‌ترین الگوی personalised-from-attribute)؛
• سگمنت «نزدیک به اتمام دورهٔ مصرف» بسازید و از ورود سگمنت تریگر بگیرید اگر Delay context-native غنی‌تر در موتور رقیب دیدید؛
• Exit روی خرید مجدد جداگانه بگذارید.

اگر رقیب Delay Context متغیر داخل Canvas غنی‌تری دارد، صادق بمانید: Leadara را با ترکیب ویژگی تاریخ + wait-until-date / سگمنت زمانی + پیامک/ایمیل نزدیک کنید، نه با ادعای یک‌به‌یک همهٔ سوئیچ‌های Braze.

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

کی کدام را انتخاب کنید؟

گام‌های عملی قبل از انتشار

1. بریف یک‌خطی: «همه N روز» یا «هر نفر از فیلد X»؟
2. منبع Context را مشخص کنید (سفارش، SKU table، پروفایل).
3. قانون تاریخ گذشته / خالی / خیلی دور را بنویسید.
4. دو پروفایل QA با interval متفاوت بسازید.
5. پیامک/ایمیل را طوری بنویسید که با تاریخ واقعی جور باشد («۳ روز بعد از خرید» را کور ننویسید اگر Context ۳۰روزه است).
6. Exit روی خرید مجدد را جدا تنظیم کنید.
7. بعد از انتشار، توزیع «مدت واقعی ماندن روی Delay» را هفته‌ای یک‌بار ببینید—اگر همه روی یک قله‌اند، احتمالاً هنوز ثابت می‌فرستید.

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

• گذاشتن ۳ روز ثابت روی همهٔ SKUهای consumable؛
• Context را در بریف نوشتن ولی در CRM پر نکردن؛
• ندیدن تایم‌زون تهران در برابر UTC؛
• نبود شاخه برای Context نامعتبر؛
• قاطی کردن Wait-until-event با Personalized Delay.

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

اگر تاریخ Context از قبل گذشته باشد چه می‌شود؟

در بسیاری از موتورها مخاطب از آن Delay خارج می‌شود یا به شاخهٔ «دیر شد» می‌رود—فرض نکنید خودکار «فردا» می‌فرستد. صریح تست کنید.

تایم‌زون مخاطب مهم است یا شرکت؟

بستگی به پلتفرم دارد. برای پیامک ایران معمولاً تقویم/ساعت تهران را در بریف قفل کنید و در QA با دو پروفایل چک کنید.

کی هنوز ۳ روز ثابت بهتر است؟

وقتی محتوا به تقویم مصرف وصل نیست—مثلاً آموزش محصول بعد از خرید، یا فاصلهٔ کوتاه بین دو ایمیل nurture.

می‌شود Fallback به مدت ثابت داشت؟

بله و اغلب عاقلانه است: اگر refill_at خالی بود، ۷ روز ثابت؛ وگرنه همان تاریخ Context.

این همان wait-until-date-property است؟

نزدیک است. Personalized-from-context می‌تواند «تاریخ مطلق» یا «interval ذخیره‌شده + الان» باشد؛ wait-until-date-property معمولاً روی فیلد تاریخ پروفایل قفل است. مطلب مرتبط را بالا ببینید.

برای بلک‌فرایدی هم Context لازم است؟

برای یادآوری «شروع حراج ساعت X» بیشتر تقویم کمپین مهم است تا interval شخصی. Context برای replenishment و تمدید می‌درخشد.

آیا AI Chat لیدارا این Delay را خودکار می‌سازد؟

خیر به‌عنوان ربات مشتری. AI Chat دستیار داخلی تیم است؛ طراحی جرنی و قوانین Context با خودتان است.

گزارش به مدیر محصول را چطور خلاصه کنم؟

یک جمله: «Delay ثابت همه را N روز نگه می‌دارد؛ Delay از Context هر نفر را روی تاریخ/فاصلهٔ خودش بیدار می‌کند—و بدون دادهٔ تمیز می‌شکند.»

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

روی یک دستهٔ consumable واقعی، فیلد refill_at یا interval را از سفارش پر کنید، Delay را از حالت ۳روزهٔ ثابت دربیاورید، دو پروفایل QA بسازید، و قبل از اسکیل قانون تاریخ گذشته را با تیم محصول امضا کنید. بعد سراغ کپی پیامک و Exit خرید بروید.

سناریوی ترکیبی: ثابت کوتاه + Context بلند

گاهی بهترین طراحی دو Delay پشت‌سرهم نیست؛ دو مسیر موازی است:

1. مسیر ثابت ۲۴–۴۸ ساعته: ایمیل/پیامک «رسید سفارش / راهنمای استفاده»—برای همه یکسان.
2. مسیر Context replenishment: جدا، با refill_at، بدون قاطی کردن با nurture کوتاه.

این کار دو فایده دارد: کپی کوتاه را قربانی تاریخ ۳۰روزه نمی‌کنید، و اگر Context خراب بود فقط مسیر replenishment می‌میرد نه کل تجربهٔ بعد از خرید.

دادهٔ SKU را کجا نگه دارید؟

• جدول محصول در فروشگاه با default_interval_days؛
• در ایونت order_completed خط‌به‌خط interval را به پروفایل یا Context سفارش بنویسید؛
• اگر چند قلم consumable در یک سفارش است، یا طولانی‌ترین interval را بگیرید یا per-line journey جدا—در بریف یکی را انتخاب کنید و قاطی نکنید.

معیار موفقیت بعد از لانچ

• توزیع روزهای ماندن روی Delay باید چندقله‌ای باشد (۱۴ / ۳۰ / ۶۰)، نه یک قلهٔ روز۳؛
• نرخ خرید مجدد در پنجرهٔ ±۷ روز اطراف refill_at را با گروه ثابت ۳روزه مقایسه کنید؛
• درصد Exit به‌خاطر Context نامعتبر را زیر ۵٪ نگه دارید؛ بالاتر یعنی داده کثیف است نه کپی بد.

مطالب مرتبط

• صبر تا تاریخ پروفایل در برابر تأخیر نسبی
• صبر تا رویداد در برابر تأخیر ثابت: توقف برای سیگنال در برابر توقف برای ساعت
• فلو replenishment چیست؟ یادآوری سفارش قبل از تمام‌شدن محصول