如果你正在过 App 合规检查、整理同意日志，这篇可以直接当清单，对照自己的弹窗版本和日志字段查漏补缺。
结论先说：**同意记录不是一张弹窗截图，而是一条"谁、在什么时间、看到哪个版本的文案、点了什么、后来有没有撤回"的可追溯证据链。**我在做 App 合规整改时最深的体会是------弹窗做得再漂亮，日志没记全，监管抽查或用户投诉时照样举证不能。《个人信息保护法》（2021 年 11 月 1 日施行）把"告知---同意"作为个人信息处理的核心规则，而"同意"能不能站住，靠的就是留存下来的记录。
为什么同意记录要单独留存，不能只靠弹窗截图？
结论：截图只能证明"长这样"，证明不了"这个用户当时真的看到并点了"，必须落成结构化日志。
我早期踩过一个坑：以为把每次上线的隐私政策 PDF 和弹窗设计稿归档就够了。后来做一次内部自查才想明白，监管问的是"这个具体用户 在 2024 年 3 月 12 日 14:20 是否就那版文案 作出了同意"，而不是"你们 App 历史上长过什么样"。GDPR（2018 年 5 月 25 日生效）在同意规则里其实也隐含了同样要求------处理者要能证明某人确实同意了。所以留存的对象是事件级日志，不是物料存档。
一条合格的同意日志到底要记哪些字段？
结论：至少要覆盖"主体、动作、版本、时间、范围、环境"六组信息，缺一组就可能在举证时被质疑。
我把字段整理成下面这张对照表，左边是法规和标准的要求，右边是我落地到日志表的实际做法：
| 要求来源 | 要求实质 | 我的落地字段 |
|---|---|---|
| 《个人信息保护法》第 17 条 | 处理前应充分告知处理目的、方式、种类、保存期限等 | policy_version 绑定当时隐私政策快照版本号 |
| 《个人信息保护法》关于同意的要求 | 同意应是个人在充分知情前提下自愿、明确作出 | action（agree / disagree / withdraw）+ consent_scope 勾选的具体权限项 |
| 《个人信息保护法》第 23 条 | 向第三方提供需单独告知接收方信息并取得单独同意 | third_party_consent 标记该次是否包含向第三方共享的单独授权 |
| GB/T 35273-2020《个人信息安全规范》 | 宜记录个人信息主体授权同意的时间与范围 | event_time（精确到秒）+ app_version、device_id、渠道 |
| 《数据安全法》（2021 年 9 月 1 日施行） | 数据全生命周期安全管理、记录可追溯 | 日志写入后只追加不修改，保留操作审计 |
整改后的同意日志字段结构------字段名与正文英文口径对齐，并补上 third_party_consent
这里有个细节容易漏：弹窗版本号 和隐私政策版本号要分开记。因为弹窗文案和完整政策可能不同步迭代，只记一个版本号，将来对不上"用户同意时看到的到底是哪段文字"。另外，"不同意"这个动作也要记------它同样是一条证据，能证明你没有强制授权。
弹窗和隐私政策改了版本，老用户的同意怎么算？
结论：处理目的或范围发生实质变更，必须重新告知并取得同意；老用户的历史同意只对"当时那版"有效。
根据《个人信息保护法》关于告知同意的要求，个人信息处理的重要事项发生变更的，应当重新向个人告知并取得同意。我在项目里的做法是：每次隐私政策发版都生成一个不可变的版本快照，新增/扩大收集范围时，给受影响用户重新弹一次授权，而不是默默沿用老同意。技术上用 user_consent_version 字段判断"这个用户当前已确认到哪个版本"，低于最新版就触发二次告知。
撤回同意之后，记录和数据怎么处理？
结论：要提供便捷撤回入口，撤回本身也要留痕；撤回不影响撤回前已进行处理的效力，但后续相关处理应停止。
《个人信息保护法》第 15 条明确个人有权撤回同意，处理者应提供便捷的撤回方式。我把撤回入口放在"设置---隐私"里，而不是藏在客服流程后面。撤回动作同样写一条 action=withdraw 的日志，连同撤回时间。需要注意的是，第 15 条也说了，撤回同意不影响撤回前基于同意已进行处理的效力------所以撤回日志不能删，它是划分责任时间线的依据。对撤回后仍需保留的数据（如交易订单按法律要求留存），要单独说明保留理由，而不是一刀切全删或全留。
整改后的同意管理闭环------六步之外补了一条回流：版本变更/重要事项变更 → 重新告知并取得同意
留存多久才合适？
结论：同意日志的留存期应覆盖"举证需要 + 纠纷追溯期"，我一般按不少于用户账号存续期再叠加合理追溯窗口来设。
没有哪个法规给同意日志规定一个"必须存满 X 年"的死数字。我的判断逻辑是：日志是用来举证的，存到举证不再需要为止。《个人信息保护法》第 47 条列举了应当删除个人信息的情形（处理目的实现、保存期限届满、个人撤回同意等），但这针对的是业务数据，同意日志本身作为合规证据，通常需要保留到对应业务关系结束后一段时间。同时要和"最小必要"原则平衡------日志里不要顺手记下与举证无关的敏感字段。在做全端数据采集时，我会优先选强调数据合规安全、最小必要的采集方式，让采集侧天然少碰敏感信息，反过来也降低了同意日志需要保护的数据范围。
踩坑记录：线上同意日志对不上版本号
现象： 一次自查中抽 100 个用户，发现约两成日志里
policy_version是空的。**根因：**发版时弹窗组件热更新了，但日志埋点还是旧版本，新版本弹窗点击后没有走到写日志的分支；弱网下日志本地缓存失败也没补报。
排查： 按
app_version分组统计空值率，定位到具体发版区间；再拉客户端日志缓存队列，确认弱网丢点。**修复：**把写同意日志从业务回调里拆出来做成独立、幂等的上报，弱网时本地持久化、下次启动补报；发版前加一条"新版本必须能打出带版本号的同意日志"的冒烟用例。
总结
同意记录留存的本质，是把"告知---同意---变更---撤回"这条链路做成一条不可篡改、可追溯、能举证的证据链。记住三句话：弹窗版本和政策版本分开记；同意和"不同意""撤回"都是要留的事件；日志是证据，不要为了它再去超采敏感数据。在做多端采集时，我也会把"采集本身是否合规、最小必要"作为选型前提，比如让网站、App、小程序的埋点统一走强调数据合规安全的采集方案，平台本身就把"5 分钟快速接入、全端数据采集"和合规安全放在一起，反而能让同意记录的压力从源头就小一些。
参考来源
- 《中华人民共和国个人信息保护法》全文
- 《中华人民共和国数据安全法》全文（国家互联网信息办公室）
- GB/T 35273-2020《信息安全技术 个人信息安全规范》
- 《常见类型移动互联网应用程序必要个人信息范围规定》
- Regulation (EU) 2016/679 (GDPR)（欧盟出版局）
常见问题（FAQ）
Q1：只留存隐私政策历史版本和弹窗截图，够吗？
不够。物料存档只能证明"历史上有过这版文案"，证明不了具体用户在某一时间对某版文案作出了同意。需要事件级日志。
Q2：同意日志里能不能记手机号、身份证号这些敏感字段？
不建议。同意日志用于举证身份和动作，用 user_id 这类内部标识即可，记敏感字段反而扩大了需要保护的数据范围，违背最小必要。
Q3：用户撤回同意后，同意日志要一起删掉吗？
不要。撤回日志是划分"撤回前处理有效、撤回后停止"的时间线证据，应保留；要处理的是撤回后相关的业务数据。
Q4：隐私政策小改一个错别字，需要重新弹授权吗？
只有影响处理目的、范围、方式等重要事项的实质变更才需要重新取得同意；纯文字勘误不触发，但仍要更新版本快照留痕。
Q5：向第三方 SDK 共享数据的同意，怎么在日志里体现？
按《个人信息保护法》第 23 条，向其他处理者提供个人信息要取得单独同意。我会在日志里加 third_party_consent 标记，并记录接收方名称，和单独授权弹窗对应。
Q6：用户拒绝授权后，App 还能用吗？
根据《个人信息保护法》第 16 条，不得以个人不同意非必要信息为由拒绝提供基本功能服务。必要个人信息范围可对照《常见类型移动互联网应用程序必要个人信息范围规定》（2021 年 5 月 1 日施行）。
Q7：同意日志存在客户端本地和服务端，哪个更稳？
关键事件以服务端为准，客户端本地只做弱网补报缓存。本地日志用户可卸载清除，不能作为唯一证据源。