O1.04.2Opt-in consent设计研究

需要用户主动开启而非主动关闭

别名: 选择加入 · 主动同意 · affirmative action

概念解释

选择加入(opt-in consent)指会增加数据处理或可见性的能力,只有在用户作出明确肯定动作后才启用;未响应、离开页面或沿用初始状态都不算同意。它与选择退出(opt-out)不同:后者先启动处理,再要求用户发现并关闭。关键不只是按钮存在,而是开启动作对应具体用途并发生在处理之前。

机制

选择加入把证明价值的负担放在请求处理的一方,也保留一条可观测的意愿证据。选择退出利用默认粘性、注意力不足与设置搜索成本,使大量未决定的人被计作接受者。若肯定动作与注册、关闭弹窗或核心任务捆绑,动作本身仍无法区分用户是在表达偏好还是只想继续,形式上的点击不产生有效授权。

怎么研究

可比较 opt-in 与 opt-out 界面中的启用率、理解准确度、后续撤回、功能使用价值和后悔,并分析未操作者而非只比较选择者。过程数据可记录阅读时长、返回修改和错误点击,访谈则检验人们认为何时开始处理。选择加入通常会降低启用率,但该差异不能单独证明哪种选择更符合真实偏好;需结合理解与延迟复核。

边界

用户主动请求的核心操作无需为每个必要数据流重复取得选择加入,否则会把同意退化为机械点击。紧急通信、账户安全或法定义务也可能依赖其他处理依据。相反,将营销、公开展示或跨服务追踪包装成核心功能不能使其变成必要。儿童、认知负荷高或代理决策场景还需额外判断肯定动作是否具有表达能力。

怎么落地

  • 在任何可选处理开始前保持关闭,并让开启控件明确指向一种用途和一类数据。
  • 把“继续使用”“保存设置”与可选同意分开,禁止预勾选、双重否定或把关闭弹窗解释为接受。
  • 用户暂不决定时保留核心流程和稍后入口;开启后提供同样可发现的撤回路径。
  • 分别用接受、拒绝、忽略和误触场景检查事件日志与网络请求;只有明确开启分支可产生对应数据流,其他分支必须保持静默。

延伸

  • 同组O1.04.1 默认应为最保护隐私的选项 · O1.04.3 版本更新不应静默放宽默认
  • 相邻O1.05 知情同意的可用性困境 · O2.06 同意界面的设计与滥用
  • 站内检索opt-in consent · affirmative action · opt-out

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/O1.04.2