如何提高 Web Push 的推送展示数量

「推送发出去了，但展示数量远低于预期」是 Web Push 接入方最常见的问题之一。展示数量并不是一个孤立的指标，它是订阅、发送、送达等多个环节层层折损后的结果。本文帮助您按漏斗逐层定位展示量偏低的原因，针对每类原因给出优化手段，并在最后给出一套可持续执行的综合方案。

先统一口径：展示在漏斗的哪一层

EngageLab 对每条推送按以下阶段统计，各阶段定义见 推送统计 与 统计 API：

flowchart LR
    plan["计划目标"]
    targets["有效目标<br/>365 天内活跃过的设备"]
    sent["发送数量<br/>服务器成功创建发送任务"]
    delivered["送达数量<br/>实际送达至 Web 端"]
    impressions["展示数量<br/>在终端成功展示"]
    clicks["点击数量"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

关于「展示」有三点必须先明确，否则很容易把统计口径问题误判为推送问题：

1. 展示由 SDK 上报。 回调 API 中 Impression 状态的定义是「Web Push 通知消息和应用内消息由 SDK 上报展示成功」，见 回调 API。没有经过 SDK 上报的展示不会计入展示数量。
2. 自定义消息默认不计展示。 创建推送 API 中的 message（自定义消息）不会展示在浏览器上，而是透传给您的网页；如需统计展示，需要您在网页中调用 customDisplayReport 主动上报，见 Web SDK API。
3. 统计窗口为 5 天。 发送成功 5 天之后产生的送达与展示不再计入统计，也不再回调。

因此，排查展示量低时，请先区分「展示率低」（送达了但没展示）与「展示数低但展示率正常」（问题出在更上游的订阅、发送、送达环节）。这两类问题的原因和解法完全不同。

一、展示量低如何排查原因

建议按漏斗从上游到下游逐层排查，每一层先看数据、再定位原因。

1.1 订阅池是否足够大

展示数量的上限由订阅用户规模决定。如果订阅用户本身很少，再高的送达率与展示率也无法带来可观的展示数。

看哪里：

• 用户概况：对比「订阅用户」与「活跃用户」。订阅用户是成功订阅并同意接收通知的唯一用户设备数，若订阅用户远低于活跃用户，说明大量访客没有完成授权。
• 概况：查看设备通知权限开启率与「关闭通知用户」数量。
• 资料查询：抽查具体 Registration ID 的在线状态与最后在线时间，确认订阅是否仍然有效。

常见原因（见 FAQ 与 基础设置）：

• 使用「直接申请」方式弹出浏览器原生授权框，用户一旦点击 Block / Don't Allow，之后无法再次申请，除非用户自行修改浏览器设置。
• 站点未使用 HTTPS 或域名未在控制台配置，无法弹出原生授权提示，也无法订阅。
• Service Worker 未放在网站根目录，或与站点已有的 PWA Service Worker 作用域冲突，导致订阅失败。
• iOS 用户未将网站添加到主屏幕，或授权请求不是由用户手势触发。
• 用户使用隐身模式、私人浏览模式或访客模式，这些模式不支持 Web Push。
• 同一 user_str 在多个浏览器或设备上订阅时，新订阅会替代旧订阅，只有最后一次订阅的设备能收到消息。

1.2 有效目标到发送是否有大量折损

看哪里：

• 推送记录：对比单条推送的有效目标数与发送数，并查看消息详情中的失败原因。
• 统计 API 的推送生命周期查询：target_invalid、sent_failed 状态可定位具体设备的折损阶段。

常见原因：

• 有效目标口径为「过去 365 天活跃过」，长期不活跃的订阅不会成为有效目标。
• 高级设置 中配置了单设备每小时 / 每天 / 每周的推送上限或可推送时间段，超出限制或不在时段内的消息会被直接丢弃。

1.3 发送到送达是否有大量折损

这是最容易被误判为「展示低」的一层。送达数低，展示数一定低，但此时展示率可能是正常的。

看哪里：

• 推送记录中单条推送的送达率；推送统计中按浏览器（Chrome、Safari、Firefox、Edge、EngageLab 通道等）拆分的送达数据。
• 统计 API 返回的 sub 字段可分别查看 notification 与 message 两类消息的送达与展示，engageLab_web、chrome、safari、firefox、edge 等字段可按通道拆分。

常见原因（见 创建推送 API 与 FAQ）：

• time_to_live 设为 0：不保留离线消息，仅当前在线的用户能收到；默认值为 86400 秒（1 天），最长 15 天。
• 通道差异：EngageLab 通道需要用户打开您的站点页面才能收到；系统通道（Chrome、Edge、Firefox 等）只要浏览器进程在操作系统中存在即可收到，浏览器进程完全退出则收不到；Safari 系统通道无需浏览器运行。
• 用户清除了浏览器 Cookie / 缓存，厂商通道的订阅信息随之丢失；若通知权限仍为允许，用户回到站点初始化 SDK 后会自动重新订阅并得到新的 Registration ID，若权限已改为「询问」或「阻止」则不会自动重订。
• third_party_channel.w3push.distribution 下发策略与您的用户行为不匹配，例如用户很少停留在站点却强制使用 mtpush（仅 EngageLab 通道）。
• 浏览器厂商通道不稳定，FAQ 建议此时可切换为 EngageLab 通道优先下发。

1.4 送达到展示是否有折损（展示率低）

送达数正常、展示数明显偏低时，才是真正的「展示率」问题。

看哪里：

• 推送记录详情中按平台展示的「送达数 / 展示数」及比率。
• 回调 API 的 Impression 与 impression_failed 事件。

常见原因：

1.5 排查检查表

排查时建议按下表顺序逐项确认，先排除口径与上游问题，再看展示本身：

二、排查到原因后如何对症优化

2.1 扩大订阅池

• 改用引导申请（软提示）。 在 基础设置 的通知授权中选择「引导申请」：先用自定义样式向用户说明通知价值，用户表示意愿后再触发原生授权框，避免用户在不了解价值的情况下直接点击 Block 导致永久无法再申请。软提示支持配置初次提示间隔（默认 3 天）与后续提示间隔（默认 7 天），直到用户订阅。
• 确保前置条件完整。 站点使用 HTTPS 并在【集成设定】-【网站域名】中配置域名（最多 100 个）；Service Worker 文件放在网站根目录以获得最大作用域；如站点已有 PWA Service Worker，将两者合并或确保作用域不重叠，参考 Web SDK 集成指南 与 FAQ。
• 为 iOS 用户提供引导。 iOS / iPadOS 16.4 及以上的 Safari 需要用户先将网站添加到主屏幕并从主屏幕打开，再由用户手势（如点击订阅按钮）触发授权，建议在页面上放置横幅引导。
• 避免多设备互相挤掉。 若您使用 user_str 标识用户，注意同一 user_str 在多浏览器 / 多设备订阅时只有最后一次订阅的设备能收到消息；如需覆盖用户的全部设备，请勿在不同设备上复用同一 user_str。
• 迁移时不要丢失订阅。 从其他服务商迁移到 EngageLab 时，按 如何避免 Web 推送迁移中的订阅用户流失 处理旧 Service Worker，已授权用户初始化后不会再次弹出授权框。

2.2 减少有效目标到发送的折损

• 在 高级设置 中根据业务需要配置单设备推送上限与可推送时间段。频控是保护用户体验的手段，但配置过严会直接丢弃消息，请结合推送计划评估。
• 定期通过 删除用户 API 清理确认不再活跃的订阅，使有效目标数更准确地反映可触达用户，避免统计被无效订阅稀释。删除操作不可恢复，请谨慎执行。

2.3 提升送达

• 合理设置 time_to_live。 不要使用 0；保持默认 1 天或按内容时效延长，最长 15 天。对时效性不强的内容适当延长离线保存时间，可以让离线用户在重新打开浏览器后仍能收到。

• 选择匹配的下发策略。 在 third_party_channel.w3push.distribution 中：

  • first_ospush（默认）：优先系统通道，无效再走 EngageLab 通道；
  • secondary_push：优先 EngageLab 通道，用户不在线再走系统通道，创建推送 API 建议使用此方式；
  • mtpush：强制 EngageLab 通道，仅适合用户长时间停留在站点的场景；
  • ospush：强制仅系统通道。

  当浏览器厂商通道不稳定时，可临时切换为 EngageLab 通道优先。

• 谨慎使用 override_msg_id。 覆盖上一条未清除的通知会让用户只看到最新一条，适用于内容更新的场景，不适用于希望多条通知都展示的场景。

• 大促或大批量推送使用定速推送。 通过 big_push_duration 将推送在指定分钟数内均匀下发（最大 1440 分钟），避免瞬时峰值。

2.4 提升展示

• 优先使用通知消息。 需要在通知栏展示并统计展示数的内容，请使用 notification 而非 message；若业务确实需要自定义消息，在网页展示后调用 customDisplayReport('msg_id') 上报展示，点击时调用 customClickReport('msg_id')。
• 避免短时间内向同一用户连续推送多条通知。 在 Chrome、Edge、Firefox 上后一条会替换前一条，用户最终只看到最后一条，展示数也只计入一条。将多条内容合并为一条，或拉开发送间隔。
• 注意素材与文案的浏览器兼容性。 icon 建议 192×192、不超过 1M，仅 Chrome、Firefox 支持自定义，Safari 与 Edge 使用系统默认图标；image 建议 360×180、不超过 1M，仅 Chrome、Edge 支持，Firefox 与 Safari 不支持。系统通道对标题长度有限制（中文少于 20 字、英文少于 40 字符），超长可能影响展示效果。
• 为应用内消息设置合理的展示有效期。 超过展示有效期后用户再进入页面不会展示，并触发 impression_failed。时效性不强的内容适当延长有效期，并控制图片体积以避免图片下载失败。
• 在用户活跃时段推送。 使用 定时任务 的智能投递或结合推送统计中的活跃时间匹配数据，在用户更可能打开浏览器的时段下发，减少离线过期。
• 正确解读 Safari 数据。 Safari 系统通道无法获得展示与点击回调，该通道展示数偏低属于统计能力限制，不代表通知未展示；评估展示率时建议将 Safari 与其他通道分开看。

三、综合方案：系统性提高展示数量

单点优化只能解决某一层的问题，要持续提高展示数量，建议把「订阅增长、送达保障、展示监控」作为一套日常机制来运营。

3.1 建立分通道的监控视图

• 每日关注 概况 中的推送转化漏斗与送达率、展示率、点击率趋势，以及通知权限开启 / 关闭用户数。
• 在 推送统计 中按浏览器拆分查看送达与展示，重点关注 Chrome 与 EngageLab 通道；Safari 单独评估。
• 通过 回调 API 接收 delivered、Impression、impression_failed、click 等事件并落库，可以按用户、按消息做比控制台更细粒度的分析（单条消息统计在 EngageLab 侧最多保留一个月）。
• 为送达率与展示率分别设定基线：送达率异常下降优先排查 time_to_live、下发策略与厂商通道；展示率异常下降优先排查消息类型、多条覆盖与用户侧权限。

3.2 分阶段行动清单

接入期（上线前后）

• 使用 HTTPS，配置域名，Service Worker 放根目录并确认无作用域冲突；
• 通知授权选择「引导申请」，配置软提示文案与间隔；
• 为 iOS 用户准备添加到主屏幕的引导；
• 以通知消息（notification）而非自定义消息（message）作为主要触达方式；
• 联调时用推送记录与资料查询确认目标设备的在线状态、送达与展示都能正常计数。

增长期（日常运营）

• 每周对比订阅用户与活跃用户增长，订阅转化不佳时调整软提示文案与触发时机；
• time_to_live 保持 1 天以上，distribution 使用 secondary_push 或默认策略；
• 控制向同一用户的推送频率，避免覆盖导致的展示损失，同时配置频控保护体验；
• 借助智能投递或活跃时间匹配数据选择发送时段；
• 定期清理长期不活跃订阅。

大促期（高峰推送）

• 使用定速推送平滑峰值；
• 对时效性强的内容适当缩短 time_to_live，对可延后触达的内容延长离线保存；
• 多条营销通知合并为一条，或按用户分批错峰发送；
• 推送后按通道复盘送达率与展示率，将异常通道的经验回填到下次推送配置。

3.3 一句话总结

展示数量 = 订阅用户 × 有效目标比例 × 送达率 × 展示率。先用漏斗数据判断折损发生在哪一层，再针对该层优化；对「展示」这一层本身，核心是使用通知消息并确保 SDK 上报、避免多条覆盖、分通道解读数据。

参考文档

• Web SDK 集成指南
• Web SDK API
• 基础设置
• 高级设置
• 创建推送 API
• 回调 API
• 统计 API
• 推送统计
• 推送记录
• FAQ
• 如何避免 Web 推送迁移中的订阅用户流失