Frecuencia de notificaciones push: ¿cada cuánto debería enviar un medio?

No hay un número correcto, y cualquier fuente que le dé uno sin nombrar su muestra está vendiendo algo. Lo que existe es un techo que impone el navegador, un presupuesto que fijan sus lectores y un mínimo que marca lo que vale un envío. Así puede encontrar su propio número.

La respuesta honesta es que depende, y lo útil es saber de qué depende.

No hay un número publicable sobre cada cuánto debería enviar notificaciones push un medio. Quien le cite "de dos a cinco al día para medios" está repitiendo un blog de un proveedor sin muestra identificada o promediando sitios que no tienen nada en común con el suyo. Lo que sí existe, y sobre lo que puede actuar hoy, es un techo que impone el navegador, un presupuesto que tienen sus lectores y un mínimo marcado por lo que realmente vale cada envío.

Dos frecuencias que se confunden

Casi todas las discusiones improductivas sobre la frecuencia del push vienen de mezclar estas dos.

Frecuencia del sitioFrecuencia por suscriptor
Qué cuentaEnvíos que salen de su cuenta al díaNotificaciones que recibe una persona al día
A quién le importaLa redacción, la mesa, el calendario de campañasAl lector, al navegador, a la salud de su lista
Quién la fijaEl ritmo de publicaciónLa segmentación, los topes y la elegibilidad
Efecto en la fatigaIndirectoDirecto

Una redacción que envía 20 veces al día y en la que un lector típico recibe dos es un producto completamente distinto de una que envía cuatro y en la que cada lector recibe las cuatro. La segunda es más agresiva, y el número de envíos del dashboard dice lo contrario.

Así que la pregunta "cada cuánto deberíamos enviar" son en realidad dos preguntas, y solo la segunda tiene una respuesta de fatiga. Fije primero el número por suscriptor. La frecuencia del sitio pasa entonces a ser un problema editorial y de segmentación, no de confianza de la audiencia.

El techo que Chrome impone de verdad

Esta parte no es una opinión, ni una previsión. Está en vigor desde 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, y 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.

Aparte de eso, desde octubre de 2025 Chrome retira automáticamente el permiso de notificaciones a los 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, que 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 se ven afectadas. Escritorio y Android.

De ahí se siguen dos cosas, y las dos cambian cómo debería pensar en el número.

Primero, la medida que se aplica es una proporción, no un recuento. Mensajes push por tiempo en el sitio. Solicitudes de permiso por tiempo en el sitio. Un sitio cuyos lectores se quedan y vuelven tiene más margen que un sitio con el mismo número de envíos y sin engagement, lo que significa que "cuántos al día" es la unidad equivocada y "cuántos por unidad de atención que nos ganamos" es la correcta.

Segundo, la aplicación es por sitio, pero la revocación automática es por persona. Una frecuencia que está bien en conjunto puede seguir retirando permisos en silencio a su tercio menos implicado.

No puede calcular su posición respecto al umbral de Chrome. La puntuación interna no se publica, y modelarla es adivinar. Fije su propio techo bien por dentro del suyo y deje de buscar el borde.

Por qué esta página no tiene una tabla de referencias por categoría

Podría poner aquí una tabla con una fila por sector y un número verosímil en cada una. Posicionaría. También sería inventada.

Solo publicamos datos de navegadores y de mercado a partir de un registro de afirmaciones fechado y con fuente primaria, y no hay ninguna fuente aprobada para "los medios envían X notificaciones al día". Los blogs de proveedores que publican tasas de opt-in y frecuencias de envío por país no indican un denominador, no describen una muestra y casi siempre miden su propia base de clientes. Las instantáneas de detección de tecnología le dicen qué sitios usan una plataforma de push, no con qué frecuencia envían esos sitios.

Así que esta página le da un marco en lugar de un número, y el resultado que produce es el suyo. Cualquier cifra que sí publiquemos lleva al lado su método y su fuente, sacados del registro de afirmaciones.

Un marco para encontrar su número

1. Empiece por el techo por suscriptor

Elija un máximo que una sola persona pueda recibir en un día y en una semana. Elíjalo a conciencia, escríbalo y conviértalo en la restricción dentro de la cual funciona todo lo demás. Si la redacción protesta, el número está haciendo su trabajo.

2. Fije un umbral de valor antes de fijar un recuento

Algunos envíos no deberían salir con ninguna frecuencia. Defina lo que una historia tiene que superar antes de convertirse en un Nudge: un umbral de confianza en el contenido, una regla por tipo de historia, lo que su mesa acepte. Un tope con margen libre no es una instrucción para llenarlo.

3. Separe lo rutinario de lo urgente, de forma explícita

Los envíos rutinarios viven dentro del tope, respetan las horas de silencio y se saltan a los suscriptores inactivos. Los envíos urgentes pueden romper el tope mediante una anulación con nombre que queda registrada. Si la anulación no se registra, en un mes todo es urgente. Lo he visto pasar.

4. Guíese por la calidad por envío, no por los envíos al día

El número que vale la pena colgar en la pared es lo que cuesta y devuelve un envío, no cuántos consiguió hacer.

Una versión que funciona: para cada envío, tome las interacciones por cada 1.000 entregados y reste las bajas y los endpoints inválidos por cada 1.000 entregados. Eso le da una cifra neta por envío que baja cuando empuja una historia floja a una audiencia amplia, que es exactamente el comportamiento que quiere que la métrica castigue. Este es nuestro marco, no un estándar del sector. Cambie las ponderaciones si su economía es distinta, pero mantenga la resta, porque una métrica sin un término de coste siempre va a defender enviar más.

5. Avance paso a paso y espere

Cambie el tope por suscriptor en uno, manténgalo de dos a cuatro semanas y observe el movimiento neto de la lista: nuevos permisos concedidos menos bajas menos endpoints inválidos. Una variable, el tiempo suficiente para ver cómo responde la lista. Los experimentos de frecuencia que duran cuatro días miden el ciclo de noticias, no su política.

La parte que es específica de los medios

Todo periodista quiere que su historia se envíe como push. Eso no es un defecto de la redacción, es la redacción funcionando como debe, y cada petición es razonable por sí misma.

El problema es que la persona responsable de la audiencia está discutiendo contra un montón de peticiones razonables una por una, y el único número en la sala es el recuento de clics del último envío. Los recuentos de clics siempre defienden enviar más. Nada en el dashboard estándar muestra lo que el envío costó en suscriptores, así que la contención llega con una opinión y pierde.

Ese es el argumento para llevar un registro por envío incluso antes de cambiar ninguna política. Clics, bajas, endpoints inválidos y movimiento neto de la lista en la semana, en una fila por envío. La discusión se convierte en aritmética, y con aritmética es mucho más fácil ganar.

Limitaciones y advertencias sobre navegadores

  • Los límites de tasa de Chrome se aplican a la Push API, no a la Notifications API, y Chrome afirma que casi ningún sitio se verá afectado. No los use para asustar a nadie y forzar un número.
  • Las plataformas de Apple son distintas. 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. La tolerancia a la frecuencia y las señales que recibe de vuelta no son idénticas a las de Chrome.
  • La mezcla de navegadores cambia lo que todo esto significa para usted. StatCounter informó la cuota mundial de navegadores de julio de 2026 como Chrome 68,22 % y Safari 16,47 %. Europa: Chrome 60,71 % y Safari 18,67 %. Suecia: Chrome 57,37 % y Safari 24,75 %. Una política de frecuencia ajustada al comportamiento de Chrome cubre una parte distinta de su lista en cada mercado.
  • Ninguna cifra de esta página es una medición de EngageNudge. El marco es nuestro, los datos de navegadores son de Chrome y WebKit, y las cifras de cuota son de StatCounter, todo con la fecha indicada arriba.

Cómo gestiona EngageNudge la frecuencia

En EngageNudge la frecuencia es una política que el envío tiene que superar, no un campo de la campaña. Los topes diarios y semanales por suscriptor, el espaciado mínimo entre Nudges, las horas de silencio, las reglas de inactividad y un filtro de envíos de poco valor se evalúan antes de la entrega, y un Nudge que no los supera se omite con el motivo registrado.

Los grupos de control (holdouts) están por debajo de todo eso, así que la pregunta "¿el envío extra trajo de verdad a alguien de vuelta?" tiene una respuesta que no es el recuento de clics.

Escrito por William Kim, fundador de EngageNudge. Revisado el 20 de agosto de 2026.