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