Google Play Data safety 表单完整指南

Data safety 表单是你上传到 Google Play 的每个应用都必须填写的问卷;你需要在其中申报应用收集了哪些数据类型、出于什么目的,以及是否与第三方共享这些数据。在 Play Console 中,选中你的应用后可在 Policy > App content > Data safety 找到它。

该表单会填充用户在你商店页面上看到的"Data safety"部分;你申报的每一项都会成为潜在用户安装前看到的列表的一部分。该表单并不能替代另行要求的隐私政策 URL——两者都必须完成。

不完成该表单就无法进入正式发布(production);留空或从未打开过的 Data safety 部分会在发布流程中显示为阻断性警告。

表单从两个独立的维度提问:数据收集与数据共享。根据 Google 的官方定义,收集是指数据被你的应用或其使用的 SDK 传输到用户设备之外;仅在设备上处理、从未发送到任何地方的数据(瞬时的、设备端处理)不算作收集,也无需申报。共享则是指将已收集的用户数据传输给第三方(如广告网络、分析服务商)——无论数据最初收集的目的是什么,只要传输给第三方就算作共享。两者并不相同,表单会让你分别勾选。

例如,某广告 SDK 获取广告标识符(Advertising ID)用于广告个性化并将其发送到自己的服务器,这同时算作收集与共享:SDK 将数据传输到设备之外(收集),而该数据会在广告网络自己的服务器上被处理(共享)。相比之下,仅发送到你自己后端(由你直接运营的服务器,而非第三方)的数据,算作收集但不算共享,因为并未涉及第三方。而完全不离开设备的数据——仅保存在本地存储中,比如应用在本地记住的主题或语言偏好——则根本不算收集;根据 Google 的官方定义,这类数据完全不需要在表单中申报。

对于每种数据类型,表单还会询问用途(应用功能、分析、广告/营销、防欺诈、个性化等)、是否为可选项,以及传输过程中是否加密。这些字段与你 SDK 实际行为不匹配,是被标记为不一致最常见的原因。

如果你使用 AdMob,必须申报广告标识符(Advertising ID)被收集并用于广告个性化;AdMob 还可能出于广告投放和防欺诈目的处理大致位置及设备/应用信息。这是 AdMob 自身发布者政策对开发者的要求——遗漏它会在 Play 审核和 AdMob 后台两方面都造成问题。

如果你使用 Firebase Analytics,需要勾选应用交互和使用数据被用于分析目的的收集。如果你使用 Firebase Crashlytics,需要另外申报崩溃日志、设备标识符和诊断数据被收集——把 Crashlytics 和 Analytics 合并写在同一行可能被视为漏报,因为它们是各自独立的 SDK,理应在表单中占据独立的行。

如果你的应用独立于任何 SDK 自行收集数据——登录邮箱或电话、支付信息、位置权限——也应单独申报这些内容。每个 SDK 自身文档中关于 data-safety/隐私披露的部分,是填写表单时最可靠的参考;这些内容可能随 SDK 版本变化。

你的 Data safety 申报与隐私政策文本必须彼此一致。在表单中勾选"收集了广告标识符",而你的政策却从未提及 AdMob——或反之——可能在审核中被标记为不一致,最坏情况下会启动导致应用被暂停的流程。

实用的做法是:先列出你使用的每个 SDK 以及各自收集的内容,然后把这份清单以相同的细节程度分别写入 Data safety 表单和隐私政策。每当你为应用新增一个 SDK 或权限时,在同一个发布版本中同步更新这两份文档,能极大降低日后出现不一致的风险。

最常见的问题是漏报:应用通过某个 SDK 收集了数据,但表单从未体现这一点。这通常发生在集成 SDK 后表单未被更新的情况下,并可能在 Play 的自动或人工审核中被判定为不一致。

第二种情况是隐私政策 URL 为空、无法访问,或其中文字与表单申报内容相矛盾;这种不匹配是一个独立的拒绝原因,可以脱离 Data safety 表单本身单独被标记出来。

第三种是内容变更后未重新检查表单:新增一个 SDK、一个新权限(比如位置权限)或一个新的第三方集成而未更新表单,会使现有申报与应用的真实行为脱节。Google 会定期就此重新评估各版本。