4 级推送通知疲劳模型

推送通知是流失用户最廉价的方式。每天 1 条推送时，留存曲线看起来还不错——来自 Localytics 和 Urban Airship 的行业数据集中在 3 个月留存率 88% 左右。每天 3 条推送时，曲线下降 17 个百分点。每天 5 条推送时，则下降 34 个百分点。这条曲线陡峭且不可逆：当一款应用每周向用户发送 2 到 5 条他们并不想要的推送时，46% 的用户会彻底关闭推送。

Soulwise 的应对方案是一套 4 级疲劳模型。它会在一个滚动的 14 天窗口内检测打开率的衰减，并在用户彻底退订之前逐步降低通知频率。

本文将带你了解它的设计、阈值以及恢复逻辑。

四个层级

这个状态机很小。每位用户在任一时刻只处于一个层级。

• T0 —— 健康。 完整日程。早间仪式提示、上午情境提醒、傍晚回顾，再加上以事件为锚点的提示。
• T1 —— 降级。 暂停上午的情境提醒。其余一切照常。
• T2 —— 仅保留锚点。 只保留早间仪式提示和周日回顾。所有非必要推送都暂停。
• T3 —— 仅保留每周。 只留下一条每周推送。每日节奏暂停。

顺序很重要。上午情境提醒第一个被砍掉，因为它的事件权重最低：它只是情境提醒，而非每日仪式本身的一部分。早间提示保留得最久，因为以事件为锚点的每日推送带来的留存率约为通用推送的2.85倍；砍掉它就等于砍掉整个应用。

什么会触发层级变化

系统会为每位用户保留一个滚动的 14 天打开率数据窗口。每天，模型都会查看最近 14 天的数据，计算用户在该窗口内对推送通知的打开率。

Soulwise 的阈值是相对于用户个人基线的打开率下降 30%。如果某位用户通常会打开 60% 的推送，而滚动窗口内降至 42% 或更低，模型就会将其下调一个层级。这种下降必须持续至少 3 天，以避免对单独一个糟糕的星期（休假、生病、工作繁忙的一周）做出反应。

晋升是对称的。如果某位用户处于 T2，且其打开率连续 3 天回升到基线减去 30% 阈值之上，就会被上调至 T1。恢复到 T0 也采用相同的步骤。

为什么以事件为锚点的推送留存最久

支撑这一设计的，是 Localytics / Urban Airship 的一项数据：以事件为锚点的每日推送，留存率约为普通每日推送的 2.85 倍。凌晨 9 点一句泛泛的"快来看看吧！"很容易被遗忘。而一条与今天实际周期阶段挂钩的晨间提示（"温和的开端。今天你都有哪些安排？"）则是以事件为锚点的——它带来了新信息。

T2 之所以保留晨间提示，是因为去掉它就等于去掉了整个每日仪式。应用里的其余一切，都围绕着用户早晚各登录一次来构建。没有这条提示，整个循环就会断裂。

疲劳提示横幅的设计

当用户被降级后，下次打开应用时，界面里会出现一条小小的横幅：

"我们已经为你减少推送 7 天——要重新打开吗？"

这句话做了 3 件事：承认变化、把原因归于应用的行为（而非用户的失败），并把选择权交还给你。如果你想恢复通知，只需轻点一下，就能撤销这次降级。

这一点很重要。无声的降级会让人觉得应用抛弃了用户，而有提示的降级则让人感到应用在乎你。同样的动作，换一种表达，感受截然不同。

我们刻意不去构建的反模式

产品规格明确规定了哪些做法是被禁止的：

• 不做"别中断连续打卡"式的愧疚推送。 连续打卡本质上是利用损失厌恶来羞辱用户。疲劳模型会降低用户的等级，而不是羞辱他们。
• 不在 T3 末尾发送"我们想你了"式的召回推送。 处在 T3 的用户已经在向应用传递信息了。再增加推送是错误的回应。
• 不在推送正文里使用虚假计数器或稀缺感。 "刚刚有 X 人注册"是暗黑模式的表演，而非真正的通知。
• 不在推送标题或正文中出现经期或星座内容。 推送会经过 CI lint 检查，凡是含有被禁模式的构建都会被拒绝；疲劳模型绝不会绕过它。

系统内部的数据究竟是什么样的

模型为每位用户存储 3 个字段的状态：

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

这就是疲劳状态的全部。没有浏览历史，没有打开率之外的互动评分，也没有针对用户训练的机器学习模型。简单本身就是关键所在：规则可审计，阈值有记录，用户体验的结果可预测。

这不是什么

关于适用范围的说明。

疲劳模型是针对每位用户的，而非针对群体。我们不会去看"和你相似的用户"，也不会通过降低某些用户的推送来研究留存。这个模型服务于每一个个体。

它也不会取代你自主设置的选项。免打扰时段、按类别静音，以及明确关闭全部推送，都独立于疲劳模型运作。这两套系统相互配合；你的明确选择，始终优先于模型的推断。

这对应用的其他部分为何重要

推送通知，是让每日仪式得以延续的关键。一款打卡应用若失去推送权限，就失去了主要的留存循环。4 层级模型之所以存在，正是为了让应用不滥用这项权限，避免以最缓慢的方式失去它——只因稍稍恼人，又持续得够久。

更完整的每日仪式背景，请见 Soulwise 中心页。疲劳模型只是其中一环，它让这场仪式保持互惠，而非一味索取。

简而言之：合适的推送次数，是不会引发退订的最大次数。疲劳模型正是应用每隔 14 天，为每位用户找出这一数字的方式。