Dónde alojar una política de privacidad si no tienes dominio

No necesitas un dominio para publicar una política de privacidad: necesitas una URL pública que cargue sin iniciar sesión y que siga cargando dentro de dos años. Ambas tiendas comprueban el enlace, y la documentación de App Privacy de Apple incluye “the URL to your publicly accessible privacy policy” (la URL de tu política de privacidad accesible públicamente) como campo obligatorio. La única pregunta es dónde ponerla.

Seis lugares que los desarrolladores usan de verdad, con lo que cada uno cuesta realmente. Ninguno es incorrecto para todo el mundo; fallan en sitios distintos.

1. Un host estático en un subdominio que te dan

GitHub Pages, Cloudflare Pages, Netlify, Vercel. Gratis, rápido, y la URL es estable mientras lo sea la cuenta.

Dónde falla: la página de eliminación de cuenta. El hosting estático sirve archivos; no puede recibir una solicitud. Si tu app tiene cuentas, Google Play quiere una ruta web donde el usuario pueda pedir la eliminación, así que acabas publicando una dirección de correo en una página estática para que la recojan los scrapers, o añadiendo un servicio de formularios de terceros que ahora ve las direcciones de correo de tus usuarios. También falla si alguna vez cambias el nombre del repositorio o del proyecto, porque la URL cambia y la ficha de la tienda no.

2. Un enlace a un documento: Google Docs, Notion, un PDF

Lo más rápido del mundo y lo que más desconfianza genera en los revisores.

Dónde falla: la configuración de uso compartido. Un documento que hoy es “cualquier persona con el enlace” pasa a ser “personas de tu organización” tras un cambio de política del workspace, y nadie te avisa. Las páginas de Notion se despublican. En algunos dispositivos un PDF es una descarga, no una página. Más allá de la mecánica, da sensación de improvisación, que es justo la impresión que no quieres asociar a un envío que ya se está revisando por otra cosa.

3. Firebase Hosting

Nivel gratuito, un dominio real que te asignan, text/plain servido correctamente, y AdMob lo menciona expresamente como lugar aceptable para app-ads.txt, lo cual es práctico si también muestras anuncios.

Dónde falla: igual que cualquier host estático en lo referente a la eliminación de cuenta, y además ahora mantienes un paso de despliegue para cinco páginas de texto. Viable si Firebase ya está en tu stack; una carga extra si no lo está.

4. Una página en un sitio que no controlas

Un perfil social, una página en el sitio de un publisher, el blog de un amigo.

Dónde falla: en todo, tarde o temprano. No puedes arreglar un enlace roto en el sitio de otra persona en el momento en que una revisión está bloqueada por él, y que un revisor de la tienda acepte un perfil social como política de privacidad no es algo con lo que se pueda contar.

5. Comprar un dominio y alojarlo tú mismo

Unos $12 al año más una tarde. La respuesta correcta si de todas formas ibas a querer un sitio de marketing.

Dónde falla: las renovaciones y el problema de recibir solicitudes. Un dominio caducado tumba a la vez la URL de privacidad, la de soporte y la de eliminación en una ficha de tienda activa, y te enteras por la tienda. Si eliges este camino, pon la renovación en una tarjeta que no caduque y crea un recordatorio en el calendario con un mes de antelación.

6. Una página de cumplimiento alojada

Un servicio que te da las cinco páginas en una URL propia del servicio.

Dónde falla: lo que pasa cuando dejas de pagar. Esa es la pregunta que hay que hacer antes de pegar la URL en cualquier sitio, y es justo hacérnosla también a nosotros; mira más abajo.

El requisito que descarta la mitad

Si tu app tiene cuentas, no publicas una página, publicas un conjunto: la política de privacidad y una ruta web donde el usuario pueda solicitar la eliminación de su cuenta. Google Play pide tanto una vía dentro de la app como un enlace web público. Una página que solo muestra texto no puede cubrir lo segundo, y por eso las opciones 1 a 3 se convierten discretamente en “y un servicio de formularios” en cuanto llegas a ese punto.

Decídelo una sola vez, para las cinco URL, en lugar de resolver la política de privacidad esta noche y redescubrir el problema en el próximo rechazo.

Elijas lo que elijas, compruébalo como lo hará un revisor

Sin sesión iniciada, en una ventana privada, con datos móviles en lugar de tu propia red:

curl -i https://your-url.example/privacy

200 OK y contenido legible. Los hallazgos habituales son un 404, una redirección a un inicio de sesión o una página que funciona en tu portátil solo porque tienes la sesión iniciada en el servicio que la aloja.

Qué hace AppFoyer aquí

Las cinco páginas se publican en el subdominio propio de tu app, sin dominio ni servidor tuyos, y la página de eliminación de cuenta puede recibir de verdad una solicitud: la guarda y te avisa. La notificación por correo está en todos los planes, incluido el gratuito; Telegram y Slack están en los planes de pago. La eliminación la haces tú en tus propios sistemas; no tenemos acceso a ellos y nunca afirmamos lo contrario.

La pregunta justa, respondida: si dejas de pagar, la página de eliminación de cuenta sigue en línea, indefinidamente. Tus usuarios nunca nos eligieron y no saben nada de tu facturación, así que quitarles la vía para contactarte por una factura impagada sería un error nuestro, no tuyo. Una app es gratis, sin tarjeta.

Las fuentes oficiales

• Requisitos de la política de privacidad — Ayuda de Google Play
• Detalles de privacidad de las apps en el App Store — Apple
• Proporcionar información sobre la eliminación de datos — Ayuda de Google Play