بازگشت به وبلاگ

بهترین زمان ارسال پوش نوتیفیکیشن؛ چگونه زمان مناسب را پیدا کنیم؟

بهترین زمان ارسال پوش نوتیفیکیشن؛ چگونه زمان مناسب را پیدا کنیم؟

بهترین زمان ارسال پوش نوتیفیکیشن یک ساعت ثابت برای همه کسب‌وکارها و کاربران نیست. نقطه شروع درست، ارسال پیام در زمان محلی مخاطب، هماهنگ‌کردن آن با رویداد موردنظر و سپس مقایسه کنترل‌شده چند زمان است؛ نه تکیه بر جدول‌های عمومی یا وعده افزایش قطعی نرخ کلیک.

در این مقاله:

اصل تصمیم‌گیری درباره زمان ارسال

زمان مناسب از ترکیب سه عامل به دست می‌آید: کاربر چه زمانی احتمالاً می‌تواند پیام را ببیند، پیام در چه مرحله‌ای از تعامل با محصول ارسال می‌شود و تأخیر چه هزینه‌ای دارد. اعلان یادآوری یک کلاس آنلاین با پیام معرفی یک مقاله یا هشدار پایان تخفیف، منطق زمانی یکسانی ندارد.

برای نمونه، برای یک فروشگاه فرضی می‌توان این نقطه‌های شروع را در نظر گرفت: پیام تأیید سفارش بلافاصله پس از ثبت سفارش، یادآوری سبد رهاشده پس از یک فاصله آزمایشی، و معرفی محصولات جدید در یک بازه محلی آرام‌تر. این‌ها «پیشنهاد اولیه برای تست» هستند، نه قانون عمومی. اگر داده‌های واقعی کاربران خلاف آن را نشان دهد، داده باید تصمیم را تغییر دهد.

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

منطقه زمانی و شخصی‌سازی محلی

اگر مخاطبان در شهرها یا کشورهایی با ساعت متفاوت هستند، ساعت ارسال را برای هر گروه بر اساس زمان محلی همان گروه محاسبه کنید. ارسال ساعت ۹ صبح تهران به همه مشترکان، ممکن است برای بخشی از مخاطبان نیمه‌شب یا ابتدای صبح باشد. زمان محلی باید از اطلاعات رضایت‌داده‌شده، تنظیمات حساب یا نشانه‌های قابل‌اعتماد مانند منطقه فعالیت به دست آید؛ حدس‌زدن مکان دقیق کاربر ضروری نیست.

ابتدا گروه‌های معنادار بسازید، نه ده‌ها بخش کوچک. برای مثال، می‌توانید مخاطبان را به «ایران»، «اروپای مرکزی» و «آمریکای شرقی» یا به چند منطقه زمانی اصلی تقسیم کنید. سپس برای هر گروه یک بازه آزمایشی تعریف کنید؛ مثلاً بازه شروع روز، میانه روز و پایان روز محلی. در گزارش، زمان نمایش یا کلیک را با همان منطقه زمانی ثبت کنید تا مقایسه میان گروه‌ها گمراه‌کننده نشود.

در وب، تجربه اعلان به وضعیت مرورگر و دستگاه نیز وابسته است. در iOS و iPadOS، وب‌اپی که به صفحه اصلی افزوده شده از نسخه ۱۶.۴ به بعد می‌تواند پس از یک اقدام مستقیم کاربر برای اجازه اعلان درخواست کند؛ تب معمولی مرورگر را نباید با این حالت یکی دانست. جزئیات رسمی این محدودیت در مستند WebKit درباره وب‌پوش در iOS و iPadOS آمده است.

ابزارهای مفید برای زمان‌بندی خودکار

رویدادهای چرخه عمر و فوریت پیام

به‌جای انتخاب یک ساعت ثابت، پیام را به رویداد مرتبط کنید و برای آن پنجره زمانی تعیین کنید. رویدادهای فرضی زیر نمونه‌ای برای طراحی جریان هستند:

  • عضویت یا فعال‌سازی: پیام راهنمای شروع را پس از تکمیل عضویت ارسال کنید، اما اگر کاربر قبلاً همان اقدام را انجام داده است، آن را تکرار نکنید.
  • سبد خرید رهاشده: ابتدا بررسی کنید کالا هنوز موجود است و سفارش ثبت نشده؛ سپس یک یادآوری آزمایشی پس از فاصله‌ای مشخص بفرستید. پیام دوم فقط در صورت وجود ارزش واقعی و رعایت سقف تماس فعال شود.
  • محتوای تازه: انتشار را با زمان فعالیت گروه هدف هماهنگ کنید، مگر آنکه موضوع واقعاً فوری باشد.
  • پایان فرصت: زمان پایان پیشنهاد را با ساعت محلی کاربر محاسبه کنید و از ایجاد فوریت ساختگی پرهیز کنید.
  • بازگشت کاربر: اگر کاربر برای مدتی غیرفعال بوده، ابتدا یک پیام کم‌فشار و مرتبط با آخرین علاقه او آزمایش کنید، نه چند اعلان پشت‌سرهم.

برای رویدادهای فوری، تأخیر اضافی ممکن است هدف پیام را از بین ببرد؛ برای پیام‌های تبلیغاتی و محتوایی، رعایت ساعات سکوت معمولاً ارزشمندتر از ارسال سریع است. وضعیت رویداد را در سامانه خود نگه دارید تا با انجام اقدام اصلی، پیام‌های زمان‌بندی‌شده منسوخ لغو یا بی‌اثر شوند.

ساعات سکوت و سقف تماس

ساعات سکوت را بر اساس زمان محلی تعریف کنید و آن را برای پیام‌های غیرضروری به‌صورت پیش‌فرض فعال نگه دارید. بازه‌ای مانند ۱۰ شب تا ۸ صبح فقط یک نقطه شروع فرضی است؛ کاربران و کشورها تفاوت دارند. برای پیام‌های تراکنشی یا هشدارهای واقعاً ضروری، سیاست جداگانه‌ای بنویسید و دامنه آن را محدود کنید.

ساعت سکوت تنها مسئله خواب نیست. جلسات کاری، تعطیلات، روزهای مذهبی، تفاوت تقویم کاری کشورها و نوع دستگاه می‌توانند تجربه کاربر را تغییر دهند. در Android 13، اجازه اعلان به مجوز زمان اجرا وابسته است و در Android 8 به بعد، کانال اعلان و تنظیمات انتخابی کاربر نیز روی نمایش اثر می‌گذارد. بنابراین گزارش «ارسال شد» به‌تنهایی نشان نمی‌دهد اعلان در زمان مطلوب دیده شده است.

یک سقف تماس عملی تعیین کنید؛ مثلاً در هر گروه برای پیام‌های بازاریابی بیش از یک تعداد مشخص در روز یا هفته ارسال نکنید. پیام‌های هم‌موضوع را ادغام کنید و برای هر کاربر فهرست پیام‌های در انتظار داشته باشید. این محدودیت را با نرخ لغو اشتراک و تبدیل بررسی کنید، نه با یک عدد ثابت که برای همیشه معتبر فرض شود. برای بحث بیشتر درباره تعداد ارسال، می‌توانید راهنمای سقف تماس و تعداد پوش را بخوانید.

ساخت فرضیه محلی و طراحی آزمایش

فرضیه باید مشخص، قابل اندازه‌گیری و محدود به یک متغیر باشد. نمونه مناسب: «برای کاربران منطقه زمانی تهران که در هفت روز گذشته از فروشگاه بازدید کرده‌اند، ارسال پیام پیشنهاد در ساعت ۱۸:۳۰ محلی نسبت به ساعت ۱۲:۳۰، طی ۲۴ ساعت نرخ تبدیل بیشتری ایجاد می‌کند.» این جمله هم گروه هدف، هم زمان‌ها و هم معیار را روشن می‌کند؛ اما نتیجه را از قبل تضمین نمی‌کند.

  1. جامعه را تعریف کنید: کاربران فعال، مشتریان بازگشتی و مشترکان تازه را با هم مخلوط نکنید.
  2. گروه‌ها را تصادفی تقسیم کنید: دو گروه باید از نظر کانال، نوع پیام، صفحه مقصد و ویژگی‌های اصلی تا حد امکان مشابه باشند.
  3. یک متغیر را تغییر دهید: اگر هم‌زمان ساعت، عنوان، پیشنهاد و صفحه فرود را عوض کنید، اثر زمان معلوم نخواهد شد.
  4. پنجره مشاهده تعیین کنید: برای پیام فوری ممکن است چند ساعت کافی باشد؛ برای محتوای غیرفوری، پنجره طولانی‌تری لازم است.
  5. آزمایش را تکرار کنید: یک نتیجه در یک روز خاص ممکن است ناشی از تعطیلی، رویداد خبری یا اختلال باشد.

مقایسه را در زمان محلی هر گروه انجام دهید و اگر حجم هر گروه کوچک است، نتیجه را با احتیاط گزارش کنید. به‌جای ادعای «بهترین زمان»، بگویید «در این بازه و برای این گروه، شواهد فعلی به نفع گزینه A است». برای روش‌های تکمیلی، راهنمای آزمایش A/B در وب‌پوش مرتبط است.

اندازه‌گیری نتیجه و تفسیر گزارش‌ها

حداقل این شاخص‌ها را جداگانه ثبت کنید: تعداد ارسال، تحویل یا نمایش موفق، کلیک یکتا، نرخ کلیک، اقدام نهایی، لغو اشتراک و خطاهای ارسال. «تحویل» الزاماً به معنی خواندن توسط انسان نیست؛ در وب، تأیید تحویل می‌تواند به موفقیت نمایش اعلان مربوط باشد، نه اثبات اینکه کاربر متن را خوانده است.

برای لینک مقصد، برچسب‌های UTM یکسان و نام‌گذاری مستند داشته باشید؛ مانند utm_source=push و utm_campaign=cart_reminder. اطلاعات شخصی را در URL قرار ندهید. راهنمای مستندات Google Analytics درباره برچسب‌گذاری کمپین برای قواعد نام‌گذاری و سازگاری گزارش‌ها مفید است.

در Pushfa می‌توان از گزارش‌های تحویل و کلیک برای مقایسه کمپین‌ها استفاده کرد و ارسال‌های زمان‌بندی‌شده را در فرآیند عملیاتی قرار داد. این گزارش‌ها باید کنار داده‌های سامانه خودتان، مانند تکمیل سفارش یا بازگشت کاربر، تفسیر شوند. افزایش کلیک بدون افزایش اقدام اصلی یا همراه با لغو اشتراک، نشانه موفقیت پایدار نیست.

چک‌لیست اجرای زمان‌بندی

  • هدف هر پیام و اقدام مورد انتظار را بنویسید.
  • منطقه زمانی گروه را تعیین و زمان‌ها را در همان منطقه ذخیره یا تبدیل کنید.
  • برای پیام‌های غیرضروری، بازه سکوت و سقف تماس تعریف کنید.
  • پیام‌های ناشی از رویدادهای منقضی‌شده را پیش از ارسال حذف کنید.
  • عنوان و متن را ثابت نگه دارید تا آزمایش فقط زمان را بسنجد.
  • گزارش تحویل، کلیک، اقدام نهایی و لغو اشتراک را با شناسه کمپین مرتبط کنید.
  • برای هر گروه، یک فرضیه محلی و یک بازه مشاهده مشخص کنید.
  • نتیجه را با زبان احتمالی گزارش کنید و زمان برنده را به‌عنوان قانون همیشگی اعلام نکنید.

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

پرسش‌های متداول

آیا ساعت مشخصی برای همه پوش‌ها بهترین است؟

خیر. نوع پیام، منطقه زمانی، عادت کاربر، مرحله چرخه عمر و حساسیت زمانی تعیین‌کننده‌اند. ساعت مناسب باید با داده مخاطبان خودتان آزموده شود.

آیا ارسال در عصر همیشه نرخ کلیک بیشتری دارد؟

نه. عصر ممکن است برای یک گروه مناسب باشد، اما تعطیلات، نوع محتوا و الگوی استفاده می‌تواند نتیجه را تغییر دهد. میانگین‌های عمومی جای آزمایش محلی را نمی‌گیرند.

اگر کاربر هنگام ارسال آفلاین باشد، باید پیام را بی‌نهایت نگه داشت؟

خیر. زمان ماندگاری یا TTL فقط مدت تلاش برای تحویل در حالت آفلاین را محدود می‌کند و تضمین ذخیره‌سازی نامحدود یا تحویل قطعی نیست. پیام‌های منقضی‌شده باید از نظر منطقی نیز کنار گذاشته شوند.

جمع‌بندی تصمیم ساده است: زمان محلی را رعایت کنید، پیام را به رویداد واقعی کاربر وصل کنید، ساعات سکوت و سقف تماس داشته باشید و اثر زمان را با آزمایش کنترل‌شده بسنجید. هیچ ساعت طلایی تضمین‌شده‌ای وجود ندارد؛ شواهد هر گروه باید راهنمای برنامه بعدی باشد.