app合规:用户协议及隐私政策审查要点

很多团队不是没写隐私政策，而是写了却经不起问：审核被驳回、应用商店要求整改、用户投诉说你没告知就采集。问题往往不在文笔，在于条款和App实际行为对不上。这篇按审查动作拆成几组清单，告诉你在哪儿比对、比对什么、发现不一致先改哪一头，最后把证据留下来。

很多团队不是没写隐私政策，而是写了却经不起问：审核被驳回、应用商店要求整改、用户投诉说你没告知就采集。问题往往不在文笔，在于条款和App实际行为对不上。这篇按审查动作拆成几组清单，告诉你在哪儿比对、比对什么、发现不一致先改哪一头，最后把证据留下来。

整体思路是先跑App再读条款，而不是抱着文档抠字眼。顺序上建议分四遍：第一遍用实际行为对条款，第二遍做权限与数据的映射表，第三遍清点第三方与SDK，第四遍处理更新留证与提交前自查。每一遍都有明确的产出物，做完能直接交给下一个人复核，而不是停留在「看过了」。这套流程对自研团队和外包交付同样适用，区别只在谁来填表。

第一遍：拿App实际行为去对条款，不是读条款本身

先别打开隐私政策。把App从安装到主要功能完整跑一遍，重点记录三件事：申请了哪些系统权限、在哪个页面触发、拒绝之后还能不能用。这份记录就是你的核对底稿，拿着它逐条去条款里找对应表述，找不到对应的一句话，就是一个整改项。判断口径很简单：不是条款写得漂不漂亮，而是用户看完能不能知道自己的数据去了哪。

• 后台采集：App切到后台甚至没打开界面时是否仍在传输，这类最容易被审核抓住，先在真机上看流量和权限调用记录
• 默认勾选或一揽子同意：注册页、引导页有没有替用户预先打勾，或者把多项授权捆在一句话里
• SDK 静默上报：初始化时不经用户操作就发数据，尤其是统计和崩溃类组件，要在集成阶段就确认触发时机
• 剪贴板读取：很多App在启动或返回前台时读剪贴板，条款里没提就属于漏写

权限、功能、数据三类要能一一映射

这一步的产出物是一张三列表：权限名、触发场景、收集到的字段。填完之后拿去核对条款里「我们收集哪些信息」那一节，数量对不上就是漏写。敏感权限要单独成条，写清楚用途和关闭方式，别混进「为改善服务体验」这种笼统句里。拒绝授权时的降级路径也要写出来：哪些功能还能用、哪些不能用，这既是审核关注点，也是投诉高发区。

映射表做完不要只放在文档里，把它当成评审材料：产品、开发、法务各看一遍，谁填不出触发场景，就说明这条权限可能没必要申请。用不到的权限直接不申请，比写一段解释更省事。

第三方与SDK：谁在收、收到哪、怎么退出

把接入的统计、推送、崩溃、支付、内容审核类组件列清楚，每个写明白收什么字段、用于什么目的。共享清单最忌讳只放一句「可能与合作伙伴共享」，这种表述在审核眼里等于没写。如果涉及数据出境或转委托处理，要单独成段说明场景与范围，概念别用错，具体口径可以到 /safety 和相关术语页核对，写错术语比写少更麻烦。

共享清单

逐项列出组件名称、收集字段、使用目的，而不是笼统的「合作方」

退出入口

个性化推荐、推送、统计类开关要真实可达，条款里写了就等于作出承诺

删除路径

账号注销与数据删除的入口、处理时限、删除范围，先在App里走一遍再落笔

跨境场景

哪些数据出境、出境到哪、依据是什么，写不清就先去术语页核对口径

这一节的判断标准是：一个普通用户顺着条款能不能自己找到关闭或删除的入口。如果入口藏在三级菜单，条款里就必须写出完整路径，否则就属于告知不充分。什么情况下不适用？如果App完全不接入第三方组件、且所有数据只在本地处理，这一节可以压缩，但本地处理的说法同样要能验证，不能只是嘴上说。

更新、留证与提交前自查

条款改了什么要留痕：版本号、生效时间、旧版归档三样缺一不可。重大变更要重新征得同意，别默认用户继续使用就算同意。留证顺序建议固定下来：带版本和时间的界面截图、权限调用记录、应用商店的审核往来。出事的时候，这三样比事后补写的说明有用得多。

1. 改前归档把旧版条款原文和生效时间存一份，改动点列成差异表，谁改的、为什么改写清楚
2. 重新取得同意涉及收集范围、共享对象、使用目的的变更，弹窗让用户重新确认，拒绝后要能给到可用的降级版本
3. 固定证据截图带上版本号和时间，权限调用记录导出留存，审核沟通记录按时间顺序归档
4. 提交前自查权限表、SDK 清单、删除入口、变更记录四样齐全再提审，缺一样就补完再交

如果团队同时接入了多个中转或代理类服务，审查时要额外确认数据流向和留存策略，别只看对方官网的说明。想核对各家服务的可信度和更新情况，可以到 /sites 和 /rankings 看当时的记录，数字和结论以页面上的为准。