O1.05.2Bundled consent设计研究
一揽子同意无法表达细粒度意愿
别名: 捆绑同意 · 一揽子授权 · granular consent
概念解释
捆绑同意（bundled consent）把多个彼此可分离的数据用途、接收者或渠道压成一次接受或拒绝。它只能记录“接受整包”，无法表达用户愿意为核心功能提供必要数据、却不愿用于广告、跨服务画像或公开展示的组合意愿。细粒度不是为每个技术事件弹一次框，而是让具有不同目的和后果的选择可被分别表达。
机制
偏好往往是条件性的：同一人可能接受端侧个性化却拒绝上传原始记录，接受安全通知却拒绝营销。单一开关把多维偏好投影成二元结果，产生不可识别性——系统无法知道接受者认可哪一项，也无法知道拒绝者排斥哪一项。若其中包含用户依赖的功能，整包接受率主要反映最重要那一项的价值，其他用途则搭便车获得授权。
怎么研究
可用离散选择或联合分析让参与者在用途、数据、接收方和回报不同的方案间选择，估计各属性对意愿的贡献；也可比较捆绑与分组界面的选择稳定性、完成时间和事后修改。分析需检查选项过多造成的随机点击，并用重复题或延迟复测判断偏好一致性。把每个字段拆开会混淆技术粒度与有意义的决策粒度。
边界
并非所有处理都应独立选择。共同实现一个明确请求且无法合理分离的必要步骤，可以作为同一功能单元说明；过度碎片化会制造疲劳和错误心智模型。粒度也不能掩盖依赖：关闭一个用途若会降低另一功能，应在选择前说明。法律允许的处理基础与同意粒度是不同问题，不能用漂亮的开关替代必要性判断。
怎么落地
- 先按用户可理解的目的和后果分组，再判断各组能否独立关闭；不要按内部数据库表或供应商数量机械拆分。
- 把核心必需处理与广告、共享、公开展示、训练等可选目的分开，并明确每个选择改变的功能。
- 提供组合状态摘要和一次性“全部拒绝可选项”，同时允许有明确需求的人展开细调。
- 用覆盖常见偏好组合的测试账户核对实际数据流；任何关闭用途仍被发送，或关闭无关用途导致核心任务失败，都视为粒度设计错误。