Firebase WebPush 技术能力调研

1. 传统 GCM WebPush 的优势与弊端

2. Firebase WebPush / GCM / HTTP/2 Server Push 对比

3. Service Worker 对 WebPush 的支持

1. 仅在 HTTPS 环境注册 navigator.serviceWorker.register()。
2. 通过 PushManager.subscribe() 与浏览器推送服务（如 FCM、Mozilla Push Service、WebPush Proxy）建立订阅，生成 endpoint 与公钥。
3. Service Worker 监听事件：
   • push — 收到推送数据
   • notificationclick — 用户点击通知
   • pushsubscriptionchange — 订阅失效时自动重新订阅

4. 基于 Service Worker 实现 WebPush 可用能力

5. Service Worker 生命周期与后台限制

1

安装 (install) ➜ 激活 (activate) ➜ 空闲 ➜ 事件触发 (如 push) ➜ 终止 (terminate)

• Chrome 桌面：浏览器未运行时，FCM 进程不会常驻；系统唤醒 Chrome 后才会触发 push 事件 → 通知存在延迟。
• Chrome Android：依赖系统级 FCM 组件，即使 Chrome 未启动也能收到通知。
• Firefox：后台进程 firefox --headless 维持 WebPush 通道；完全退出后无法收到。
• Safari：iOS 16.4+ 仅 PWA 安装后可收，可被 iOS “通知摘要””专注模式”限制。

规范：事件脚本须在 30 s 内 event.waitUntil() 结束；否则浏览器可能终止。

何时会被 Terminate？

• 脚本空闲继续 30 s（Chrome 桌面/Android）、≈ 2–3 min（Firefox）后，浏览器为释放内存而回收。
• 前台无相关页面且设备进入低电量 / 内存压力场景。
• 浏览器升级、标签崩溃或调用 registration.unregister()。
• 用户在设置中清除站点数据 / 缓存。

Terminate 后还能接收推送吗？

• 可以。终止仅意味着 运行时实例 被销毁，Service Worker 注册信息与 Push 订阅仍保留。
• 当下一条推送到达时，浏览器会”冷启动” Service Worker，再次触发 push 事件，随后可继续展示通知或执行逻辑。
• 若站点已被用户撤销通知权限、取消订阅或注销 SW，则后续推送不会再投递。

6. WebPush 延迟与优先级

• FCM 提供 priority: high (即时) / normal (省电，Doze 时可能批量投递)。
• TTL (time_to_live) 决定缓存时长 (0–2419200 s)。
• 实测在 Wi-Fi 环境 high 消息 < 1 s；移动网 + Doze 可能延迟 15 min+。

推送频率限制

最佳实践

1. 后端维护 Frequency Control：Redis 计数器或滑动窗口，按用户 & 通知类型限流，如 5/min, 20/day。
2. 在 Payload 中使用 collapse_key（FCM HTTP v1 可用 android.collapse_key、Web 可用 notification.tag）合并同类事件。
3. 对低优先级消息使用 priority=normal 并延长 ttl，让系统在省电模式下批量下发。
4. 监控 429/5xx 响应，对同一 token 采用指数退避避免被 FCM 封禁。
5. 观察 Chrome DevTools Application → Push Messaging 报告中的 Quota usage，避免触达上限（实验性）。

7. 到达率 / 点击率监控实现

1. 服务器侧：在 Firebase 控制台开启 Cloud Messaging Analytics，可自动收集到达、打开事件，结合 Google Analytics 报表展示。
2. 前端侧：在 push 事件里上报 “收到”; 在 notificationclick 里上报 “点击” 并 clients.openWindow。
3. 整合：可将 messageId 置于 payload，在前端回传即可关联。

自建统计服务方案

若不依赖 Firebase Analytics / BigQuery，可通过以下方式自行采集与计算送达、展示、点击等指标：

1. 事件模型设计
   定义统一的事件类型与字段，例如：
   • delivered —— Service Worker 收到 push 事件后立即上报。
   • displayed —— showNotification() 成功后上报（可在 Promise 解析后）。
   • clicked —— notificationclick 里上报。
   • closed —— notificationclose（部分浏览器支持）上报。
   建议字段：messageId、endpoint、token/registrationId、timestamp、userAgent、extra。

2. Service Worker 代码埋点

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

   // push 事件 self.addEventListener('push', event => { const data = event.data?.json() || {}; const { messageId } = data; event.waitUntil( fetch('/stats/track', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ type: 'delivered', messageId, ts: Date.now() }) }) ); // ...显示通知... }); self.addEventListener('notificationclick', event => { const { messageId } = event.notification.data || {}; event.waitUntil( fetch('/stats/track', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ type: 'clicked', messageId, ts: Date.now() }) }) ); });

3. 后端埋点收集
   搭建 /stats/track API（REST、GraphQL 或 gRPC）写入高性能时序/分析数据库：

   • 轻量场景：MySQL/PostgreSQL + 表分区。
   • 大规模：ClickHouse、Apache Druid、InfluxDB、Kafka ➜ Flink ➜ OLAP。
     同时保留发送日志（messageId, endpoint, sent_at），即可在离线任务中计算送达率、点击率、平均延迟等。

4. 离线与实时分析

   • 离线：每日批量 SQL 聚合或 Spark/Flink 批处理。
   • 实时：Flink / Kafka Streams 维表关联，分钟级监控仪表盘（Grafana、Superset、Metabase）。

5. 可靠性细节

   • 端上采用 navigator.sendBeacon 或 IndexedDB 队列，在离线时缓存数据，恢复网络后重传。
   • 为避免阻塞 push 事件，可使用 event.waitUntil() 并吞掉 fetch 异常。
   • HTTPS + CORS 配置，确保 SW 可向自建域名上报。

注意：Web Push 标准与 FCM 均 不提供官方投递回执（delivery receipt）。因此”送达”只能靠 Service Worker 主动回报，可能受设备离线、杀进程等因素影响，需要结合 TTL 与重试策略评估数据完整性。

8. 卸载与取消订阅

取消订阅

1
2
3
4
5

const sub = await registration.pushManager.getSubscription();
if (sub) {
  await sub.unsubscribe(); // 向浏览器推送服务注销
  await fetch('/api/removeToken', { body: sub.endpoint, method: 'POST' });
}

清理 Service Worker

1
2
3

for (const reg of await navigator.serviceWorker.getRegistrations()) {
  await reg.unregister();
}

用户亦可在浏览器 设置 → 隐私与安全 → 网站设置 → 通知 手动移除。

9. FCM Web Push 的消息类型

10. Firebase 控制台简介

• Cloud Messaging 面板：生成 Web API Key，查看注册 Token 数；可按 Topic、Segment、测试设备 发送。
• Campaign：A/B 测试、计划发送、目标分析。
• 报表：送达率、打开率、转化漏斗；可导出到 BigQuery。

11. Service Worker 是否必须依赖 PWA？

否。推送功能只要求：

1. 站点 HTTPS。
2. 注册 Service Worker。
3. 获得用户通知权限。

是否被安装为 PWA (beforeinstallprompt) 不影响推送，虽然安装后能获得 iOS 通知、后台运行等额外好处。

12. Push API 规范之外的厂商自定义层

浏览器/平台厂商在标准 Push API 之上仍掌控了推送服务（Push Service）及系统级 UX 行为，主要差异体现在以下方面：

13. Push 推送在广告领域的应用

广告素材规范

• 通知标题 ≤ 50 字符，正文 ≤ 120 字符，避免误导或高频营销词。
• icon 建议使用品牌 Logo；image (Chrome v59+) 可传 2:1 Banner 展示更丰富视觉。
• 必须提供 action button 描述，例如”查看详情 / 立即购买”。
• 禁止使用自动下载、成人内容、虚假中奖等违规素材，违反可被浏览器封禁。

效果测量与归因

1. 在 payload 写入 campaign_id、creative_id，前端所有埋点回流该字段。
2. 打开落地页时在 URL 带上 UTM & deep link，如 utm_source=webpush&utm_campaign=summer_sale。
3. 后端结合 发送 ➜ 展示 ➜ 点击 ➜ 转化 四级漏斗计算 eCPM / eCPC / eCPA。

最佳实践

1. Frequency Capping：结合第 6 节策略，广告型通知建议 ≤1 次/日。
2. 用户偏好中心：允许用户订阅/退订不同广告类别，提升留存。
3. 渐进授权：先获取通知权限，再在设置页引导同意”个性化广告”。
4. 合规透明：隐私政策列明数据用途，提供”一键退订”。

14. 监控层 | 数据采集点 / 工具 | 关键指标 | 说明

参考：

• https://developer.chrome.com/docs/extensions/how-to/integrate/web-push?hl=zh-cn
• https://developer.chrome.com/docs/extensions/how-to/integrate/chrome.gcm?hl=zh-cn
• https://firebase.google.com/docs/cloud-messaging/fcm-architecture?hl=zh-cn
• https://firebase.google.com/docs/cloud-messaging/js/receive?hl=zh-cn#web_6
• https://developer.mozilla.org/zh-CN/docs/Web/API/Push_API
• https://developer.mozilla.org/zh-CN/docs/Web/API/Service_Worker_API
• https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-via-mozillas-push-service/
• https://web.developers.google.cn/articles/push-notifications-overview?hl=zh-cn
• https://web.developers.google.cn/articles/push-notifications-notification-behaviour?hl=zh-cn#notification_click_event
• https://web.developers.google.cn/articles/push-notifications-display-a-notification?hl=zh-cn#browsers_and_feature_detection
• https://web.dev/articles/service-worker-lifecycle?hl=zh-cn
• https://w3c.github.io/ServiceWorker/#service-worker-lifetime