Notificaciones web push: cómo funcionan y cómo usarlas bien

Las notificaciones web push son el único canal de marketing donde una sola mala decisión de diseño puede dejarte fuera de un cliente para siempre. Pides permiso en el momento equivocado, la persona pulsa Bloquear, y ese navegador se te cierra para siempre. Sin segundo aviso, sin segunda campaña, sin email de recuperación. Esa asimetría es la razón por la que merece la pena entender el mecanismo antes de escribir un solo mensaje.

Qué son las notificaciones web push

Una notificación web push es un mensaje enviado desde tu servidor al navegador de una persona suscrita, mostrado por el centro de notificaciones del sistema operativo y entregado incluso cuando tu sitio está cerrado. Esa última parte es lo esencial: a diferencia de una ventana emergente en la página, el web push llega a alguien que no está mirando tu web en ese momento.

Se construye sobre tres APIs de la plataforma web que trabajan juntas, y el reparto entre ellas explica casi todo el comportamiento del canal: la Service Worker API, la Push API y la Notifications API.

Cómo funciona web push por dentro

El service worker

Un service worker es un worker de JavaScript que actúa como proxy entre tu aplicación web, el navegador y la red. Se ejecuta en su propio hilo, no tiene acceso al DOM y sigue existiendo después de que se cierre la página que lo registró. Esa persistencia es lo que le permite recibir un mensaje push y mostrar una notificación cuando nadie tiene tu pestaña abierta. Los service workers solo funcionan en contextos seguros, es decir HTTPS, con http://localhost tratado como seguro para desarrollo.

La suscripción: un endpoint más dos claves

Una vez que el service worker está activo, la página llama a registration.pushManager.subscribe(). El navegador habla con el servicio push de su fabricante y devuelve un PushSubscription que contiene:

• endpoint, una URL de capacidad única en la que el servicio push acepta mensajes
• keys.p256dh, una clave pública de Diffie-Hellman de curva elíptica sobre la curva P-256
• keys.auth, un secreto de autenticación

Tu servidor guarda las tres y trata el endpoint como un secreto, porque cualquiera que lo tenga puede enviar a esa persona suscrita. Las claves existen porque los payloads se cifran de extremo a extremo. El RFC 8291 especifica cómo: un intercambio ECDH sobre P-256 establece un secreto compartido, HKDF deriva claves de él, y el payload se sella con AES-128-GCM bajo la codificación de contenido aes128gcm. El servicio push retransmite un texto cifrado que no puede leer.

El servicio push

No envías mensajes push directamente a un dispositivo. Los envías a un servicio push gestionado por el fabricante del navegador: los endpoints de FCM de Google para Chrome, autopush de Mozilla para Firefox, el servicio push de Apple para Safari. El RFC 8030, “Generic Event Delivery Using HTTP Push”, define el protocolo. Tu servidor hace un POST al endpoint de la suscripción, y el servicio push se encarga de las partes difíciles de la entrega móvil: una única conexión eficiente en batería con el dispositivo, encolado mientras está sin conexión, despertar al navegador cuando llega un mensaje. Esto también explica por qué la entrega no se puede garantizar. Si el dispositivo está apagado el tiempo suficiente, los mensajes caducan según su TTL y se descartan.

VAPID: demostrar quién envía

Que el endpoint sea un secreto es una seguridad frágil. El RFC 8292 añade Voluntary Application Server Identification, o VAPID, para que un servicio push pueda saber de qué servidor de aplicación vino un mensaje.

Generas una vez un par de claves ECDSA sobre la curva NIST P-256. La clave pública va en applicationServerKey cuando el navegador se suscribe, y vincula la suscripción a tu servidor. En cada envío, tu servidor manda un JWT firmado con la clave privada correspondiente usando ES256, con una reclamación aud para el origen del servicio push, una reclamación exp de como mucho 24 horas, y opcionalmente una reclamación sub con datos de contacto. El servicio push verifica la firma, así que un endpoint robado ya no basta por sí solo para enviar spam a tus suscriptores.

El camino de entrega, de principio a fin

1. La página registra un service worker y, tras concederse el permiso, llama a subscribe() con tu clave pública VAPID.
2. Tu servidor guarda el endpoint y las claves devueltas junto al registro de la persona suscrita.
3. Para enviar, tu servidor cifra el payload con p256dh y auth, firma un JWT de VAPID y hace un POST al endpoint.
4. El servicio push autentica la petición y entrega el mensaje cifrado.
5. El navegador despierta al service worker con un evento push, que descifra el payload y llama a ServiceWorkerRegistration.showNotification().
6. Un clic dispara notificationclick en el service worker, donde abres la URL de destino.

Por qué el modelo de permisos es tan estricto

Fíjate en lo que concede una suscripción: un proceso en segundo plano que se ejecuta sin que tu sitio esté abierto, más la capacidad de dibujar sobre la superficie de notificaciones del sistema operativo. Por eso los navegadores lo protegen tras un permiso explícito, por origen, concedido por la persona, y la mayoría exige que la solicitud siga a un gesto real.

Hay una segunda restricción que sorprende. Chrome y Edge exigen userVisibleOnly: true al suscribirse, una promesa de que cada envío producirá una notificación visible, así que los envíos silenciosos en segundo plano no son un uso admitido de la API. Firefox también aplica una cuota a los mensajes push que no generan notificación.

Compatibilidad de navegadores y plataformas

Según MDN, la Push API está en Baseline ampliamente disponible desde marzo de 2023, lo que significa que funciona en las versiones actuales de Chrome, Edge, Firefox y Safari en escritorio, y en Chrome y Firefox para Android. Dos matices importan más que el titular.

Primero, la Notifications API no está disponible de forma uniforme. MDN la marca como de disponibilidad limitada porque el constructor Notification() lanza un TypeError en la mayoría de los navegadores móviles. Para cualquier cosa que deba funcionar en teléfonos, usa notificaciones persistentes mediante ServiceWorkerRegistration.showNotification(), que es el camino del service worker en el que ya estás.

Segundo, las opciones de notificación están implementadas de forma desigual. Los botones de acción, las insignias, las imágenes y requireInteraction varían entre navegadores y sistemas operativos, así que diseña notificaciones que se lean bien con solo un título, un cuerpo y un icono.

El requisito de iOS y iPadOS

Este matiz decide si web push es viable para una audiencia mayoritariamente móvil, y casi en todas partes se cuenta mal.

Apple añadió Web Push en iOS y iPadOS 16.4, y solo funciona para aplicaciones web que se han añadido a la pantalla de inicio. Como lo expresó WebKit, “estamos añadiendo compatibilidad con Web Push para las aplicaciones web de la pantalla de inicio”, y “una aplicación web que se ha añadido a la pantalla de inicio puede pedir permiso para recibir notificaciones push”. La persona la añade desde el menú Compartir y “Añadir a pantalla de inicio”, y el permiso debe solicitarse entonces como respuesta a una interacción directa, por ejemplo al pulsar un botón de suscripción.

Un sitio abierto en una pestaña normal de Safari en el iPhone no puede crear una suscripción push. Eso es una barrera real: estás pidiendo un paso de instalación antes de poder siquiera pedir permiso. En macOS es más fácil, porque Safari 16.1 en macOS Ventura añadió Web Push basado en estándares para sitios web normales, sin paso de instalación.

Un ejemplo mínimo de suscripción

Este es todo el flujo del lado del cliente. Su sitio es un manejador de clic, no la carga de la página.

async function subscribeToPush(vapidPublicKey) {
  // Push y los service workers requieren un contexto seguro (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Debe llamarse desde un gesto del usuario, y solo una vez por usuario.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // clave pública P-256 en base64url
  });

  // Guarda endpoint + claves en el servidor; trata el endpoint como un secreto.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Dentro de sw.js gestionas el evento push, llamas a self.registration.showNotification(title, options) y gestionas notificationclick para abrir la URL de destino.

Experiencia de permiso: donde fracasan casi todos los programas

Nunca pidas al cargar la página

Lighthouse tiene una auditoría dedicada a esto: “si tu página pide permiso para enviar notificaciones al cargarse, puede que esas notificaciones no sean relevantes para tus usuarios ni para sus necesidades”. Su recomendación es ofrecer un tipo concreto de notificación y pedir permiso solo después de que la persona se apunte a ese tipo. Safari 12.1 y otros navegadores fueron más allá, exigiendo interacción con la página antes de que se pueda hacer siquiera una solicitud.

Usa un aviso previo suave

Muestra primero tu propia invitación dentro de la página. Nombra la propuesta de valor, se puede descartar sin coste permanente, y solo un clic en ella dispara el aviso real del navegador. A quien ignora hoy tu aviso suave le puedes preguntar de nuevo el mes que viene. A quien pulsa Bloquear, no. Dos reglas hacen que funcione: describe lo que vas a enviar de verdad en lugar de “recibe novedades”, y nunca provoques un clic por error, porque una aceptación accidental produce una baja inmediata.

Pregunta en contexto

La propia recomendación de Chrome es “deja que tus usuarios tomen la iniciativa y activen las notificaciones a su propio ritmo”, colocando los interruptores de forma discreta dentro de las superficies de interfaz existentes, y evitar “mostrar avisos o superposiciones sin contexto o justo después de que alguien llegue al sitio”.

Los momentos que funcionan en comercio son concretos: un control de “avísame cuando vuelva a estar disponible” en un producto agotado, una página de confirmación de pedido que ofrece avisos de entrega, un interruptor de vigilancia de precio en un producto que se consulta a menudo. El permiso se cambia por un beneficio con nombre en vez de recogerse a la fuerza.

Una denegación es prácticamente permanente

Cuando alguien bloquea las notificaciones, el navegador guarda esa decisión para tu origen. Las llamadas posteriores a Notification.requestPermission() se resuelven con el valor denied guardado sin mostrar nada, y por eso el propio ejemplo de MDN comprueba Notification.permission antes de llamar a requestPermission(). Revertir un bloqueo implica escarbar en los ajustes del sitio, algo que prácticamente nadie hace.

Qué hacen los navegadores cuando lo haces mal

Las consecuencias ya no son solo una tasa de aceptación baja.

• Chrome inscribe automáticamente en una interfaz de permisos más silenciosa a los orígenes con tasas de aceptación muy bajas, por separado según el tipo de dispositivo, suprimiendo el aviso para todo el mundo.
• Chrome limita la frecuencia de los sitios que combinan mucho volumen de push con poco engagement, devolviendo HTTP 429. La escalada dura un día, luego siete, luego catorce, y solo se reinicia tras 42 días consecutivos sin comportamiento disruptivo.
• Chrome ahora revoca automáticamente el permiso de notificaciones de los sitios con los que alguien no ha interactuado recientemente, cuando hay “muy poco engagement por parte del usuario y un alto volumen de notificaciones enviadas”. La justificación de Google es rotunda: “menos del 1 % de todas las notificaciones recibe alguna interacción de los usuarios”.

Puedes perder suscriptores que ya te habías ganado simplemente por enviar mal.

Web push comparado con el email y el SMS

La diferencia de propiedad que cambia la estrategia

Una suscripción push es una URL de capacidad ligada a un perfil de navegador en un dispositivo. No es una persona. El mismo cliente usando Chrome en un portátil y Firefox en el teléfono son dos suscripciones sin relación entre sí, y no puedes saber que son el mismo ser humano a menos que se identifique.

Tampoco es portable. Puedes exportar una lista de email y cargarla mañana en otra plataforma. No puedes mover suscripciones push entre proveedores, porque las claves y el vínculo VAPID se crearon contra una clave de servidor de aplicación concreta.

Así que trata el web push como un acelerador de un canal propio, nunca como un sustituto. Usa el momento del push para ganarte una dirección de email o un número de teléfono, no al revés. La guía completa de automatización del marketing explica cómo conectar varios canales en un mismo recorrido.

Casos de uso que funcionan de verdad

El canal premia los mensajes urgentes, personalmente relevantes y accionables en un solo toque.

• Carrito abandonado. Un push dentro de la primera hora, reforzado por un email más tarde. La guía del email de carrito abandonado cubre la secuencia.
• Avisos de vuelta a stock. El caso más fuerte, porque la persona pidió explícitamente que se lo dijeran.
• Bajadas de precio en productos vigilados. La misma lógica, relevancia autoseleccionada.
• Estado de entrega y de pedido. Alta intención de apertura, bajo riesgo de queja.
• Novedades urgentes en un tema suscrito. Noticias, resultados, ventanas de disponibilidad.

Lo que fracasa está igual de claro: los envíos genéricos de “hemos publicado un artículo nuevo”, las ofertas diarias indiferenciadas, cualquier cosa que necesite más de un título y una línea, los envíos de reactivación a suscriptores que ignoraron las últimas veinte notificaciones, y el contenido transaccional que necesita un registro duradero.

Frecuencia, momento y segmentación

Empieza con moderación: de una a tres notificaciones por persona suscrita y semana, ampliando solo si las tasas de baja y de clic aguantan. La fatiga aparece antes que en el email porque silenciarlo cuesta un toque sobre una notificación que el sistema operativo ya ha mostrado.

El momento es a la vez una ventaja y un peligro. El push llega de inmediato, así que un mensaje enviado a las 02:00 llega a las 02:00. Guarda o infiere la zona horaria de cada persona suscrita en el momento de la suscripción y mantén los envíos dentro de una ventana definida.

La segmentación está limitada por lo que sabes de una suscripción y no de una persona, así que las dimensiones viables son de comportamiento: páginas vistas, productos vigilados, estado del carrito, recencia de compra, plataforma. La guía de segmentación de clientes profundiza en ello.

Cómo medir el web push

Importan cuatro métricas, y no todas se miden igual.

• Entrega. Si el servicio push aceptó la petición. Un 201 significa aceptado, no entregado. Un 404 o un 410 significa que la suscripción está muerta.
• Visualización. Si la notificación se mostró. Solo lo sabes si el service worker lo informa cuando showNotification() se resuelve.
• Tasa de clics. Clics divididos entre visualizaciones. Este es el número que merece la pena optimizar.
• Tasa de baja. Bajas y revocaciones de permiso por envío. Vigílala más de cerca que la tasa de clics, porque es el indicador adelantado de la muerte del canal.

Trampas de la atribución

La atribución del push se halaga a sí misma. La notificación llega a un dispositivo que la persona ya tiene en la mano, así que a menudo se lleva el mérito de una sesión que iba a ocurrir igualmente. Usa grupos de control en lugar de dar por hecha la incrementalidad. Las visualizaciones se subestiman mientras que todos los clics se registran, así que una tasa de clics calculada sobre los envíos exagera el rendimiento. Y como una suscripción es un navegador y no una persona, un push pulsado en el teléfono que acaba en una compra de escritorio parece dos eventos sin relación. La guía de métricas de email marketing cubre la higiene de medición entre canales.

Consentimiento, RGPD y baja

El aviso de permiso del navegador es una barrera técnica. No es automáticamente una base legal completa para hacer marketing.

Cuando hagas marketing a personas de la UE o del Reino Unido, trata el push como tratas el email. Explica qué vas a enviar antes de que aparezca el aviso, para que el consentimiento sea informado y específico. Registra cuándo y dónde se creó la suscripción, y nunca mezcles el consentimiento de push con una acción no relacionada. Si vinculas las suscripciones a clientes identificados, esos datos entran en tus obligaciones sobre datos personales, incluidas las solicitudes de supresión.

La higiene de la baja importa igual. Ofrece un control de preferencias dentro del sitio para que la gente pueda reducir la frecuencia en vez de bloquear, llama a PushSubscription.unsubscribe() y borra el registro en el servidor cuando lo hagan, y purga las suscripciones ante un 404 o un 410. La orientación de MDN es breve y correcta: a las personas usuarias se les debe “ofrecer una forma sencilla de dejar de recibir más en el futuro”.

Dónde encaja el web push en tu conjunto de canales

El web push es un buen tercer canal y un mal primero: rápido, gratuito en el margen e insuperable para avisos urgentes, pero atado al dispositivo, no exportable y a un clic de la pérdida permanente.

Eso convierte la orquestación en el verdadero problema. Qué mensaje va a qué canal, cómo suprimes el email cuando el push ya convirtió, y cómo mantienes una única visión del cliente en superficies que identifican a las personas de forma distinta. Brevo ofrece push web y móvil junto al email y el SMS, y Tajo se sitúa sobre Brevo para coordinar esa lógica multicanal en tiendas de Shopify. Para la parte de SMS, consulta la guía de automatización de SMS.

Puntos clave

• El web push son tres APIs cooperando: un service worker para la ejecución en segundo plano, la Push API para la suscripción y el transporte, la Notifications API para la visualización. Una suscripción es un endpoint más una clave p256dh y un secreto auth, los payloads se cifran de extremo a extremo y VAPID demuestra quién envía.
• El push está en Baseline ampliamente disponible desde marzo de 2023, pero en iOS y iPadOS solo funciona para aplicaciones web añadidas a la pantalla de inicio.
• Nunca pidas permiso al cargar la página. Usa un aviso previo suave, pregunta en contexto y recuerda que un bloqueo es permanente para ese origen.
• Chrome ya aplica avisos más silenciosos, límites de frecuencia y revocación automática de permisos, así que enviar mal te cuesta suscriptores que ya tenías.
• Una suscripción es un navegador, no una persona, y no se puede exportar. Construye primero la lista de email y usa el push para acelerarla.