隐私政策模板教程

做产品走到要挂隐私政策这一步，常见的卡点是：不知道总共该分几块、每一块该写到什么颗粒度、抄来的模板里那些「我们可能收集……」的模糊句子到底算不算数。这篇不给你一份模板文档，而是给你一个可复用的结构骨架和逐条表述要点，你照着往里填自己的业务事实就行。适用范围是自建网站、App、小程序和工具类产品；如果你只是给单个页面做说明、或者业务根本不接触个人信息，下面很多条目可以跳过。

做产品走到要挂隐私政策这一步，常见的卡点不是「不会写」，而是不知道总共该分几块、每块写到什么颗粒度。抄来的模板里那些「我们可能收集相关信息用于改善服务」的句子看着稳妥，真出事时几乎等于没写。

这篇不给模板文档，给一套能复用的结构骨架和逐条表述要点，你照着往里填自己的业务事实就行。适用对象是自建网站、App、小程序和工具类产品；如果你只是给单个页面加一句说明，或者业务根本不接触个人信息，下面很多条目可以跳过。

先定死三件事：谁负责、管哪些产品、管谁

开篇第一段别铺垫，直接写清运营主体名称和联系方式。产品形态要分别列出网站、App、小程序，不能只写一个统一名字——同一家公司不同端的技术实现和收集行为往往不一样，写成一个名字，日后核对就会对不上。

• 运营主体名称与有效联系方式，写在同一段，别让用户翻三屏才找到
• 覆盖的产品形态逐个列，网站、App、小程序各占一行
• 适用人群与地域范围，涉及未成年人或境外用户时单独点出来并说明会额外处理
• 留一句「本政策不覆盖什么」，比如第三方链接、合作方页面由对方负责
• 生效日期与更新方式写在相邻位置，别散落在全文各处

把「收集什么、怎么收、用来干什么」写成一张对照表

这一节是整份政策里最容易被追问的部分。建议直接用表格落地，四列缺一不可：业务功能、收集的信息项、收集方式、使用目的。表格比大段文字好核对，也方便开发逐项确认技术实现。

自动收集类最容易漏，按你实际的埋点清单逐条核，不确定的项目宁可删掉，也别写「可能收集」。每一项都要对应一个具体目的，写不出目的的信息项，说明它本身就不该收。

• 明确哪些是「不提供就无法使用」，哪些是「不提供只影响某个功能」
• 同一信息项被多个功能共用时，在使用目的里分别说明，不要合并成一句笼统描述
• 第三方 SDK 收集的信息要单独标注来源，别混进自有收集里

共享、委托处理、存储与出境，分开写别揉在一起

共享、转让、公开披露是三种不同动作，分三小段写，每段说清触发条件和你对接收方的约束方式。接收方清单如果变化频繁，不要在正文里写死名单，用可维护的指向方式，让大家去站内合规相关页面看当时的版本。

共享

为完成某项功能主动提供给合作方，需说明约束方式

委托处理

对方只按你的指令处理，责任主体仍在你这边

存储期限

写清按什么规则判断保留多久，以及到期怎么处理

数据出境

写清走的哪条合规路径，路径本身到站内对应页面核对

用户权利部分最忌只写「您有权……」。要给可执行动作：怎么查、怎么改、怎么删、怎么撤回同意、多久回应。没有时限和入口的权利条款，在争议里基本站不住。

表述要点：哪些句子能写，哪些句子是坑

能写具体就写具体。「收集手机号用于登录验证」比「收集必要信息用于提供服务」有用得多。后者读起来安全，真被追问时你没法解释「必要」到底指什么，用户也没法判断该不该同意。

安全措施部分写机制类别而不是技术品牌。全文术语要统一，别一会儿「个人信息」、一会儿「用户数据」、一会儿「隐私信息」，术语不一致最容易被挑，也最容易让用户误解范围。

• 不写无限授权式句子，扩展用途必须重新走同意
• 不把「可能」「必要时」当作兜底词，能删就删
• 安全措施写可验证的机制类别，不写具体产品品牌
• 全文统一一套术语，改动时全文替换

上线前的核对顺序

1. 第一步：对事实拿这份政策和实际收集行为逐项比对，多写的删掉，少写的补上。这一步比润色重要得多，文本再漂亮，和实际行为不一致就是隐患。
2. 第二步：对入口确认政策链接能从注册、下单、权限申请等关键位置一到两次点击到达。链接失效、跳转空白、只在页脚最底部放一个灰字，都等于没挂。
3. 第三步：对版本留一份历史版本和更新记录，每次改动留痕。出了问题能说明「当时生效的是哪一版」，而不是事后靠回忆。
4. 第四步：对协作产品、法务、开发三方各签一遍：开发确认技术实现与文本一致，法务确认表述，产品确认业务描述。三方签字比任何一次评审会都管用。

涉及的合规路径、接收方清单这类会变动的信息，不要在正文里写死，指向站内可维护的页面，让用户和内部同事都能看到当时的版本。