بروزرسانی پوش نوتیفیکیشن با Collapse ID؛ راهنمای کامل جلوگیری از اعلان‌های تکراری

مقدمه

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

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

در ادبیات فنی، این رفتار با نام‌هایی مثل collapse_key در Firebase Cloud Messaging، Topic در Web Push، یا در سطح محصول با عنوان Collapse ID شناخته می‌شود. هدف نهایی یکی است: وقتی چند پیام هم‌خانواده برای یک کاربر ارسال می‌شوند و هنوز پیام قبلی تحویل یا دیده نشده، فقط آخرین و مهم‌ترین وضعیت نگهداری شود. مستندات Firebase توضیح می‌دهد که برای collapsible message در Android باید پارامتر collapse_key در payload قرار بگیرد و FCM برای هر دستگاه تعداد محدودی کلید collapse را نگه می‌دارد. همچنین در کتابخانه‌های Web Push، گزینه topic به‌عنوان شناسه‌ای برای coalesce یا یکی‌کردن پیام‌های مشابه معرفی شده است.

در این مقاله، Collapse ID را نه به‌عنوان یک اصطلاح خشک فنی، بلکه به‌عنوان یک ابزار رشد، تجربه کاربری و کاهش نویز بررسی می‌کنیم. همچنین توضیح می‌دهیم چه زمانی باید از آن استفاده کنید، چه زمانی نباید، چه تفاوتی با Tag و Topic دارد، چطور در سناریوهای واقعی مثل فروشگاه، بانک، CRM، مانیتورینگ، تاکسی اینترنتی و سامانه‌های پشتیبانی به کار می‌آید، و چطور می‌توان آن را در یک سرویس پوش نوتیفیکیشن مثل Pushfa به‌صورت محصولی و قابل فهم برای تیم مارکتینگ پیاده‌سازی کرد.

فهرست مطالب

مقدمه

Collapse ID چیست؟

چرا اعلان‌های تکراری به تجربه کاربر آسیب می‌زنند؟

Collapse ID دقیقاً چه کاری انجام می‌دهد؟

تفاوت Collapse ID با Notification Tag و Topic

چرا گوگل و سرویس‌های Push این قابلیت را اضافه کردند؟

کاربرد Collapse ID در فروشگاه اینترنتی

کاربرد Collapse ID در بانک، فین‌تک و پرداخت

کاربرد در تاکسی اینترنتی و لجستیک

کاربرد در CRM و اتوماسیون بازاریابی

کاربرد در مانیتورینگ سرور و DevOps

کاربرد در بورس، قیمت و داده‌های لحظه‌ای

کاربرد در IoT و دستگاه‌های هوشمند

مزایای Collapse ID برای تجربه کاربری

مزایای غیرمستقیم برای SEO و رشد

ساختار نام‌گذاری Collapse ID

نمونه payload برای FCM

نمونه Web Push با Topic و Tag

تفاوت پیام Collapsible و Non-collapsible

اشتباهات رایج در استفاده از Collapse ID

معماری پیشنهادی برای Pushfa

چک‌لیست فنی قبل از انتشار قابلیت

بهترین الگوهای عملی

چه زمانی نباید از Collapse ID استفاده کنیم؟

پیاده‌سازی راحت Collapse ID با سرویس پوشفا

نتیجه‌گیری

سوالات متداول

منابع پیشنهادی برای مطالعه بیشتر

Collapse ID چیست؟

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

برای ساده‌سازی، Collapse ID را مثل شماره پرونده تصور کنید. اگر موضوع اعلان «سفارش شماره ۱۲۳۴» باشد، هر تغییر وضعیت مربوط به همین سفارش می‌تواند یک Collapse ID مشترک داشته باشد. در این حالت، به جای اینکه کاربر چند اعلان جداگانه درباره همان سفارش دریافت کند، آخرین پیام مرتبط با سفارش به او نمایش داده می‌شود.

نمونه ساده:

• پیام اول: سفارش شما ثبت شد.

• پیام دوم: سفارش شما در حال آماده‌سازی است.

• پیام سوم: سفارش شما تحویل پیک شد.

• پیام چهارم: پیک نزدیک آدرس شماست.

اگر هر چهار پیام بدون Collapse ID ارسال شوند، ممکن است هر چهار مورد در Notification Center باقی بمانند. اما اگر همه آن‌ها Collapse ID یکسانی مانند order_1234_status داشته باشند، سیستم می‌تواند نسخه قدیمی‌تر را با نسخه جدیدتر جایگزین کند. در نتیجه، پیام نهایی برای کاربر معنی‌دارتر و تمیزتر است.

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

چرا اعلان‌های تکراری به تجربه کاربر آسیب می‌زنند؟

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

وقتی کاربر چند اعلان مشابه از یک برند می‌بیند، ذهن او سه برداشت منفی پیدا می‌کند. اول اینکه سیستم بی‌نظم است. دوم اینکه برند به زمان و آرامش او احترام نمی‌گذارد. سوم اینکه اعلان‌های بعدی احتمالاً ارزش خواندن ندارند. این سه برداشت، به مرور نرخ کلیک، نرخ نگهداری opt-in و حتی تصویر برند را خراب می‌کند.

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

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

Collapse ID دقیقاً چه کاری انجام می‌دهد؟

Collapse ID معمولاً در یکی از سه سطح اثر می‌گذارد:

۱. سطح صف ارسال

اگر کاربر آفلاین باشد یا دستگاه در لحظه قابل دسترس نباشد، push service ممکن است چند پیام را در صف نگه دارد. وقتی چند پیام با یک collapse identifier مشترک وجود داشته باشد، سرویس می‌تواند پیام‌های قبلی را کنار بگذارد و فقط آخرین پیام را نگه دارد. این رفتار در سیستم‌هایی مثل FCM با collapse_key شناخته می‌شود.

۲. سطح نمایش اعلان

گاهی پیام به دستگاه رسیده، اما هنوز اعلان قبلی روی دستگاه وجود دارد. در این حالت، با استفاده از شناسه‌هایی مثل notification tag در سمت مرورگر یا شناسه کانال/نوتیفیکیشن در اپلیکیشن، می‌توان اعلان قبلی را جایگزین کرد. این لایه بیشتر به کد کلاینت، Service Worker یا اپلیکیشن موبایل مربوط است.

۳. سطح منطق محصول

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

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

تفاوت Collapse ID با Notification Tag و Topic

یکی از دلایل سردرگمی توسعه‌دهندگان این است که اصطلاحات مختلف در پلتفرم‌های مختلف استفاده می‌شود. Collapse ID، collapse_key، Topic و Notification Tag گاهی شبیه هم به نظر می‌رسند، اما دقیقاً یک چیز نیستند.

Collapse ID

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

collapse_key در FCM

در Firebase Cloud Messaging برای پیام‌های collapsible در Android از collapse_key استفاده می‌شود. طبق مستندات Firebase، برای علامت‌گذاری پیام به‌عنوان collapsible باید این پارامتر در payload قرار بگیرد. همچنین FCM به صورت همزمان تعداد محدودی collapse key برای هر دستگاه نگه می‌دارد. بنابراین نباید برای هر پیام یک کلید تصادفی بسازید؛ چون فلسفه collapse از بین می‌رود و محدودیت پلتفرم هم می‌تواند باعث رفتار غیرقابل پیش‌بینی شود.

Topic در Web Push

در Web Push، Topic می‌تواند برای یکی‌کردن یا coalescing پیام‌ها به کار رود. بعضی کتابخانه‌ها مثل web-push این گزینه را با نام topic ارائه می‌کنند و آن را شناسه‌ای برای ادغام اعلان‌ها می‌دانند. محدودیت‌های کاراکتری و پشتیبانی مرورگرها باید در طراحی در نظر گرفته شود. بنابراین بهتر است روی رفتار قطعی یکسان در همه مرورگرها حساب نکنید و در کنار آن، منطق کلاینت مثل tag در Notification API را هم پیاده‌سازی کنید.

Notification Tag

tag در Notification API بیشتر به مرحله نمایش اعلان مربوط است. اگر در Service Worker هنگام نمایش نوتیفیکیشن از یک tag مشترک استفاده کنید، مرورگر می‌تواند اعلان قبلی با همان tag را جایگزین کند. تفاوت مهم این است که tag معمولاً بعد از رسیدن پیام به مرورگر اثر دارد، اما collapse key یا Topic می‌تواند قبل از رسیدن پیام و در صف push service اثر بگذارد.

به زبان ساده:

• Collapse ID: مفهوم محصولی و عمومی.

• FCM collapse_key: کنترل ادغام در مسیر ارسال FCM برای Android.

• Web Push Topic: کمک به ادغام پیام‌ها در سطح push service.

• Notification tag: جایگزینی اعلان در سطح نمایش مرورگر.

چرا گوگل و سرویس‌های Push این قابلیت را اضافه کردند؟

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

Collapse messageها برای سناریوهایی طراحی شده‌اند که «آخرین وضعیت» از همه نسخه‌های قبلی مهم‌تر است. مثلاً در اپلیکیشن هواشناسی، اگر دمای فعلی چند بار تغییر کند، لازم نیست همه آپدیت‌های قبلی نمایش داده شوند. آخرین دما کافی است. در اپلیکیشن ورزشی، اگر نتیجه زنده بازی از ۱-۰ به ۲-۰ تغییر کند، کاربر معمولاً به آخرین نتیجه نیاز دارد، نه یک آرشیو کامل از هر تغییر.

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

کاربرد Collapse ID در فروشگاه اینترنتی

فروشگاه‌های اینترنتی یکی از بهترین نمونه‌ها برای استفاده از Collapse ID هستند. هر سفارش چند مرحله دارد و هر مرحله می‌تواند یک اعلان تولید کند. اما نمایش همه این مراحل همیشه مفید نیست. برای مثال، کاربر به آخرین وضعیت سفارش نیاز دارد، نه لزوماً همه تغییرات پشت سر هم.

ساختار پیشنهادی:

order_{{order_id}}_status

مثلاً:

order_872193_status

با این ساختار، تمام اعلان‌های وضعیت سفارش ۸۷۲۱۹۳ در یک خانواده قرار می‌گیرند. اگر پیام «سفارش شما در حال آماده‌سازی است» هنوز دیده نشده و پیام «سفارش شما تحویل پیک شد» ارسال شود، نسخه جدیدتر جایگزین نسخه قبلی می‌شود.

این الگو در موارد زیر بسیار کاربردی است:

• تغییر وضعیت سفارش

• تغییر زمان تحویل

• بروزرسانی کد رهگیری

• موجود شدن کالای مورد علاقه

• تغییر قیمت کالای دنبال‌شده

• یادآوری سبد خرید در چند مرحله

اما باید مراقب باشید پیام‌های متفاوت را اشتباه collapse نکنید. مثلاً اعلان «پرداخت ناموفق» و «کد تخفیف جدید» نباید Collapse ID یکسان داشته باشند، حتی اگر هر دو برای یک کاربر ارسال شده‌اند. Collapse ID باید بر اساس موضوع پیام ساخته شود، نه فقط شناسه کاربر.

کاربرد Collapse ID در بانک، فین‌تک و پرداخت

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

اما در بعضی سناریوها Collapse ID عالی عمل می‌کند:

• وضعیت بررسی درخواست وام

• بروزرسانی مرحله احراز هویت

• وضعیت تیکت پشتیبانی مالی

• تغییر وضعیت درخواست کارت

• اطلاع‌رسانی نرخ یا قیمت لحظه‌ای برای واچ‌لیست

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

loan_{{request_id}}_status

در فین‌تک، اصل طلایی این است: پیام‌های وضعیت‌محور قابل collapse هستند؛ پیام‌های امنیتی و تراکنشی مستقل معمولاً نباید collapse شوند.

کاربرد در تاکسی اینترنتی و لجستیک

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

Collapse ID پیشنهادی:

ride_{{ride_id}}_driver_status

نمونه پیام‌ها:

• راننده در مسیر شماست.

• راننده ۳ دقیقه دیگر می‌رسد.

• راننده به محل مبدا رسید.

• راننده منتظر شماست.

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

کاربرد در CRM و اتوماسیون بازاریابی

در CRM، تیم مارکتینگ معمولاً چند کمپین همزمان دارد. اگر کاربر در چند segment قرار بگیرد، ممکن است چند پیام مشابه دریافت کند. Collapse ID می‌تواند کمک کند پیام‌های یک مسیر اتوماسیون به شکل هوشمند کنترل شوند.

مثلاً در کمپین بازگشت کاربر، ممکن است سه پیام طراحی شده باشد:

• هنوز منتظرت هستیم.

• تخفیف اختصاصی شما فعال شد.

• آخرین فرصت استفاده از تخفیف.

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

ساختار پیشنهادی:

campaign_{{campaign_id}}_user_{{user_id}}

یا در حالتی که برای حریم خصوصی و امنیت نمی‌خواهید شناسه مستقیم کاربر در payload باشد:

campaign_{{campaign_id}}_{{hash}}

در کمپین‌های مارکتینگ، Collapse ID نباید باعث حذف پیام‌های واقعاً مهم شود. بهتر است برای هر journey تعریف کنید که آیا پیام‌ها قابل جایگزینی هستند یا نه.

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

کاربرد در مانیتورینگ سرور و DevOps

یکی از حرفه‌ای‌ترین کاربردهای Collapse ID در مانیتورینگ است. فرض کنید یک سرور دچار افزایش مصرف CPU شده و سیستم مانیتورینگ هر دقیقه هشدار می‌فرستد. اگر هر هشدار جداگانه نمایش داده شود، تیم فنی با سیلی از اعلان‌ها روبه‌رو می‌شود. در چنین وضعیتی، Collapse ID می‌تواند هشدارهای تکراری یک incident را به یک اعلان زنده تبدیل کند.

Collapse ID پیشنهادی:

incident_{{incident_id}}_status

نمونه بروزرسانی:

• CPU سرور بالا رفت.

• CPU همچنان بالاست.

• مصرف CPU به ۹۵٪ رسید.

• مشکل برطرف شد.

این ساختار باعث می‌شود تیم فقط آخرین وضعیت حادثه را ببیند. البته برای escalation، مثلاً وقتی incident از warning به critical تبدیل می‌شود، ممکن است بخواهید علاوه بر collapse، صدای هشدار یا اولویت بالاتر هم تنظیم کنید.

کاربرد در بورس، قیمت و داده‌های لحظه‌ای

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

مثلاً:

price_BTC_USDT_alert

یا:

watchlist_{{symbol}}_threshold

اگر قیمت بیت‌کوین چند بار از سطح هشدار عبور کند، کاربر به آخرین وضعیت نیاز دارد. البته اگر کاربر چند هشدار مختلف تعریف کرده باشد، مثل عبور از ۶۰ هزار و سپس ۶۵ هزار، بهتر است برای هر rule یک Collapse ID مستقل داشته باشید.

کاربرد در IoT و دستگاه‌های هوشمند

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

نمونه:

device_{{device_id}}_battery

device_{{device_id}}_temperature

device_{{device_id}}_connectivity

با این روش، هشدار باتری یک دستگاه با هشدار دمای همان دستگاه قاطی نمی‌شود، اما هر کدام در خانواده خودش بروزرسانی می‌شود.

مزایای Collapse ID برای تجربه کاربری

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

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

مزایای غیرمستقیم برای SEO و رشد

ممکن است بپرسید Collapse ID چه ربطی به SEO دارد؟ از نظر مستقیم، گوگل به خاطر استفاده از Collapse ID رتبه صفحه شما را بالا نمی‌برد. اما از نظر رشد محصول و بازگشت کاربر، این قابلیت می‌تواند اثر غیرمستقیم داشته باشد.

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

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

ساختار نام‌گذاری Collapse ID

یکی از اشتباهات رایج این است که تیم‌ها Collapse ID را بدون استاندارد می‌سازند. گاهی یک توسعه‌دهنده از order-status استفاده می‌کند، دیگری از order_123, و نفر سوم از یک UUID تصادفی. نتیجه این است که سیستم قابل پیش‌بینی نیست.

یک استاندارد خوب باید این ویژگی‌ها را داشته باشد:

• کوتاه باشد.

• معنی‌دار باشد.

• شامل نوع موجودیت باشد.

• شامل شناسه موضوع باشد.

• شامل نوع بروزرسانی باشد.

• از اطلاعات حساس مستقیم استفاده نکند.

• در محدودیت‌های پلتفرم جا شود.

• برای تعداد زیادی پیام، کلیدهای بی‌نهایت و بی‌هدف نسازد.

فرمت پیشنهادی:

{{entity}}_{{entity_id}}_{{event_type}}

نمونه‌ها:

order_872193_status

ticket_4412_reply

ride_991_arrival

incident_2026_cpu

product_554_price

اگر محدودیت طول دارید، از hash کوتاه استفاده کنید:

o_9f2a_status

i_7bd1_alert

برای Web Push که topic ممکن است محدودیت کاراکتری داشته باشد، بهتر است شناسه‌ها را کوتاه و URL-safe نگه دارید. از فاصله، حروف خاص، ایموجی و کاراکترهای فارسی در خود شناسه فنی استفاده نکنید، حتی اگر متن اعلان فارسی است.

نمونه payload برای FCM

نمونه زیر برای درک ساختار است و باید با معماری واقعی شما تطبیق داده شود:

{  "message": {    "token": "USER_DEVICE_TOKEN",    "android": {      "collapse_key": "order_872193_status",      "priority": "high",      "notification": {        "title": "وضعیت سفارش شما بروزرسانی شد",        "body": "سفارش شما تحویل پیک شد."      }    },    "data": {      "collapse_id": "order_872193_status",      "type": "order_status",      "order_id": "872193",      "url": "https://example.com/orders/872193"    }  } }

نکته مهم این است که collapse_key در لایه Android قرار گرفته، اما collapse_id در data هم تکرار شده تا backend، analytics و client بتوانند آن را بفهمند. این تکرار آگاهانه است، نه اضافه‌کاری. داده محصولی باید برای گزارش‌گیری و رفتار سمت کلاینت قابل دسترس باشد.

نمونه Web Push با Topic و Tag

در Web Push می‌توان از topic برای coalescing در سطح ارسال و از tag برای جایگزینی اعلان در سطح نمایش استفاده کرد. نمونه مفهومی:

webpush.sendNotification(subscription, JSON.stringify({  title: "وضعیت سفارش شما بروزرسانی شد",  body: "سفارش شما تحویل پیک شد.",  tag: "order_872193_status",  url: "/orders/872193" }), {  TTL: 3600,  urgency: "high",  topic: "ord872193status" });

در Service Worker:

self.addEventListener("push", event => {  const payload = event.data.json();  event.waitUntil(    self.registration.showNotification(payload.title, {      body: payload.body,      tag: payload.tag,      renotify: false,      data: {        url: payload.url,        collapse_id: payload.tag      }    })  ); });

در این نمونه، topic کوتاه و مناسب مسیر ارسال است، اما tag برای نمایش در مرورگر استفاده می‌شود. renotify: false کمک می‌کند در بعضی مرورگرها، جایگزینی اعلان با مزاحمت کمتر انجام شود. البته رفتار دقیق مرورگرها می‌تواند متفاوت باشد، پس همیشه تست عملی لازم است.

تفاوت پیام Collapsible و Non-collapsible

همه پیام‌ها نباید collapsible باشند. پیام collapsible زمانی مناسب است که نسخه‌های قبلی با رسیدن نسخه جدید بی‌ارزش یا کم‌ارزش می‌شوند. پیام non-collapsible زمانی مناسب است که هر پیام اهمیت مستقل دارد.

نمونه‌های مناسب برای collapsible:

• آخرین وضعیت سفارش

• آخرین موقعیت پیک

• آخرین قیمت یک نماد

• آخرین وضعیت incident

• آخرین مرحله درخواست وام

• آخرین تعداد پیام خوانده‌نشده

نمونه‌های نامناسب برای collapsible:

• کد ورود یک‌بارمصرف

• هشدار امنیتی مستقل

• رسید پرداخت

• اعلان برداشت از حساب

• پیام قانونی یا قراردادی

• هر پیام دارای الزام ثبت و پیگیری مستقل

اگر شک دارید، این سوال را بپرسید: «اگر کاربر فقط آخرین پیام را ببیند، چیزی مهم از دست می‌دهد؟» اگر پاسخ بله است، پیام را collapse نکنید. اگر پاسخ خیر است، Collapse ID گزینه خوبی است.

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

اشتباهات رایج در استفاده از Collapse ID

اشتباه اول: ساختن Collapse ID تصادفی

اگر برای هر پیام یک UUID جدید بسازید، دیگر چیزی collapse نمی‌شود. Collapse ID باید برای پیام‌های هم‌موضوع ثابت باشد.

اشتباه دوم: استفاده از یک Collapse ID برای همه پیام‌ها

اگر همه پیام‌های یک کاربر Collapse ID یکسان داشته باشند، پیام‌های غیرمرتبط همدیگر را حذف می‌کنند. مثلاً وضعیت سفارش نباید یادآوری پرداخت را حذف کند.

اشتباه سوم: قرار دادن اطلاعات حساس در شناسه

Collapse ID نباید شامل شماره موبایل، ایمیل، کد ملی یا اطلاعات حساس باشد. بهتر است از شناسه داخلی یا hash استفاده کنید.

اشتباه چهارم: نادیده گرفتن محدودیت پلتفرم

FCM برای collapse key محدودیت‌هایی دارد. Web Push topic هم از نظر طول و کاراکتر باید با احتیاط طراحی شود. پس نام‌گذاری باید کوتاه و پایدار باشد.

اشتباه پنجم: نبود گزارش‌گیری

اگر Collapse ID را در analytics ثبت نکنید، نمی‌فهمید چه پیام‌هایی جایگزین شده‌اند، چند پیام واقعاً به کاربر نمایش داده شده، و آیا نرخ کلیک بهتر شده یا نه.

معماری پیشنهادی برای Pushfa

برای یک سرویس پوش نوتیفیکیشن حرفه‌ای، Collapse ID نباید فقط یک فیلد مخفی در API باشد. باید به‌عنوان یک قابلیت قابل فهم برای کاربران پنل ارائه شود.

پیشنهاد محصولی:

1. در فرم ارسال پوش، بخشی با عنوان «شناسه بروزرسانی اعلان» اضافه شود.

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

3. چند preset آماده ارائه شود:

• وضعیت سفارش

• وضعیت تیکت

• بروزرسانی قیمت

• هشدار مانیتورینگ

• کمپین مرحله‌ای

4. در API، فیلد collapse_id اضافه شود.

5. در گزارش ارسال، ستون Collapse ID و تعداد پیام‌های جایگزین‌شده نمایش داده شود.

6. در مستندات، تفاوت collapse در Android، Web Push و نمایش مرورگر توضیح داده شود.

نمونه API پیشنهادی:

{  "audience": "segment:active_customers",  "title": "قیمت محصول مورد علاقه شما تغییر کرد",  "body": "محصولی که دنبال می‌کردید اکنون با قیمت جدید موجود است.",  "url": "https://pushfa.com",  "collapse_id": "product_554_price",  "ttl": 3600,  "urgency": "normal" }

این مدل برای تیم مارکتینگ ساده است و برای تیم فنی هم قابل پیاده‌سازی.

چک‌لیست فنی قبل از انتشار قابلیت

قبل از اینکه Collapse ID را در سیستم پوش خود فعال کنید، این موارد را بررسی کنید:

• آیا برای هر نوع پیام، سیاست collapse مشخص شده است؟

• آیا پیام‌های امنیتی از collapse مستثنی شده‌اند؟

• آیا Collapse ID کوتاه، پایدار و بدون داده حساس است؟

• آیا در Android از collapse_key درست استفاده شده است؟

• آیا در Web Push از topic و tag با احتیاط استفاده شده است؟

• آیا در Service Worker رفتار tag تست شده است؟

• آیا TTL با ماهیت پیام هماهنگ است؟

• آیا گزارش‌گیری برای پیام‌های جایگزین‌شده وجود دارد؟

• آیا تیم مارکتینگ می‌داند چه زمانی از این قابلیت استفاده کند؟

• آیا مستندات داخلی برای نام‌گذاری آماده شده است؟

بهترین الگوهای عملی

برای سفارش

order_{{order_id}}_status

برای همه تغییرات وضعیت یک سفارش.

برای تیکت پشتیبانی

ticket_{{ticket_id}}_reply

برای بروزرسانی آخرین پاسخ یا وضعیت تیکت.

برای قیمت محصول

product_{{product_id}}_price

برای تغییر قیمت یا موجودی یک محصول.

برای هشدار فنی

incident_{{incident_id}}_status

برای بروزرسانی وضعیت یک رخداد فنی.

برای پیام‌های خوانده‌نشده

inbox_{{user_hash}}_count

برای بروزرسانی تعداد پیام‌های جدید.

چه زمانی نباید از Collapse ID استفاده کنیم؟

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

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

پیاده‌سازی راحت Collapse ID با سرویس پوشفا

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

در مستندات پوشفا توضیح داده شده که Collapse ID یک رشته متنی دلخواه است و وقتی پیام جدیدی با همان Collapse ID ارسال شود، مرورگر از مسیر WebPush Topic header و اندروید از مسیر FCM collapse_key می‌تواند پیام قدیمی‌تر را با پیام جدیدتر جایگزین کند؛ البته این رفتار بیشتر روی اعلان‌هایی اثر دارد که هنوز توسط کاربر دیده یا بسته نشده‌اند.

برای استفاده عملی، کافی است در پنل ارسال پوش نوتیفیکیشن پوشفا بخش تنظیمات پیشرفته را باز کنید و مقدار مورد نظر را در فیلد Collapse ID وارد کنید. در ارسال API هم می‌توانید از پارامتر collapse_id در endpointهای ارسال کامل استفاده کنید. برای مثال در سناریوی نتیجه زنده مسابقه، مقدارهایی مثل live_score_match_42 باعث می‌شود هر بروزرسانی جدید امتیاز، اعلان قبلی همان مسابقه را به‌روز کند، نه اینکه چند اعلان تکراری روی دستگاه کاربر انباشته شود.

مزیت این رویکرد این است که تیم محصول یا مارکتینگ لازم نیست درگیر جزئیات متفاوت FCM، Web Push، مرورگرها و Service Worker شود. شما فقط منطق کسب‌وکار را مشخص می‌کنید: برای سفارش از ساختاری مثل order_9090_status، برای قیمت از stock_BTC، برای آب‌وهوا از weather_today و برای نتیجه زنده از live_score_123 استفاده می‌کنید. پوشفا این شناسه را در مسیرهای فنی لازم اعمال می‌کند و پیاده‌سازی را برای تیم شما قابل مدیریت‌تر می‌سازد.

برای مطالعه جزئیات فنی، نمونه درخواست API، محدودیت‌ها و مرورگرهای پشتیبانی‌شده، می‌توانید مستندات رسمی پوشفا را ببینید: راهنمای Collapse ID در پوشفا.

نتیجه‌گیری

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

برای کسب‌وکارهایی مثل فروشگاه اینترنتی، تاکسی اینترنتی، بانک، CRM، مانیتورینگ، بورس، IoT و سرویس‌های پشتیبانی، Collapse ID می‌تواند تفاوت بین یک سیستم اعلان مزاحم و یک سیستم اعلان هوشمند باشد. نکته مهم این است که Collapse ID باید با استراتژی درست، نام‌گذاری استاندارد، رعایت محدودیت پلتفرم و گزارش‌گیری دقیق پیاده‌سازی شود.

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

سوالات متداول

Collapse ID در پوش نوتیفیکیشن چیست؟

Collapse ID شناسه‌ای است که پیام‌های مرتبط با یک موضوع را در یک گروه قرار می‌دهد تا در صورت ارسال چند پیام مشابه، فقط آخرین پیام یا مهم‌ترین نسخه به کاربر نمایش داده شود.

آیا Collapse ID همان collapse_key در Firebase است؟

نه دقیقاً. Collapse ID یک مفهوم عمومی و محصولی است، اما collapse_key پیاده‌سازی این مفهوم در Firebase Cloud Messaging برای Android است.

آیا در Web Push هم می‌توان اعلان‌ها را collapse کرد؟

بله، در Web Push می‌توان از Topic برای coalescing در مسیر ارسال و از tag در Notification API برای جایگزینی اعلان در سطح نمایش استفاده کرد، اما باید رفتار مرورگرها تست شود.

آیا Collapse ID باعث حذف همه پیام‌های قبلی می‌شود؟

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

برای چه پیام‌هایی نباید Collapse ID استفاده کنیم؟

برای پیام‌های امنیتی، کد ورود، رسید تراکنش، برداشت از حساب، پیام‌های قانونی و هر پیامی که ارزش مستقل دارد، بهتر است از Collapse ID استفاده نشود.

بهترین ساختار نام‌گذاری Collapse ID چیست؟

ساختار پیشنهادی entity_entityId_eventType است؛ مثل order_872193_status یا ticket_4412_reply. این ساختار کوتاه، معنی‌دار و قابل گزارش‌گیری است.

آیا Collapse ID روی سئو اثر مستقیم دارد؟

اثر مستقیم ندارد، اما با بهبود تجربه کاربر، افزایش بازگشت، کاهش opt-out و افزایش تعامل می‌تواند به رشد کلی سایت و کمپین‌های بازگشتی کمک کند.

آیا Pushfa از Collapse ID پشتیبانی می‌کند؟

بله، پوشفا قابلیت Collapse ID را در مستندات خود معرفی کرده و می‌توانید آن را از مسیر پنل ارسال در تنظیمات پیشرفته یا از طریق پارامتر collapse_id در APIهای ارسال کامل استفاده کنید.