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

Collapse ID چیست؟ تفاوت ادغام پیام و جایگزینی اعلان

۱۴۰۵-۰۴-۱۸ احسان
Collapse ID چیست؟ تفاوت ادغام پیام و جایگزینی اعلان

پاسخ کوتاه: Collapse ID دقیقاً چه چیزی را یکی می‌کند؟

Collapse ID به‌تنهایی یک استاندارد مشترک برای همه پلتفرم‌ها نیست؛ یک نام محصولی برای گروه‌بندی پیام‌های هم‌موضوع است. در Android معمولاً این ایده با collapse_key در Firebase Cloud Messaging یا FCM اجرا می‌شود، در APNs با هدر apns-collapse-id و در اعلان مرورگر با گزینه tag در زمان نمایش.

در این مقاله:

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

اگر مسئله شما عیب‌یابی نرسیدن اعلان است، راهنمای دلایل ارسال‌شدن و دریافت‌نشدن وب‌پوش را هم ببینید.

تفاوت صف انتقال با اعلان نمایش‌داده‌شده

برای فهم رفتار Collapse ID، مسیر پیام را به دو مرحله تقسیم کنید. در مرحله اول، پیام هنوز به مقصد نرسیده یا دستگاه آفلاین است و سرویس انتقال درباره نگه‌داری، انقضا یا ادغام آن تصمیم می‌گیرد. در مرحله دوم، پیام به دستگاه رسیده و برنامه یا Service Worker آن را با showNotification نمایش می‌دهد. این دو مرحله نتیجه یکسانی ندارند.

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

TTL نیز فقط مدت اعتبار پیام برای تلاش تحویل در زمان آفلاین‌بودن است؛ TTL به معنی ذخیره نامحدود یا تضمین تحویل نیست. جزئیات این تفاوت در مستندات طول عمر پیام FCM توضیح داده شده است.

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

جریان ارسال از سرور تا مرورگر با Collapse ID

تفاوت Android، iOS و مرورگر

Android و FCM collapse_key

در Android، collapse_key تنظیمی در مسیر FCM است که برای پیام‌های قابل‌ادغام به کار می‌رود. کاربرد آن زمانی منطقی است که آخرین وضعیت یک موضوع از نسخه‌های قبلی مهم‌تر باشد؛ مانند وضعیت سفارش، شمارنده پیام‌های خوانده‌نشده یا آخرین وضعیت یک رخداد فنی.

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

iOS و APNs apns-collapse-id

در اعلان‌های بومی iOS، هدر apns-collapse-id شناسه‌ای برای پیام‌هایی است که درباره یک موضوع مشترک هستند. APNs می‌تواند پیام‌های معلق با شناسه مشابه را در مسیر تحویل ادغام کند، اما این هدر به‌تنهایی فرمان پاک‌کردن اعلان‌های قبلاً تحویل‌شده نیست.

این اصطلاح را با tag مرورگر یکی نگیرید. APNs بخشی از مسیر سرویس اعلان اپل است؛ tag در API اعلان مرورگر هنگام ساخت اعلان در سمت کلاینت استفاده می‌شود. وب‌پوش در iOS نیز شرایط مخصوص خود را دارد: در iOS و iPadOS 16.4 به بعد، وب‌اپی که به صفحه اصلی اضافه شده می‌تواند پس از اقدام مستقیم کاربر اجازه اعلان بخواهد؛ این رفتار را نباید به همه تب‌های عادی تعمیم داد. جزئیات در توضیح WebKit درباره وب‌پوش در iOS و iPadOS آمده است.

مرورگر و Notification tag

Notification tag در گزینه‌های اعلان مرورگر، یک شناسه نمایشی است. اگر Service Worker برای اعلان‌های هم‌موضوع tag یکسان بدهد، مرورگر می‌تواند اعلان قبلیِ همان tag را هنگام نمایش نسخه جدید جایگزین یا به‌روزرسانی کند. این رفتار پس از رسیدن پیام و اجرای کد نمایش اتفاق می‌افتد، نه در صف FCM یا APNs.

self.registration.showNotification(payload.title, { body: payload.body, tag: payload.tag })

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

طراحی شناسه و انتخاب پیام‌های قابل ادغام

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

  • order-872193-status برای آخرین وضعیت یک سفارش؛
  • ticket-4412-reply برای آخرین پاسخ یک تیکت؛
  • incident-2026-status برای وضعیت یک رخداد فنی؛
  • product-554-price برای آخرین تغییر قیمت یک محصول.

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

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

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

اینفوگرافیک مزایای Collapse ID برای پوش نوتیفیکیشن

کار با Collapse ID در معماری پوشفا

پوشفا از FCM استفاده می‌کند و توکن‌های مشترکان را نگه‌داری می‌کند؛ بنابراین Collapse ID در معماری آن باید یک تصمیم در سمت سرور و محصول باشد، نه یک ادعای یکسان‌سازی رفتار همه دستگاه‌ها. پوشفا فیلد اختیاری collapse_id را در API پشتیبانی می‌کند، اما معنای نهایی آن همچنان به پلتفرم مقصد و مرحله‌ای که پیام در آن قرار دارد وابسته است.

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

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

چک‌لیست آزمایش و گزارش‌گیری

  1. برای یک موضوع، دو یا سه پیام متوالی با شناسه یکسان بفرستید و حالت دستگاه آنلاین و آفلاین را جدا آزمایش کنید.
  2. بررسی کنید آیا ادغام فقط در صف رخ داده یا اعلانِ قبلاً نمایش‌داده‌شده نیز در رابط دستگاه جایگزین شده است.
  3. در Android، کانال اعلان، اجازه اعلان و تنظیمات باتری را ثبت کنید؛ در Android 13 به بعد اجازه اعلان یک مرحله runtime است.
  4. در iOS، رفتار APNs را از رفتار وب‌اپ نصب‌شده و تب عادی جدا کنید.
  5. در مرورگر، tag یکسان و tag متفاوت را با چند نسخه مرورگر آزمایش کنید و نتیجه را به‌عنوان رفتار آزموده‌شده همان محیط مستند کنید.
  6. برای پیام‌های مستقل، یکسان‌بودن شناسه را ممنوع کنید و در سمت سرور اعتبارسنجی داشته باشید.
  7. شناسه، زمان ارسال، پلتفرم، وضعیت نمایش، کلیک و لینک مقصد را در گزارش ثبت کنید؛ اما محتوای حساس را در لاگ یا URL نگذارید.

برای FCM نیز تفاوت پیام‌های notification و data مهم است؛ رفتار foreground و background می‌تواند یکسان نباشد. به همین دلیل، تست باید هم با برنامه باز و هم در پس‌زمینه انجام شود.

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

آیا Collapse ID اعلان قبلی را حتماً حذف می‌کند؟

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

آیا collapse_key، apns-collapse-id و tag یکی هستند؟

خیر. collapse_key در FCM و apns-collapse-id در APNs به مسیرهای انتقال پلتفرمی مربوط‌اند، اما tag عمدتاً شناسه جایگزینی در مرحله نمایش اعلان مرورگر است.

برای وضعیت سفارش از کدام سازوکار استفاده کنیم؟

در سمت سرور یک شناسه موضوعی مانند order-872193-status تعریف کنید، سپس تنظیم متناسب پلتفرم را اعمال و نمایش واقعی را جداگانه آزمایش کنید. برای رسید پرداخت یا هر رویداد مستقل، شناسه مشترک نسازید.

آیا Collapse ID در Pushfa قابل استفاده است؟

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