ورود شروع رایگان
بازگشت به وبلاگ

تاریخچه پوش نوتیفیکیشن؛ از APNs و GCM تا وب پوش

۱۴۰۵-۰۵-۲۵ علیرضا
تاریخچه پوش نوتیفیکیشن؛ از APNs و GCM تا وب پوش

تاریخچه پوش نوتیفیکیشن از زیرساخت اعلان موبایل شروع می‌شود: اپل در سال ۲۰۰۹ سرویس APNs را معرفی کرد، گوگل در سال ۲۰۱۰ C2DM را برای اندروید ارائه داد، سپس GCM در سال ۲۰۱۲ جای آن را گرفت و FCM در سال ۲۰۱۶ به مسیر اصلی پیام‌رسانی گوگل تبدیل شد. بعدتر، Service Worker و استاندارد Web Push امکان ارسال اعلان از وب‌سایت‌ها را فراهم کردند؛ با این تفاوت که در iOS، وب‌پوش برای وب‌اپی که کاربر به صفحه اصلی افزوده است از نسخه ۱۶.۴، منتشرشده در سال ۲۰۲۳، قابل استفاده شد.

در این مقاله:

پوش نوتیفیکیشن دقیقاً چیست؟

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

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

پیش از APNs؛ از ایمیل و پیامک تا اعلان موبایل

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

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

نقطه عطف موبایل: APNs، C2DM، GCM و FCM

APNs؛ آغاز مدل استاندارد اپل

اپل در سال ۲۰۰۹ سرویس Apple Push Notification service یا APNs را برای دستگاه‌های iOS معرفی کرد. در این مدل، اپلیکیشن لازم نبود دائماً یک اتصال اختصاصی و پرهزینه را مدیریت کند؛ توسعه‌دهنده پیام را به زیرساخت اپل می‌سپرد و APNs آن را به دستگاه مربوط می‌رساند. همین جداسازی، مدیریت باتری و ارتباط شبکه را برای اپلیکیشن‌ها ساده‌تر کرد.

از C2DM تا GCM

گوگل در سال ۲۰۱۰ Android Cloud to Device Messaging یا C2DM را معرفی کرد. C2DM نخستین مسیر رسمی گوگل برای رساندن پیام به دستگاه اندرویدی بود، اما در ادامه کنار گذاشته شد و Google Cloud Messaging یا GCM در سال ۲۰۱۲ جای آن را گرفت. GCM امکانات و مقیاس مناسب‌تری برای پیام‌رسانی میان سرور، اپلیکیشن و دستگاه فراهم کرد.

FCM و یکپارچه‌تر شدن پیام‌رسانی

در سال ۲۰۱۶، Firebase Cloud Messaging یا FCM به مسیر جدید گوگل تبدیل شد. اهمیت FCM فقط تغییر نام نبود؛ پیام‌رسانی با ابزارهای Firebase و مدیریت سناریوهای مختلف اپلیکیشن هماهنگ‌تر شد. در این دوره، تفاوت میان پیام اعلان و پیام داده نیز اهمیت بیشتری پیدا کرد: یک پیام ممکن است برای نمایش مستقیم طراحی شود یا داده‌ای را به منطق اپلیکیشن بسپارد. رفتار هرکدام در حالت فعال یا پس‌زمینه یکسان نیست.

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

ورود وب‌پوش و Service Worker

در وب، یک صفحه باز معمولی برای دریافت رویدادهای پس‌زمینه کافی نیست؛ مرورگر ممکن است صفحه را ببندد یا اجرای جاوااسکریپت آن را متوقف کند. Service Worker، یعنی اسکریپت پس‌زمینه وب، برای حل همین مسئله وارد معماری وب شد. این فایل جدا از صفحه اجرا می‌شود و می‌تواند رویداد دریافت پیام را پردازش کند و در صورت مجاز بودن، اعلان را با قابلیت نمایش سیستم‌عامل ایجاد کند.

Web Push نیز استانداردی برای رساندن پیام از سرور به اشتراک مرورگر است. کاربر ابتدا باید در یک تعامل قابل فهم، عضویت و اجازه اعلان را بپذیرد. سپس مرورگر اطلاعات اشتراک را در اختیار وب‌سایت می‌گذارد و سرور می‌تواند پیام را از مسیر سرویس پوش مربوط ارسال کند. HTTPS، ثبت درست Service Worker و مدیریت تغییر یا لغو اشتراک، اجزای فنی این فرایند هستند.

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

وب‌پوش در iOS و محدودیت وب‌اپ‌های صفحه اصلی

پشتیبانی iOS از وب‌پوش دیرتر از بسیاری از مرورگرهای دسکتاپ و اندروید شکل گرفت. از iOS و iPadOS 16.4 به بعد، وب‌اپی که کاربر آن را به صفحه اصلی افزوده است می‌تواند پس از یک اقدام مستقیم کاربر، درخواست اجازه اعلان کند. این قابلیت به معنای آن نیست که هر زبانه باز در Safari مانند یک اپلیکیشن، اعلان پس‌زمینه دریافت می‌کند.

در عمل، مسیر iOS چنین مراحلی دارد: سایت باید از HTTPS استفاده کند، Service Worker را درست ثبت کند، کاربر وب‌سایت را به صفحه اصلی بیفزاید، سپس در یک تعامل روشن مانند فشردن دکمه «فعال‌سازی اعلان»، درخواست مجوز را ببیند. توضیح رسمی WebKit درباره این محدودیت‌ها در راهنمای Web Push برای وب‌اپ‌ها در iOS و iPadOS آمده است.

یک نکته مهم دیگر این است که اعلان وب در WebKit باید قابل مشاهده باشد. بنابراین نباید برای Safari یا وب‌پوش iOS روی پیام‌های کاملاً بی‌صدا و پنهان حساب کرد. اگر هدف فقط همگام‌سازی داده است، باید آن را جداگانه و با توجه به قابلیت‌های همان پلتفرم طراحی کرد، نه اینکه نام پوش را برای هر رویداد پس‌زمینه به کار ببریم.

از تاریخچه تا معماری امروزی ارسال

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

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

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

درس‌های عملی این تحول

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

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

آیا APNs و FCM خودِ اعلان را می‌نویسند؟

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

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

خیر. پشتیبانی Service Worker، مجوزها، اجرای پس‌زمینه و روش نمایش اعلان به مرورگر و سیستم‌عامل وابسته است. در iOS 16.4 و نسخه‌های بعد، مسیر وب‌پوش برای وب‌اپ افزوده‌شده به صفحه اصلی تعریف شده، نه هر زبانه معمولی Safari.

آیا دریافت اعلان یعنی کاربر آن را خوانده است؟

خیر. دریافت یا نمایش موفق فقط بخشی از مسیر است. برای سنجش خواندن یا اثرگذاری باید رویدادهایی مانند کلیک و اقدام در صفحه مقصد را جداگانه ثبت و تحلیل کرد.

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