用户协议与隐私政策的区别和联系

做产品时常见两种翻车：把数据处理的事全塞进用户协议，结果隐私政策里没写；或者两份文档互相抄，责任条款和告知条款混成一锅。上线被应用市场打回、被用户投诉时才回头改，成本高得多。这篇不重复模板怎么写，只讲两份文档的边界、重叠区怎么处理、评审时按什么顺序看，以及什么情况下这套分工不适用。

做产品时最常见的两种翻车：一种是产品、法务图省事，把数据处理的事全塞进用户协议，结果应用市场审核时发现隐私政策里根本没提；另一种是两份文档互相抄，责任条款和告知条款混成一锅，用户投诉时你连哪句写了、哪句没写都说不清。等到被打回或者被投诉才回头改，返工成本比一开始就分清楚高得多。

这篇不重复模板怎么写，只讲两份文档的边界在哪、重叠区怎么处理、评审时按什么顺序看，以及什么情况下这套分工不适用。产品经理和法务都可以直接拿去当对照表用。数据类的判断，比如某类信息的留存期是否合理，去站内 /tools/speed-test 旁边的资料区核对当时的数字和口径，别照搬别家的截图。

为什么是两份文档而不是一份

用户协议调整的是「你和平台之间的交易与服务关系」，回答的是我用你的服务要守什么规矩、你不给我用了我能不能退款；隐私政策调整的是「平台怎么处理你的个人信息」，回答的是你收我哪些信息、拿去干什么、给谁看。一个偏合同，一个偏告知与授权，法律基础和成立时点都不一样。

合成一份的后果，最常见的是同意链条断裂：用户点一次「同意」，被当成对全部条款的授权。事后你很难说清哪部分是知情同意、哪部分是合同约定，遇到监管问询或投诉，举证会很被动。所以两份文档分开不是形式主义，是让每一个「同意」都有明确的指向。

边界对照：同一件事该写在哪一份

很多团队纠结某句话放哪边，其实大部分内容归属是清晰的。下面这几组对照可以直接贴在工位上，写的时候照着归位，评审的时候照着挑错。

账号与交易

注册、付费、退款、违约、封号、争议解决、免责范围，全部归用户协议。

信息处理

收哪些字段、用来干什么、存多久、给谁看、怎么删怎么导出，全部归隐私政策。

第三方服务

协议里只写「会使用第三方服务」，政策里写清该第三方的处理目的和信息类型。

通知与送达

协议里写法律文书和平台通知怎么发；政策里写隐私相关的变更怎么告知。

拿不准的时候，用前面那个问题过一遍就够了。还有一个容易忽略的点：涉及第三方 SDK、埋点、推送、位置与设备标识时，两份都要提到。协议里一句带过，政策里写透，这样既不让协议变得臃肿，也不会在政策里漏项。

重叠区怎么处理：三处最容易打架的地方

边界再清楚，也有三处天然重叠。这三处如果不提前对口径，上线后不是被审核挑出来，就是被用户截图对比后投诉「前后不一致」。每一处都要指定一个主文档，另一份只做引用或补充。

• 未成年人条款：协议里写使用资格与监护人责任，政策里写儿童信息的收集范围和监护人同意方式，两边的年龄表述必须能对上，不能协议说「未成年人需监护人同意」而政策里只字不提儿童信息。
• 账号注销与数据删除：协议写注销的条件和后果，政策写删除范围与法定留存例外。两边口径不一致，就是虚假告知的高发区——协议说「注销即删除」，政策却另有留存期，用户一定会抓着这点投诉。
• 跨境与共享：协议里只能笼统写「可能委托第三方处理」，具体接收方类型和目的放政策。别把接收方名单写进协议正文，名单会变，协议改动成本比政策高得多。

处理原则：一主一辅，不做双向复述

重叠内容的写法建议是：指定一处为主，另一处只做一句话引用，指向主文档。比如数据删除的细节以政策为准，协议里写「注销后的数据处理见隐私政策」，而不是把政策里那段话抄一遍。抄一遍的代价是下次改一处漏一处，两份文档就慢慢对不上了。

两份文档的配合关系：引用、版本与同意

配合关系体现在三个地方：引用怎么写、版本怎么管、同意怎么分层。这三个地方做扎实，两份文档才是「一整套」而不是「两个孤岛」。

1. 引用写法协议只引用政策名称和可查看路径，不复述政策细节。引用处写明文档全称，产品里对应的入口要能点得到，验证方式是随便找一个新用户走一遍，看能不能从协议页跳到政策页。
2. 版本管理两份文档各自独立版本号，但要记录「同一次上线的配对版本」。评审时按配对版本对拉，确认这一版协议对应的就是那一版政策，避免出现协议更新了、政策还是旧版的情况。
3. 同意分层注册页给协议的同意，收集信息前给政策的同意，敏感信息再单独给一次同意。三种同意的文案和落点要能区分开，具体交互写法可以参考站内关于同意提示的讨论页面。
4. 变更节奏区分协议变更多数走通知加继续使用视为接受，政策重大变更通常需要重新取得同意。两种节奏不要混用，尤其别把政策的重大变更当成协议的常规更新来发通知。

评审顺序：先看分工，再看单份

评审时最容易犯的错是逐字读单份文档，读到后面忘了前面的逻辑。更高效的方式是按四步走，先看两份的分工对不对，再看单份内部有没有硬伤。这个顺序能把大部分结构性问题在前两步就暴露出来。

第三步是很多团队漏掉的：政策写得再全，如果产品实际有的功能、权限、SDK 没在政策里体现，一样会被打回。验证方法很简单，拿产品的功能清单和权限清单，一条条在政策里找对应表述，找不到的就是缺项。第四步查的是说做不一，这是审核和投诉里最高频的原因。

参与人怎么安排

建议产品出功能清单，法务出边界判断，两边一起过第二步和第三步。纯法务闭门改文档，往往改出一份合规但和产品对不上的政策；纯产品自己写，又容易漏掉法定必须告知的内容。两边碰一次，比各自改三版都管用。

什么情况下这套分工不适用

上面这套分工是给面向外部用户的消费类产品准备的。有几类场景直接套用会别扭，甚至适得其反，需要换一套判断逻辑。

• 纯内部工具、不面向外部用户时，重点从「告知同意」转成内部数据管理制度，两份文档的写法差别很大，照抄对外模板没有意义。
• 单一功能小程序、几乎不收集个人信息时，政策可以很短，硬套长篇模板反而暴露了没做的承诺，将来执行不了更麻烦。
• 出海产品还要看当地要求，披露颗粒度和同意机制可能不一样，不能直接翻译中文版就用，至少要让当地专业人士过一遍。
• 纯 B 端签约场景里，数据处理条款常放在合同或数据处理协议里，不一定走「隐私政策」这种对外的公开形式。

判断自己属不属于例外，问一句：这份文档是给谁看的、用户有没有可能拿它来主张权利。如果答案偏向内部管理或合同相对方，那这套对外告知同意的分工就不完全适用。

上线前自查清单

最后一节给一份可以直接拿去用的清单。每一条都要能验证，验证不了的就当成没过。清单不用长，关键是每条都对应一个能被检查的动作。

• 两份文档的名称、版本、生效时间在页面上都能找到，并且能互相跳转。
• 政策里每条收集目的，都能在协议或产品功能里找到对应的业务动作。
• 注销、删除、导出、撤回同意这四条路径都真实可用，不是只写在文档里。
• 与第三方共享的类型和目的已列出，并且和实际的 SDK 清单核对过。
• 隐私相关的变更通知方式写清楚了，产品里也真有对应的推送或弹窗能力。
• 功能清单和权限清单逐条对照过政策，没有「产品有、政策没写」的漏项。