隐私政策模板制作

很多独立站和店铺的隐私政策，要么直接从别处抄一份，要么拖到平台审核卡住才临时补。抄来的模板往往和你的实际收集行为对不上：装了统计脚本没写、用了海外仓没写、接客服工具把手机号传出去也没写。这篇按「先盘点、再套模板、后核对」的顺序给一份可照着做的流程，并说明哪些情况下模板得推倒重写。

很多独立站和店铺的隐私政策，要么直接从别处抄一份，要么拖到平台审核卡住才临时补。抄来的模板往往和你的实际收集行为对不上：装了统计脚本没写、用了海外仓没写、接客服工具把手机号传出去也没写。这几种情况一旦被用户问到或者平台抽查，解释成本都很高。

这篇按「先盘点、再套模板、后核对」的顺序给一份可照着做的流程，并说明哪些情况下模板得推倒重写。整篇不涉及具体数字，凡是涉及价格、排名、版本的，都可以到站内对应页面核对当时的数字。

动手写模板前：把自己收集了什么先盘清楚

隐私政策的本质是一份「告知」，告知的内容必须等于你实际在做的行为。所以第一步不是打开模板，而是拿张表把现状列出来。盘不清楚就动手写的，最后基本都要返工。这一步建议两个人在场：一个懂业务，一个懂技术，各自说一遍数据从哪来到哪去。

• 列三张清单：收集到的字段（姓名、手机号、收货地址、支付信息）、收集途径（下单页、客服聊天、埋点脚本、第三方插件）、对外流向（物流、支付、短信、分析工具）
• 把每类数据的用途写成一句能对得上业务的话，用途写不出来的字段，先考虑是不是可以不要
• 区分「必须收集才能下单」和「可选收集」，这决定后面同意条款怎么写
• 盘不清楚就先别套模板，抄来的条目会跟你的实际行为冲突，审核和投诉都从这里出

模板怎么挑：按业务形态选骨架，不按好看选

模板不是越全越好，而是要和你最重的那块业务对得上。一个纯展示站套交易型骨架，会写进去大量你根本没做的行为；反过来一个天天发货的店用展示型骨架，物流和第三方共享这块必然缺项。先想清楚自己属于哪一类，再去找对应的骨架。

纯展示型骨架

只收邮箱或留言信息，重点在 Cookie 与联系方式

下单交易型骨架

涉及支付、物流、售后，重点在第三方共享与留存期限

会员营销型骨架

涉及画像、推送、自动化营销，重点在同意机制与退订路径

• 一份能用的骨架至少覆盖：收集范围与用途、Cookie 与同类技术、第三方共享、用户权利与行使方式、数据留存期限、联系方式
• 遇到免费模板时先看它的更新时间与适用法域，跨法域直接拿来用往往缺项
• 站内可以先把通用条目对照一遍，隐私政策包括哪些内容这类清单类文章就是干这个的，重点别漏 Cookie、未成年人、跨境传输这几块
• 选定骨架后先别逐字改，先拿它跟你第一步的三张清单对一遍，缺的补、多的删，再动文字

如果你同时经营多个渠道，比如一个独立站加几个平台店铺，不要指望一份模板覆盖全部。先按渠道把数据处理动作列出来，再决定是拆成几份还是共用一份加差异说明。涉及具体平台规则的，到站内规则整理页核对当时的条款。

改模板的四个动作：替换、删除、补写、标注

改模板最容易犯的错是只做「替换」这一个动作，把公司名和网址换掉就发出去。真正要花时间的是删除和补写：模板里写了你没做的要删掉，模板里没写你做了的要补上。删掉比留着更安全，因为写了不做的条目一旦被用户拿出来对照，很难解释。

1. 替换把公司主体、联系方式、数据接收方全部换成真实信息。验证方式：全文搜一遍「XX」「示例」「placeholder」这类占位词，一个都不该剩。
2. 删除模板里写了但你没做的整条删掉，比如人脸识别、精确位置、第三方广告联盟。验证方式：每条保留的条目都要能对应到第一步清单里的一行。
3. 补写模板里没写但你在做的补上，重点是埋点、客服系统、海外仓与物流面单。验证方式：把第一步清单反过来逐行对照，看有没有哪行在政策里找不到落点。
4. 标注留存期限和删除触发条件写具体；写不清就先写「按业务必要期限留存，到期删除」，同时内部留一份台账说明具体是多久。

改完的稿子不要一个人看完就发。让实际接触客服或订单的同事读一遍，他们最容易发现「这条跟我们实际做法不一样」的地方。读的时候不看措辞，只看事实是否对得上。

上线前后的核对：页面放在哪、改完怎么验证

政策写得再全，用户点不到也白搭。上线前先把访问路径确认清楚，再做一轮行为核对。平台审核通常就看几个固定位置能不能点到政策链接，这几处没做，内容写得再规范也会卡。

• 把政策做成独立可访问的页面，链接放到底部导航、注册页和结算页，平台审核一般就看这几处能不能点到
• 核对顺序：先自己走一遍下单流程看有没有漏告知的步骤，再找你实际用到的第三方工具逐个确认数据流向
• 改版要留版本记录：改了什么、什么时候生效、老用户是否需要重新确认，都要能查得到
• 政策不是一次性文件，新增插件、换物流商、开通跨境结算都属于要回头改的触发点

什么情况下套模板不管用

模板解决的是「通用场景下不缺项」，但它解决不了敏感数据、多法域和争议处理这三类问题。碰到下面这些情况，不要指望改模板能糊过去，得先处理更上游的事情。

• 涉及未成年人数据、医疗或金融类敏感信息时，通用模板不够用，需要按行业口径单独补章节
• 已经发生投诉或监管问询的，先处理具体争议点，再谈改模板，顺序反了没用
• 多法域同时经营（比如同时面对国内与欧盟用户）时，一份模板打天下通常站不住，要按受众拆版本
• 用户权利响应流程没建立起来的话，政策写得再全也只是纸面，先确定谁来接请求、多久回

还有一种常见情况：业务本身还在快速试错，今天加一个插件明天换一个物流商。这种阶段不必追求一次写到位，但每次改动都要同步到政策里，并且留下改动记录。宁可版本多，也不要出现「政策写的和实际做的对不上」。判断标准很简单：随便挑一个你在用的第三方工具，如果政策里找不到对应说明，就说明这版还没到能上线的程度。