صف تأخیری زیر سقف فرکانس در برابر حذف پیام: نگه داشتن تا آزاد شدن سقف در برابر دور انداختن
وقتی FC پر است پیام را صف کنیم یا drop؟ جدول nurture در برابر فلشسیلز، TTL بلکفرایدی، quiet hours و Leadara.
سارا مرادی
طراحی سفر مشتری و کمپینهای مارکتینگ اتومیشن برای نگهداشت کاربر و کاهش ریزش.
۵ مهر ۱۴۰۵ · 7 دقیقه مطالعه
نسخه دیگر English
صف تأخیری زیر سقف فرکانس یعنی اگر ارسال بهخاطر frequency capping (یا گاهی DND/فاصله زمانی) الان مجاز نیست، پیام برای یک پنجرهٔ قابلتنظیم نگه داشته میشود و وقتی سقف روز/هفته/ماه آزاد شد تحویل میرود؛ Drop یعنی اگر الان نتواند برود، همان ارسال دور انداخته میشود و دیگر برنمیگردد مگر جرنی دوباره به همان قدم برسد.
صف تأخیری و Drop زیر FC دقیقاً چه فرقی دارند؟
Frequency capping سقف پیام برای شخص است—نه گلوگاه لولهٔ ارسال. وقتی مخاطب امروز به سقف رسیده و جرنی میخواهد یک ایمیل nurture یا پیامک پرومو بفرستد، موتور دو رفتار رایج دارد:
- Queue-delay: ارسال را در صف میگذارد (ساعتها تا چند روز)، مرتب چک میکند آیا سقف روزانه/هفتگی/ماهانه و quiet hours اجازه میدهند؛ اگر تا TTL صف آزاد شد، میفرستد.
- Drop: همان تلاش ارسال را میکشد. پیام آن قدم از دست میرود. اگر بعداً سقف آزاد شد، خودکار برنمیگردد مگر قدم یا تریگر دیگری دوباره fire شود.
این را با گلوگاه لوله در برابر سقف شخص قاطی نکنید: rate limit از زیرساخت محافظت میکند؛ FC از رابطه با مخاطب.
جدول تصمیم: nurture در برابر فروش فلش
| سناریو | Queue-delay | Drop |
|---|---|---|
| سری nurture هفتگی (آموزش محصول) | معمولاً بهتر—محتوا هنوز مفید است اگر فردا برسد | ممکن است یک قدم آموزشی برای همیشه از دست برود |
| فلشسیلز ۶ ساعته / بلکفرایدی محدود | خطرناک—پیام دیر میرسد و کد منقضی شده | شفافتر: اگر الان جا نبود، نرو |
| بازیابی سبد با کد ۴۸ ساعته | صف کوتاه (مثلاً تا ۶–۱۲ ساعت) منطقی است | اگر TTL کد کوتاه است، drop + شاخهٔ جایگزین |
| پیام تراکنشی / شبیه OTP | اصلاً نباید زیر FC nurture بماند—مسیر Ignore FC | — |
| مخاطب در ساعات سکوت پیامک | صف تا پایان quiet hours | یا drop و فردا دوباره تلاش از قدم دیگر |
برای ساعات و روزهای ممنوع پیامک ببینید: ساعات سکوت در برابر روزهای ممنوع.
مثال فروشگاه ایرانی روی کاوهنگار
فرض کنید سقف: حداکثر ۲ پیامک پرومو در روز، ۳ در هفته. جرنی بلکفرایدی سه پیام پشتهم طراحی کرده.
- اگر Drop باشد و مخاطب صبح دو پیامک دیگر از کمپینهای موازی گرفته، پیام سوم ظهر میمیرد—حتی اگر عصر سقف آزاد شود.
- اگر Queue با TTL ۱۸ ساعت باشد، پیام سوم عصر یا شب (با رعایت quiet hours) میرود و هنوز به فروش فلش میرسد.
سؤال تیم: «TTL صف بلکفرایدی چقدر باشد؟» جواب عملی: کوتاهتر از عمر کد تخفیف و کوتاهتر از پنجرهٔ موجودی؛ مثلاً ۶–۱۲ ساعت برای فلش، ۲۴–۴۸ برای nurture عادی.
سیاست لایهای engagement
سقف ثابت برای همه گاهی بیرحم است. بعضی تیمها برای کاربران با engagement بالا سقف بالاتر میگذارند و برای خاموشها سختگیرترند—مطلب مرتبط: سیاست فرکانس لایهای در برابر سقف ثابت. Queue در کنار سقف لایهای یعنی «برای VIP صبر کن تا جا باز شود»؛ Drop برای خاموشها یعنی «اگر جا نبود، این پرومو ارزش آزار ندارد».
نگاشت به Leadara
در Leadara با journeys و ایمیل/پیامک (کاوهنگار/نیکالاین) میتوانید سقف فرکانس و پنجرههای سکوت را در طراحی کمپین در نظر بگیرید و برای پیامهای حساس مسیر جدا (تراکنشی) تعریف کنید. دقیقاً مثل هر پلتفرم، قبل از اسکیل مشخص کنید وقتی سقف پر است صف میکنید یا drop. AI Chat لیدارا دستیار داخلی تیم است، نه ربات مشتری در Live Chat. واتساپ را فرض نکنید مگر در مستندات عمومی آمده باشد.
کی صف، کی Drop؟
- ارزش پیام با تأخیر هنوز بالاست → Queue با TTL مشخص؛
- پیام فقط در پنجرهٔ کوتاه معنا دارد → Drop یا صف خیلی کوتاه؛
- پیام شبیه رسید/OTP است → خارج از FC nurture؛
- چند جرنی موازی روی یک مخاطب میزنند → اول سقف و اولویت کانال را یکی کنید، بعد صف.
گامهای پیکربندی عملی
- سقف روز/هفته/ماه را برای ایمیل و پیامک جدا بنویسید؛
- quiet hours تهران را مشخص کنید؛
- برای هر قدم ارسال، TTL صف یا سیاست drop را در بریف بیاورید؛
- در QA دو پروفایل بسازید: یکی زیر سقف، یکی آزاد؛
- بعد از کمپین، گزارش «queued / delivered / dropped» را ببینید؛
- کدهای تخفیف با عمر کوتاه را به صف طولانی نسپارید؛
- Ignore FC را فقط برای موارد واقعاً تراکنشی روشن کنید—و بدانید آیا time-gap را هم دور میزند یا نه.
اشتباههای رایج
- صف بدون TTL → پیام هفته بعد برای فروش دیروز؛
- Drop بدون شاخهٔ جایگزین → کاربر هیچ follow-up نمیبیند؛
- یک سقف برای ایمیل و پیامک بدون جداسازی کانال؛
- فرض اینکه Queue همیشه «مهربانتر» است (برای فلشسیلز نیست)؛
- روشن کردن Ignore FC روی همهٔ nurtureها.
سؤالات پرتکرار
TTL صف پیامک بلکفرایدی چقدر باشد؟
کوتاهتر از عمر کد و موجودی—اغلب ۶ تا ۱۲ ساعت؛ اگر بعد از آن رسید، بهتر drop شود تا پیام بیربط برود.
Ignore FC آیا time-gap و quiet hours را هم دور میزند؟
بستگی به پلتفرم دارد. در بریف بنویسید و در QA تست کنید؛ فرض نکنید همهٔ قفلها باز میشوند.
وقتی TTL صف تمام شود چه میشود؟
معمولاً همان ارسال drop میشود. مخاطب جلو میرود یا روی همان قدم میماند بسته به طراحی جرنی—این را صریح مشخص کنید.
Queue برای ایمیل و پیامک یکی است؟
بهتر است سیاست کانال جدا باشد؛ سقف و quiet hours پیامک سختگیرانهتر است.
اگر دو جرنی همزمان صف کنند؟
اولویت و سقف مشترک را مشخص کنید وگرنه هر دو بعد از آزاد شدن سقف پشتسرهم میرسند و تجربه خراب میشود.
Drop یعنی از جرنی خارج میشود؟
نه لزوماً—فقط آن ارسال از دست میرود. قدمهای بعدی ممکن است ادامه یابد مگر exit جدا تعریف کرده باشید.
برای بازیابی سبد کدام بهتر است؟
صف کوتاه با TTL همتراز عمر کد؛ اگر موجودی فلش است، drop شفافتر از پیام دیرهنگام است.
چطور به مدیر گزارش بدهم؟
«زیر FC یا صف با TTL میگذاریم یا drop؛ برای بلکفرایدی TTL کوتاه، برای nurture هفتگی صف بلندتر.»
گام بعدی چیست؟
برای یک جرنی واقعی nurture و یک فلشسیلز، سیاست Queue/Drop و TTL را جدا بنویسید، با دو پروفایل زیر/بالای سقف تست کنید، و quiet hours تهران را قبل از اسکیل قفل کنید.
چکلیست قبل از کمپین بزرگ
قبل از بلکفرایدی یا کمپین نوروزی، این لیست را با تیم کانال یکی کنید:
- سقف روزانه/هفتگی پیامک و ایمیل جدا نوشته شده؟
- Quiet hours تهران (مثلاً ۲۲ تا ۸) در همهٔ مسیرهای پرومو یکسان است؟
- برای هر قدم ارسال، Queue+TTL یا Drop در بریف آمده؟
- پیامهای شبیه رسید/رمز از FC nurture جدا شدهاند؟
- اگر چند جرنی موازی روی یک سگمنت میزنند، اولویت مشخص است؟
- گزارش queued/dropped بعد از ۲۴ ساعت اول کی خوانده میشود؟
- کد تخفیف عمرش از TTL صف کوتاهتر نیست؟
اگر یکی از اینها «نمیدانیم» است، اسکیل را عقب بیندازید. هزینهٔ یک پیام دیرهنگام بیربط، بیشتر از یک drop شفاف است—بهخصوص وقتی موجودی فلش تمام شده و کاربر حس اسپم میگیرد.
زبان مشترک با پشتیبانی و انبار
پشتیبانی باید بداند اگر مشتری میگوید «پیامک تخفیف نیومد»، ممکن است Drop زیر FC بوده باشد نه خطای کاوهنگار. یک جمله در دانشنامهٔ داخلی بنویسید: «اگر سقف پر باشد، پیام nurture یا صف میشود یا حذف؛ تراکنشی جداست.» انبار هم بداند پیام دیررسیده ممکن است کد منقضی نشان دهد—پس TTL صف را با عمر کد همتراز کنید.
متریکهایی که باید روی داشبورد باشد
- نرخ queued → delivered در برابر queued → expired
- فاصلهٔ زمانی میانگین صف تا ارسال
- شکایت/لغو بعد از پیامهای صفشده در برابر پیامهای فوری
- تعداد Ignore FC در هفته (باید نزدیک صفر برای nurture بماند)
این اعداد را هفتگی به مدیر محصول نشان دهید تا وسوسهٔ «همه را Ignore FC کنیم» کم شود.
