وب پوش در حالت آفلاین؛ TTL و شرایط تحویل پس از اتصال
اگر دستگاه هنگام ارسال آفلاین باشد، پیام وب‌پوش ممکن است پس از اتصال دوباره تحویل شود؛ اما این نتیجه نه همیشگی است و نه به‌معنای نمایش قطعی اعلان. عمر پیام، وضعیت صف، اعتبار اشتراک، مجوز اعلان، اتصال به زیرساخت پوش و محدودیت‌های سیستم‌عامل همگی اثر دارند. همچنین «پذیرفته‌شدن ارسال» در سرور پوش با «نمایش موفق اعلان» یکی نیست.
در این مقاله:
- TTL چیست و صف پیام چه زمانی منقضی می‌شود؟
- سناریوهای آفلاین و آنلاین‌شدن دستگاه
- از پذیرش ارسال تا نمایش اعلان
- محدودیت‌های مرورگر، سیستم‌عامل و دستگاه
- طراحی پیام برای تأخیر و تازگی محتوا
- چک‌لیست بررسی پیام دریافت‌نشده
- پرسش‌های متداول
TTL چیست و صف پیام چه زمانی منقضی می‌شود؟
TTL مخفف Time To Live و به‌معنای مدت اعتبار پیام برای تلاش جهت تحویل است. سرویس ارسال می‌تواند پیام دستگاهی را که موقتاً در دسترس نیست، تا پایان این مدت در صف نگه دارد؛ بعد از انقضا، آنلاین‌شدن دستگاه پیام منقضی‌شده را دوباره معتبر نمی‌کند.
TTL را نباید با زمان ذخیره‌سازی دائمی یا آرشیو رویدادها اشتباه گرفت. مقدار طولانی‌تر فقط فرصت بیشتری برای تحویل ایجاد می‌کند و تضمین نمی‌دهد که پیام تا آن زمان نگه‌داری شود یا حتماً نمایش داده شود. مقدار نهایی و محدودیت مسیر ارسال را باید در پیکربندی واقعی همان سرویس بررسی کرد. در FCM نیز عمر پیام بر تحویل هنگام آفلاین‌بودن اثر دارد و به‌معنای نگه‌داری نامحدود نیست: مستندات تنظیم طول عمر پیام در FCM.
TTL صفر برای پیام‌هایی مناسب است که پس از تأخیر ارزش خود را از دست می‌دهند؛ در این حالت نباید برای اتصال بعدی دستگاه روی ذخیره‌شدن پیام حساب کرد. برای پیشنهاد محدود، هشدار لحظه‌ای یا وضعیت کوتاه‌عمر، TTL باید با پایان اعتبار محتوا هماهنگ باشد، نه صرفاً با بیشترین زمان ممکن.
سناریوهای آفلاین و آنلاین‌شدن دستگاه
| وضعیت فرضی | برداشت درست |
|---|---|
| پیام با عمر دو ساعت ارسال شده و دستگاه پس از سی دقیقه وصل می‌شود | در صورت معتبر بودن اشتراک و دسترسی مسیر پوش، امکان تحویل وجود دارد؛ نمایش همچنان تضمین نیست. |
| دستگاه سه ساعت بعد وصل می‌شود | انتظار دریافت همان پیام دو ساعته منطقی نیست، چون عمر محتوایی آن گذشته است. |
| دستگاه آنلاین است اما اعلان دیده نمی‌شود | آنلاین‌بودن به‌تنهایی مجوز اعلان، اجرای سرویس‌ورکر و نمایش موفق را ثابت نمی‌کند. |
| چند پیام وضعیت پشت‌سرهم ارسال شده‌اند | ممکن است پیام‌های در حال انتقال با سیاست جایگزینی یا ادغام کنار گذاشته شوند؛ همه نسخه‌ها الزاماً به مقصد نمی‌رسند. |
مثلاً فرض کنید وضعیت سفارش از «در حال آماده‌سازی» به «ارسال‌شده» تغییر کرده است. اگر کاربر چند ساعت آفلاین باشد، نمایش وضعیت قدیمی بعد از اتصال می‌تواند گمراه‌کننده باشد. بهتر است اعلان فقط کاربر را به صفحه‌ای هدایت کند که آخرین وضعیت را از سرور می‌خواند؛ تاریخچه معتبر نیز در سامانه اصلی نگه‌داری شود، نه در صف اعلان.
از پذیرش ارسال تا نمایش اعلان
مسیر را به چند مرحله جدا تقسیم کنید تا گزارش‌ها اشتباه تفسیر نشوند:
- پذیرش در سرور ارسال: سرویس پوش یا سامانه واسط درخواست را دریافت می‌کند. این مرحله فقط نشان می‌دهد درخواست از نظر فنی پذیرفته شده یا برای پردازش در صف قرار گرفته است.
- تلاش برای تحویل: مسیر ارسال با استفاده از اشتراک یا توکن ذخیره‌شده تلاش می‌کند پیام را به دستگاه برساند. انقضا، توکن نامعتبر، قطع شبکه یا سیاست‌های پلتفرم می‌تواند این تلاش را متوقف کند.
- اجرای دریافت در مقصد: مرورگر یا برنامه پیام را دریافت و منطق مربوط به حالت پیش‌زمینه یا پس‌زمینه را اجرا می‌کند. رفتار این دو حالت همیشه یکسان نیست.
- نمایش اعلان: در وب، کد سرویس‌ورکر باید اعلان قابل‌مشاهده را با
showNotificationایجاد کند. گزارش موفق این مرحله نیز فقط نشانه نمایش فنی است، نه اثبات اینکه انسان متن را خوانده یا روی آن کلیک کرده است.
در پوشفا، گزارش‌های ارسال و کلیک و APIهای سرور می‌توانند برای تفکیک مراحل و پایش وضعیت استفاده شوند؛ بااین‌حال، یک گزارش پذیرفته‌شدن درخواست یا حتی نمایش فنی را نباید معادل خوانده‌شدن پیام دانست. برای تحلیل، شناسه رویداد، زمان ارسال، زمان انقضا و نتیجه هر تلاش را در سامانه خود ثبت کنید.
محدودیت‌های مرورگر، سیستم‌عامل و دستگاه
- مجوز اعلان ممکن است قبلاً رد یا بعداً لغو شده باشد.
- کاربر می‌تواند اعلان را در تنظیمات سیستم خاموش کند یا کانال اعلان را بی‌صدا و مخفی کند.
- توکن یا اشتراک ممکن است پس از حذف داده‌های مرورگر، تغییر محیط یا لغو عضویت دیگر معتبر نباشد.
- حالت ذخیره باتری، محدودیت اجرای پس‌زمینه و قطع دسترسی شبکه می‌تواند زمان دریافت را تغییر دهد.
- دسترسی به اینترنت سایت با دسترسی پایدار به سرویس پوش یکسان نیست؛ آنلاین‌بودن صفحه، اتصال کامل مسیر اعلان را ثابت نمی‌کند.
- در اندروید ۱۳ و بالاتر، برنامه برای نمایش اعلان به مجوز زمان اجرا نیاز دارد و در اندروید ۸ به بعد، کانال‌های اعلان و تنظیمات کاربر روی نمایش اثر می‌گذارند.
وب‌پوش iOS نیز قاعده مخصوص خود را دارد: در iOS و iPadOS نسخه ۱۶٫۴ به بعد، وب‌اپی که به صفحه اصلی افزوده شده می‌تواند پس از یک اقدام مستقیم کاربر درخواست مجوز پوش کند؛ یک تب معمولی را نباید با وب‌اپ صفحه اصلی یکسان فرض کرد. جزئیات این محدودیت در توضیح WebKit درباره وب‌پوش در iOS و iPadOS آمده است.
در وب‌کیت، حذف نمایش اعلان برای ساختن یک پوش بی‌صدا راهکار عمومی و قابل اتکایی نیست؛ وب‌پوش باید اعلان قابل‌مشاهده ایجاد کند. بنابراین برای همگام‌سازی پنهانی یا اجرای تضمین‌شده کار در پس‌زمینه، معماری وب را بر چنین فرضی بنا نکنید.
برای مقایسه جزئیات مجوزها و تفاوت محیط‌ها، مطالعه مقایسه پوش نوتیفیکیشن اندروید و iOS مفید است.
طراحی پیام برای تأخیر و تازگی محتوا
محتوای پیام باید با احتمال تأخیر سازگار باشد. برای پیشنهاد، حراج یا کد تخفیف، تاریخ پایان را هم در متن یا صفحه مقصد بررسی کنید و پس از پایان کمپین، اعلان قدیمی را بی‌اعتبار بدانید. برای وضعیت سفارش، به‌جای قرار دادن جزئیات ثابت در متن، لینک صفحه‌ای را بدهید که وضعیت تازه را از سرور می‌گیرد.
- رویدادهای قابل جایگزینی: برای وضعیت لحظه‌ای، نگه‌داشتن آخرین وضعیت معمولاً از انباشته‌شدن چند اعلان قدیمی مفیدتر است. در FCM، ادغام پیام‌های در انتظار انتقال با جایگزین‌شدن اعلان نمایشی یکی نیست و تنظیمات پلتفرم‌ها تفاوت دارد؛ بنابراین
collapse_idیا سازوکار مشابه را معادل حذف قطعی اعلان‌های قبلی در همه محیط‌ها ندانید. - رویدادهای تاریخی: اگر هر رخداد اهمیت دارد، آن را در پایگاه داده یا حساب کاربر ذخیره کنید و اعلان را فقط به‌عنوان اطلاع‌رسانی کوتاه به کار ببرید.
- پیام‌های زمان‌دار: زمان انقضا، زمان ارسال و اعتبار صفحه مقصد باید یکدیگر را نقض نکنند. تأخیر نباید کاربر را به پیشنهاد تمام‌شده یا اطلاعات حساس قدیمی هدایت کند.
ارسال مجدد کورکورانه نیز راه‌حل مناسبی نیست؛ ممکن است پس از یک تأخیر موقت، همان پیام دوباره نمایش داده شود. پیش از تکرار، وضعیت آخرین تلاش، اعتبار اشتراک و شناسه رویداد را بررسی کنید.
برای لینک کمپین، برچسب‌های UTM را ثابت و قابل تحلیل نگه دارید و اطلاعات شخصی را در URL قرار ندهید. این کار به تفکیک کلیک کمک می‌کند، اما کلیک را نباید با تحویل یا خواندن اعلان یکی دانست.
چک‌لیست بررسی پیام دریافت‌نشده
- زمان پذیرش ارسال و عمر تعیین‌شده پیام را ثبت کنید؛ شاید پیام پیش از اتصال منقضی شده باشد.
- بررسی کنید شناسه اشتراک یا توکن هنوز معتبر است و کاربر عضویت خود را لغو نکرده است.
- مجوز اعلان مرورگر و تنظیمات سیستم‌عامل را در همان دستگاه و همان مرورگر بررسی کنید.
- در اندروید، کانال اعلان، سطح اهمیت و حالت بی‌صدا را کنترل کنید.
- در iOS، بررسی کنید کاربر وب‌اپ را به صفحه اصلی افزوده و مجوز را در همان محیط صادر کرده باشد.
- لاگ سرویس‌ورکر، اجرای موفق
showNotificationو خطاهای دریافت را جداگانه بررسی کنید. - نتیجه پذیرش درخواست، نتیجه تلاش برای تحویل، گزارش نمایش فنی و کلیک را در چهار ستون جدا ثبت کنید.
- اگر محتوا منقضی شده، به‌جای ارسال همان متن، صفحه تازه یا پیام جدیدی با اعتبار روشن ارائه کنید.
اگر مشکل تکرار می‌شود، یک آزمایش کنترل‌شده با یک دستگاه، یک اشتراک تازه، شبکه پایدار و پیام کوتاه انجام دهید؛ سپس هر متغیر را جداگانه تغییر دهید. این روش بهتر از نتیجه‌گیری از یک گزارش کلی مانند «ارسال موفق» است.
برای مشکلاتی که پیام در پنل ارسال‌شده دیده می‌شود اما روی دستگاه ظاهر نمی‌شود، راهنمای دلایل ارسال‌شدن و دریافت‌نشدن وب‌پوش را هم بررسی کنید.
پرسش‌های متداول
آیا با آنلاین‌شدن دستگاه، همه پیام‌های قبلی نمایش داده می‌شوند؟
خیر. فقط پیام‌هایی که هنوز منقضی نشده‌اند و از نظر اشتراک، شبکه، مجوز و سیاست پلتفرم شرایط تحویل دارند ممکن است برسند. نمایش همه پیام‌های صف تضمین نمی‌شود.
آیا پاسخ موفق API یعنی کاربر اعلان را دیده است؟
خیر. پاسخ موفق معمولاً به پذیرش درخواست یا ثبت پردازش مربوط است. حتی گزارش نمایش موفق فنی فقط اجرای نمایش اعلان را نشان می‌دهد و خواندن یا کلیک کاربر را ثابت نمی‌کند.
برای پیام‌های مهم، TTL را خیلی طولانی بگذاریم؟
نه لزوماً. عمر پیام باید با ارزش و تازگی محتوا هماهنگ باشد. برای رخدادهای مهم، سابقه را در سامانه اصلی نگه دارید و در صورت نیاز، با رضایت کاربر مسیر ارتباطی مناسب دیگری طراحی کنید؛ صف پوش آرشیو قابل اتکایی برای همه رویدادها نیست.