Blog · Privacidad
RGPD y notificaciones push: consentimiento, datos y responsabilidades
Qué datos personales hay en una suscripción push, cuándo no basta el permiso del navegador, cómo facilitar la baja y quién responde de qué. Guía informativa.
Las notificaciones push en la UE quedan bajo dos normas: la Directiva ePrivacy, porque suscribirse guarda y lee información en el dispositivo, y el RGPD, porque la suscripción y lo que asocias a ella son datos personales. En la práctica necesitas un consentimiento informado antes del permiso del navegador, una baja tan fácil como el alta, pocos datos y un contrato claro con tu proveedor. Este artículo es informativo y no sustituye el asesoramiento jurídico.
En resumen:
- El endpoint de una suscripción es un identificador en línea: trátalo como dato personal, sobre todo si lo unes a tu id de usuario.
- El diálogo nativo del navegador no explica quién eres ni para qué avisarás; un aviso previo propio hace que el consentimiento sea informado.
- Separa los avisos transaccionales de los promocionales: no se apoyan en la misma base jurídica.
- Darse de baja debe ser tan fácil como suscribirse, y las suscripciones muertas no deben quedarse en tu base de datos.
- La plataforma de push que contratas es encargada del tratamiento: necesitas un contrato del artículo 28.
Qué datos personales hay en una suscripción push
Cuando alguien se suscribe, el navegador genera una suscripción con tres piezas: un endpoint (una URL única en el servicio push de ese navegador) y dos claves de cifrado, p256dh y auth. No incluyen el nombre de nadie, pero el RGPD menciona expresamente los «identificadores en línea» en su definición de dato personal (art. 4.1), y en cuanto los vinculas a una cuenta, la identificación es directa. A eso se suma lo que tú añades:
| Dato | Para qué lo necesitas | Recomendación |
|---|---|---|
| Endpoint y claves | Enviar y cifrar cada push | Imprescindibles; bórralos cuando caduquen |
| Id de usuario | Avisar de su cuenta en todos sus dispositivos | Usa tu id interno, no el email |
| Etiquetas (idioma, plan, intereses) | Segmentar envíos | Solo las que vayas a usar; nada sensible |
| Registros de entrega y clics | Medir y depurar | Fija un plazo de conservación |
| IP y navegador al suscribirse | Seguridad o prueba del consentimiento | Guárdalos solo si tienen un fin claro |
Aplica la minimización (art. 5.1.c): una etiqueta como «interesado en productos para diabéticos» revela información de salud, que es una categoría especial (art. 9) y no pinta nada en tu sistema de notificaciones.
El permiso del navegador no basta por sí solo
El artículo 5.3 de la Directiva ePrivacy exige consentimiento para guardar o leer información en el dispositivo, salvo que sea estrictamente necesario para un servicio que el usuario ha pedido. El diálogo nativo cubre una parte: nadie se suscribe sin pulsar «Permitir». Pero solo dice que el sitio quiere enviar notificaciones. No explica quién eres, qué vas a enviar ni con qué frecuencia, y el RGPD pide que el consentimiento sea libre, específico, informado e inequívoco (art. 4.11).
La solución habitual es un aviso previo propio, que aparece antes del diálogo del navegador:
- Di qué recibirá: «Te avisamos cuando tu pedido salga y cuando llegue. Nada de publicidad».
- Enlaza tu política de privacidad desde el propio aviso.
- Ofrece un «Ahora no» real: no bloquees contenido a quien no acepte (art. 7.4).
- Guarda prueba: fecha, texto mostrado y su versión, porque debes poder demostrar el consentimiento (art. 7.1).
En castly este aviso se configura por proyecto, con textos en español e inglés y los días que deben pasar antes de volver a mostrarlo tras un «Ahora no». El momento importa tanto como el texto: lo tratamos en cuándo pedir permiso de notificaciones.
Avisos transaccionales y promocionales: bases distintas
No todos los mensajes se apoyan en la misma base jurídica:
- Transaccionales (tu pedido ha salido, tu cita es mañana): el tratamiento puede apoyarse en la ejecución del contrato (art. 6.1.b), porque informan sobre algo que el usuario ha contratado. Aun así, el canal push siempre requiere que acepte el permiso del navegador.
- Promocionales (ofertas, novedades, carritos abandonados): necesitan consentimiento (art. 6.1.a). En España, la LSSI (art. 21) prohíbe además enviar comunicaciones publicitarias o promocionales por correo electrónico «u otro medio de comunicación electrónica equivalente» sin solicitud o autorización previa, y lo prudente es aplicar el mismo criterio a las push.
Si un mismo permiso sirve para ambos, deja claro desde el aviso previo que habrá promociones. Mejor aún: pide el consentimiento promocional aparte y guárdalo como una etiqueta del suscriptor, por ejemplo promos: "si", para dirigir cada campaña solo a quien aceptó. La técnica está en segmentar con etiquetas, y los avisos de servicio, en notificaciones transaccionales.
Darse de baja y borrar: tan fácil como suscribirse
El artículo 7.3 exige que retirar el consentimiento sea tan sencillo como darlo. Bloquear las notificaciones en los ajustes del navegador funciona, pero está escondido. Ofrece un interruptor en tu web, en la cuenta o en el pie, que anule la suscripción con un clic, y explica también la vía del navegador en tu política.
- Elimina las suscripciones caducadas. Cuando el servicio push responde 404 o 410, la suscripción ya no existe y no hay motivo para conservarla. castly las marca como caducadas automáticamente; decide tú cuándo las borras de tus propios sistemas.
- Fija plazos para los registros. castly guarda los logs de entrega 30 días; si copias eventos a tu base de datos mediante webhooks, aplica allí tu propio plazo.
- Atiende acceso y supresión (arts. 15 y 17): debes poder localizar todas las suscripciones de una persona por su id de usuario y eliminarlas.
Qué poner y qué no en una notificación
El contenido de una push viaja cifrado de extremo a extremo según el RFC 8291: el servicio push del navegador lo transporta sin poder leerlo y solo ve metadatos como el endpoint, el tamaño, la hora o la caducidad. El riesgo está en el otro extremo, porque la notificación aparece en la pantalla de bloqueo, en un monitor compartido o en mitad de una videollamada.
- Mejor «Tienes una cita mañana a las 10:00» que «Tu cita en la Unidad de Fertilidad es mañana».
- Mejor «Tu pago no se ha completado» que «Tu pago de 1.240 € a la Clínica Dental Sonrisa ha fallado».
- Nunca códigos de un solo uso ni enlaces que inicien sesión automáticamente: cualquiera que vea la pantalla podría usarlos.
Deja el detalle para la página que se abre al pulsar, protegida por la sesión del usuario.
Quién es responsable de qué
| Actor | Papel | Qué hacer |
|---|---|---|
| Tu empresa | Responsable del tratamiento: decide qué se envía, a quién y para qué | Política de privacidad (art. 13), registro de actividades (art. 30) y una base jurídica por finalidad |
| La plataforma de push que contratas | Encargada del tratamiento: guarda suscripciones y envía por tu cuenta | Contrato de encargo (art. 28), medidas de seguridad, lista de subencargados y ubicación de los datos |
| Servicios push de los navegadores (Google, Mozilla, Apple, Microsoft) | Llevan el mensaje cifrado hasta el dispositivo; su encaje jurídico es menos claro | Menciónalos en tu política como canal de entrega |
Si alguno de ellos trata datos fuera del Espacio Económico Europeo, comprueba qué mecanismo ampara la transferencia, como una decisión de adecuación o cláusulas contractuales tipo, e indícalo en tu política.
Preguntas frecuentes
¿El endpoint de una suscripción push es un dato personal?
Es un identificador único ligado a un navegador concreto, y el RGPD incluye los identificadores en línea en la definición de dato personal. Si además lo asocias a una cuenta, no hay duda: trátalo como tal.
¿Sirve el diálogo del navegador como consentimiento?
Es imprescindible, pero por sí solo no informa de quién envía ni para qué. Acompáñalo de un aviso previo con la finalidad y un enlace a tu política, y guarda prueba de lo que mostraste.
¿Necesito consentimiento para las notificaciones transaccionales?
El usuario siempre tiene que aceptar el permiso del navegador para recibir push. En cuanto al tratamiento de datos, los avisos ligados a un contrato pueden apoyarse en su ejecución, mientras que los promocionales requieren consentimiento.
¿Cuánto tiempo puedo guardar las suscripciones?
Mientras sigan activas y el usuario no se dé de baja. Elimina las que el servicio push da por inexistentes (404 o 410) y fija un plazo para los registros y estadísticas por dispositivo.
¿Las notificaciones push salen de la UE?
Pueden hacerlo: los servicios push de los navegadores y algunos proveedores operan fuera del EEE. El contenido va cifrado, pero los metadatos no, así que documenta esas transferencias en tu política y verifica su base legal.