隐私政策和用户协议有什么区别

上线前整理协议时最常见的卡点：一份文档里又写数据怎么收、又写违约责任，结果审批被退回来，说定位不清。这篇把三类协议的边界拆开，给一张对照表和一份自查顺序，产品、法务、开发各看自己那一列就行。具体条款数值和地区差异到站内页面核对，别照抄网上模板。

上线前整理协议，最常见的卡点就是一份文档里又写数据怎么收、又写违约责任，结果审批被退回来，说定位不清。原因通常是产品从网上找了一份模板，把隐私政策、用户协议、权限说明全塞进去，谁看都觉得像，谁看都找不到自己要的那一句。

这篇不讨论某个具体条款该怎么写，只把三类协议的边界拆开：各自管什么、放在哪里、改了要不要重走同意、审核时先看哪几处。产品、法务、开发可以各看自己那一列，先把口径对齐再动笔。涉及具体字段清单和地区差异，到站内安全与合规专区核对，别照抄模板。

三份文件各管一段，别混在一份里

• 用户协议管的是你和我之间的交易关系：账号规则、付费与退款、内容权属、违约与停用，核心是权利义务；
• 隐私政策管的是我把你的个人信息怎么收、怎么用、怎么存、给谁看、你能怎么撤回，核心是告知与同意；
• 权限政策（有的产品叫权限说明或系统权限声明）管的是设备和系统能力：相机、通讯录、定位、通知这些调用点在哪、什么时候弹、拒绝之后功能怎么降级，核心是调用时机与必要性；
• 一份文档同时讲这三件事，最直接的后果是同意链条断裂——用户点了同意收集数据，不等于同意你随时调权限，也不等于接受停用条款；
• 更麻烦的是后续更新：三件事的改动频率完全不同，捆在一起意味着改一句退款规则也要重新走一遍隐私告知流程。

所以判断一份文件属于哪类，不要看标题，看它试图约束的行为落在哪一段：落在账号和付费上，就是用户协议；落在个人信息的收集使用上，就是隐私政策；落在设备能力和弹窗时机上，就是权限说明。三者可以互相引用，但不能互相替代，引用时也要写清引用的是哪一条。什么情况下不适用这条判断：如果产品本身不采集任何个人信息、也不调用敏感权限，比如纯离线的计算器工具，那它可以只有用户协议，但这属于少数情况，具体到你的产品还得到 安全与合规（/compliance） 对照说明确认。

一张对照表：位置、触发点、改起来快慢不一样

另外两个细节容易被忽略。第一，同一件事在三份文档里的说法必须能对上，比如「注销后多久删除数据」，写在不同地方就是不同答案，用户投诉时你会很被动。第二，判断改动的严重程度要看是否扩大了数据用途或收集范围，扩大就是实质性变更，不改就是技术性调整。具体某次改动算哪一类，站内合规专区有对应的判断口径，按你的实际场景去对。

审查顺序：先对调用点，再对文字

1. 拉一份真实清单把代码、SDK、埋点里实际调用的权限和采集字段列出来。别拿需求文档对，拿线上包和真实请求对，抓包截图存一份。
2. 用清单反查三份文档清单里有、文档里没写的，是缺口；文档里写了、代码里没有的，属于过度承诺，一并删掉，别留着好看。
3. 检查同意是否分层隐私政策的同意不能默认勾选；权限弹窗要在用户实际用到该功能时再弹，不能一进首页把所有权限弹一遍。
4. 检查撤回与降级撤回同意之后哪些功能还能用、数据怎么处理，三份文档里的说法要一致。不一致的先统一口径再发版。
5. 把清单脚本化把权限调用和埋点字段做成一份可自动比对的清单，每次发版前跑一遍，比人工逐句读文档省事得多。常用字段和术语口径到 安全与合规（/compliance） 专区顺着分类找。

哪些写法一看就会被打回

• 用户协议里出现「包括但不限于收集以下信息」这类开放式表述，会被认为范围不可预期；
• 隐私政策用「最终解释权归我方所有」兜底，跟告知同意的逻辑本身冲突；
• 权限说明只列权限名称，不写调用场景和拒绝后的降级方案，用户和审核都看不懂为什么要给；
• 三份文档互相引用却不写清引用哪一条，比如用户协议写「个人信息处理详见隐私政策」，但隐私政策里根本没覆盖那个场景；
• 把撤回同意、注销账号的入口藏在多层菜单里，文档里却写「可随时撤回」，前后对不上。

落地分工：产品写场景，法务定边界，开发验调用

交接口径不确定时，先把名词对齐再开会。比如「设备标识符」「去标识化」「必要的个人信息」这几个词，产品和法务的理解经常不一致，在会上争半小时，不如先到 站内安全与合规术语对照（/compliance） 把定义看一遍。这篇给的是判断顺序和分工方式，具体条款怎么写、某个地区要求告知到什么颗粒度，还是得按你产品的实际形态和上线地区去站内页面核对当时的规则。