通知分层：什么该打断，什么该等

通知的容量不是无限的，用户对「被打断」的耐心也不是。

一、关掉全部通知之后，他错过了扣款失败

许野的协作工具给每条评论、每个任务变更都发推送。上线一年，推送开关的关闭率稳定在六成以上，他以为用户「不喜欢推送」，于是把文案改得更热情，关闭率没动。

直到一个付费用户来信：信用卡过期三天，服务被停，他完全不知道。查后台才发现，这位用户在三个月前就把全部通知关掉了，因为「你们一天推我七条」。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

许野把通知重做成四级：阻断级只留给安全和资金，即时级给需要当天处理的协作事件，摘要级把评论合并成每天一条，静默级只放在站内。同一批用户的通知量从每天 7 条降到 2.1 条，关闭率降到两成，扣款失败这类消息的到达率回到九成。

问题不是推送太多，是所有推送都长得一样重要。 用户没有能力只关掉不重要的那些，只能全关。

二、四级通知：默认渠道、延迟与上限

分级的依据不是「你想不想让用户看」，而是「如果用户今天没看到，会损失什么」。

阻断级必须同时走两个渠道。 推送会被系统静音，邮件会进推广箱；两条路都失败的概率，远低于单条路。

级别要写在消息定义里，不写在文案里。 每条消息在代码或配置中有固定的级别字段，发送逻辑据此选渠道；靠人工判断，迟早会把促销标成阻断。

即时级只给「别人在等你」的事。 被指派、被提及、待审批，这些有明确的时间压力；「有人给你的文章点了赞」不属于即时。

摘要级要真的合并。 十条评论合成一条「有 3 人回复了你的任务」，比十条单独推送有效得多，也更难被关掉。

摘要要有固定发送时间。 每天早晚各一次，用户会形成预期；随时可能到来的摘要，与即时通知没有区别。

静默级不要发推送。 产品更新放在站内，愿意看的人会看；推到锁屏上，只会加速用户关闭全部通知。

三、合并、延迟与「重要」通胀

分级之后，还要处理三个具体动作：合并、延迟、降级。

合并要有上限。 一条摘要里最多列三条具体内容，其余写「等 N 条」；无限合并会变成一条没人读的长消息。

延迟要按收件人时区。 用服务器时间做判断，跨境用户会永远收到凌晨的消息；时区字段要跟用户资料一起存。

降级要可解释。 用户看到的是「今天还有 4 条动态，已合并到晚间摘要」，而不是「为什么这条没推给我」。

抑制要看用户上下文。 用户正在那个页面里，就不要再推同一事件；这需要客户端上报当前页面，或者至少在点击后短时间内抑制。

不要用「重要」当标题。 所有消息都写「重要」，等于训练用户忽略「重要」。标题直接写发生了什么，比如「扣款失败，服务将在 3 天后暂停」。

四、关闭率、到达率与打扰预算

分层是否有效，看两个方向：打扰下降，关键消息到达上升。

关闭率下降不等于打扰减少，要同时看总量。 如果总量不变而关闭率下降，可能只是用户懒得关。

关键消息的到达率才是验收指标。 一条扣款失败如果 90% 的用户能看到，分层就是成功的；如果仍然有三成收不到，说明渠道或时机还有问题。

摘要级的阅读率通常比单条高。 因为它把「十条碎消息」变成「一件完整的事」，用户愿意花十秒读完。

每季度重估一次级别。 产品会变，今天的事务消息明天可能变成营销；级别跟着场景走，不跟着消息名字走。

按本例复算打扰预算：

分层前：每人每天 7 条
分层后目标：
阻断 ≤1 + 即时 ≤2 + 摘要 ≤1 = 4 条上限
实际按七日均值 = 2.1 条

总通知量下降 = (7 − 2.1) ÷ 7 = 70%
全部关闭率 = 62% → 21%
阻断级到达率 = 38% → 90%

按 800 名月活计
每天少发 = 800 × (7 − 2.1) = 3920 条
每月少发 ≈ 117600 条

每月少发的十一万条，是用户不再关闭通知的原因。 数量本身就是产品体验的一部分。

五、行动清单与复算验收

先给每条通知定级，再调渠道。级别没定就改文案，只是把噪音说得更好听。

• 导出全部通知类型，逐条标注「用户今天没看到会损失什么」。
• 按阻断、即时、摘要、静默四级归档，给出每级的默认渠道。
• 为每级设定频率上限，并写进发送逻辑而不是文档。
• 把同一对象的重复事件改成合并摘要，设单条上限。
• 按收件人时区设置免打扰时段，休息时段只发阻断级。
• 检查所有标题，删掉「重要」「提醒」「通知」这类空词。
• 配置降级规则：超限自动降到摘要或站内。
• 每月统计总量、关闭率与阻断级到达率，三项一起看。

验收标准：任取一条阻断级消息，它能在用户关闭其他通知的情况下仍然到达；同时每人的日均通知数不超过 3 条，且每一条都能说出它属于哪一级、为什么。

使用边界与实操验收

本文只做一人产品的业务分层与默认渠道，不涉及推送平台的队列、回执、限流与多通道扇出架构。

P0–P3 的工程分级不归本文。 按优先级排队、聚合层、投递适配层与到达回执，属于系统架构；本文关心的是「这条消息该不该打断用户」。

推送 SDK 的接入不归本文。 令牌管理、APNs 与 FCM 的差异、本地通知调度，属于客户端实现；分层定完再选实现。

分层不是越细越好。 四级已经够用；分成八级，团队记不住，最后又回到「全部标重要」。

系统设置优先级高于你的分层。 用户关掉系统通知权限后，你的阻断级也发不出去；这时要回退到邮件，而不是继续推。

关键参考与核验范围

核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对系统级通知分级与打扰控制的一般做法，本文未逐条引用其内容。

• Android 通知渠道 ：用于核对按类别分组、单独开关与重要级别的一般模型。
• Apple 人机界面指南：通知 ：用于核对通知的时机、频率与用户控制。

引用口径。 本文只借用两份材料的一般模型：通知要按类别分组，用户要能单独控制。文中的 7 条、2.1 条、62%、21% 与 90% 全部来自教学假设，与上述材料无关。

核验范围。 核验的是「四级 + 四个动作 + 三项指标」这套分层方法是否仍然可操作，不是比对某个推送服务的功能。系统会变，分级原则不变。

如何自行复核。 取一周的发送记录，按用户算日均条数与关闭率；如果关闭率超过三成，先减量再改文案。

系列导航

• 上一篇：送达率账本：退信、投诉、垃圾箱与黑名单
• 下一篇：偏好中心：让用户自己决定收什么
• 回到目录：一个人的消息系统：事务邮件、通知分层与送达率
• 相关阅读：消息推送平台设计