频次超过阈值会触发整体关闭
别名: 通知关闭漏斗 · 超阈值关推送 · permission revocation
概念解释
人对一个应用的推送有一个整体耐受阈值。越过之后，下一步常常不是少看某类，而是关掉整条通道：系统权限关、应用内总开关关、卸载。阈值按「最近这段时间被烦的密度」校准，不是按产品计划的周配额。这条关心的是超阈值之后的关闭漏斗，不是给每一类设独立上限，也不是静默时段怎么穿透。
机制
关闭是一种节省决策的策略。逐类微调要理解和寻找控件；一次总关把未来的判断费清零。当到达密度高到人不再愿意分拣，总关的成本低于继续分拣。关闭还具有不对称性：打开权限有系统弹窗和说明成本，关上往往只要一次开关。所以漏斗是单向的——密度把人推过沿，回来要另付一笔信任。
阈值是体验密度，不是服务器计数。同一条数，夜里连响和下午静默入栏，越过沿的速度不同。人也把「没有相应动作的到达」计进密度：打开率可以不低，但若打开后无事可做，密度仍在积累厌恶。
怎么研究
把关闭当成漏斗来画，而不是只报日活。从到达 → 清除不打开 → 在通知上关这类 → 关应用总开关 → 撤系统权限 → 卸载，看每一跳的前置密度。
自变量：单位时间到达数、无后续动作的到达占比、是否存在比总关更近的出口。 因变量：各跳转化、从高密度到总关的天数、关闭后是否再打开权限。
实验室里很少有人真去关系统权限。要用生产日志或至少允许「请像在自己手机上一样关掉」。不要把「少发之后打开率上升」直接读成阈值被尊重——打开率上升也可能是因为剩下的人更耐烦，关闭者已经离开样本。
边界
值班、客服、交易终端以到达为工作本身，阈值极高，总关几乎不发生；用关闭漏斗优化会误伤。法定送达不能因怕关闭而停发，但应走独立通道，避免和营销密度绑在同一计数器里。新安装前几天的「多介绍一点」会迅速烧阈值，早期密度要按更短窗口看。同一账号多设备，关闭发生在被吵到的那一台，服务器侧的「用户还开着」可能是错的。
怎么落地
- 按用户画关闭漏斗，找出总关前一周的到达密度和无动作到达占比，把那一段当警戒线。
- 接近警戒线时先减少无动作类型的发送，而不是继续用同一总量撞开关。
- 总关发生后不要用更频的「我们怀念你」去把人推回来，那会确认关闭是对的。
- 验证：对比总关用户与仍开启用户在关前 7 天的日均到达。若关的一侧显著更高，阈值在起作用；把那一侧的无动作类型砍掉一截，再看下一cohort的总关率，而不是只看打开率。