چند پوش نوتیفیکیشن ارسال کنیم؟ تعیین سقف و Frequency Cap
پاسخ کوتاه: عدد ثابتی مثل «روزانه یک پوش» یا «سه پوش در روز» برای همه سایت‌ها درست نیست. سقف مناسب به نوع پیام، انتظار کاربر، منطقه زمانی، تعداد اشتراک‌های فعال و داده‌هایی مانند کلیک، تبدیل و لغو اشتراک بستگی دارد. Frequency Cap یا «سقف دفعات ارسال» باید یک سیاست قابل‌آزمایش باشد، نه عددی که بدون توجه به زمینه برای همه کاربران اعمال شود.
در این مقاله:
- Frequency Cap دقیقاً چیست؟
- چه چیزی را باید بشماریم؟
- اولویت پیام‌های تراکنشی و تبلیغاتی
- ساعات سکوت و لغو ارسال
- طراحی یک سیاست اجرایی
- تعیین سقف با داده و آزمایش
- پرسش‌های متداول
در این مقاله، منظور از سقف، تعداد پیام‌هایی است که یک کاربر یا اشتراک در یک بازه زمانی دریافت می‌کند. اگر یک کاربر روی چند مرورگر یا دستگاه عضو شده باشد، شمارش در سطح اشتراک ممکن است با شمارش در سطح فرد تفاوت داشته باشد؛ بنابراین پیش از تعیین عدد، واحد شمارش را مشخص کنید.
Frequency Cap دقیقاً چیست؟
Frequency Cap محدودیتی است که می‌گوید هر واحد مخاطب، در یک بازه مشخص، چند پیام می‌تواند دریافت کند. این بازه می‌تواند روزانه، هفتگی یا شناور باشد؛ برای نمونه، «حداکثر دو پیام تبلیغاتی در هفت روز گذشته». بازه شناور معمولاً از جهش ناگهانی ارسال در ابتدای هر روز جلوگیری می‌کند، اما پیاده‌سازی و توضیح آن به تیم محصول نیازمند دقت بیشتری است.
سقف دفعات با مفاهیمی مانند حذف رویداد تکراری، جایگزینی پیام‌های معلق و زمان انقضای پیام یکی نیست. سقف دفعات، فشار کلی پیام‌رسانی را کنترل می‌کند؛ درحالی‌که حذف تکرار از ارسال دوباره یک رویداد جلوگیری می‌کند. همچنین collapse_id در بعضی مسیرهای ارسال می‌تواند پیام‌های در انتظار انتقال را با هم ادغام کند، اما رفتار آن در همه پلتفرم‌ها یکسان نیست و نباید آن را معادل جایگزینی قطعی اعلان‌های نمایش‌داده‌شده دانست.
در سرویس‌هایی مانند پوشفا، گزارش‌های ارسال و کلیک می‌توانند بخشی از داده تصمیم‌گیری باشند؛ بااین‌حال، ثبت تحویل به‌تنهایی نشان نمی‌دهد کاربر پیام را خوانده یا اقدامی انجام داده است. سیاست سقف باید بر اساس هدف واقعی کمپین و کیفیت تجربه کاربر ارزیابی شود.
چه چیزی را باید بشماریم؟
پیش از انتخاب عدد، این چهار پرسش را پاسخ دهید:
- واحد شمارش چیست؟ کاربر، اشتراک مرورگر، دستگاه یا شناسه دیگری؟ اگر اتصال چند اشتراک به یک کاربر را نمی‌توانید با اطمینان انجام دهید، ادعای «سقف برای هر کاربر» نکنید و آن را در سطح اشتراک اجرا کنید.
- کدام پیام‌ها شمرده می‌شوند؟ پیام تبلیغاتی، محتوایی، یادآوری، خدماتی و تراکنشی را جدا کنید.
- مبنای شمارش چیست؟ تلاش برای ارسال، پذیرش از سوی سرویس، تأیید نمایش اعلان یا کلیک؟ این رویدادها را در گزارش‌ها به جای یکدیگر ننویسید.
- بازه و منطقه زمانی کدام است؟ «روزانه» بدون تعیین منطقه زمانی می‌تواند برای کاربری در یک کشور، نیمه‌شب یا ساعات نامناسب باشد.
یک جدول تصمیم داخلی بسازید و برای هر نوع پیام، هدف، اولویت، بازه شمارش و اقدام هنگام عبور از سقف را ثبت کنید. این مستند از اجرای پراکنده محدودیت در پنل، کدهای مختلف و کمپین‌های دستی جلوگیری می‌کند.
اولویت پیام‌های تراکنشی و تبلیغاتی
همه پیام‌ها ارزش و فوریت یکسان ندارند. پیام تراکنشی معمولاً بخشی از یک فرایند آغازشده توسط کاربر است؛ مانند تغییر وضعیت سفارش یا هشدار مربوط به عملی که کاربر درخواست کرده است. پیام تبلیغاتی برای ایجاد تقاضای جدید ارسال می‌شود. این دو گروه را در یک سهمیه ساده ادغام نکنید، چون ممکن است یک کمپین تبلیغاتی، پیام مهم‌تر را مسدود کند.
یک مدل پیشنهادی برای تصمیم‌گیری چنین است:
| نوع پیام | اولویت | اقدام پیشنهادی هنگام هم‌زمانی |
|---|---|---|
| تراکنشی یا امنیتی | بالا | در صورت ضرورت ارسال شود؛ متن و زمان را دوباره بررسی کنید. |
| یادآوری مرتبط با اقدام کاربر | متوسط تا بالا | با توجه به تازگی رویداد و رضایت کاربر ارسال یا به زمان مناسب موکول شود. |
| محتوایی یا آموزشی | متوسط | با سقف محتوایی جداگانه و بر اساس علاقه‌مندی ارسال شود. |
| تبلیغاتی عمومی | پایین‌تر | در صورت رسیدن به سقف، حذف یا جایگزین شود؛ نباید از مسیر استثنا استفاده کند. |
مثلاً فرض کنید کاربر هم در گروه دریافت پیشنهاد عمومی قرار دارد و هم منتظر موجودشدن کالایی است که قبلاً به آن علاقه نشان داده است. به‌جای ارسال هر دو پیام، پیام موجودشدن کالا را انتخاب کنید و کمپین عمومی را برای این اشتراک کنار بگذارید. این تصمیم یک نمونه فرضی از «انتخاب پیام مرتبط‌تر» است، نه یک قاعده اجباری برای همه کسب‌وکارها.
برای طراحی سگمنت‌ها و جلوگیری از رقابت کمپین‌ها، می‌توانید راهنمای سگمنت‌بندی پوش نوتیفیکیشن را هم بررسی کنید.
ساعات سکوت و لغو ارسال
ساعات سکوت، بازه‌ای است که پیام‌های غیرضروری در آن ارسال نمی‌شوند. این بازه باید بر اساس منطقه زمانی مخاطب ذخیره شود، نه فقط ساعت سرور. اگر مخاطبان در چند منطقه هستند، زمان محلی هر اشتراک یا منطقه انتخاب‌شده توسط کاربر را مبنا قرار دهید.
ساعات سکوت نباید بهانه‌ای برای ارسال هر پیام در هر زمان دیگر باشد. برای پیام‌های تبلیغاتی، زمان مجاز و شرایط لغو را روشن کنید. برای پیام‌های تراکنشی، به‌جای استثناهای نامحدود، فهرست کوتاهی از رویدادهای واقعاً ضروری تعریف کنید. اگر رویداد در زمان سکوت رخ داد، گزینه‌هایی مانند تعویق تا پایان سکوت، تجمیع چند رویداد یا لغو پیام منقضی‌شده را در سمت سرور بررسی کنید.
هنگام تعویق، ارزش پیام را در زمان ارسال دوباره بسنجید. برای نمونه، یادآوری فروش یک‌روزه ممکن است پس از پایان فروش بی‌معنا باشد. TTL یا زمان حیات، تضمین ذخیره‌سازی نامحدود پیام نیست؛ در سامانه‌های انتقال، پیام آفلاین ممکن است پس از پایان مهلت دیگر قابل تحویل نباشد. توضیح فنی بیشتر درباره این موضوع در مقاله وب پوش در حالت آفلاین و TTL آمده است.
لغو اشتراک نیز یک سیگنال مهم است. اگر با وجود ارسال کم، لغو اشتراک زیاد است، فقط سقف را پایین نیاورید؛ موضوع پیام، وعده‌ای که هنگام عضویت داده‌اید، کیفیت صفحه مقصد و روش درخواست اجازه را نیز بررسی کنید. برای تشخیص این عوامل، دلایل لغو اشتراک وب پوش می‌تواند نقطه شروع مناسبی باشد.
طراحی یک سیاست اجرایی
سیاست را ابتدا به‌صورت فرضیه بنویسید و سپس در گروهی مشخص اجرا کنید. نمونه زیر فقط یک الگوی فرضی است:
- پیام‌های تبلیغاتی عمومی: یک سقف مستقل و محافظه‌کارانه در بازه هفتگی.
- پیام‌های محتوایی: شمارش جداگانه بر اساس موضوعات مورد علاقه.
- یادآوری اقدام نیمه‌تمام: یک یا چند تلاش محدود، با بررسی تازگی رویداد.
- پیام تراکنشی ضروری: خارج از سهمیه تبلیغاتی، اما با ثبت دلیل و کنترل تکرار.
- ساعات سکوت: اعمال در منطقه زمانی اشتراک، مگر برای رویدادهای ضروری تعریف‌شده.
این مثال عمداً عدد عمومی ارائه نمی‌کند، زیرا مقدار مناسب به داده و نوع محصول بستگی دارد. هنگام اجرا، برای هر تصمیم این موارد را ثبت کنید: شناسه کمپین، نوع پیام، زمان ایجاد رویداد، زمان ارسال، وضعیت سقف، دلیل ارسال یا حذف، و نسخه متن. اگر سیاست در سمت سرور پیاده می‌شود، پیش از فراخوانی ارسال، شمارنده و وضعیت عضویت را بررسی کنید؛ از اتکا به حافظه مرورگر یا کد سمت کاربر برای نگهداری اسرار و تصمیم نهایی ارسال خودداری کنید.
همچنین مرز مسئولیت‌ها را روشن کنید. تنظیمی که در یک کمپین دستی انجام می‌شود لزوماً تمام مسیرهای خودکار یا API را پوشش نمی‌دهد. فهرست مسیرهای ارسال را مستند کنید و برای هرکدام مشخص کنید Frequency Cap در کجا اعمال می‌شود. این کار از دورزدن ناخواسته سقف توسط یک جریان خودکار جلوگیری می‌کند.
تعیین سقف با داده و آزمایش
برای تغییر سقف، یک گروه مقایسه یا دست‌کم دو بازه زمانی قابل‌مقایسه تعریف کنید. تنها به نرخ کلیک نگاه نکنید؛ کلیک بیشتر ممکن است با لغو اشتراک، شکایت، کاهش تبدیل نهایی یا افت کیفیت تجربه همراه باشد. معیارها را به‌ازای هر اشتراک و در کنار تعداد پیام‌های دریافتی تحلیل کنید.
- نرخ کلیک و اقدام نهایی روی صفحه مقصد
- لغو اشتراک و تغییر وضعیت اجازه دریافت
- نسبت پیام‌های حذف‌شده به‌دلیل سقف یا هم‌زمانی
- فاصله زمانی میان پیام‌ها و زمان واکنش
- عملکرد هر نوع پیام، سگمنت و منطقه زمانی
برای مثال فرضی، اگر افزایش سقف در گروهی باعث کلیک بیشتر اما لغو اشتراک قابل‌توجه شود، نتیجه را موفقیت قطعی تلقی نکنید. ممکن است نسخه متن، زمان ارسال یا صفحه مقصد عامل اصلی باشد. تغییر را مرحله‌ای انجام دهید، یک متغیر را در هر آزمایش تغییر دهید و قبل از تعمیم، اثر آن را در چند بازه بررسی کنید.
ثبت UTM برای مقایسه کمپین‌ها مفید است، اما پارامترهای URL نباید حاوی اطلاعات شخصی باشند. نام کمپین، منبع و محتوای پیام را به‌شکل سازگار ثبت کنید و اطلاعات هویتی را در آدرس صفحه قرار ندهید. برای تحلیل عملکرد کلی، به راهنمای تحلیل عملکرد پوش نوتیفیکیشن مراجعه کنید.
پرسش‌های متداول
آیا یک پوش در روز برای همه مناسب است؟
خیر. یک پیام تراکنشی ضروری با یک پیشنهاد تبلیغاتی عمومی قابل‌مقایسه نیست. سقف را بر اساس انتظار کاربر، نوع محتوا، داده‌های لغو اشتراک و نتیجه نهایی تعیین کنید.
آیا می‌توان پیام‌های تراکنشی را همیشه از سقف مستثنا کرد؟
فقط اگر واقعاً ضروری و مرتبط با اقدام کاربر باشند. استثنای گسترده باعث می‌شود پیام‌های تبلیغاتی با برچسب خدماتی از سیاست عبور کنند. فهرست استثناها را محدود، مستند و قابل‌ممیزی نگه دارید.
آیا تحویل موفق یعنی کاربر پیام را خوانده است؟
خیر. تأیید تحویل یا نمایش فنی، نشانه خواندن انسانی نیست. برای سنجش اثر، کلیک، اقدام نهایی و تغییرات عضویت را با احتیاط و در کنار عوامل دیگر بررسی کنید.
اگر پنل سرویس گزینه Frequency Cap نداشت چه کنیم؟
نام یا محل چنین گزینه‌ای را حدس نزنید. می‌توانید منطق شمارش، اولویت، ساعات سکوت و تصمیم ارسال را در بک‌اند خود پیاده کنید و فقط پس از بررسی مستندات سرویس، قابلیت‌های واقعی پنل یا API را به آن متصل کنید.