H5.09.1category subscription versus master switch设计研究
分类订阅让用户按内容类型而非全部开关做取舍
别名: 分类订阅 · 按类型开关 · notification channels
概念解释
系统权限打开之后，人面对的不该只剩一个总开关。分类订阅让接收按内容类型拆开：消息、交易、安全、社交、营销，每一类可单独留或丢。取舍发生在「这一类还要不要」，而不是「这个应用还许不许出声」。总开关是权限层的事；订阅是权限已经给过之后，通道内部的粒度。
机制
人对应用的价值判断是分类型的：聊天要留、促销要走。只有总开关时，这两类被捆成一次决策，厌恶的那一类会把需要的那一类一起带走。拆开之后，损失函数可以对齐：留下高错过成本的类型，丢掉无待办的类型，整条系统权限得以保全。
类型必须是人能从到达内容反推的。叫「动态」「提升」却混着账单和推荐，订阅名和到达对不上，人只能回到总关。分类是语义合同：名字、例子、实际到达三者一致。
怎么研究
给已授予权限的人两种设置：仅总开关，或可按类型开关。持续发送混合类型，看系统权限保留率、各类型到达的打开与清除。
自变量：是否提供类型开关、类型命名是否与到达一致、营销是否与事务捆在同一类。 因变量：系统权限关闭率、单类关闭率、事务类到达在营销被关之后是否仍被打开。
实验室一次勾选测不出「后来把整个权限关了」。要看数日。不要把类型开关的点击率当成功——成功是权限还在、不想要的类被单独拿掉。
边界
只有一类到达的工具（验证码应用）做分类是空架子。操作系统若已提供通道（Android channels）而应用再做一套不同名的开关，两套会打架。权限尚未授予时谈订阅没有对象——那是何时申请权限，不是订阅模型。
怎么落地
- 在权限已开的前提下，把到达拆成少数可理解的类型，每类独立开关。
- 事务与营销不得共用一类；安全单独一类且默认保留。
- 设置页用真实到达举例，而不是只写内部代号。
- 验证：让人关掉营销类后仍能收到订单和安全。若关营销时系统权限也被撤，或订单跟着停，分类就没有从总开关里独立出来。