O1.05.4Just-in-time consent设计研究
同意请求出现的时机决定用户是否有认知资源阅读
别名: 即时同意 · 情境化同意 · consent timing
概念解释
即时同意（just-in-time consent）把告知和选择放在相关数据即将被处理、且用途能够由当前任务理解的时刻。同一段文案若出现在启动页、关键提交之前或功能首次调用之后，用户可投入的注意力和对后果的理解会不同。合适时机既不能早到没有情境，也不能晚到处理已经发生；它关注的是决策窗口，而不是把弹窗贴近任何一次点击。
机制
人会优先维护当前任务目标。注册开头尚不知道功能价值时，抽象的数据请求缺少可挂接的心智模型；付款、求助或紧急操作中，完成压力又会挤占阅读与比较资源。接近相关动作且允许暂停的请求，能让数据、用途和即时收益形成因果联系。若请求挡在不可中断的关键路径上，情境相关性反而会变成强迫，用户仍会为恢复任务而快速通过。
怎么研究
可在不改变文案与选项的条件下操纵请求位置：首次启动、功能入口、数据即将上传前或任务完成后，测量阅读行为、用途理解、选择稳定性、任务恢复时间和事后惊讶。双任务范式或主观负荷量表可估计认知资源，但应与真实任务表现结合。接受率不是主要效果指标；最佳时机可能降低接受，却提高预测准确度和偏好一致性。
边界
并非所有处理都适合逐次提示。连续传感、后台同步或安全监测若每次打断会造成疲劳，应在首次启用的可理解时刻说明持续范围，并保留状态指示与复核入口。处理开始后才告知不构成事前选择。高压场景即使与数据用途高度相关，也可能缺乏自由决定条件，此时应延后可选处理，而不是利用迫切性取得点击。
怎么落地
- 把每个可选用途映射到用户首次能理解其价值、但数据尚未产生或发送的具体事件。
- 避开付款确认、故障恢复和紧急求助等高负荷节点；允许关闭请求、稍后决定并继续原任务。
- 对持续处理说明开始、停止和后台状态，不用高频弹窗替代可见指示。
- 以相同文案测试多个触发点，要求参与者在选择后解释用途并预测数据流；联合比较理解、任务恢复和延迟反悔，选出不是单纯接受率最高的时机。