Fatiga de notificaciones: cómo medirla y cómo reducirla

La fatiga de notificaciones es un suscriptor que ha dejado de leer sus notificaciones y todavía no se lo ha dicho.

Ese es todo el problema en una frase. Nadie escribe para quejarse. El permiso sigue concedido durante un tiempo. El número de envíos se ve igual que el mes pasado. Lo que cambia es más silencioso: los mismos tipos de historia reciben menos interacciones, los visitantes nuevos rechazan el aviso más a menudo, los endpoints empiezan a fallar y la base encoge casi todas las semanas aunque nada haya cambiado en el flujo de trabajo.

Si quiere la respuesta corta a "cómo reduzco la fatiga de notificaciones push": limite la exposición por persona y no por campaña, y aplique el límite antes del envío en lugar de leer sobre él después. El resto de esta página trata de cómo saber si tiene un problema de fatiga y qué cambiar realmente.

Cómo se ve la fatiga en la operación

La fatiga no es una sola cifra. Aparece como cuatro curvas distintas, y se mueven a velocidades distintas.

La curva de bajas. Bajas concentradas en las horas posteriores a un envío. Es la señal más rápida y la que todo el mundo ya tiene. Se queda muy corta, porque la mayoría de los suscriptores cansados nunca hace clic en darse de baja.

La curva de rechazo del permiso. La proporción de visitantes que rechaza su aviso. Sube cuando su marca le ha enseñado a la audiencia general que sus notificaciones no valen la pena, y es la única curva que daña la captación en lugar de la retención. El capítulo PWA del Web Almanac 2025, a partir de un rastreo de HTTP Archive de julio de 2025, informa que los usuarios de escritorio ignoran los avisos de notificaciones el 78 % de las veces, con una aceptación del 16 % en móvil. Es el comportamiento de los avisos en un rastreo, no en su sitio, pero marca la base contra la que trabaja.

La curva de rachas ignoradas. Personas que siguen suscritas, siguen recibiendo y no han interactuado con los últimos cinco, diez o veinte mensajes. Esta es la verdadera población fatigada, y casi ningún dashboard de push la muestra. Chrome afirma que menos del 1 % de todas las notificaciones recibe alguna interacción de los usuarios, lo que da una idea de lo grande que es este grupo en la web en su conjunto.

La curva de eliminación silenciosa. Suscripciones que desaparecen sin un clic en darse de baja. Algunas son dispositivos muertos y datos del navegador borrados. Otras son el navegador decidiendo por el lector.

Esa última es el cambio que convirtió la fatiga de una cuestión de cortesía en una cuestión de entrega.

El navegador ahora forma parte de su política de fatiga

Pasaron tres cosas, y ya están en vigor. Nada de esto es una previsión.

En octubre de 2025 Chrome lanzó la retirada automática del permiso de notificaciones para sitios con los que un usuario no ha interactuado recientemente, cuando el engagement es muy bajo y el volumen de notificaciones es alto. Chrome informa al usuario. El usuario puede volver a conceder el permiso en Safety Check o en el sitio, o desactivar la revocación automática. Las aplicaciones web instaladas no quedan revocadas por esta función. Se aplica en escritorio y Android.

En enero de 2026 Chrome empezó a desplegar límites de tasa en la Push API para sitios que envían muchas notificaciones con poco engagement en el sitio. Un sitio considerado disruptivo queda limitado a no menos de 1.000 mensajes por minuto, y las peticiones que exceden el límite reciben HTTP 429. Los factores diarios que nombra Chrome son mensajes push por tiempo en el sitio, solicitudes de permiso por tiempo en el sitio y engagement, medido como puntuación de engagement del sitio y minutos en primer plano. La escalada es de un día, luego siete días, luego catorce. El estado se reinicia tras 42 días consecutivos no disruptivos. Se aplica solo a la Push API, no a la Notifications API. Chrome afirma que casi ningún sitio web se verá afectado.

En agosto de 2026 Chrome Security describió el conjunto como una defensa en varias capas: revocación automática por bajo engagement y para sitios con advertencias repetidas de notificaciones sospechosas, detección por comportamiento de redes coordinadas de abuso, límites de tasa en el servidor de FCM y un modelo de permisos simplificado que incluye darse de baja con un toque en Android. Los usuarios revisan los permisos revocados en Safety Hub.

Vuelva a leer la lista de factores de los límites de tasa, porque es la frase más útil que un fabricante de navegadores ha publicado sobre este tema. Los factores son proporciones. No mensajes por día, sino mensajes por unidad de atención que usted se ganó de verdad. Un sitio que publica sin parar y retiene a los lectores en la página puede sostener un volumen que haría saltar las alarmas en un sitio con el mismo número de envíos y sin engagement.

Lo que no puede hacer es deducir el umbral. Chrome no publica su puntuación interna, y quien le diga que la replica está adivinando. Trate al navegador como un límite exterior firme y fije su propia política bien por dentro de él.

Cómo medir la fatiga en su propia lista

Esto es un procedimiento, no una referencia del sector. Usa datos que ya tiene en cualquier proveedor de push más su analítica, y puede tener la primera versión funcionando en una semana.

1. Fije el denominador

Defina de forma explícita qué es un suscriptor activo: un endpoint válido que ha recibido al menos un mensaje en los últimos 30 días y no ha devuelto un fallo permanente. Escriba la definición. La mayoría de las discusiones sobre el tamaño de la lista son en realidad discusiones sobre dos denominadores distintos.

2. Construya un registro por envío

Para cada envío, anote: audiencia elegible, entregados, interacciones, bajas en 24 horas y endpoints eliminados por inválidos en 24 horas. Cinco cifras por fila. Su proveedor tiene cuatro. La quinta suele requerir el registro de errores de entrega.

3. Construya un contador de exposición por suscriptor

Para cada suscriptor, guarde los mensajes recibidos en los últimos 7 días y los mensajes consecutivos sin interacción. Esos dos enteros son todo el modelo de fatiga que importa, y son lo que la mayoría de las plataformas no guarda.

4. Agrupe por racha de ignorados

Los límites de cada grupo son un punto de partida para una prueba, no una referencia medida. Lo que importa es que divida la lista, porque un promedio de toda la lista esconde la forma por completo.

5. Siga el movimiento neto de la lista cada semana

Nuevos permisos concedidos, menos bajas, menos endpoints inválidos eliminados. Represéntelo cada semana frente al volumen de envíos. Si la línea es negativa en las semanas de mucho volumen y positiva en las de poco volumen, ya tiene su respuesta, y la tiene en un formato que un editor aceptará.

Una advertencia honesta: ningún navegador le dice qué eliminación fue una revocación automática. Ve que el endpoint devuelve un fallo permanente, y el motivo se deduce, no se informa. No presente causas deducidas como si fueran medidas.

Lo que de verdad reduce la fatiga

Límites de frecuencia por suscriptor. Un tope de ocho envíos al día a nivel de sitio no dice nada de la persona que recibió los ocho. Limite lo que una persona recibe en un día y en una semana. Este único cambio suele hacer más que todo lo demás de esta lista.

Deduplicación por tema e historia. Que la misma historia llegue dos veces al mismo lector con dos titulares distintos es la forma de fatiga más evitable que existe. Deduplique sobre el contenido de fondo, no sobre la fila de la campaña, y añada un enfriamiento por tema para que una historia en desarrollo no ocupe toda la semana de un lector.

Horas de silencio. Los envíos rutinarios respetan una ventana de envío local con una zona horaria real. Entregar de noche compra un poco de alcance y mucho resentimiento, y es la forma más rápida de enseñarle a alguien a desactivar el canal entero.

Descanso tras rachas ignoradas. Deje de enviar a quien ha ignorado los últimos mensajes, y manténgalo suscrito mientras tanto. Un descanso es una decisión. No es una campaña fallida, y protege el permiso que ya pagó por conseguir.

Un umbral de valor. Algunos envíos no deberían ocurrir con ninguna frecuencia. Si el contenido es flojo, el número correcto de destinatarios es cero, y un tope con margen libre no es un motivo para llenarlo.

Una anulación explícita. Las noticias de última hora necesitan saltarse la política. Hágalo una decisión con nombre y registrada, en lugar de una excepción general, o en un mes cada historia será de última hora.

La fatiga va antes del envío, no en un informe

La mayoría de las herramientas de push pone la fatiga en la pestaña de analítica. Usted envía, y luego descubre lo que le costó. Para entonces el permiso ya no está y el coste de captación para reemplazarlo es real.

La versión que funciona trata la fatiga como una política que el envío tiene que superar. Los límites por suscriptor, el espaciado mínimo, las horas de silencio, las reglas de inactividad y un umbral de valor se evalúan en el momento del envío, los destinatarios no elegibles se eliminan antes de la entrega y el motivo queda registrado para que alguien pueda discutirlo después. Esa última parte importa más de lo que parece. En una redacción, la contención pierde todas las discusiones en las que no puede mostrar cifras.

Si quiere ponerlo por escrito en un formato portable, la Open Attention Policy es un formato JSON abierto para exactamente estos campos, con un validador con licencia MIT. Puede usarla con cualquier proveedor, incluido uno que no sea el nuestro.

Limitaciones y advertencias sobre navegadores

• Las plataformas de Apple se comportan de otra manera. Declarative Web Push llegó en Safari 18.4 el 31 de marzo de 2025 para aplicaciones web en la pantalla de inicio de iOS y iPadOS, con un payload JSON estandarizado y sin service worker instalado. Las señales de interacción de esos suscriptores no son idénticas a las de Chrome, así que no las junte en un único modelo de fatiga sin comprobarlo.
• Los límites de tasa de Chrome se aplican a la Push API, no a la Notifications API. Las notificaciones activadas localmente son otra superficie.
• No hay ninguna API entre navegadores que le diga por qué terminó una suscripción. Las eliminaciones silenciosas se deducen.
• Cada cifra de navegadores de esta página viene de Chrome, WebKit o HTTP Archive, con la fecha indicada arriba. EngageNudge no ha publicado una referencia de fatiga propia, y no vamos a inventarnos una para que una página parezca autorizada.

Cómo lo resuelve EngageNudge

EngageNudge evalúa la política de fatiga antes de que salga un Nudge, no después. Los límites de exposición diarios y semanales, el tiempo mínimo entre Nudges, las señales de racha de ignorados, la protección de lectores inactivos, los enfriamientos por tema, las horas de silencio y una anulación explícita para noticias de última hora son todos entradas de una única decisión de enviar u omitir, y una omisión se registra como decisión, no como error.

La puntuación de reputación ya está en su dashboard: una cifra con una banda, los factores que hay detrás y un email al propietario del espacio de trabajo cuando un sitio entra en zona de riesgo. Las pérdidas se desglosan por causa: baja, revocación del navegador, entrega fallida, para que una caída se pueda leer en lugar de adivinar. La puntuación es solo suya. No se publica en ninguna parte ni se comparte con otros sitios.