Google Play data safety表单：填错更糟

在 Play Console 里，data safety 表单是那种人人都过过手、没人愿意多看一眼的页面：新应用上架或者发新版本，它拦在流程中间，声明做完才放行。于是常见的处理方式是「尽快点完，别挡发版」——一路往下选，能选否的都选否。

麻烦不会当场出现。它会在几个月后回来，形式可能是政策邮件、更新被拦，也可能是商店页上那行隐私摘要被用户截图发到社交平台。到那时候再回头翻当初的选项，很多团队已经说不清是谁填的、按什么依据填的。

先说结论

这张表单的代价结构很特别：填得慢，损失是几天工期；填得错，损失是一份写进公开页面的错误承诺。

你的声明会被整理成用户可见的摘要，挂在商店页的数据安全区域。它和实际行为一旦对不上，问题的性质就变了——不是「表单没填好」，而是「页面在误导用户」。平台对声明与行为不一致有自己的处理路径，从提醒、限制更新到下架都存在，具体以官方最新说明为准。

所以我的建议一直是同一句：宁可填得保守而准确，也不要为了让页面好看选否。准确是底线，不是加分项。

data safety 表单到底在问什么

把表单拆开，其实就两组问题。

第一组关于收集：应用是否从设备收集用户数据；如果收，收哪些类型——位置、联系人、照片、诊断日志、广告标识符，类别不少。第二组关于去向：这些数据会不会传到你的公司之外。

每个勾选的类型后面还跟着附加问题：收集是使用应用所必需，还是可选；是否只在设备内存里临时处理；传输过程是否加密；用户能不能主动要求删除自己的数据。

答完之后，答案会被生成一份摘要，展示在商店页上。换句话说，你不是在填内部表格，而是在写一段公开示人的话。表单的问题项和展示方式会随政策迭代调整，动手前以 Play Console 里的当前版本为准。

「收集」和「共享」是两个定义，不是同义词

最容易出错的是这两个词。收集，指数据从设备发出、传到你的公司或你委托的一方；共享，指数据再从那里流向第三方。你的应用自己一行数据代码都不写，只要接了广告或者统计 SDK，这两问的答案大概率都不是否。

还有一个被滥用的概念是「临时处理」。它本意是指数据只在内存里短暂停留、不留存也不转发，适用条件很严格。把它当万能挡箭牌，凡是拿不准的都往里塞，等于把整张表的准确性都押了上去。

判断口径别靠猜：每个 SDK 的文档里都有数据行为说明，按文档填，不按印象填。

再补一个容易被轻视的判断：「必需还是可选」。它问的是用户能不能在不交出这类数据的前提下正常使用核心功能。很多团队把「我们不拿它做坏事」当成「必需」，这是两回事。用户关掉广告个性化，应用照样能用，那广告标识符相关的那部分就不算必需。这一项填错，用户在系统层面关闭授权时的体验对不上，又是一个新的错配。

第三方 SDK 是最常见的翻车点

我见过的错配多数长一个样：团队自己的代码很干净，不碰用户数据，于是声明「不收集」。但构建里躺着统计 SDK、崩溃收集 SDK、广告 SDK——它们各自都在往回传数据。

这类错配的讨厌之处在于它有潜伏期。接入时看了一眼文档，表单照当时的行为填了；之后 SDK 升级，行为变了，表单不会自己跟着变。发版是手动的，声明却停在了旧版本。

所以核对的对象不是「我们写了什么代码」，而是「这个包里所有组件在做什么」。把依赖清单拉出来，一个一个查过去，比任何经验判断都可靠。

查的时候有个省力的办法：正规 SDK 厂商都会在文档里写清自己的数据行为，有的还专门提供面向开发者填报的说明页，把「收集哪些类型、是否共享、是否加密」逐项列好。找到这类页面，照着抄进表单就行。反过来，一个 SDK 连自己的数据行为都说不清楚，这本身就是换掉它的理由——你总不能在公开声明里写「不确定」。

另外别漏掉那些「看起来不像 SDK 的 SDK」：推送、深链归因、性能监控、热修复，甚至某些 UI 组件库，都可能内置上报行为。名单要按构建依赖拉，不能凭功能印象列。

填错 data safety 表单为什么比不填更糟

有人会想：反正大家都乱填，平台哪查得过来。这个判断有两个漏洞。

第一，隐私摘要是公开的。它不只是合规文件，还是用户决定装不装的依据之一。一旦被截图对比出「声明不收集、实际在收集」，伤害的是品牌本身，这个成本不需要平台动手就已经在付了。

第二，对平台来说，一份与行为不符的声明本身就是证据。空着不填，最多是流程没完成；填了错的，是白纸黑字把误述放进了系统。平台对这两种情形的处理不会一样，具体以官方政策为准。

我们自己做商店页，对这件事的立场很简单：声明是资产，错配是负债，负债会复利。

还有一层成本很少被算进去：错误的声明会传染给整个团队的工作习惯。商店页文案、官网隐私政策、应用内的权限说明、给投资者的材料——这些地方一旦各自为政，互相矛盾，任何一处被拿出来对照，其他几处都成了佐证。数据口径是一个团队最该统一的东西之一，而这张表单恰好是逼你统一的那个契机。

别把上一款 App 的答案抄过来

手里有几个应用时，很自然拿旧应用的表单当模板。我理解这种省事，但答案跟着应用走，不跟着团队走。

不同应用的 SDK 组合不同、账号体系不同、目标市场不同，上一款里「不收集用户数据」的选项，到这一款可能就是错的。还有一种更隐蔽的：同一个应用，中途接入了新的支付或推送服务商，表单没人回头改。

如果非要复用，就复用流程，别复用答案——把盘点这一步重做一遍，代价最小。

顺带对照：App Store 的隐私标签

做双端的人常问：两边能不能填成一样的。答案是不能照搬。Apple 在 App Store Connect 里有一套自己的隐私标签，问题项、分类口径和展示方式跟 Google Play 这边不完全一致，各自填各自的。

但盘点是一次性的活。把「我们有哪些 SDK、各自什么数据行为」这个问题回答清楚之后，两边填的都是同一份事实，只是格式不同。这也是为什么我建议把数据盘点做成独立于任何表单的内部文档——表单会换，事实不会。

什么情况下别在这上面过度投入

反过来也得说：不是每个团队都需要为此立项。

如果你的应用完全离线、没有账号体系、构建里没有第三方 SDK，表单如实填完很快，不需要任何人的帮助，也别被吓去买了不需要的服务。

判断标准就一条：你能不能一句话说清自己的应用把什么数据发给了谁。说得清，自己填；说不清，先补数据盘点这一课，再谈填表。问题从来不在表单，在盘点。

一套能落地的填写流程

实际操作里我们习惯按这个顺序走。

先列依赖清单，把构建里所有第三方 SDK 找全，包括传递依赖。再逐个查官方文档，记录每个 SDK 收什么、发到哪里、是否加密、能否删除。然后把口径在团队内对齐，特别是「必需还是可选」这类需要产品判断的项。填表时逐项对应文档，别凭记忆。填完留档：把当时的答案导出或截图，跟依赖清单的版本放在一起。最后给发版流程加一道检查：依赖变了，表单跟着过一遍。

这套流程不快，但它把「填错」从概率问题变成了流程问题。

可以先做这几件事

1. 打开 Play Console，把现有应用的 data safety 声明导出或截图存档，先知道自己现在承诺了什么。 2. 拉一份完整的第三方依赖清单，逐个核对 SDK 文档里的数据行为说明。 3. 对照商店页上用户可见的隐私摘要，检查它和实际行为有没有明显出入。 4. 把「依赖变更要触发表单复查」写进发版流程，避免声明停在旧版本。

如果你在海外双商店的合规与元数据上拿不准，站内有咨询组件，可以把现状发给我们看看。柚鸥做这件事的出发点从来不是替你填表，而是让你在签任何声明之前，先弄清自己的应用到底在做什么。