任务提醒提前提醒教程：产品经理实操方法，避坑指南

我做过一个 300 人规模研发组织的项目管理平台迁移，上线第八周收到一条很扎心的反馈：一位测试负责人在周会上说，他给 47 个测试用例截止任务设置了「提前 3 天提醒」，结果有 19 个还是迟了。不是他没看到提醒，而是他每天收到 30 多条提醒，最后只对「提前 15 分钟的会议」还保持条件反射，其余全部滑掉。这条反馈让我意识到，提前提醒从来不是一个「提前多久」的参数问题，而是一个注意力资源的分配问题。

这篇文章我会把过去几年设计、重构、复盘提醒功能的完整方法拆开讲：先给结论，再讲场景，然后逐条拆解产品经理最容易踩的七个坑，最后给一套可以直接拿去对照的检查清单。

一、先给结论：提前提醒的三条底层判断

在进入具体操作之前，我需要先把三条我认为最重要的结论放在前面。如果你只想记住一段内容，记住这一段就够了。这三条不是从教科书里抄的，而是我在真实项目里被反复教育之后留下来的判断。

1. 提前量不是提醒参数，而是决策参数

大部分产品经理把「提前提醒」理解成一个可配置项：给用户一个下拉框，让他选提前 5 分钟、15 分钟、1 小时、1 天。这个设计表面上很尊重用户，实际上是把决策成本甩给了用户。

真正的问题是：用户根本不知道自己需要提前多久。他不知道明天上午的日程密度，不知道任务的实际准备成本，也不知道自己届时的注意力状态。让他自己选提前量，等于让他在信息最不完整的时刻做一个最影响结果的决策。

更合理的做法是：先按任务类型给出一组经过验证的默认值，再开放有限度的调整。默认值承担 80% 的场景，调整能力只服务于那 20% 的例外情况。

2. 提醒的有效性 = 时机 × 通道强度 × 行动入口

这三个因子是相乘关系，不是相加关系。任何一个为零，整条提醒就等于没发。我见过太多团队只优化其中一项：把时机算得很精细，但通道用的是最低优先级的站内信；或者通道用了推送，但点进去只有一个任务标题，没有跳转、没有「标记完成」按钮。

三个因子里，最容易被忽略的是行动入口。一条提醒如果只告诉用户「该做 X 了」，而不提供「现在就能做 X 的路径」，用户的行动成本会被拉高，转化的概率会快速衰减。

3. 提前提醒是稀缺资源，必须做配额管理

这是我最想强调的一条，也是最多团队踩坑的地方。用户的注意力是有限的，通知权限更是一次性资源。一旦用户因为打扰过多而关闭通知权限，你的所有提醒能力会瞬间归零，而且是不可逆的，重新获取通知权限的难度远高于第一次获取。

所以提前提醒必须像预算一样管理：每个用户每天能收到多少条强提醒、多少条弱提醒，需要有明确的上限和降级规则。没有配额意识的提醒系统，本质上是在透支产品的信用。

二、真实场景：三次让我重写提醒逻辑的翻车

结论说完了，接下来讲场景。我更愿意用具体的翻车经历来说明问题，因为抽象原则谁都能讲，但只有具体场景才能让人判断自己的产品处在哪一档。

1. 会议提醒提前 15 分钟，会议室还是空的

这是我最早做的一个版本。会议室预订系统在会议开始前 15 分钟推送「您有一个会议即将开始」。上线一周后，我们发现会议迟到率几乎没有改善。

我去看了二十几个用户的手机通知截图，发现问题出在一个很朴素的地方：那 15 分钟里用户正在做别的事。他看到了提醒，心里说「知道了」，然后继续手上的工作，等回过神来已经过了开始时间。

后来我们把提醒改成两个节点：提前 20 分钟提醒并附带「加入会议」按钮，提前 2 分钟再发一次只有振动、没有文案的轻提醒。迟到率从 27% 降到了 14% 左右。这里的判断是：提前量要覆盖「打断当前任务 + 移动到新任务」的完整切换成本，而不是只覆盖移动成本。

2. 截止日期提前 3 天提醒，用户第三天晚上才开始

第二个翻车更典型。我们给所有带截止日期的任务默认加了「提前 3 天提醒」。数据看起来很美好，提醒触达率 99%，但任务的按时完成率只从 61% 提升到 64%。

原因不难理解：提前 3 天的提醒，实际效果是告诉用户「你还有 3 天」。这句话没有制造任何紧迫感，反而提供了一个心理许可，「既然还有 3 天，那今天先做别的」。

我把这个现象叫做提醒的心理许可效应。一条过早的提醒，不仅不会推动行动，反而会削弱行动动机。它让用户以为自己已经管理好了这件事，从而停止思考它。

3. 全量提醒上线两周，通知关闭率冲到 19%

第三个翻车是系统性的。我们当时做了「全量提醒」：任何任务状态变化、任何评论、任何截止日期，都推一条。上线前两周数据很漂亮，日活提醒交互次数涨了 3 倍。

但从第三周开始，iOS 端的通知权限关闭率从 4% 涨到 19%，Android 端从 7% 涨到 23%。更严重的是，关闭通知的用户里，有相当一部分是产品最核心的重度用户，因为他们任务最多，收到的提醒也最多。

这次事故之后我定了一条规则：凡是可能触发通知的功能，上线前必须做「最坏情况提醒量」测算，也就是假设用户把所有能开的提醒都打开，一天最多会收到多少条。这个数字超过 12 条，就必须重新设计。

三、常见误区拆解：产品经理最容易踩的七个坑

这一节我会把七个坑一个个拆开讲。每个坑我都按「典型表现 → 造成的后果 → 正确的做法」三段式来说，方便你直接对照自己的产品。

1. 坑一：默认所有任务都需要提前提醒

典型表现：任务创建时勾选框默认选中「启用提前提醒」，用户不主动取消就会收到提醒。

造成的后果：提醒池被大量低价值任务占满。当用户一天收到 20 条提醒，其中 18 条是「看看这个任务」这种无用信息时，剩下 2 条真正重要的提醒也会被一起略过。

正确做法：把提前提醒从「默认开启」改成「默认关闭，仅对具备以下特征的任务建议开启」：有明确截止时间、有外部依赖方、逾期会产生实际损失。这三个条件同时满足才值得占用一条提醒配额。

2. 坑二：提前量一刀切，不做任务类型区分

典型表现：全局配置「提前 1 天提醒」，无论是 15 分钟的会议还是 2 周的开发任务，都按同一规则触发。

造成的后果：会议提醒太早，用户忘掉；长周期任务提醒太晚，来不及准备。同一套参数在两端都是错的。

正确做法：按任务的时间尺度分档。我的经验是分三档：分钟级（会议、面试、值班交接）提前量在 5-30 分钟；天级（评审、交付、上线）提前量在 1-2 天，且需要「前一天的固定时刻 + 当天早上」双节点；周级（版本发布、季度目标）提前量在 5-7 天，但只发一次，且必须附带进度检查清单。

3. 坑三：把提醒当通知做，忽略行为触发设计

典型表现：提醒内容就是一句文案加一个任务标题，点进去是任务列表页，用户还要自己找。

造成的后果：从「看到提醒」到「开始行动」之间的路径太长。每多一次点击，转化率大约衰减 15%-25%。

正确做法：提醒必须直连行动。会议提醒直达入会链接，审批提醒直达审批按钮，逾期任务提醒直达状态变更控件。判断标准很简单：用户从看到提醒到完成第一个有效动作，点击次数不应该超过 2 次。

4. 坑四：忽略系统权限和免打扰模式的限制

典型表现：产品设计里假设推送一定能到达，没有考虑系统层面的拦截和折叠。

造成的后果：iOS 的通知摘要功能会把非紧急通知批量延迟投递；Android 各厂商的省电策略会限制后台唤醒；用户的专注模式会让所有非白名单通知静默。这些情况下你的「提前 15 分钟」可能变成「提前 3 分钟后才看到」。

正确做法：关键提醒需要申请系统级的时效性通知权限，并对不同的通道做降级设计。同时，产品内部必须有一条不依赖系统推送的兜底通道，比如打开 App 时的置顶横幅、桌面小组件、邮件摘要。设计时按「推送失败后 5 分钟内必须有一条备用通道触达」的标准来检查。

5. 坑五：提醒文案只写「该做 X 了」，不给行动入口

典型表现：文案是「您有一个任务即将到期」。

造成的后果：用户需要自己判断「哪个任务」「还剩多久」「我现在要做什么」，认知成本高，容易直接划掉。

正确做法：好的提醒文案包含三个要素：具体对象、剩余时间、建议动作。比如「《支付模块联调》还有 4 小时到期，建议现在提交自测报告」。这句话比「您有任务即将到期」的点击率在我的项目里高出 2.3 倍。

6. 坑六：不做提醒效果的闭环验证

典型表現：提醒上线后只看发送量，不看后续行为。

造成的后果：无法判断哪条提醒有效、哪条是无用噪音，也就无法优化。提醒系统会随着任务数量增长自然恶化，但团队毫无察觉。

正确做法：至少埋四个指标：提醒送达率、提醒点击率、点击后 30 分钟内产生有效动作的比例、以及提醒后用户关闭权限的比例。最后一个指标最重要，它是负向信号。

7. 坑七：忽略用户对提醒时间的自主控制权

典型表现：为了统一体验，不提供「免打扰时段」「每日提醒汇总时间」这类设置。

造成的后果：习惯在晚上 10 点后处理工作的用户，会被早上 9 点的提醒淹没；而习惯早起的用户又会在深夜被打扰。用户唯一的反抗手段就是关掉通知。

正确做法：把控制权拆成三层：免打扰时段（必须提供）、提醒渠道偏好（必须提供）、单任务提前量微调（可选提供）。前两层是底线，缺失会直接导致权限流失。

四、专业判断逻辑：提前量到底怎么算

拆完坑，接下来是我认为最有价值的部分，判断逻辑。这部分我会给出可计算的框架，而不是「根据实际情况灵活调整」这种正确的废话。

1. 提前量公式：行动准备时间 + 任务切换成本 + 缓冲

我用的公式是这样的：

合理提前量 = 行动准备时间 + 任务切换成本 + 缓冲系数

三个变量的含义分别是：

• 行动准备时间：用户从「决定开始」到「真正开始」需要的物理时间。比如要打开电脑、找到文档、拉取代码，可能是 5-10 分钟；要写一份方案，可能是 2 小时。
• 任务切换成本：用户从当前正在做的事情中抽离出来的心理成本。正在开会的用户切换成本极高，正在刷消息的用户切换成本很低。这一项通常被完全忽略。
• 缓冲系数：覆盖意外情况。我一般取前两项之和的 20%-30%。

按这个公式，一个需要准备材料的评审会，准备时间 20 分钟、切换成本 10 分钟、缓冲 8 分钟，合理提前量是 38 分钟，而不是我最初设的 15 分钟。这就解释了为什么会议室总是空的。

2. 三种任务类型的提醒特征矩阵

公式给的是单点计算，但产品设计需要的是可批量配置的规则。我把任务按时间尺度分成三种类型，每种的提醒特征差异很大。

这张表最值得注意的地方是周期型任务的提前量逻辑完全不同。它不需要「提前」，因为它本来就是周期性发生的，用户已经形成了预期。对它做提前提醒是纯粹的资源浪费，正确的做法是固定在某个时刻触发，把提前量设为零。

3. 通道分层：强提醒、弱提醒、静默记录

提醒的有效性由通道强度决定，但通道强度是有限资源。所以我把它分成三层，并且给每层设了每日配额。

1. 强提醒层：响铃 + 横幅 + 应用角标，配额每日 3 条。只给会议开始、关键审批、当天到期任务这三类使用。超出配额自动降级。
2. 弱提醒层：横幅或列表置顶，无声音，配额每日 8 条。给一般截止任务、状态变更、评论提及使用。
3. 静默记录层：只写入消息中心，不主动触达，无配额限制。给所有信息类更新使用。

配额用尽后的降级规则必须明确：强提醒降到弱提醒，弱提醒降到静默记录。用户不会因为你降级而抱怨，但会因为一天 30 条推送而关掉权限。

4. 闭环验证：四个必须埋点的指标

提醒系统上线后，我会固定看四个数。这四个数构成一个完整的闭环，缺一个都会导致判断失真。

第一个是提醒送达率，它反映通道健康度，正常应该稳定在 98% 以上，低于这个值先查技术问题。

第二个是提醒点击率，反映时机和文案质量，会议型提醒的健康值在 45%-65%，截止型在 20%-35%。

第三个是点击后有效动作率，也就是点击提醒后 30 分钟内产生实质操作的比例，反映行动入口质量，目标值应该在 60% 以上。

第四个是通知权限关闭率，这是最重要的负向指标。如果某条提醒规则的关闭率贡献超过 5%，无论它的点击率多好，都应该被重新设计。

五、案例与数据观察：一次 300 人研发组织的提醒规则重构

前面讲的都是框架，这一节我用一个具体项目来说明框架落地的过程。这是我经手的最完整的一次提醒系统重构，前后跨度约 4 个月。

1. 重构前的状态与问题定位

背景是一家 300 人规模的研发组织，使用某项目管理平台管理研发工作项。接入平台后，团队把所有工作项都开了默认提醒，规则是「截止前 1 天提醒所有人」。

问题在上线第 6 周集中爆发：一是通知权限关闭率从 5% 升到 19%；二是逾期工作项占比不降反升，从 21% 涨到 24%；三是项目经理反馈「每天在群里催人，平台提醒根本没人信」。

我做了一次全量数据分析，发现三个关键事实。第一，日均提醒发送量是 11.4 条/人，其中 68% 属于静默记录就能覆盖的信息类更新。第二，截止型提醒的点击率只有 12%，但会议型提醒点击率高达 58%，说明不是提醒通道坏了，是提醒内容不值钱。第三，逾期的工作项中，有 74% 是「用户打开过任务但没完成」，而不是「用户不知道有任务」。

第三点是这次重构最重要的发现。提醒要解决的不是「让用户知道」，而是「让用户行动」。这两件事需要完全不同的设计。

2. 重构方案的三次迭代

（1）第一轮：做减法，砍掉无价值提醒

第一轮改动最简单也最有效：把所有状态变更、评论、字段修改类提醒全部下沉到静默记录层，只保留消息中心，不推送。同时把工作日项的默认提醒改成「仅对设置了截止日期的任务生效」。

这轮改动之后，日均提醒量从 11.4 条降到 4.2 条。通知权限关闭率在两周内从 19% 回落到 11%。但逾期率没有明显改善，说明减量只是必要条件，不是充分条件。

（2）第二轮：改时机，建立双节点和分层通道

第二轮我们按前面讲的三种任务类型重建了规则。截止型任务改成「截止前一天 17:00 + 当天 09:30」双节点，会议型任务改成「开始前 20 分钟 + 前 2 分钟」双节点，周期型任务改成固定时刻触发一次。

同时建立了通道配额：每人每天强提醒上限 3 条、弱提醒上限 8 条，超出后自动降级。这个规则上线第一周就触发了降级，有 12% 的用户在周三就触发了弱提醒配额上限。

这轮效果明显：逾期率从 24% 降到 17%，截止型提醒点击率从 12% 涨到 29%。但行动入口的问题暴露出来了，点击率涨了，点击后的有效动作率只有 41%。

（3）第三轮：补入口，把提醒变成操作起点

第三轮改动集中在行动入口。我们把所有截止型任务的提醒，从「跳转任务列表」改成「跳转任务详情并展开状态变更控件」，同时在提醒卡片上直接提供「标记完成」「顺延 1 天」「转交」三个快捷动作。

这一轮之后，点击后有效动作率从 41% 涨到 68%，逾期率进一步降到 13%。整个重构过程让逾期率下降了 46%，同时通知权限关闭率回落到 6%。

3. 私有化部署场景下的通道差异

这个项目还有一个特殊之处：它采用的是私有化部署方案，服务端在内网，这带来了一些公有云产品不会遇到的通道问题，值得单独说一下。

内网部署意味着无法直接使用第三方推送服务，所有提醒必须通过企业自有的通道体系下发，通常是内部 IM、邮件网关或客户端长连接。这三条通道的特性差异很大：内部 IM 到达快但容易被免打扰拦截，邮件网关稳定但时效性差，客户端长连接只在应用运行时有效。

我们的处理方式是做通道优先级和降级链：长连接优先，5 分钟内未确认送达则走内部 IM，IM 未确认则 15 分钟后走邮件摘要。关键提醒必须有兜底通道，这是私有化环境下最重要的设计原则，因为一旦唯一通道失效，提醒会静默丢失，而发送方完全无感知。

顺便说一句选型经验。中大型企业（100 人以上组织）在选项目管理平台时，提醒能力往往被低估，实际上它直接决定了流程能不能跑起来。选型时我会重点看三件事：是否支持私有化部署以便接入自有通道体系、是否支持从既有工具（比如国外主流平台）平滑迁移历史数据、以及提醒规则的可配置粒度是否足够细。

这几项能力在国产替代场景下尤其关键。我见过一些团队因为平台不支持平滑迁移，导致历史任务和提醒规则全部重建，迁移成本远超预期。所以如果你正在做类似选型，建议把「提醒规则能否按工作项类型分别配置」和「能否接入自有通知通道」写进评估清单，而不是只看任务管理和看板功能。

4. 一个反直觉的数据观察

重构过程中有一个数据让我意外：把提醒数量减少 63% 之后，用户对「提醒有用」的主观评分反而从 3.1 分涨到 4.3 分（5 分制）。

这说明用户对提醒的感知不是「收到了多少」，而是「收到的里面有多少是有效的」。一个每天只收到 3 条但每条都准的系统，比一个每天收到 12 条但只有 2 条有用的系统，评价高出近 40%。

这个发现也影响了我后面所有项目的第一优先级：先做减法，再做优化。在提醒量没有降到合理区间之前，任何时机优化和文案优化都是在噪声上做文章。

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

框架和案例都讲完了，接下来是行动层。我把产品经理最可能遇到的四种情况分开写，你可以直接对号入座。

1. 情况一：还在从 0 到 1 设计提醒功能

如果你的产品还没有提醒能力，我建议按这个顺序做，不要跳步。

1. 先定义任务类型体系，至少要能区分会议型、截止型、周期型。没有类型体系，后面所有规则都无处挂靠。
2. 设计通道分层和每日配额，把强提醒/弱提醒/静默记录三层定义清楚，并明确降级规则。
3. 为每类任务设定默认提前量和提醒频次，先只做双节点，不要一上来做多节点。
4. 把行动入口做进提醒本身，确保点击次数不超过 2 次。
5. 埋好四个验证指标，尤其是权限关闭率。

最关键的是第一版不要提供「自定义提前量」的入口。在默认值没有被验证之前，开放自定义只会让你收到一堆互相矛盾的反馈，无法定位问题。

2. 情况二：已有提醒功能，但用户抱怨打扰多

这种情况最常见，处理顺序很重要。

第一步是先做量化，统计日均提醒量、提醒类型分布、点击率分布。如果日均超过 8 条，问题一定在数量，不在时机。

第二步是砍量，按前面讲的做减法，把信息类提醒全部下沉到静默层，通常能砍掉 50%-70%。

第三步是加免打扰和汇总机制。免打扰时段是必需品，每日汇总（比如把弱提醒合并成 18:00 的一条摘要）能显著降低打扰感。

这里有个重要提醒：不要在砍量之前去做 A/B 测试优化文案。在噪声环境下测出来的文案差异，基本都是随机波动。

3. 情况三：提醒不小，但用户还是错过关键节点

如果提醒量已经合理，但关键任务还是经常逾期，问题通常出在两个地方。

第一个是提前量不够覆盖准备时间。去查那些逾期的任务，看用户是在什么时候开始做的。如果集中在截止前 1-2 小时，说明提前量给的是「提醒存在感」，不是「准备时间」。

第二个是行动入口断了。点击率高但有效动作率低，说明用户点了但没做成。这时候要看的是点击之后发生了什么：是跳转太深、是缺少快捷操作、还是权限不对导致无法操作。

我的经验是，这类问题的根因有 70% 在入口，30% 在时机。

4. 情况四：跨平台或多端产品

如果产品同时有 iOS、Android、Web 和桌面端，需要特别注意能力差异。

跨平台最重要的是统一业务语义，差异化技术实现。业务上「关键提醒」的定义应该一致，但落到具体平台用什么通道、什么优先级，必须按平台能力分别设计，不能一套参数打天下。

七、不同情况下的取舍

最后这一节我想讲取舍。做提醒设计最难的不是知道该做什么，而是在资源有限、场景冲突的时候决定放弃什么。这里给四组我认为最难的取舍。

1. 取舍一：提前量给足 vs 提醒不被打扰

这两个目标天然冲突。给足提前量意味着更早打扰用户，而更早的打扰更容易被遗忘且更令人反感。

我的选择是优先保证「不被打扰」的下限，用双节点而不是单节点长提前量来解决。与其提前 3 天提醒一次，不如提前 1 天提醒一次并在当天早上补一次。前者用户会忘，后者用户会烦，但双节点的总打扰量更可控，且第二次提醒的时机与行动窗口重合。

具体判断标准：如果提前量超过任务准备时间的 3 倍，就应该拆成双节点。

2. 取舍二：统一规则 vs 用户自定义

统一规则的好处是可维护、可分析、可优化；用户自定义的好处是尊重个体差异。

我的选择是默认规则统一，只开放有限的调整空间。具体做法是提供「安静模式」「标准模式」「积极模式」三档预设，而不是给一个自由输入的时间框。三档预设的差异是提前量倍率和通道强度，用户选档位，系统管细节。

这样做的原因是：自由输入会产生大量无法归因的配置组合，让数据分析和优化变得不可能。而三档预设既给了控制感，又保住了规则的可分析性。

3. 取舍三：覆盖全部任务 vs 只覆盖关键任务

覆盖全部任务会让提醒系统看起来「很完整」，但实际上会稀释有效性。

我的选择是只覆盖关键任务，其余全部走静默记录。判断「关键」的标准前面说过：有明确截止时间、有外部依赖方、逾期会产生实际损失，三者同时满足。

这个取舍的代价是有时会漏掉用户认为重要但系统没识别的任务。所以需要配套一个机制：允许用户手动把某个任务升级为「关键」，但每天有次数上限（比如 3 次）。这既保留了兜底能力，又避免了配额失控。

4. 取舍四：通道覆盖广 vs 实现复杂度低

多通道覆盖能提高到达率，但每个通道都需要适配、测试、维护，成本是线性累加的。

我的选择是核心通道做深，兜底通道做浅。核心通道（系统推送 + 应用内）要做到 98% 以上到达率并且完整支持行动入口；兜底通道（邮件、桌面组件）只保证「内容能被看到」，不追求交互能力。

这个取舍在私有化部署场景下尤其重要。内网环境下每多接一个通道，就多一套运维配置和排障流程。与其做四个半成品通道，不如做两个可靠通道加一个纯文本兜底。

八、一份可以直接对照的检查清单

文章到这里，我把前面所有内容压缩成一份清单。你可以在评审提醒功能方案时逐条对照，任何一条答不上来，都是上线后的隐患。

1. 任务类型体系是否建立？能不能区分会议型、截止型、周期型，并给出各自的默认提前量？
2. 提前量是否有计算公式？是否考虑了行动准备时间、任务切换成本和缓冲，而不是拍脑袋定一个数？
3. 是否使用双节点？对于提前量超过准备时间 3 倍的任务，是否拆成了两个提醒节点？
4. 通道是否分层并设置配额？强提醒、弱提醒、静默记录三层是否定义清晰，每日配额是多少？
5. 配额用尽后的降级规则是否明确？是丢弃还是降级，降级到哪一层？
6. 提醒是否直连行动入口？从看到提醒到完成第一个有效动作，点击次数是否 ≤ 2 次？
7. 是否有不依赖系统推送的兜底通道？在免打扰或通知被关的情况下，关键提醒是否仍能触达？
8. 是否提供免打扰时段和每日汇总？这两项是降低权限流失率的底线配置。
9. 四个验证指标是否全部埋点？送达率、点击率、点击后有效动作率、权限关闭率。
10. 是否做过最坏提醒量测算？用户把所有提醒都打开时，一天最多会收到多少条？超过 12 条就必须重做。

这十条里，第 6 条和第 10 条是最常被遗漏的。前者决定提醒能不能被转化成行动，后者决定提醒系统会不会在用户规模增长后自我崩溃。

回到我开头提到的那位测试负责人。重构完成后，他给 47 个测试用例设置的提醒从「提前 3 天一次」变成了「提前 1 天 17:00 + 当天 09:30 两次」，每条提醒都附带「标记完成」按钮。他的逾期数从 19 个降到 4 个，而且他再也没有关过通知权限。

这就是我对这个功能最核心的判断：提前提醒的价值不在于提醒得早，而在于提醒得准、提醒完能直接动手，以及在整个过程中不消耗用户对通知的信任。任何一条提醒规则上线前，都值得问自己一句，如果用户每天只能收三条提醒，这一条配得上其中一个名额吗？

下一步我建议你做一件很具体的事：打开你正在负责的产品，导出最近两周的提醒发送日志，按任务类型统计条数、点击率和点击后的实际动作率。这三个数会立刻告诉你，你的提醒系统现在处在哪个阶段，是量太大需要做减法，还是时机不对需要重设提前量，又或者是入口断了需要补快捷操作。数据不会骗人，而且这份统计通常花不了一个小时。