通知权限应在产生价值后请求
别名: 通知权限时机 · 价值后请求 · notification opt-in timing · ask after value
概念解释
通知权限没有「正在拍照」这种当场可见的任务锚，人无法在启动时判断以后会收到什么。应在产品已经用应用内方式兑现过一次价值之后再请求：订单已生成、对话已有回复、关注的内容已出现更新。这条只谈授权请求的时机，不谈推送文案怎么写、一天推几次、多条如何聚合——那些属于通知本身的模式，不是这张授权卡。
机制
系统通知开关是总闸：一开，以后各类打断都可能进来；一关，通道往往很难再打开。启动时请求等于要求人在未见过任何一条有用消息时，预先接受未知打断。允许率即使不低，也混进了大量「先点了再说」，随后在系统层关掉或忽略。价值之后再问，把授权接到刚发生的具体结果上：「订单状态变化时告诉你」，必要性来自刚被体验过的功能，而不是来自品牌承诺。通知不像相机，没有「现在这一步做不成」的压力，过早询问只会烧掉首次拒绝的通道。
怎么研究
比较「首次启动即请求通知权限」与「完成一个有结果的任务后再请求」，看授权质量而不是只看允许率。
自变量：请求相对首次价值事件的位置、价值事件是否与通知将覆盖的类型一致。 因变量：允许率、七日内系统层仍保持开启的比例、授权后首次打开通知的点击、因通知而卸载或整体关闭的比例。
实验室里没有真正的后续推送，允许不等于以后会容忍打断。要用产品日志看授权后的保留与关闭。不要把允许率当成功——启动时高允许、三天后高关闭，是时机失败。
边界
强时效工具（验证码、来电、抢票）在完成绑定后就可以问，不必等「用了好几天」；但仍应发生在人看见「这条信息会出现在通知里」的那一次成功之后。企业强制推送的设备管理通道不走这套消费级授权。没有账号、从未产生过可通知事件的应用，不应为了增长在空状态上要通知权限。
怎么落地
- 列出一条「可被通知的价值事件」（订单提交成功、收到第一条真人回复），把系统通知权限请求挂在该事件的确认屏上，不要挂在启动或注册末尾。
- 确认屏上先用应用内方式展示同一条信息，再问要不要以后用通知送达；人可以只看这次、不授权。
- 未发生价值事件前，禁止调用通知权限 API，也禁止用全屏拦截假装应用不能继续。
- 验证：漏斗从安装到通知权限弹窗，中间必须经过至少一次价值事件。抽查允许后七日仍开启的比例；若大量在系统设置里被关掉，把请求再往后移，而不是改弹窗上的形容词。