Cuándo y cómo pedir permiso para notificaciones sin que lo bloqueen

Pide el permiso de notificaciones justo después de que el usuario haga algo que dé sentido al aviso, nunca al cargar la página, y siempre con un mensaje tuyo antes del diálogo del navegador. Ese diálogo es casi de un solo uso: si el usuario pulsa «Bloquear», tu web pierde el canal hasta que él mismo lo cambie en los ajustes.

En resumen:

• El permiso tiene tres estados: default, granted y denied. Desde denied ya no puedes volver a preguntar.
• Firefox y Safari exigen que la petición salga de un gesto del usuario, y Chrome muestra una interfaz más discreta a las webs con tasas de aceptación muy bajas.
• Usa dos pasos: un aviso propio que explica el beneficio y, solo si el usuario acepta, el diálogo del navegador.
• Pregunta en momentos con intención: seguir un pedido, esperar una exportación, vigilar un precio.
• Si ya está bloqueado, no insistas: explica cómo desbloquearlo cuando el usuario lo busque.

Por qué un «Bloquear» es casi definitivo

Notification.permission puede valer default (aún no ha decidido), granted o denied. Mientras esté en default puedes pedirlo con Notification.requestPermission() o al suscribir con pushManager.subscribe(). Pero en cuanto el usuario elige «Bloquear», el estado pasa a denied y cualquier petición nueva se resuelve al instante como denied, sin mostrar nada. Ni tu código ni un rediseño lo arreglan: solo el usuario puede cambiarlo, desde la configuración del sitio.

Además, los navegadores penalizan las malas prácticas:

• Firefox, desde la versión 72, solo muestra el diálogo si la petición sale de un gesto del usuario (un clic, un toque o una tecla). Si no, rechaza la petición y deja un pequeño icono en la barra de direcciones.
• Safari, en Mac y en iPhone, también exige un gesto del usuario.
• Chrome, desde la versión 80, sustituye el diálogo por un aviso discreto en la barra de direcciones para las webs con tasas de aceptación muy bajas y para los usuarios que suelen rechazar estos permisos.

Pedir el permiso nada más entrar es el camino más corto hacia esa interfaz silenciosa. Google lo resume en sus buenas prácticas sobre permisos: pide después de una interacción, cuando el usuario entiende para qué.

El patrón de dos pasos: tu aviso primero

La solución es partir la pregunta en dos. Primero muestras un aviso tuyo, como un banner, una tarjeta o un botón dentro de la página, que explica qué vas a enviar. Ese aviso no gasta nada: si el usuario responde «Ahora no», el permiso del navegador sigue en default y puedes ofrecerlo de nuevo más adelante. Solo cuando dice que sí llamas al diálogo del navegador, que llega con contexto y con la decisión casi tomada.

const SNOOZE_DAYS = 14;

function shouldOffer() {
  if (!('PushManager' in window) || Notification.permission !== 'default') return false;
  const snoozedAt = Number(localStorage.getItem('push-snoozed-at') || 0);
  return Date.now() - snoozedAt > SNOOZE_DAYS * 86400000;
}

async function onAccept() { // clic en «Avisarme» de tu aviso
  const permission = await Notification.requestPermission();
  if (permission === 'granted') await subscribeAndSave();
}

function onNotNow() { // clic en «Ahora no»
  localStorage.setItem('push-snoozed-at', String(Date.now()));
}

onAccept se ejecuta dentro del clic, así que cumple el requisito del gesto en todos los navegadores. subscribeAndSave() es tu función que crea la suscripción y la envía a tu servidor; si quieres repasar qué ocurre ahí, lo explicamos en qué es Web Push.

Cuándo pedirlo: momentos con intención

El mejor momento llega justo después de una acción que hace evidente el valor del aviso. Algunos ejemplos:

Todos comparten algo: el usuario acaba de mostrar interés en algo que pasará en el futuro, y el aviso promete exactamente eso. Compáralo con un banner genérico en la portada a los dos segundos de llegar, cuando el visitante aún no sabe ni qué vendes.

Como regla práctica, no lo ofrezcas en la primera página que ve un visitante nuevo, no lo muestres a la vez que el banner de cookies y no lo repitas a quien acaba de responder «Ahora no».

Qué decir en tu aviso

Un buen aviso responde tres preguntas en dos líneas: qué recibiré, con qué frecuencia y cómo lo desactivo. Compara:

• Flojo: «¿Quieres recibir notificaciones?», con los botones «Sí» y «No».
• Mejor: «Te avisamos cuando tu pedido salga del almacén y cuando esté en reparto. Solo esos dos avisos», con los botones «Avisarme» y «Ahora no».

Algunas reglas que funcionan:

• El botón afirmativo describe la acción («Avisarme», «Activar avisos de entrega»), no un «Aceptar» genérico.
• La alternativa es «Ahora no», no «No, prefiero perderme las ofertas». Las respuestas que culpabilizan generan desconfianza.
• No imites el diálogo del navegador ni el del sistema: el usuario se siente engañado cuando aparece el de verdad.
• Si prometes una frecuencia, cúmplela. En cuántas notificaciones enviar vemos cómo fijarla.

Si ya lo bloquearon: cómo ayudar a desbloquear

Cuando Notification.permission vale denied, esconde tu aviso y el botón de suscribir; enseñarlos solo genera frustración. Pero si el usuario busca los avisos, por ejemplo en los ajustes de su cuenta, explícale cómo revertirlo:

• Chrome y Edge: el icono a la izquierda de la dirección, después la configuración del sitio y Notificaciones en «Permitir».
• Firefox: el icono de permisos de la barra de direcciones, para quitar el bloqueo.
• Safari en Mac: Safari > Ajustes > Sitios web > Notificaciones.
• iPhone, con la web instalada: Ajustes > Notificaciones > nombre de la web.

Después del cambio, al recargar la página verás granted y podrás suscribirlo sin que aparezca ningún diálogo. Otro caso distinto es cuando el usuario cierra el diálogo sin elegir: el estado sigue en default y técnicamente puedes volver a pedirlo, pero Chrome puede bloquear la petición durante un tiempo si se descarta varias veces seguidas. Trata ese cierre como un «Ahora no».

Mide la aceptación y ajusta

Sin datos, todo lo anterior es intuición. Registra cinco eventos: aviso mostrado, aviso aceptado, «Ahora no», permiso concedido y permiso denegado. Con ellos calculas dos tasas que dicen cosas distintas:

• Aceptación de tu aviso (aceptados entre mostrados): mide si el momento y el texto convencen.
• Concesión en el navegador (concedidos entre aceptados): debería acercarse al total. Si no, algo entre tu aviso y el diálogo confunde al usuario.

Compara por página y por momento: el mismo aviso puede funcionar muy bien tras un pedido y fatal en la portada. Si usas castly, el aviso se configura en el panel de cada proyecto: textos en español e inglés, posición, retraso, a partir de qué página vista, en qué rutas y cuántos días esperar tras «Ahora no». El SDK lo muestra solo si el permiso sigue en default, así que puedes probar momentos distintos sin desplegar; lo tienes en la documentación del aviso de permiso.

Preguntas frecuentes

¿Puedo pedir permiso al cargar la página si el usuario ya conoce mi web?

Puedes, pero no conviene. Firefox y Safari ni siquiera mostrarán el diálogo sin un gesto del usuario, y en Chrome una tasa de aceptación baja puede llevar a tu web a la interfaz discreta. Incluso con usuarios fieles, un botón en el lugar adecuado funciona mejor.

¿Cualquier clic sirve como gesto del usuario?

Técnicamente sí, pero aprovechar un clic que no tiene nada que ver, como el del banner de cookies o el de un menú, se percibe como una trampa. El clic debería ser la respuesta a una pregunta sobre notificaciones.

¿Cuántas veces puedo mostrar mi aviso propio?

No hay límite técnico, porque es tu interfaz. Como regla práctica, tras un «Ahora no» espera entre una y varias semanas, y deja de ofrecerlo de forma proactiva tras dos o tres rechazos; un interruptor en los ajustes de la cuenta puede seguir ahí.

¿Qué hago con los usuarios que ya concedieron el permiso?

No les muestres ningún aviso. En cada visita comprueba con pushManager.getSubscription() que su suscripción sigue existiendo y, si ha desaparecido, ofrécele reactivarla con un botón: con el permiso ya concedido, no verá ningún diálogo del navegador.

¿Funciona igual en iPhone?

El patrón es el mismo, pero en iPhone y iPad el permiso solo existe dentro de la web instalada en la pantalla de inicio. Antes de tu aviso necesitas otro paso: explicar la instalación. Lo detallamos en web push en iPhone.