Política de privacidad si usas Firebase, Analytics o anuncios: qué declarar
Cómo adaptar tu política de privacidad cuando integras Firebase, Google Analytics, crash reporting o AdMob: categorías de datos, terceros, Data safety y errores que generan inconsistencias.
El escenario más común en apps indie
Instalas Firebase Auth, Analytics, Crashlytics y más tarde AdMob. La app funciona… pero la política sigue diciendo “no recopilamos datos personales”.
Esa inconsistencia es exactamente lo que miran revisores, usuarios avanzados y el formulario de Data safety. No necesitas un tratado legal: necesitas declarar con honestidad lo que los SDKs hacen.
Qué suelen recopilar estos stacks (categorías)
No copies esta lista a ciegas: audita tu build.gradle / SPM y la consola de cada proveedor. Categorías frecuentes:
| SDK / feature | Datos típicos | Finalidad habitual |
|---|---|---|
| Auth | email, ID de usuario | cuenta |
| Analytics | eventos de uso, IDs de instancia | analítica de producto |
| Crash reporting | logs, modelo de dispositivo | estabilidad |
| Cloud Messaging | token de push | notificaciones |
| AdMob / ads | ID de publicidad, datos de interacción | publicidad |
| Remote Config | identificadores técnicos | configuración |
Si usas Google Analytics for Firebase, asume telemetría de uso. Si hay anuncios personalizados, decláralo con claridad.
Cómo escribirlo en la política (estructura útil)
- Datos de cuenta — si el usuario inicia sesión.
- Datos de uso y dispositivo — eventos, versión de app, idioma, etc.
- Datos de diagnóstico — crashes y rendimiento.
- Identificadores de publicidad — si hay ads.
- Proveedores — “usamos proveedores de analytics/hosting/ads” (nombra categorías; puedes nombrar Firebase/Google cuando sea central).
- Base / finalidad — operar la app, mejorar el producto, mostrar anuncios, seguridad.
- Retención — plazos realistas o criterios.
- Derechos y eliminación — cómo pedir borrado (y enlace al canal web si lo tienes).
Alineación con Google Play Data safety
La política y Data safety deben contar la misma historia:
- si Analytics está on → no marques “no compartimos / no recopilamos” de forma incompatible,
- si AdMob está on → revisa declaraciones de publicidad e identificadores,
- si hay cuenta → contempla eliminación.
Más detalle del formulario: guía de Data safety.
ATT y tracking en iOS
Si en iOS pides permiso de seguimiento para ads personalizados, tu política y las Privacy Labels deben reflejarlo. No prometas “sin tracking” si el flujo ATT existe para personalización.
Proceso cuando agregas un SDK nuevo
- Anota qué datos introduce
- Actualiza la política el mismo día
- Actualiza Data safety / Nutrition Labels
- Republica la URL (mismo link, nuevo contenido)
- Revisa app-ads.txt si cambias de red publicitaria
Con un hosting editable esto toma minutos, no un sprint de DevOps.
Cómo AppConsol ayuda
AppConsol centraliza:
- política y términos en tu subdominio,
app-ads.txtpara AdMob,- formulario de eliminación de datos si hay cuentas.
Así el cumplimiento acompaña al stack técnico en lugar de quedar en un Doc olvidado.
Errores frecuentes
- Política estática de hace dos años con ads nuevos
- Nombrar “terceros” sin ninguna categoría útil
- Declarar base legal inventada o derechos que no atiendes
- Olvidar crash reporting (también es dato)
Conclusión
Firebase, Analytics y ads no “prohíben” publicar: obligan a declarar. Mantén la política como un documento vivo acoplado a tus SDKs. Si quieres una URL editable para Play y App Store, publícala en AppConsol.