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

چگونه پوش نوتیفیکیشن را در سایت فعال کنیم — راهنمای کامل پیاده‌سازی برای صاحبان وب‌سایت

چگونه پوش نوتیفیکیشن را در سایت فعال کنیم — راهنمای کامل پیاده‌سازی برای صاحبان وب‌سایت

فعال‌سازی پوش نوتیفیکیشن وب در ساده‌ترین حالت تنها به سه چیز نیاز دارد: یک وب‌سایت روی HTTPS، یک فایل سرویس ورکر (Service Worker)، و کسب اجازه (Permission) از کاربر؛ و سریع‌ترین مسیر برای رسیدن به این هدف، استفاده از یک سرویس آماده پوش مانند پوشفا (Pushfa) است که با افزودن یک قطعه کد و یک فایل سرویس ورکر، تمام پیچیدگی فنی را برای شما مدیریت می‌کند.

خلاصه سه خطی:

  • پیش‌نیاز اصلی: وب‌سایت روی HTTPS + سرویس ورکر + اجازه کاربر. ساده‌ترین راه، استفاده از سرویس آماده‌ای مانند پوشفا است که فقط با یک قطعه کد و یک فایل سرویس ورکر کار می‌کند و نیازی به مدیریت کلیدهای VAPID، سرور یا ذخیره توکن ندارد.
  • دو رویکرد دارید: (۱)  سرویس آماده (پوشفا،  OneSignal، PushEngage)  با حداقل کدنویسی، یا (۲) پیاده‌سازی دستی با Push API + سرویس ورکر + کلیدهای VAPID و کتابخانه‌ای مانند web-push برای Node.js.
  • محدودیت iOS: روی آیفون و آی‌پد، پوش فقط زمانی کار می‌کند که سایت به‌صورت PWA به صفحه اصلی (Home Screen) اضافه شده باشد )از iOS 16.4 به بعد(؛ اما روی کروم، فایرفاکس و اج در دسکتاپ و اندروید مستقیماً و بدون این محدودیت کار می‌کند.

 

کلیدی‌ترین یافته‌ها (Key Findings)

پوش نوتیفیکیشن وب پیامی است که از سرور به مرورگر کاربر ارسال می‌شود — حتی وقتی سایت شما باز نیست یا اصلاً در حال اجرا نیست. این فناوری بر سه استاندارد مرورگری استوار است که در کنار هم کار می‌کنند:

  1. Push API —  به وب‌اپلیکیشن اجازه می‌دهد پیام‌هایی را که از سرور ارسال می‌شوند دریافت کند.
  2.  Notification API — نوتیفیکیشن را روی صفحه کاربر نمایش می‌دهد.
  3.  Service Worker — اسکریپتی که در پس‌زمینه و جدا از صفحه وب اجرا می‌شود و پیام‌های پوش را مدیریت می‌کند.

طبق مستندات MDN، برای دریافت پیام پوش، اپلیکیشن باید یک سرویس ورکر فعال داشته باشد؛ این سرویس ورکر با متد  PushManager.subscribe() مشترک می‌شود و نتیجه آن یک شیء   PushSubscription است که شامل یک  endpointو کلیدهای رمزنگاری لازم برای ارسال پیام می‌باشد. هر مرورگر سرویس پوش مخصوص خود را دارد (مثلاً کروم از Firebase Cloud Messaging و فایرفاکس از Mozilla Push Service استفاده می‌کند)، اما به‌عنوان توسعه‌دهنده نیازی نیست نگران جزئیات هر کدام باشید — درخواست خود را به endpoint اشتراک ارسال می‌کنید و سرویس پوش مرورگر، مسیریابی پیام به دستگاه درست را انجام می‌دهد.

نکته مهم: پوش نوتیفیکیشن یکی از معدود کانال‌های بازاریابی است که از فیلتر تبلیغات (ad-blocker) عبور می‌کند، چون از طریق سیستم نوتیفیکیشن بومی مرورگر تحویل داده می‌شود؛ طبق گزارش Sleeknote، با وجود اینکه ۳۲.۵٪ کاربران اینترنت از ad-blocker استفاده می‌کنند، وب پوش تحت تأثیر آن قرار نمی‌گیرد و امروزه بیش از ۹۶٪ مرورگرها از استاندارد وب پوش پشتیبانی می‌کنند.

 

پیش‌نیازهای فعال‌سازی پوش نوتیفیکیشن

۱. الزام HTTPS  (منشأ امن)

سرویس ورکرها فقط روی منشأ امن (secure context) اجرا می‌شوند. مستندات Firebase به‌صراحت می‌گوید که SDK آن «تنها روی صفحات سرو‌شده با HTTPS پشتیبانی می‌شود، زیرا از سرویس ورکر استفاده می‌کند که فقط روی سایت‌های HTTPS در دسترس است». تنها استثنا localhost است که برای توسعه محلی به‌عنوان منشأ امن در نظر گرفته می‌شود. بنابراین اولین قدم، نصب گواهی SSL و انتقال کامل سایت به HTTPS است.

۲. داشتن وب‌سایت و دسترسی به ریشه

شما باید بتوانید فایل سرویس ورکر را در ریشه سایت (root) آپلود کنید تا scope آن کل سایت را پوشش دهد (در ادامه توضیح داده می‌شود).

۳. پشتیبانی مرورگرها 

  • دسکتاپ و اندروید: کروم، فایرفاکس، اج و اپرا به‌طور کامل وب پوش را پشتیبانی می‌کنند. کروم سهم اصلی مشترکان وب پوش را تشکیل می‌دهد )طبق Sleeknote، کروم به‌تنهایی ۹۰ تا ۹۵٪ مشترکان وب پوش را در بر می‌گیرد).
  • سافاری روی مک: طبق وبلاگ WebKit اپل، پشتیبانی استاندارد Web Push نخست در Safari 16.1 روی macOS اضافه شد. (به نقل از WebKit: «Chrome first supported these standards in 2015 and Firefox in 2016» — یعنی کروم از ۲۰۱۵ و فایرفاکس از ۲۰۱۶ پشتیبانی کرده‌اند.)
  • iOS و iPadOS: از نسخه  16.4 (مارس ۲۰۲۳)پوش پشتیبانی می‌شود، اما فقط برای سایت‌هایی که به‌صورت PWA به صفحه اصلی اضافه شده‌اند (Home Screen web apps). همه مرورگرها روی iOS — حتی کروم و اج — زیر موتور WebKit اجرا می‌شوند، پس این محدودیت برای همه آنها یکسان است.
پشتیبانی مرورگر ها از پوش نوتیفیکیشن

۴. محدودیت‌هایی که باید بدانید

پوش در حالت Incognito/Private، داخل مرورگرهای این‌اپ (مانند مرورگر داخل اینستاگرام و فیسبوک) و در WebView اندروید کار نمی‌کند.

 

دو رویکرد اصلی برای فعال‌سازی پوش

رویکرد اول: استفاده از سرویس آماده (توصیه‌شده برای اکثر سایت‌ها)

سرویس‌هایی مانند پوشفا، OneSignal،  PushEngage و Pushwoosh کل زیرساخت پیچیده پوش — رمزنگاری، کلیدهای VAPID، endpointها، ذخیره توکن و ارتباط با سرویس‌های پوش مرورگرها — را مدیریت می‌کنند. آنها به شما یک قطعه کد اسکریپت و یک فایل سرویس ورکر می‌دهند.

مزایا: راه‌اندازی در چند دقیقه، بدون کدنویسی پیچیده، بدون نیاز به مدیریت سرور یا کلید، پنل آماده برای ارسال، گزارش‌گیری لحظه‌ای، سگمنت‌بندی کاربران و A/B تست.

معایب: وابستگی به سرویس ثالث و محدودیت‌های احتمالی پلن رایگان.

رویکرد دوم: پیاده‌سازی دستی (برای توسعه‌دهندگان)

شما با Push API، سرویس ورکر، کلیدهای VAPID و یک کتابخانه سمت سرور مانند web-push (npm) همه‌چیز را خودتان می‌سازید.

مزایا: کنترل کامل، بدون وابستگی به فروشنده (vendor lock-in).

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

 

جزئیات: راه‌اندازی گام‌به‌گام با یک سرویس (مثال پوشفا)

پوشفا (Pushfa) یک سرویس ایرانی ارائه‌دهنده خدمات مبتنی بر پوش نوتیفیکیشن است که علاوه بر ارسال وب پوش، خدمات جانبی مانند احراز هویت مبتنی بر پوش نوتیفیکیشن و ریتنشن مارکتینگ نیز ارائه می‌دهد.

۱. ثبت‌نام و ایجاد سرویس: در پوشفا ثبت‌نام کنید و یک سرویس/اپ جدید بسازید.

۲. دریافت کد و فایل سرویس ورکر: پنل به شما یک قطعه کد اسکریپت و یک فایل سرویس ورکر اختصاصی می‌دهد.

۳. محل قراردادن کد — هدر یا فوتر؟ توصیه پوشفا این است که کد را به‌جای فوتر در هدر (header) قرار دهید. به بیان دقیق خود پوشفا: «نیازی به اینکار نیست اما توصیه این است به جای فوتر در هدر قراردهید تا در ابتدای بالا آمدن سایت پوش نوتیفیکیشن آماده عضوگیری و دریافت پیام شود». قراردادن در هدر باعث می‌شود فرایند اشتراک‌گیری زودتر در چرخه بارگذاری صفحه آماده شود.

۴. آپلود سرویس ورکر در ریشه: فایل سرویس ورکر را در ریشه سایت قرار دهید تا scope آن کل دامنه را پوشش دهد.

۵. تنظیم پیام opt-in: از بخش «تنظیمات سرویس»، نحوه نمایش پیام درخواست اجازه به کاربران را تنظیم کنید.

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

۷. ارسال اولین پیام تستی: از پنل، یک پیام تستی ارسال کنید تا از کارکرد صحیح مطمئن شوید.

۸. ارسال تکی در مقابل گروهی/تاپیک:

  • ارسال به یک کاربر خاص: باید توکن انحصاری آن فرد را دریافت کرده و در سرور خودتان ذخیره کنید. ارسال تکی امکان گزارش تحویل پیام و گزارش کلیک را فراهم می‌کند.
  • ارسال به یک تاپیک خاص یا به همه کاربران: نیازی به ذخیره‌سازی توکن کاربران نیست. در پوشفا «تاپیک‌ها» ابزار سگمنت‌بندی هستند؛ با کد window.subscribeTopic(topicID) کاربر را عضو یک تاپیک می‌کنید، با window.unSubscribeTopic(topicID)  از آن خارج می‌کنید، و با window.getDeviceTopics()  تاپیک‌های فعلی دستگاه را می‌خوانید. ارسال گروهی با گزارش سرعت متوسط دارد، و ارسال فوق‌سریع به تاپیک بدون گزارش است.

نکات اختصاصی پوشفا:

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

 

جزئیات: پیاده‌سازی دستی (سطح توسعه‌دهنده)

اگر می‌خواهید از پایه و بدون سرویس ثالث پیاده‌سازی کنید، مسیر مفهومی زیر را دنبال کنید:

۱. بررسی پشتیبانی مرورگر: ابتدا بررسی کنید 'serviceWorker' in navigator و 'PushManager' in window برقرار باشند.

۲. ثبت سرویس ورکر: با navigator.serviceWorker.register('/sw.js') — بهتر است این کار پس از رویداد load صفحه انجام شود تا با بارگذاری منابع حیاتی صفحه رقابت نکند.

۳. درخواست اجازه:  با Notification.requestPermission(). این فراخوانی باید از داخل یک رویداد کاربری (مثل کلیک) آغاز شود؛ فایرفاکس و سافاری فراخوانی روی load را مسدود می‌کنند و خطایی مانند «The Notification permission may only be requested from inside a short running user-generated event handler» برمی‌گردانند.

۴. تولید کلیدهای VAPID: با دستور خط فرمان web-push generate-vapid-keys یا تابع webpush.generateVAPIDKeys() که یک جفت کلید عمومی و خصوصی (رشته‌های Base64 امن برای URL) برمی‌گرداند. این کلیدها فقط یک‌بار تولید و سپس ذخیره می‌شوند و برای همه پیام‌های آینده استفاده می‌شوند. VAPID (Voluntary Application Server Identification) یک جفت کلید نامتقارن است: کلید عمومی هنگام اشتراک به مرورگر داده می‌شود و کلید خصوصی هر درخواست ارسال را امضا می‌کند تا سرویس پوش، فرستنده را تأیید کند.

۵. اشتراک کاربر: با registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: <کلید عمومی VAPID> }). کلید عمومی باید به Uint8Array تبدیل شود (با تابع کمکی urlBase64ToUint8Array).

۶. ذخیره اشتراک: شیء PushSubscription (شامل endpoint و کلیدهای p256dh و auth) را در سرور خود ذخیره کنید. این endpoint یک URL منحصربه‌فرد است و باید محرمانه بماند، وگرنه دیگران می‌توانند به اپ شما پیام بفرستند.

۷. ارسال از سرور: با کتابخانه web-push و فراخوانی webpush.sendNotification(subscription, payload). این کتابخانه به‌طور خودکار پیام را رمزنگاری می‌کند. مقدار TTL مدت نگهداری پیام در سرویس پوش را تعیین می‌کند (پیش‌فرض چهار هفته).

۸. مدیریت رویداد push در سرویس ورکر: self.addEventListener('push', event => { ... self.registration.showNotification(title, options) ... }) — نمایش نوتیفیکیشن حتماً باید داخل event.waitUntil() قرار گیرد تا سرویس ورکر تا پایان نمایش زنده بماند.

۹. مدیریت notificationclick: وقتی کاربر روی نوتیفیکیشن کلیک می‌کند، با clients.matchAll({ type: 'window', includeUncontrolled: true })  پنجره باز را پیدا و focus() می‌کنید، یا با clients.openWindow(url) پنجره جدید باز می‌کنید. استفاده از includeUncontrolled: true توصیه می‌شود، چون در غیر این صورت ممکن است لیست کلاینت‌ها خالی بازگردد و تابع نتواند پنجره موجود را پیدا کند.

برای کاربران FCM )فایربیس:( با getToken({ vapidKey })  توکن دریافت می‌شود و به یک فایل به‌نام firebase-messaging-sw.js  نیاز دارید. کلیدهای VAPID را می‌توانید در کنسول Firebase از بخش Cloud Messaging → Web Push certificates → Generate Key Pair بسازید.

 

 scope و محل قراردادن فایل سرویس ورکر

scope پیش‌فرض یک سرویس ورکر، همان دایرکتوری‌ای است که فایل در آن قرار دارد. طبق MDN، اگر sw.js در /js/ قرار گیرد، فقط مسیرهای زیر /js/ را کنترل می‌کند و درخواست‌های ریشه را نادیده می‌گیرد. برای پوشش کل سایت دو راه دارید:

  1. فایل را در ریشه سایت قرار دهید (ساده‌ترین و توصیه‌شده برای پوش).
  2. اگر مجبورید فایل در زیرپوشه باشد، با هدر HTTP به‌نام Service-Worker-Allowedدامنه scope را گسترش دهید.

خطای رایجی که در کروم می‌بینید: «The path of the provided scope ('/') is not under the max scope allowed ('/.../pwa/'). Adjust the scope, move the Service Worker script, or use the Service-Worker-Allowed HTTP header». برای پوش نوتیفیکیشن، قراردادن سرویس ورکر در ریشه بهترین روش است.

 

مشکلات رایج راه‌اندازی و راه‌حل آنها

  • خطای HTTPS: سرویس ورکر روی HTTP کار نمی‌کند؛ گواهی SSL نصب و سایت را به HTTPS منتقل کنید.
  • شکست ثبت سرویس ورکر: معمولاً به‌دلیل مسیر اشتباه فایل، منشأ متفاوت با صفحه، یا scope بزرگ‌تر از مجاز است. مسیر را نسبت به ریشه سایت بدهید (مثلاً /sw.js).
  • اجازه مسدود/رد شده: اگر کاربر یک‌بار «Block» را بزند، پرامپت بومی دیگر نمایش داده نمی‌شود و کاربر باید از تنظیمات مرورگر (آیکون قفل کنار نوار آدرس) آن را دستی فعال کند.
  • نمایش نشدن پرامپت: درخواست روی load صفحه به‌جای رویداد کاربری، یا فعال بودن حالت Incognito، یا فعال بودن «quieter messaging» مرورگر.
  • خطای «This site has been updated in the background»:این پیام پیش‌فرض کروم زمانی ظاهر می‌شود که پوش دریافت می‌شود اما هیچ نوتیفیکیشنی نمایش داده نمی‌شود. کروم پوش بی‌صدا (silent push) را مجاز نمی‌داند و برای اطلاع کاربر، این پیام پیش‌فرض را نشان می‌دهد. راه‌حل: همیشه showNotification را داخل  event.waitUntil() فراخوانی کنید تا پیش از پایان نمایش نوتیفیکیشن، رویداد بسته نشود. این مشکل به‌طور مکرر در پیاده‌سازی‌های FCM، Angular  و OneSignal گزارش شده است.
  • انقضای توکن/اشتراک: توکن‌های غیرفعال پس از مدتی توسط فایربیس سوزانده می‌شوند؛ رویداد pushsubscriptionchange  را در سرویس ورکر مدیریت و اشتراک جدید را به سرور ارسال کنید. (در سرویس‌های آماده مانند پوشفا، این کار خودکار انجام می‌شود.)

 

بهترین روش‌های پرامپت opt-in (افزایش نرخ پذیرش)

پرامپت soft-ask / دو مرحله‌ای (double opt-in)

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

زمان‌بندی درست

هرگز روی load صفحه نپرسید. در لحظه‌ای بپرسید که ارزش پوش برای کاربر روشن است — مثلاً پس از تکمیل خرید (برای پیگیری سفارش)، هنگام اتمام موجودی یک کالا (اطلاع از موجود شدن مجدد)، یا پس از مطالعه چند مقاله. طبق گزارش web.dev، درخواست اجازه به‌محض ورود کاربر، هیچ زمینه‌ای برای ضرورت آن فراهم نمی‌کند و کاربر را از انجام کار اصلی‌اش بازمی‌دارد.

چرا دو مرحله‌ای جواب می‌دهد — با عدد

طبق گزارش Sleeknote («15 Push Notification Statistics You Need to Know in 2026»)، یک تحقیق اخیر نشان داده که حذف یک کلیک اضافی می‌تواند ثبت‌نام‌ها را بیش از ۶۰۰٪ افزایش دهد («Recent research found that removing it can boost sign-ups by over 600%») و با یک استراتژی opt-in مؤثر، حدوداً ۱۵٪ از کل مخاطبان سایت می‌توانند به مشترک پوش تبدیل شوند. در عین حال، double opt-in  مزیت کیفی هم دارد: مشترکانی که دو بار تأیید می‌کنند دقیقاً می‌دانند چه چیزی را پذیرفته‌اند، که به نرخ خروج کمتر و تعامل بالاتر منجر می‌شود.

 

به‌روزرسانی‌های مهم ۲۰۲۵–۲۰۲۶

تغییرات کروم در مدیریت اجازه نوتیفیکیشن

طبق وبلاگ رسمی Chromium گوگل (۱۰ اکتبر ۲۰۲۵، به نقل از Archit Agarwal، مدیر محصول کروم)، گوگل ویژگی حذف خودکار اجازه نوتیفیکیشن برای سایت‌هایی که کاربر اخیراً با آنها تعامل نداشته را معرفی کرد. به گفته این پست: «Less than 1% of all notifications receive any interaction from users. But notifications can be genuinely valuable and helpful» — یعنی کمتر از ۱٪ نوتیفیکیشن‌ها هیچ تعاملی از کاربر دریافت می‌کنند. این ویژگی به Safety Checkروی دسکتاپ و اندروید افزوده می‌شود، اما فقط اجازه سایت‌هایی را لغو می‌کند که هم تعامل بسیار کم دارند و هم حجم بالایی پیام می‌فرستند؛ و اپ‌های نصب‌شده (PWA) را تحت تأثیر قرار نمی‌دهد. پیام مهم برای صاحبان سایت: کیفیت و ارتباط (relevance) پیام‌ها مهم‌تر از حجم آنها شده است.

سافاری/iOS و فناوری Declarative Web Push

طبق وبلاگ WebKit اپل (اعلام ۳۱ مارس ۲۰۲۵)، اپل فناوری Declarative Web Push را معرفی کرد که با Safari 18.4 روی iOS/iPadOS 18.4 برای وب‌اپ‌های افزوده‌شده به Home Screen عرضه شد، و سپس با  Safari 18.5 روی macOS 15.5 اضافه گردید. مزیت این روش این است که «doesn't require Service Workers — which makes it far easier for you as a developer to implement. And saves battery life for your users» — یعنی بدون نیاز به سرویس ورکر کار می‌کند، پیاده‌سازی را برای توسعه‌دهنده ساده‌تر می‌کند و باتری کاربر را کمتر مصرف می‌کند. در این روش، پیام پوش در قالب JSON استاندارد فرستاده می‌شود و مرورگر مستقیماً آن را نمایش می‌دهد.

با این حال، الزام افزودن به صفحه اصلی برای iOS همچنان پابرجاست. برای اینکه پوش روی آیفون کار کند:

  • سایت باید manifest با مقدار display: standalone )یا fullscreen( داشته باشد.
  • آیکون‌ها باید فایل‌های PNG واقعی با اندازه درست (مثلاً ۱۹۲×۱۹۲ و ۵۱۲×۵۱۲) باشند.
  • کاربر باید از منوی Share در سافاری گزینه «Add to Home Screen» را بزند و سایت را از روی آیکون صفحه اصلی باز کند.
  • درخواست اجازه باید از داخل یک کلیک کاربر آغاز شود.

توصیه: برای کاربران iOS، یک بنر راهنما نمایش دهید که آنها را به افزودن سایت به صفحه اصلی هدایت کند.

 

نکات مخصوص CMS و وردپرس

در وردپرس، ساده‌ترین راه استفاده از افزونه است. طبق صفحه رسمی افزونه در WordPress.org، OneSignal محبوب‌ترین افزونه پوش وردپرس با بیش از ۱۰۰٬۰۰۰ نصب فعال («the most popular push notification plugin on WordPress with 100,000+ installations») است؛ این سرویس مورد اعتماد بیش از ۱.۸ میلیون توسعه‌دهنده است و روزانه بیش از ۶میلیارد نوتیفیکیشن ارسال می‌کند و پلن رایگان آن تا ۱۰٬۰۰۰ مشترک وب پوش را پوشش می‌دهد. گزینه‌های دیگر مانند  PushEngageو Webpushr  نیز برای وردپرس در دسترس‌اند.

برای سایت‌های کدنویسی‌شده سفارشی، کافی است قطعه کد سرویس را در هدر و فایل سرویس ورکر را در ریشه سایت قرار دهید — همان الگویی که سرویس‌هایی مانند پوشفا توصیه می‌کنند.

 

نحوه تست و بررسی سرویس ورکر در DevTools

طبق مستندات Chrome for Developers:

  • در کروم، DevTools  را باز کنید و به مسیر Application > Service Workers بروید؛ سرویس ورکر ثبت‌شده باید با وضعیت activated دیده شود.
  • دکمه Push در همان بخش یک پیام تستی بدون payload )به‌اصطلاح «tickle»( ارسال می‌کند.
  • در مسیر  Application > Background services > Push Messaging و Notifications می‌توانید رویدادهای پوش را — حتی وقتی DevTools باز نیست — تا سه روز ضبط کنید.
  • گزینه  Update on reload سرویس ورکر را در هر بارگذاری به‌روز می‌کند که برای توسعه مفید است؛ و Offline رفتار آفلاین را شبیه‌سازی می‌کند.

اگر در کنسول پیام [Service Worker] Push Received را می‌بینید اما نوتیفیکیشن ظاهر نمی‌شود، مشکل از نحوه نمایش (showNotification) و قرارگرفتن آن داخل waitUntil است.

 

توصیه‌ها (Recommendations)

اگر صاحب کسب‌وکار یا سایت‌دار غیرفنی هستید: از یک سرویس آماده مانند پوشفا شروع کنید. راه‌اندازی سریع (در حد چند دقیقه)، بدون نیاز به مدیریت کلید VAPID یا سرور، و با پنل گزارش‌گیری و سگمنت‌بندی. کافی است کد را در هدر و سرویس ورکر را در ریشه قرار دهید.

اگر توسعه‌دهنده هستید و کنترل کامل می‌خواهید: پیاده‌سازی دستی با  web-push و کلیدهای VAPID را انتخاب کنید، اما برای مدیریت توکن‌ها، رمزنگاری و رویداد pushsubscriptionchange برنامه‌ریزی کنید.

در هر دو حالت:

  • همیشه از الگوی دو مرحله‌ای (soft-ask) استفاده کنید و در زمان مناسب )نه روی load صفحه( بپرسید — این تنها اهرم مستقیم شما برای بالا بردن نرخ پذیرش است.
  • فایل سرویس ورکر را در ریشه قرار دهید و سایت را کاملاً روی HTTPS منتقل کنید.
  • برای کاربران iOS، آنها را به افزودن سایت به صفحه اصلی راهنمایی کنید )با manifest درست و بنر راهنما(.
  • پیام‌ها را مرتبط و کم‌حجم نگه دارید؛ معیار تغییر استراتژی: اگر نرخ Block بالا یا نرخ تعامل پایین است (به‌خصوص پس از تغییرات ۲۰۲۵ کروم)، فرکانس ارسال را کاهش و سگمنت‌بندی را افزایش دهید.

بنچمارک‌هایی که باید رصد کنید: نرخ opt-in (هدف واقع‌بینانه حدود ۱۵٪ از کل مخاطبان با استراتژی خوب)، نرخ Block (هرچه پایین‌تر بهتر)، و نرخ کلیک (CTR). افزایش نرخ Block یا کاهش CTR نشانه آن است که باید زمان‌بندی پرامپت و ارتباط محتوا را بازنگری کنید.

 

هشدارها (Caveats)

  • اختلاف آمار میان منابع: ارقام نرخ پذیرش و opt-in بین منابع مختلف متفاوت است (از حدود ۵٪ تا ۱۵٪ برای وب پوش، بسته به روش و صنعت). این اعداد را به‌عنوان راهنمای جهت‌دهی، نه عدد قطعی، استفاده کنید.
  •  Declarative Web Push فناوری جدیدی است: در حال حاضر عمدتاً در سافاری/WebKit پیاده شده و پشتیبانی سایر مرورگرها در حال تکامل است؛ مرورگرهایی که از آن پشتیبانی نمی‌کنند، پیام را از طریق سرویس ورکر کلاسیک مدیریت می‌کنند.
  • ناپایداری اشتراک روی iOS: برخی توسعه‌دهندگان گزارش کرده‌اند که اشتراک‌های پوش روی iOS گاهی پس از مدتی غیرفعالیت «ناپدید» می‌شوند و کاربر باید دوباره مشترک شود؛ این مشکل به‌طور کامل حل نشده است.
  • پوشفا فقط وب و پنج مرورگر: پوشفا در حال حاضر تنها از پلتفرم وب و مرورگرهای کروم، فایرفاکس و اج و سافاری/iOS و Opera پشتیبانی می‌کند..