Google Play 要求的账号删除 URL
Play Console 在 App content → Data deletion 下要求公开网页 URL。该页面须让用户免登录完成什么,以及导致提交被退回的错误。
Google Play 要求有账号的 App 提供两条删除途径:一条在 App 内,另一条是一个公开的网页 URL,用户无需登录或重新安装即可在那里提出同样的请求。你在 App content → Data deletion 下声明这个网页 URL。页面负责收集请求;在你自己的系统中删除数据仍然是你的责任。
几分钟就能搞定
AppFoyer 托管本指南所讲的页面——隐私政策、服务条款、支持、账号删除和 app-ads.txt——放在它们自己的子域名上,你无需自己的域名或服务器。一个应用免费,而且商店要求的任何内容都绝不放在付费墙后面。
核查于 2026年9月19日。 商店政策会变,有时不会事先通知。下文所有内容都链接到官方文档,以那个页面为准,而不是本页。如果两者不一致,以商店为准。 本指南译自英文;引用的商店文档保留英文原文。
如果你的 App 允许用户创建账号,Google Play 会要求提供两条删除账号的途径:一条在 App 内,另一条是一个可公开访问的网页 URL,用户可以在那里提出同样的请求。 你在 Play Console 的 App content → Data deletion(应用内容 → 数据删除)下声明这个网页 URL,Google Play 帮助中写道,它 “must be functional (for example, loads without error), relevant in scope”(译文:必须可以正常使用(例如加载时不出错),且范围相关)。已经卸载 App 的人也必须能够使用它。
这就是一段话概括的要求。本页其余部分讲的是这个页面本身必须做到什么,以及会导致提交被退回的错误。
这里要求的是两件事,而且很容易混淆:
- 一个公开页面,可以在上面提交请求。
- 请求到达时,在你自己的系统中实际删除数据。
第一件是托管问题。第二件只能由你来做,任何服务都无法替你完成——说可以的人,并没有访问你的数据库的权限。
这个页面必须让用户能做什么
这项要求是从用户的角度写的,所以也要从用户的角度去读。一个已经卸载了你的 App、忘记了密码或者根本没有设置过密码的人,仍然应该能够访问这个页面,并请你删除他的账号。
这就排除了一些常见的做法:
- 需要登录才能访问的页面。 如果用户必须登录才能申请删除,那么最可能需要它的人反而用不了。
- 只有 App 内的入口。 App 内的途径也是必需的,但它不能代替网页 URL:网页 URL 可以从商店页面访问,供已经没有这个 App 的人使用。
- 返回 404 的 URL。 这是真正会被发现的问题,因为检查起来轻而易举。
页面应当说明会删除哪些数据、保留哪些数据以及保留多久(账单记录通常必须依法保留),以及删除需要多长时间。
人们常犯错的部分:接收请求
一个显示表单的页面本身是不够的——请求必须真正到达你这里。
这正是单纯的文件托管自身做不到的部分。GitHub Pages、放在 CDN 后面的存储桶:它们提供文件,却无法接收 POST 请求。开发者实际会选择的大多数托管服务确实能解决这个问题——Cloudflare Workers、Netlify 和 Vercel 的函数、Netlify Forms——所以这是一项接线工作,而不是一堵墙。但总得有东西来接收请求,而常见的自建方案最终会落到以下四种之一:
- 页面上印着一个电子邮件地址,没有任何措施防止它被抓取;
- 第三方表单服务,它从此能看到你的用户的电子邮件地址;
- 你的托管服务上的边缘函数,只有几行代码,但从此每个 App 都有一份你要维护的代码;
- 一台你必须一直运行的小服务器,可能一年只为两个请求。
无论选择哪种,都要有意识地做决定。一个悄悄丢弃请求的删除页面比没有页面更糟:你在告诉用户他的请求已经收到。
保留记录
无论你搭建的是什么,都要保留请求日志:地址、日期、你做了什么处理。如果监管机构或商店问起,“我们删了”只是一个说法,而一份带日期的清单才是证据。
AppFoyer 在这里做什么
我们托管这个页面并转达请求。用户提交请求,我们把它保存为你的审计记录,并通知你——任何套餐都可以通过电子邮件通知,付费套餐还可以通过 Telegram 或 Slack 通知。删除操作由你在自己的系统中完成——我们无法访问你的系统,也从不声称可以。
即使你停止付费,这个页面也会保持在线,因为你的用户与此无关。
权威来源
- 提供有关数据删除的信息 — Google Play 帮助中心。提交前请阅读此页;起决定作用的是它,而不是本页。