隐私政策模板小程序

安全与风控

给小程序开发者的隐私政策模板生成思路:必备条款、权限声明口径、上架被驳回时的自查顺序,附条款清单与常见坑。

小程序提审被打回,十有八九是隐私政策写得不到位:该写的没写、该声明的权限没声明、用户信息收集范围和实际代码对不上。这篇不给你一份抄了就能过的万能文本,而是把条款骨架、权限声明与代码的对应关系、以及被驳回后按什么顺序排查讲清楚,让你自己拼出一份站得住的模板。

小程序提审被打回,十有八九是隐私政策写得不到位:该写的没写、该声明的权限没声明、用户信息收集范围和实际代码对不上。这篇不给你一份抄了就能过的万能文本,而是把条款骨架、权限声明与代码的对应关系、以及被驳回后按什么顺序排查讲清楚。

先摆正一个预期:没有任何一份模板能保证过审,因为审核看的是你的政策和你这个小程序实际收集了什么、收集来干什么,两件事对不对得上。所以下面所有内容都当成「骨架+自查方法」,不是填空即用的成品。

必备条款骨架:这八块缺一块都容易被挑

很多开发者写政策是从别处复制一段,改改公司名就交上去。问题在于结构残缺:用户看完不知道谁在收集、收什么、什么时候收、怎么撤回。下面这几块建议先列成清单,逐块确认存在再往外发。

  • 主体与联系方式:谁在收集、怎么联系到人,主体名要和备案、账号主体一致,别写简称或产品名
  • 收集清单逐项对齐:哪类信息、什么目的、什么场景触发、存多久、给不给第三方,写成表格比写成段落更容易自查
  • 用户权利入口:查询、更正、删除、撤回同意、注销账号,每一项都要说清在小程序内哪个位置能操作
  • 未成年人条款:面向儿童的功能要单独说明监护同意方式,别只用一句「未成年人请在监护人陪同下使用」糊过去
  • 第三方 SDK 与共享清单:接了哪个服务、拿走了什么字段、对方的隐私政策在哪看,缺这块被打回的概率很高
  • 数据存储地与跨境:服务器放在哪、有没有出境、出境时依据什么,写一句总比不写好
  • 政策更新与生效方式:改了怎么通知、旧版本怎么处理、生效时间怎么定
  • 权限用途说明:每个敏感权限单独说用途和关闭后的影响,不要和总政策混成一坨

清单里的第三方共享部分,建议直接做成表格,一列写 SDK 或服务名,一列写收集字段,一列写用途,一列写关闭方式。审核方和你自己后续维护都省事。

条款块写不全会怎样自查方式
主体信息无法确认责任方,直接驳回核对备案主体与账号主体名称
收集清单被判超范围收集逐字段对照代码里的埋点与服务端落库
权利入口用户无法行使删除与注销在未登录状态下走一遍入口路径
第三方共享SDK 上报行为无告知按 SDK 初始化位置逐个列清单

权限声明和代码要对得上:多写少写都是问题

这一节的核心动作只有一个:拿代码事实反查文本,而不是拿文本去凑代码。先把工程里所有权限申请、第三方 SDK、埋点字段拉一遍,形成一份「实际发生的事」清单,再逐条对到政策里的表述。

  1. 导出事实清单把权限申请、SDK 初始化、埋点字段三处代码过一遍,列成一张表,标注触发场景。验证方式:随便挑一个字段,能不能说清它在哪个页面被采集。
  2. 反向比对政策文本拿事实清单去政策里找对应描述。找不到就是漏声明;政策里写了但清单里没有,就是多写,属于超范围收集的嫌疑。
  3. 敏感权限单独处理位置、相机、相册、通讯录这类,要在使用前单独弹窗、单独说明用途,不能只靠一份总政策兜底。
  4. 确认撤回路径用户关掉权限后功能降级到什么程度,政策里要有一句对应描述,同时代码里要有不崩溃的兜底逻辑。

用工具生成模板的步骤:先喂对信息再谈生成

用大模型写隐私政策初稿是省时间的,但前提是你喂进去的是业务事实,不是「帮我写一份小程序隐私政策」这种空话。输入越模糊,输出越是通顺的套话,改起来比自己写还费劲。

  • 第一步列业务事实:产品形态、用户角色、收集字段、第三方服务、服务器所在地,事实不清生成出来的都是套话
  • 第二步用需求文档或字段表做输入,让模型输出条款初稿,再人工逐条对照代码确认,别直接粘贴上线
  • 第三步按平台侧的填写要求拆分:政策正文、权限用途说明、第三方共享清单往往是分开填的,位置不一样
  • 第四步统一术语:同一个字段在政策、权限说明、弹窗里叫法要一致,叫法不一致审核容易当成两件事
  • 第五步留版本记录:改了什么、什么时候改的、怎么通知用户,自己留一份,出问题好回溯

生成出来的内容一律当草稿。模型写得通顺不等于写得对,尤其涉及合规口径、免责表述、跨境依据这些地方,必须人工复核。拿不准的表述,宁可写得更具体、更保守,也不要留模糊空间。

提审被驳回后的排查顺序

被驳回时最常见的错误是「哪里都改一点」,结果下次还是被同一个问题打回。正确做法是先判断驳回属于哪一类,因为三类的改法完全不同,顺序错了就是白费功夫。

驳回类型典型表现优先动作
政策缺失提示未提供隐私政策或入口不可见先补入口,再补正文
权限声明不符提示权限用途与申请不一致回到代码逐条比对权限
入口不可达链接打不开、白屏、登录后可见先验证未登录状态下的可达性
文本措辞提示表述不清或存在歧义放最后改,前面几层先过
  1. 读驳回原文先确认它指向的是政策缺失、权限不符还是入口不可达,三类不要混着改。
  2. 查可达性未登录状态能不能打开、断网会不会白屏、地址是不是稳定不变,这三条逐条试。
  3. 比对权限与字段重点看有没有新增的第三方 SDK 没同步进清单,新增依赖最容易漏。
  4. 最后改措辞前面几层都过了再动文字,措辞问题通常是最后一层。

如果你的小程序还涉及服务器部署与访问速度,提审和用户体验之间是有取舍的:链路不稳会影响政策页加载,进而被判入口不可达。这类基础设施层面的判断标准,可以到 /tools/speed-test 看当时的检测结果,别用感觉代替实测。

另外,不同平台对政策正文、权限说明、共享清单的填写位置和字段要求经常调整,具体要填哪些、格式怎么要求,以你提交时后台的提示为准,别照搬别人的旧截图。

下一步先把你的权限与字段事实清单拉出来,再对照模板逐条补齐;同时到站内的价格与模型资料核对第三方服务的现状,避免政策里写的共享范围和实际接入的服务对不上。

常见问题

网上抄一份隐私政策模板直接用行不行?

风险在于模板里的收集字段和第三方清单跟你的实际代码对不上。政策和代码不一致,比没有政策更容易在提审或事后核查时被认定为超范围收集。可以用模板做骨架,但收集项、权限、第三方 SDK 这几块必须按自己的工程实际情况逐条替换。

小程序没有登录功能,还需要隐私政策吗?

要。只要涉及任何用户信息处理,哪怕只是设备标识、位置或相册权限,都需要有对应的告知。没有账号体系可以减少「账号注销」那类条款的写法,但不等于可以不写。以平台侧当前的填写要求为准。

政策写好了,多久要更新一次?

新增权限、接入新第三方 SDK、增加新的收集字段、更换服务器所在地,这几类变动发生时都要同步更新,并在政策里体现更新日期和生效方式。没有变动就不用为了更新而更新,频繁改版本号反而会让用户以为你在动数据用途。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。