La URL de eliminación de cuenta que pide Google Play
Play Console pide una URL web pública en App content → Data deletion. Qué debe permitir esa página sin iniciar sesión y los errores que frenan un envío.
Google Play pide a las apps con cuentas dos vías de eliminación: una dentro de la app y una URL web pública donde se pueda hacer la misma solicitud sin iniciar sesión ni reinstalar. La URL web se declara en App content → Data deletion. La página recoge la solicitud; eliminar los datos en tus propios sistemas sigue siendo cosa tuya.
Hazlo en unos minutos
AppFoyer aloja las páginas de las que trata esta guía —política de privacidad, términos, soporte, eliminación de cuenta y app-ads.txt— en su propio subdominio, sin que necesites dominio ni servidor propios. Una app es gratis, y nada de lo que exige una tienda está nunca detrás de un muro de pago.
Comprobado el 19 de septiembre de 2026. Las políticas de las tiendas cambian, a veces sin aviso. Todo lo que sigue enlaza la documentación oficial, y esa página —no esta— es la que manda. Si no coinciden, la tienda tiene razón. Esta guía está traducida del inglés; las citas de la documentación de las tiendas se mantienen en el inglés original.
Si tu app permite crear una cuenta, Google Play pide dos vías para eliminarla: una dentro de la app y una URL web de acceso público donde se pueda hacer la misma solicitud. La URL web se declara en Play Console en App content → Data deletion (Contenido de la app → Eliminación de datos), y la ayuda de Google Play indica que “must be functional (for example, loads without error), relevant in scope” (traducción: «debe funcionar —por ejemplo, cargar sin errores— y ser pertinente en su alcance»). Alguien que ya desinstaló la app tiene que poder usar esa URL.
Ese es el requisito en un párrafo. El resto de esta página trata de lo que tiene que hacer la página en sí y de los errores que hacen que te devuelvan el envío.
Aquí se piden dos cosas, y es fácil confundirlas:
- Una página pública donde se pueda enviar una solicitud.
- Eliminar de verdad los datos en tus propios sistemas cuando llega una solicitud.
La primera es un problema de alojamiento. La segunda es solo tuya, y ningún servicio puede hacerla por ti: quien diga lo contrario no tiene acceso a tu base de datos.
Qué debe permitir hacer la página al usuario
El requisito está escrito desde el lado del usuario, así que léelo desde ahí. Alguien que ha desinstalado tu app, ha olvidado su contraseña o nunca tuvo una, debe poder llegar a la página y pedirte que elimines su cuenta.
Eso descarta algunas configuraciones habituales:
- Una página detrás de un inicio de sesión. Si el usuario tiene que iniciar sesión para pedir la eliminación, quienes más probablemente la necesitan no pueden usarla.
- Solo una ruta dentro de la app. La vía dentro de la app también es obligatoria, pero no sustituye a la URL web: a esa se llega desde la ficha de la tienda, por alguien que ya no tiene la app.
- Una URL que devuelve 404. Este es el error que de verdad se detecta, porque es trivial de comprobar.
La página debe decir qué datos se eliminan, qué se conserva y durante cuánto tiempo (los registros de facturación a menudo deben conservarse por ley) y cuánto tarda la eliminación.
La parte que la gente hace mal: recibir la solicitud
Una página que muestra un formulario no basta por sí sola: la solicitud tiene que llegarte.
Esta es la única parte que un simple alojamiento de archivos no puede hacer por sí solo. GitHub Pages, un bucket detrás de una CDN: sirven archivos, no pueden aceptar un POST. La mayoría de los alojamientos que un desarrollador elegiría de verdad sí lo resuelven —Cloudflare Workers, las funciones de Netlify y Vercel, Netlify Forms—, así que es un trabajo de conexión, no un muro. Pero algo tiene que recibir la solicitud, y la vía habitual de hacerlo tú mismo acaba en uno de estos cuatro sitios:
- una dirección de email impresa en la página, sin nada que impida que la recopilen bots;
- un servicio de formularios de terceros, que ahora ve las direcciones de email de tus usuarios;
- una función edge en tu alojamiento, que son pocas líneas pero ahora es código tuyo en cada app;
- un pequeño servidor que tienes que mantener en marcha para quizá dos solicitudes al año.
Elijas lo que elijas, decídelo a propósito. Una página de eliminación que descarta solicitudes sin avisar es peor que no tener ninguna: le estás diciendo al usuario que su solicitud se recibió.
Guarda un registro
Construyas lo que construyas, guarda un registro de las solicitudes: la dirección, la fecha y qué hiciste al respecto. Si algún día un regulador o una tienda pregunta, «lo eliminamos» es una afirmación, y una lista con fechas es una prueba.
Qué hace AppFoyer aquí
Alojamos la página y reenviamos la solicitud. Un usuario la envía, la guardamos como tu registro de auditoría y te avisamos: por email en cualquier plan, o por Telegram o Slack en uno de pago. La eliminación la haces tú en tus propios sistemas; no tenemos acceso a ellos y nunca decimos lo contrario.
Esa página sigue en línea aunque dejes de pagarnos, porque tus usuarios no tuvieron nada que ver con eso.
La fuente oficial
- Provide information about data deletion — Ayuda de Google Play. Léela antes de enviar; es la página que decide, no esta.