消息通知管理指南：产品经理如何做好任务提醒，风险控制全流程

先说结论：通知系统的失败，几乎从不发生在"发不出去"这一端

我带过三个 B 端产品，做过两套任务提醒系统，处理过因为一条通知引发的客户投诉。如果要我用一句话总结这几年最贵的教训，那就是：通知系统里最贵的 bug，不是"该发的没发"，而是"不该发的发了，并且发给了不该看到的人"。

漏发是显性问题，测试同学点一下就发现了，用户也会立刻找你。但滥发是隐性债务，它不会立刻爆雷，它只是让用户在某一天悄悄关掉整个通知开关，然后你在三个月后从留存曲线上看到一条无法归因的下滑。

所以这篇指南我不打算讲"消息通知是什么"。这个概念任何搜索都能给你答案。我要讲的是：一个产品经理在真实项目里，怎么把通知系统从"能发出去"做到"发得对、发得少、发得准，并且在最坏情况下不会击穿用户底线"。

核心结论先摆在这里，后面每一条我都会展开论证：

• 通知不是发送功能，而是一套带预算的注意力分配系统。每个用户每天能接受的通知条数是有限的，这个预算一旦透支，恢复成本极高。
• 风控的关键不在发送端，而在触发端。80% 的通知事故，源头是触发规则写得过于宽松，而不是通道挂了。
• 通知系统的成熟度，看的不是送达率，而是"退订率与关键通知打开率是否同时健康"。这两个指标同时好看，才说明分层做对了。
• 通知的风控必须做成串联的五道闸门，而不是并列的五个开关。闸门是层层削减，开关是各行其是，后者一定会出现绕过。
• 上线不是终点，回检机制才是。没有回检的通知系统，等于没有刹车的高速公路。

先用一张图说明我理解的完整链路。一条通知从业务事件产生，到用户真正采取行动，中间要穿过五道闸门，每一道都会削减一部分量，也都会引入一类新的风险。

一、为什么通知管理是产品经理的必修课：三类通知，三套风控逻辑

我见过最常见的管理方式，是在后台画一个表格：通知类型、是否开启、渠道、发送时机。看起来很完整，实际上把所有通知都当成了同一类东西。

真正的分水岭是：这条通知是用户"必须知道"的，还是"知道了更好"的，还是"我们希望他知道"的。这三种动机对应三类通知，风控逻辑完全不同，混在一起设计必然出事。

1. 事务型通知：与某个具体的人强相关

典型场景：有人给你指派了任务、你的任务被驳回、有人在评论里 @ 了你、你负责的需求状态被上游改动。

这类通知的特点是指向性强、有效窗口短、漏发代价高。用户错过了，事情就卡在那里，直到有人线下催。所以事务型通知的风控优先级是"不漏"大于"不扰"。

但它也有一个隐藏陷阱：大量事务型通知是用户自己触发的。你改了自己的任务状态，系统给你自己发了一条"你的任务已变更"。这类通知是纯粹的噪音，必须在触发闸就砍掉。

2. 时限型提醒：与时间点强相关

典型场景：任务截止前 24 小时提醒、迭代还剩 2 天提醒、逾期未处理提醒、每周一的任务汇总。

这类通知的特点是可预测、可批量、容错空间相对大。用户今天没看到，明天还有机会。所以风控优先级是"不扰"大于"不漏"，而且非常适合做聚合。

这类通知最容易犯的错是"时间点拍脑袋"。截止前 24 小时这个数字，在大企业跨时区协作场景里几乎是错的，北京时间下午 3 点发出的提醒，对在另一个时区的同事来说是凌晨。

3. 广播/系统型通知：与组织或版本相关

典型场景：系统维护公告、组织架构调整、权限变更、新版本上线、安全策略更新。

这类通知的特点是与个人无关、量小但覆盖面大、一旦滥用后果最严重。因为它天然带有一点"官方权威"色彩，用户对它的容忍度本来较高，但一旦你开始用它发无关内容，用户会很快对整个系统失去信任。

我特别想强调一点：广播型通知是组织内部政治的高发区。哪个部门都想借这个通道推自己的信息。产品经理如果不在这一层建立准入规则，三个月内这个通道就会变成第二个全员邮件列表。

4. 三类通知的风控策略差异

下面这张表是我在实际项目里直接拿去和团队对齐的版本。它最大的价值不是告诉你"该怎么做"，而是告诉你"不同类的通知不能用同一套标准去评判"。

把这三种类型分开之后，很多原本争论不休的问题会突然变得有答案。比如"静默时段要不要对事务型通知网开一面"，答案是需要，但必须有一份明确的、可审计的白名单，而不是"看着挺急的就发"。

二、六个我亲自踩过的误区

下面这六条，每一条都对应我或我的团队真实付出的代价。我把它们放在这里，是因为它们比"最佳实践"更有用，最佳实践告诉你该做什么，误区告诉你什么会让你前功尽弃。

1. 把送达率当成北极星指标

我刚做通知系统时，看板第一行写的就是"Push 送达率"。为了把它从 92% 拉到 97%，我们花了两个月优化 Token 刷新机制、重试队列、离线缓存。

结果呢？送达率确实上去了，但用户侧的关键通知打开率几乎没动。因为送达率衡量的是通道健康度，不是用户价值。一条用户在会议中收到并划掉的 Push，技术上是"送达且已读"，业务上是彻底失败的。

后来我把看板第一行换成了"关键通知点开率 × 通知总退订率"的组合，团队的优化方向立刻变了，从修通道变成了砍噪音。

2. 用一个全局开关解决骚扰问题

这是最经典的错误设计。用户抱怨通知太多，你就加一个"接收通知"的总开关。用户关掉之后，问题表面解决了，但你同时失去了所有触达能力。

更糟的是，用户关掉之后如果错过了重要任务，责任在谁？用户会觉得是产品不行。

正确的做法是提供分层的、可解释的开关：按通知类型分（事务/提醒/广播）、按渠道分（站内/移动/短信）、按时间段分（工作时段/静默时段）。层级越多，用户越不可能一刀切。

3. 认为移动 Push 是免费的

Push 没有直接的通道费用，这让很多人默认它是"零成本"的。但每一次 Push 都在消耗用户的注意力余额，而这个余额是有硬上限的。

我们曾经做过一次内部统计：在治理前，一个活跃用户的日均通知量是 14.6 条。治理后压到 4.2 条，同一个月的通知总退订率从 3.1% 降到 0.7%。注意，我们并没有减少"关键通知"的发送量，减少的全是聚合后的重复提醒和自触发通知。

4. 只在发送端做风控，不做聚合

很多团队的风控是"发送前检查一下频率"。这属于下游拦截，能挡住量，但挡不住体验。真正有效的做法是把同类通知在源头合并。

举个具体例子：一个人在同一天被指派了 7 个任务。下游拦截只会发 1 条然后丢掉另外 6 条，用户永远不知道还有 6 件事等着他。而聚合的做法是发 1 条摘要："你被指派了 7 个任务，涉及 3 个项目，点击查看"。前者是信息丢失，后者是信息压缩。

5. 把静默时段设成一刀切的黑名单

我们最早把静默时段设成 22:00 到次日 08:00，硬性禁止一切推送。上线后第二周就收到投诉：早会 9 点的任务提醒收不到了，因为提醒是在凌晨 3 点触发的，被静默策略吃掉并且没有补发。

静默时段的正确实现是"排队 + 顺延"，不是"丢弃"。落在静默窗口内的通知应该进入待发队列，在窗口结束后的第一个合适时间点统一发出，而不是直接丢掉。

6. 通知文案追求"信息完整"

前端同学经常把任务描述的前 200 个字直接塞进 Push 正文，理由是"信息完整，用户不用点进去"。这是典型的工程师视角。

Push 的正文在锁屏上显示，用户平均停留时间是 1 到 2 秒。那 200 个字不仅没人看，还会把关键信息（谁、什么事、要你干什么）淹没掉。后来我们把模板统一成"动作 + 对象 + 时间"三段式，比如"张伟 指派给你一个任务 · 接口联调 · 明天 18:00 截止"，长度控制在 30 字以内，点开率提升了将近一倍。

三、五道闸门：一套可以照抄的通知风控逻辑

讲完误区，说方法。我把通知风控拆成五道串联的闸门，顺序不能换，因为后一道闸门的输入是前一道的输出。

这个设计的关键在于"闸门"而不是"开关"：开关可以被绕过，闸门必须按顺序通过。任何一条通知要到达用户，必须依次穿过触发闸、聚合闸、频次时间闸、通道闸、内容闸，任何一关拒掉，通知就不会发出去。

1. 第一道闸：触发闸，这条消息该不该产生

这是最容易被跳过、但性价比最高的一道闸。90% 的噪音问题可以在这里解决。

触发闸需要回答三个问题：

1. 是不是用户自己触发的？如果是 A 改了 A 自己的任务状态，不需要通知 A。
2. 是不是无业务意义的字段变更？比如仅修改了标签、仅调整了排序位置、仅修改了描述里的错别字。
3. 接收者有没有权限看这条内容？这是权限校验点，也是唯一一道涉及数据安全的闸门，绝不能放到后面。

我通常会让团队在配置层就把这些规则写清楚，而不是散在代码里。一个可维护的触发规则大概是这个结构：

{
"event": "task.assignee.changed",

"trigger_gate": {

"skip_if_self_triggered": true,

"skip_if_batch_import": true,

"skip_if_field_unchanged": ["assignee", "status", "due_date"],

"require_receiver_permission": "project:task:read"

},

"aggregate_gate": {

"group_key": "receiver_id + project_id + date",

"window_minutes": 120,

"max_batch": 10

},

"frequency_gate": {

"type": "transactional",

"daily_cap": 30,

"silent_hours_bypass": false

},

"channel_gate": {

"primary": "in_app",

"fallback": ["im", "mobile_push"],

"escalate_to_sms_after": "2h_unread"

},

"content_gate": {

"template": "assignee_changed_v3",

"desensitize_fields": ["customer_name", "contract_amount"]

}

}

这段配置的价值不在于语法，而在于它把五道闸门的决策集中到了一处。当通知出问题时，你能在一个文件里定位原因，而不是在五个服务里翻日志。

2. 第二道闸：聚合闸，能不能合

聚合是通知治理中收益最高、也最容易被做错的一环。做对了，通知量能降 60% 以上；做错了，用户会漏掉关键信息。

聚合的核心是选择正确的 group_key（聚合键）。我的经验是：

• 事务型通知的聚合键应该包含接收者，但不应该包含项目。把"张三在 A 项目和 B 项目被指派任务"合成一条，是合理的；但把"张三被指派"和"李四被指派"合成一条，就是错的，因为它只对一个人有意义。
• 时限型提醒的聚合键应该包含日期。今天的截止提醒合成一条，明天的合成另一条。
• 聚合必须设置上限和兜底。比如一个窗口内超过 10 条就不再合并，直接发摘要加链接。否则一条"你有 340 条未读"的通知会让用户直接放弃。

还有一个容易被忽略的点：聚合窗口的时长要和业务节奏匹配。在一个以周为迭代单位的研发团队里，2 小时的聚合窗口是合理的；但在一个客服工单场景里，2 小时可能意味着问题已经升级了。窗口时长不能拍脑袋，要从业务的响应时间要求倒推。

3. 第三道闸：频次与时间闸，现在能不能发

这道闸门管两件事：一天最多发几条，以及此刻是不是合适的时间。

关于频次上限，我不建议给一个全站统一的数字。合理的做法是按类型分级：

关于时间闸，我要单独强调时区问题。在跨时区协作的团队里，"几点发"这个问题比"发几条"更难。我们的做法是把所有提醒的触发时间锚定到"接收者本地时区的某个业务时刻"，而不是"服务器时间的某个绝对时刻"。这个改动看起来很小，但它把跨时区的提醒投诉几乎清零了。

4. 第四道闸：通道闸，走哪条路

通道闸的设计目标有两个：把通知送到正确的通道，以及在主通道失效时有可靠的降级路径。

通道选择的基本原则是打扰度与紧急度匹配。紧急度低的通知走打扰度低的通道，反之亦然。但如果只有这一条原则，很容易演变成"什么都往 IM 发"，因为 IM 最好用。

我建议再加一条原则：通道选择要基于"用户此刻最可能看到的地方"，而不是"我们最想让他看到的地方"。这两者经常不一致。一个正在开会的用户，IM 消息可能被静音，但锁屏 Push 会亮起；一个正在电脑前专注工作的用户，Push 反而会被手机反扣在桌上忽略掉。

5. 第五道闸：内容闸，写什么、怎么措辞

前面四道闸决定了"发不发"，这最后一道闸决定了"发了有没有用"。

内容闸要做三件事：保证信息完整、避免歧义、保护敏感数据。

我自己的团队用一份固定的自检清单，每条通知模板上线前必须过一遍：

1. 是否回答了"谁、什么事、要我在什么时候做什么"？缺任何一项都算不合格。
2. 是否存在同义词歧义？"处理一下这个需求"就不合格，因为"处理"可能是评估、可能是开发、可能是关闭。
3. 是否包含不该出现的字段？客户名称、合同金额、员工薪酬、内部代号，这些在通知里都应该被脱敏或替换为代号。
4. 是否有明确的下一步动作入口？通知的价值在于让用户立刻能做点什么，没有入口的通知等于纯打扰。
5. 在不同角色视角下读起来是否都通顺？同一条任务变更，开发者、测试、项目经理看到的措辞应该不一样。

关于敏感信息，我想多说一句。通知是数据泄露的高发渠道，因为它经常绕过主应用的数据权限体系。主应用里你看不到某个项目的数据，但通知模板可能直接把项目名、客户名拼进了文案里。这类问题一旦发生，性质就不是产品体验问题了。

四、一个中大型组织的真实观察：当通知量随组织规模非线性增长

前面讲的是通用逻辑。但如果你负责的是一个面向中大型企业的协作平台，问题会变得更复杂，因为在这里，通知量不是随人数线性增长的，而是接近平方级增长。

我参与过一个中大型企业客户的通知治理项目，对方是一个 400 人左右的研发组织，同时跑着 60 多个项目和若干条产品线。这个案例让我第一次真切地意识到，小团队的通知经验在中大型组织里几乎完全失效。

原因很简单：通知量的来源是"人与事的组合"。当人数是 N，事数是 M，理论上可能产生的通知组合接近 N×M。小团队里 N 和 M 都很小，乘出来不大；一旦人数过百，组合数就会迅速爆炸。

1. 组织规模扩大后出现的三个新问题

第一个问题：跨部门可见性冲突。在小团队里，所有人能看到所有事，通知发给谁都不是问题。但在 400 人的组织里，一个任务可能同时关联产品、研发、测试、运维四个部门，而不同部门对同一件事的可见范围不同。一条包含完整任务信息的通知，发给 A 部门合规，发给 B 部门可能就越权了。

第二个问题：批量操作引发的通知风暴。项目经理在迭代规划时一次性调整 50 个任务的负责人，如果触发规则没有批量识别能力，就会瞬间产生 50 条通知。这类操作在小型团队里很少出现，在中大型组织里却是日常。

第三个问题：通知规则的迁移错位。很多中大型企业是从其它项目管理工具迁移过来的。原工具里的通知规则、字段语义、工作流触发点，与新平台并非一一对应。如果迁移时只迁数据不迁通知规则，用户会立刻感到"换了个系统之后什么都收不到了"。

这也是为什么在这类场景里，选型时我会特别关注两点：一是平台是否支持私有化部署，因为通知通道（尤其是短信、IM、Push）在企业内网环境下的可用性和公网完全不同；二是平台是否具备成熟的历史数据与规则迁移能力，能够把原有的通知规则映射过来，而不是让客户从零重建。

以 PingCode 为例，它主要服务中大型企业及 100 人以上的组织，支持私有化部署，也支持从 Jira 平滑迁移。在实际项目里，私有化部署带来的一个直接好处是通知聚合策略可以按企业自身组织架构定制，比如按部门、按产品线、按项目集设置不同的聚合粒度和静默策略，而不是被迫接受一套通用规则。

更重要的是迁移场景。国产替代过程中，最容易出问题的往往不是数据本身，而是数据背后的协作习惯，包括通知规则。如果迁移方案里没有"通知规则映射"这一项，员工在切换后的第一周就会开始抱怨"系统不提醒了"，而这种抱怨会直接演变成对整次迁移的否定。

2. 关于通知量增长的量化观察

下面这组数据来自我在几个不同规模团队里的观察记录，属于样本推演与经验估算，不是行业统计，但趋势非常一致。

3. 这类客户最在意的其实不是"少发"

一个反直觉的发现：在中大型组织里，用户和管理者对通知的态度是分层的。

普通执行者最在意的是"少发"，他们希望噪音消失。但项目经理、部门负责人最在意的是"关键的不能漏"，他们担心的是治理过程中把重要通知也一并过滤掉了。

所以如果你只做减量，管理者会成为最大的阻力。我后来总结出的做法是：把治理的收益可视化地交给管理者。具体做法是给管理者提供一份"关键通知到达看板"，展示治理前后的对比，噪音降了多少，关键通知的到达和响应有没有变差。

这份看板往往比任何论证都有效。因为它把"减量"这件事从主观感受变成了可验证的数据。

五、发出去之后：回检机制怎么建

通知系统和其它功能最大的不同在于：它的很多问题不会在测试阶段暴露，而是在用户开始规模化使用之后才慢慢浮现。所以没有回检机制的通知系统，等于是没有仪表盘的飞机。

1. 五个必须长期监控的核心指标

我把它们分成两组：一组看"通道好不好"，一组看"用户烦不烦"。

这里我要特别提人均日通知量这个指标。它看起来很粗糙，但是它是最灵敏的先行指标。我经历过的每一次退订率飙升，往前追溯都能看到人均日通知量提前两周到一个月就开始异常爬升。

2. 建立回检节奏：三个固定动作

指标本身不会产生价值，节奏才会。我的团队固定在三个时间粒度上做回检：

1. 每周一次通知健康度巡检。只看两个数：人均日通知量的环比变化、关键通知点开率的环比变化。任何一个异常，就往下钻。
2. 每月一次通知类型盘点。把当月所有存在的通知类型列出来，逐条问"这条通知还在被需要吗"。你会发现很多通知类型是半年前某个项目遗留的，业务早就变了。
3. 每季度一次用户侧调研。不要问"你觉得通知多不多"，这种问题永远得到"有点多"的答案。要问"过去一个月，有没有因为通知错过或者耽误过什么事"，从具体的失败事件反推系统问题。

3. 异常排查的标准路径

通知出问题时，最怕的是团队各查各的。我建议固化成一条从上往下的排查路径：

异常现象：用户反馈"没收到关键通知"
↓

Step 1 查触发日志：事件是否产生？是否被触发闸拦截？

→ 被拦截：检查触发规则配置是否有误（最常见）

→ 未产生：检查上游业务事件是否正常发出

↓

Step 2 查聚合日志：是否被合并进了摘要？

→ 是：检查聚合键设计是否合理，是否该拆出单独通知

↓

Step 3 查频次时间日志：是否被频次上限拦截或在静默队列中？

→ 是：检查用户当日通知量是否异常，或静默顺延是否生效

↓

Step 4 查通道日志：是否发送失败或走了降级通道？

→ 是：检查 Token 有效性、通道服务商状态、降级策略是否触发

↓

Step 5 查终端状态：是否送达但未展示？

→ 是：检查系统通知权限、免打扰模式、锁屏策略

这条路径最大的价值是避免团队一上来就去查通道。根据我的经验，用户反馈"没收到通知"的案例里，真正属于通道故障的不到两成，绝大部分问题出在第一步的触发规则上。

六、不同情况下的行动建议

讲完逻辑，落到执行。不同的团队规模、不同的业务阶段，该做的事情优先级完全不同。下面按四种情况给出建议。

1. 20 人以下的小团队：不要过度设计

这个阶段人少、事少，通知量本身就不大。如果你在这里投入大量精力做聚合、分层、静默策略，边际收益很低。

我的建议是做三件事就够了：一是禁止自触发通知，二是把任务截止提醒做成每日一次汇总而不是逐条提醒，三是提供一个能一键关闭非关键通知的开关。这三件事的成本极低，能覆盖这个阶段 90% 的体验问题。

至于通道分层、灰度发布、A/B 测试这些，先不做。不是它们不对，而是它们的收益要等到规模上来之后才显现。

2. 20 到 100 人的团队：开始建聚合层

这个阶段开始出现跨职能协作，通知量会明显爬升。核心任务是引入聚合机制和频次上限。

具体做法：先把现有通知类型全部拉出来盘一遍，找出重复度最高的三类，为它们设计聚合键和聚合窗口。同时给每类通知设置日上限，超限后聚合而非丢弃。

这个阶段最容易忽略的是静默时段的顺延机制。很多团队只做了静默拦截，没做顺延补发，导致用户觉得"夜里的事白天也收不到提醒"。

3. 100 到 1000 人的组织：需要系统化的通知治理

这是 PingCode 主要服务的组织规模区间，也是通知问题最集中、治理价值最高的阶段。

这个阶段的建议是：

• 建立通知类型准入机制。任何新通知类型上线，必须经过评审，说明接收人群、触发条件、预期频次、退订策略。没有这个机制，通知类型会无限膨胀。
• 按组织架构配置聚合策略。不同部门、不同产品线的协作节奏不一样，用一套聚合规则套所有人一定会顾此失彼。支持私有化部署的平台通常在这件事上更灵活。
• 把通知治理纳入迁移方案。如果是国产替代或工具迁移场景，务必把通知规则映射列为独立的迁移项，而不是数据迁移的附属品。
• 给管理者提供可视化看板。前面讲过，管理者是治理的主要阻力来源，用数据说服比用道理说服有效得多。

4. 1000 人以上的组织：把通知当成基础设施来运营

这个阶段的组织通常已经有专职的平台团队或工具团队。通知不再是某个产品的功能，而是一项内部基础设施。

我建议这个阶段做三件更重的事：一是建立通知类型的全生命周期管理，包括上线、变更、下线，每个环节都有负责人；二是建立通道容灾预案，确保主通道故障时关键通知能在可控时间内降级送达；三是把通知健康度纳入部门级的运营指标，定期向管理层汇报。

5. 按产品阶段划分的补充建议

除了规模，产品所处的阶段也影响优先级。

冷启动阶段，通知的目标是让用户感知到产品的存在，此时宁可多发一点，也不要让用户觉得"这个系统没有反馈"。增长阶段，通知开始承担激活和召回职责，此时要特别小心不要把营销内容混进事务通道，一旦用户把事务通知当成营销，恢复信任的成本极高。

成熟阶段，通知的目标转向精耕，此时聚合、分层、个性化是主旋律。这个阶段最容易出现的组织问题是"通知没人管"，因为大家都觉得它是小事。我建议在成熟期明确一个通知负责人，哪怕只是兼职。

七、不同情况下的取舍

通知管理里没有"全都要"的方案。下面五组取舍，是我在实际项目里反复面对、并且每一次都需要具体判断的问题。

1. 聚合度 vs 时效性

聚合度越高，通知量越小，但单条通知的时效性越差。一个 4 小时的聚合窗口意味着最坏情况下用户要等 4 小时才收到提醒。

我的判断标准是看这件事的决策周期。如果一个任务的响应要求是"当天内"，那 4 小时窗口完全可以接受。如果响应要求是"15 分钟内"，聚合窗口就必须压到 15 分钟以内，甚至可以放弃聚合。

换句话说，聚合窗口的长度不应该由产品经理拍，而应该由业务的响应时间要求倒推。

2. 强触达 vs 用户信任

短信和电话的到达率接近百分之百，但打扰度也最高。用得越多，短期触达效果越好，长期用户信任越低。

我的做法是给高打扰通道设置明确的触发条件和预算。短信只在两种情况下触发：一是关键事务超过 2 小时未读，二是明确的线上事故。并且给全站设置年度短信预算，超出需要专门审批。有了预算约束，团队自然会珍惜每一次使用。

3. 个性化 vs 可解释性

根据用户行为动态调整通知策略，理论上体验最好。但个性化会带来一个严重的问题：当用户没收到某条通知时，你很难解释为什么。而通知这类功能，可解释性非常重要，因为它直接关系到责任归属。

我的取舍是：在"发不发"这个决策上保持可解释，在"什么时候发、以什么形式发"上做个性化。也就是说，用户可以查到"为什么我收到了这条通知"，但不需要理解为什么是 14:32 而不是 14:30 发的。

4. 通道冗余 vs 成本

多通道冗余能显著提升到达率，但短信和电话的成本高出三个数量级。全量冗余的做法在经济上不可行。

合理的做法是分级冗余：站内消息作为永久记录层，所有通知都必须写；IM 和 Push 作为常规触达层；短信和电话作为关键事务的升级层。真正需要冗余的不是通道本身，而是关键通知的送达保障。

5. 默认开启 vs 默认关闭

这是一个经典的合规与体验冲突。默认开启能保证触达率，但在很多地区的监管要求下，某些类型的通知必须获得用户明示同意。

我的处理原则是按通知性质区分：履行合同所必需的事务型通知可以默认开启；营销类、推荐类通知必须默认关闭并获得明示同意；介于两者之间的，默认开启但提供显著的、一步可达的关闭入口。关闭入口的层级深度是有讲究的，超过两步的关闭路径，用户在体验上会觉得被欺骗。

结语：三条底线，和一份可以直接拿去用的清单

回到最初那个判断：通知系统的失败几乎不在"发不出去"这一端，而在"发烂了"这一端。这几年我处理过的所有通知事故，最终都能归到三条底线上。

第一条底线是不漏发关键。事务型通知和明确的安全类通知，必须保证送达，并且要有可验证的送达凭证。这类通知可以打扰，但不能丢。

第二条底线是不滥发普通。时限型提醒和广播型通知，必须受聚合和频次约束。任何一条可以被合并的通知，都不应该单独发出去。

第三条底线是不产生歧义和越权。通知的措辞必须让接收者一眼知道要做什么，通知的内容必须严格受权限约束。越权通知不是体验问题，是安全问题，它的容忍度应该是零。

如果你明天就要开始做这件事，我的建议是按这个顺序动手：

1. 先导出过去 30 天的通知日志，算出人均日通知量，以及排名前十的通知类型。
2. 在这十类里找出"自触发"和"重复推送"占比最高的三类，先给它们加触发规则和聚合键。这一步通常能砍掉三成以上的量。
3. 再把静默时段的拦截改成排队顺延，观察一周退订率的变化。
4. 然后才去做通道分层和文案优化，因为这两件事对总量的影响最小，但对质量的感知最强。
5. 最后把回检节奏固定下来，每周看人均日通知量和关键通知点开率这两个数就够了。

不要指望一次做完。通知治理是一个持续收敛的过程，不是一次上线。我做过的最有效的一次改动，其实只是把一条自触发通知砍掉了，那个月的人均日通知量就降了 1.8 条，退订率降了 0.6 个百分点。

小改动，持续做，比一次大重构更管用。因为通知面对的是人的注意力，而人的注意力从来不会因为一次改版就重新分配，它只会因为你长期没打扰它，慢慢回来一点。