隐私政策与产品行为：十二个域名、九个披露与三个漏项

政策不是写给人看的门面，它是产品数据流的书面投影。

一、审核退回的那封邮件

陈默的发票工具「零票」在应用市场上架时被退回，理由只有一句：隐私政策的共享与披露一节写着「我们不会向第三方共享你的个人数据」，但审核方抓包看到三个未知域名，分别对应分析、模型与错误监控。邮件里附了几张截图，域名、请求时间与参数都标了出来。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他第一反应是「政策没写错」。翻出政策最后一次修改记录，是一年多以前；再翻发布日志，分析 SDK 是几个月前接入的，模型接口更晚上线，错误监控是最近才换的供应商。这几次产品变更，没有一次同步到政策。

更讽刺的是，这一节的原意是「不出售数据」。写的时候确实没有出售，也没有共享；但这一年多里「共享」的定义被产品悄悄扩大了：把事件发给分析服务、把文本发给模型、把异常堆栈发给监控，在他心里都不算「共享」，在审核方眼里全是。

他去问当初接分析 SDK 的自己，得到的回答是「只发事件，不带个人信息」。这句话在代码层面也许成立，在政策层面却不成立：设备信息、页面路径与会话标识合在一起，足以识别到具体账号。判断共享的标准不是「发了什么字段」，而是「对方能不能据此认出一个人」。

政策没写错，是产品先变了。 这句话不是自我安慰，而是问题的准确定位。政策滞后于产品，靠改几句话补不上；需要一条固定动作，让每次产品变更都触发政策复核。

域名清单是政策的底稿。 政策里的每一句「我们使用某某服务」，都应当能对应到抓包里的一个域名。对不上，要么政策漏了，要么产品多收了，两种都要改。

审核退回是结果，不是原因。 审核方只花几分钟就找到了三个域名，说明问题不是隐藏得很深，而是从来没人把「政策写的」和「产品做的」并排看过。

披露要写到处理活动，不只是公司名。 写「我们使用第三方服务商」等于没写；要写清哪类数据、为什么目的、发给谁、存在哪个区域，才有核对价值。

二、十二等于五加七

把抓包结果按主机名去重，一共十二个域名。五个是自有：app 承载页面，api 承载接口，cdn 承载静态资源，docs 承载文档，status 承载状态页。七个是外部服务，分别对应支付、邮件、对象存储、模型、分析、搜索与鉴权。

自有域名不等于没有隐私问题。app 与 api 会记录登录、项目与文件操作，cdn 日志里可能有 IP 与 UA，docs 的搜索框会把关键词发到后端，status 页面在订阅通知时收集邮箱。自有域名之所以容易被忽略，是因为它们看起来「在自己家里」，但收集行为一样发生。

外部域名的问题更直接：每一个都意味着一份数据处理协议、一次跨境判断、一条政策披露。七个外部服务里，支付与邮件在政策里写得最清楚，因为当初接入时就被提醒过；对象存储与搜索写在「数据存储」一节里，勉强能对上；分析与模型是后来加的，错误监控是最后加的，三个都没进政策。

自有与外部还有一个区别：自有域名出问题，改代码就能停；外部域名出问题，还要走合同与通知。所以外部服务的清单要单独维护，记录接入日期、数据类别、所在区域与联系人，而不是散落在各个提交记录里。

按披露项比对，政策覆盖九个，漏三个，漏项比例是 3 ÷ 12 = 25%。修复后十二个全部写进政策，漏项归零。这个比例不算高，但审核方看到的不是比例，是三个具体的域名。

三、十一节政策与十二个域名

一份能核对的政策不需要很长，但每一节都要指向一个实际数据流。零票的政策有十一节，逐节对完，才发现有些节写得很空，有些域名没有落点。

逐节对完会发现两类问题。一类是「有节无流」：比如儿童隐私一节写了很长，但产品根本没有年龄门，也没有面向未成年人的入口，这节是从模板抄来的。另一类是「有流无节」：分析、模型与错误监控三个域名在正文里找不到任何落点，只在「我们可能使用第三方服务」这种兜底句里被含糊覆盖。

兜底句是最危险的一节。它让写的人觉得「已经覆盖了」，让读的人无法核对，让审核方只能靠抓包判断。正确做法是把兜底句拆成具体条目：每个外部服务一行，写清服务类型、数据类别、处理目的与所在区域。

埋点变更必须同时改政策与同意文案。新增一个事件、换一个分析供应商、把模型调用从自建换到外部，都要走同一条变更单：改政策对应节、改同意文案、改处理者清单、通知受影响的用户。只改代码不改文本，下一次审核还会退回。

变更单不需要复杂系统，一张表就够：变更内容、涉及域名、对应政策节、是否影响同意、生效日期、复核人。这张表填完，政策与产品就不会各走各的。真正难的不是填表，而是承认「这次变更会影响用户」，而不是把它当成一次普通发版。

四、一致性检查四步

一致性检查不需要工具链，四步可以在半小时内走完，季度做一次即可。

第一步抓包列域名：打开无痕窗口，把注册、登录、核心操作、付费、导出这些路径各走一遍，记录所有请求的主机名。第二步对 SDK 清单：前端依赖、后端依赖、移动端依赖各扫一遍，把每个 SDK 对应到域名与服务类型。第三步对政策段落：拿着域名清单逐节找落点，找不到的记为漏项。第四步对同意记录：确认分析类域名只在该用户同意后出现，未同意的请求应当为零。

复算：成本与漏项放在一起看。

域名 12 = 自有 5 + 外部 7
政策披露 9；漏 12 − 9 = 3
漏项比例 3 ÷ 12 = 25%
修复后 12 − 12 = 0 个漏项
一致性检查 30 分钟 × 4 次/年 = 120 分钟 = 2 h/年
政策 11 节对应 12 个域名，12 ÷ 11 ≈ 1.09 个/节

两小时一年，看起来是一笔小开销，但它买的是「审核时不用临时翻代码」。一次审核退回，重写政策、等复审、再排期，通常以周计；两小时的季度检查，是把这笔不确定的返工换成确定的日常动作。

三个漏项里，分析最难补，因为它牵连同意记录。政策补一句「我们使用分析服务」很容易，但如果没有对应的同意，补完政策反而暴露了另一个问题：收集没有依据。补政策之前，先确认分析域名只在同意后加载。

模型与错误监控相对简单，前者补处理目的与数据类别，后者补服务类型与保留期。两者都不需要用户重新同意，因为它们的依据是合同履行或正当利益；但都要写进处理者清单，并在供应商变更时通知。

还有一个容易漏的动作：补完政策要回测一次。按新政策重新走一遍同意流程，确认分析域名只在同意后出现；再清一次浏览器缓存，确认用户看到的文案就是新政策里的表述。文本改完不等于行为改完，回测是把两者钉在一起的最后一步。

五、行动清单与复算验收

这八条按「先看见、再对上、最后联动」的顺序做，一个人一天能完成第一轮。

• 用无痕窗口把核心路径各走一遍，抓包列出全部十二个域名。
• 把七个外部服务逐一对上支付、邮件、对象存储、模型、分析、搜索与鉴权。
• 拿十一节政策逐节找落点，标出「有节无流」与「有流无节」。
• 补齐三个漏项：分析、模型与错误监控，各写清数据、目的与区域。
• 建立变更联动：新增 SDK、换供应商、加区域都触发政策与同意复核。
• 每季度花三十分钟重跑四步检查，差异写进变更记录。
• 保留每个政策版本的正文与生效日期，不要只留最新版。
• 给审核方准备一张域名与政策章节的对照截图，随提交附上。

清单的价值不在八条本身，而在它们能压缩成一句可执行的判断：抓包里的每个域名，都能在政策里找到一节，且该节写的处理活动与请求参数一致。

验收标准：任取一个抓包域名，都能在政策里指到具体一节，并说清它收了什么、为什么收、发到哪；指不到就是漏项。

使用边界与实操验收

边界一：政策不是法律文本生成器。 本文给的是「政策与产品对齐」的方法，不是可直接发布的模板。条款措辞、告知顺序与法定事项，仍需按适用法域起草或审阅。

边界二：不覆盖所有法域。 十二个域名与十一节政策是按一套基线整理的；同一产品在不同地区投放，披露项、同意方式与跨境机制都可能增加，不能一份文本全球通用。

边界三：SDK 变更可能随时发生。 前端依赖的一次小版本升级，可能新增一个默认开启的采集端点。季度检查能兜住大部分，但发版前的依赖 diff 仍然是第一道防线。

边界四：政策一致不等于合规。 域名都对得上，只能说明「写的」与「做的」一致；依据是否成立、保留期是否合理、跨境机制是否有效，是另外三条独立的检查线。

边界五：审核通过不等于正确。 审核方看的是可见的域名与文本，看不到你的字段矩阵、删除流程与内部权限。通过只是最低门槛，不是验收终点。

关键参考与核验范围

• GDPR Art 13：收集时的告知 ：用于核对政策应披露的目的、依据、接收方与保留期。
• GDPR Art 14：非直接收集的告知 ：用于核对从第三方获得数据时的告知义务。
• OWASP 隐私风险 Top 10 ：用于核对政策与实现脱节、过度收集等常见风险。
• NIST 隐私框架 ：用于核对以数据流为中心的隐私风险管理方法。
• ICO：合法性依据指南 ：用于核对披露处理目的与依据时的表述边界。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

系列导航

• 回到本组目录：一个人的隐私工程：数据地图、最小化与删除权
• 上一篇：合法性依据与同意：四类目的、三种同意与一次版本错配
• 下一篇：数据主体请求：一年十二件、三十天与一套导出脚本
• 相关：数据最小化：二十三个没人读的字段与一次删列迁移