H5.09.3new notification types default off设计研究
新增通知类型默认应关闭而非自动加入已订阅集合
别名: 新类型默认关 · 不自动订阅 · opt-in new channel
概念解释
产品后来新加的类型——购物推荐、每周摘要、好友的好友动态——必须默认关闭，不能因为用户曾经打开过「通知」或订阅过「订单更新」，就把新类型塞进已订阅集合。过去的同意覆盖的是当时存在的那些类。自动加入是在用旧同意覆盖新内容。
机制
同意是对已知对象的。集合在人背后膨胀，等于把一次历史决策当成空白支票。人发现新到达时，体验是「我没要过这个」，修复动作往往不是去设置里关这一只——那要先知道它叫什么——而是关总开关。默认关闭把新类型留在可选清单里，需要的人再打开，不需要的人不会在某天被新通道吓到。
安全类新通道有时必须默认开（新的登录警报）。那是后果矩阵的例外，要单独说明「以后会多一类安全通知」，不能偷偷混进推荐。例外必须少，否则「新类型默认开」会借安全的口子回流。
怎么研究
在已订阅用户上线一个新类型，比较默认开与默认关：新类型的打开、投诉「没订过」、以及系统权限关闭。
自变量：新类型默认状态、是否在发前告知、新类型与旧类型名称的相近程度。 因变量：非自愿到达率、总关率、事后主动打开新类型的比例。
实验室里问「你愿不愿意收这个」会得到礼貌性同意，和被突然推到手机上不是一回事。要看未提示的第一次到达。不要用新类型的打开率给默认开辩护——打开率含惊讶点击，惊讶会转化为关闭。
边界
监管要求必须送达的新类型（条款变更）可以默认开，但应走事务/法定通道，并在第一次到达上标明原因。把旧类型改名或拆分时，旧的开/关应继承到对应的新容器，这不是「新类型」，是映射；映射错了会看起来像自动加入。测试通道、内部员工开关不得泄漏成全量默认开。
怎么落地
- 发布新类型时默认关；设置里出现该项并可用一句话说明它是新的。
- 安全例外默认开时，第一次到达必须写明「这是新的安全类」，并提供单独关闭（若法律允许）。
- 禁止用「你已开启通知」作为新类型的同意记录。
- 验证：对一群已订阅订单更新的人上线推荐类。默认关的那一组不应在上线当天收到推荐；若收到了，就是自动加入。再看随后一周的总关是否只出现在被自动加入的那一组。