Blog · Producto
Cuántas notificaciones push enviar sin que la gente se dé de baja
No hay una cifra segura de avisos por semana. Separa los avisos por tipo, pon un tope bajo a los promocionales y mide las bajas de cada envío para ajustarlo.
No hay un número de notificaciones push por semana que sea seguro para todo el mundo: la gente se da de baja cuando un aviso no le sirve, no cuando recibe el quinto. Lo que sí funciona es separar los avisos por tipo, poner un tope bajo solo a los que decides tú y medir las bajas de cada envío para ajustar ese tope con tus propios datos.
En resumen:
- Los avisos que provoca el usuario (un pedido, una respuesta, una alerta que configuró) rara vez molestan; los que decides tú son los que hay que limitar.
- Empieza con un tope bajo para avisos promocionales o editoriales y súbelo solo si las bajas no se mueven.
- Deja que cada persona elija temas y ritmo, guarda sus preferencias como etiquetas y segmenta los envíos.
- Mide bajas, suscripciones caducadas y clics por envío y por tipo de aviso, no solo en el total del mes.
- Chrome puede retirar el permiso a sitios que envían mucho y reciben poca interacción: el exceso también cuesta alcance.
Por qué no hay un número mágico
La tolerancia de una persona depende de lo que esperaba al aceptar el permiso. Si tu web pidió permiso con un «te avisamos cuando cambie el estado de tu pedido», cuatro avisos en dos días (confirmado, enviado, en reparto, entregado) son exactamente lo prometido. Si un medio pidió permiso para «noticias importantes» y envía cuatro titulares genéricos al día, el mismo volumen se siente como ruido.
Por eso la pregunta útil no es «¿cuántas?», sino «¿la habría pedido esta persona si le preguntara ahora?». Si la respuesta es dudosa, ese envío resta: cada aviso irrelevante enseña a ignorar los siguientes, incluidos los importantes.
Además, el navegador también opina. Desde finales de 2025, Chrome en Android y escritorio retira automáticamente el permiso de notificaciones a sitios que combinan un volumen alto de avisos con muy poca interacción del usuario (las web apps instaladas quedan fuera). Google no publica los umbrales exactos, así que no hay una cifra «segura» a la que agarrarse: la única defensa es que tus avisos se abran.
Separa los avisos por tipo antes de fijar límites
Un solo límite para todo castiga a los avisos útiles o deja pasar demasiados promocionales. Clasifica primero:
| Tipo | Ejemplo | Quién lo dispara | Política razonable |
|---|---|---|---|
| Transaccional | Pago confirmado, pedido enviado | Una acción del usuario | Sin tope, pero sin duplicados |
| Alerta configurada | Bajada de precio, nueva respuesta | Una regla que eligió el usuario | Agrupar ráfagas en un resumen |
| Promocional o editorial | Oferta, novedad, artículo | Tú | Tope bajo por persona y semana |
Solo la tercera fila necesita un límite de frecuencia. Las otras dos dependen de eventos, pero tienen sus propios riesgos: un transaccional duplicado («tu pedido ha sido enviado» dos veces) genera desconfianza, y diez avisos de «nueva respuesta» en cinco minutos deberían llegar como uno solo: «Tienes 10 respuestas nuevas en tu hilo». Si trabajas avisos de pedidos o reservas, la guía de notificaciones transaccionales entra en detalle.
Empieza con un tope bajo y aplícalo en tu servidor
Una regla práctica para empezar (no es un estándar ni sale de ningún estudio): como máximo un aviso promocional al día y dos o tres por semana por persona, nunca de noche en su zona horaria. Es más fácil subir un tope que recuperar a quien ya bloqueó tu web.
El tope tiene que vivir en tu backend, justo antes de llamar a la API de envío, porque es ahí donde sabes qué recibió cada usuario. Un contador por persona y día basta:
// Antes de enviar un aviso promocional a un usuario
const day = new Date().toISOString().slice(0, 10); // fecha UTC
const key = `promo-cap:${userId}:${day}`;
const count = await redis.incr(key);
await redis.expire(key, 2 * 24 * 3600);
if (count > 1) return; // ya recibió su aviso promocional de hoy
// sendPush: tu función que llama a POST /v1/notifications
await sendPush({
to: { type: 'users', userIds: [userId] },
title: 'Envío gratis hasta medianoche',
url: 'https://tutienda.com/ofertas',
});Ten en cuenta una consecuencia: un envío a todo un segmento ({ "type": "segment", "tags": { … } }) es cómodo, pero no sabe cuántos avisos recibió cada persona esta semana. Si necesitas topes individuales, filtra primero en tu base de datos y envía con { "type": "users", "userIds": [ … ] }. Para la hora, guarda la zona horaria del usuario y lanza los envíos desde tu propio cron por franjas.
Deja que cada persona elija temas y ritmo
Muchas bajas no significan «no quiero nada», sino «quiero menos de esto». Si la única salida es el bloqueo, la gente la usa. Un pequeño centro de preferencias junto al botón de activar avisos cambia eso: pedidos siempre, ofertas «semanales» o «nunca», artículos del blog sí o no.
Esas preferencias encajan bien como etiquetas del suscriptor. Con el SDK de navegador de castly se guardan así (ojo: setTags reemplaza el conjunto completo, así que envía todas las claves):
// Al cambiar un interruptor del centro de preferencias
await Castly.setTags({ ofertas: 'semanal', blog: 'no' });Y al enviar, apuntas solo a quien eligió ese ritmo:
{
"to": { "type": "segment", "tags": { "ofertas": "semanal" } },
"title": "Las 5 ofertas de la semana",
"url": "https://tutienda.com/ofertas/semana"
}Ofrecer «menos» además de «ninguna» da una salida intermedia a quien solo quiere menos ruido. Tienes más ideas de este patrón en cómo segmentar con etiquetas.
Cuidado con las ráfagas al reconectar
Un detalle que infla la frecuencia percibida sin que cambies nada: si un dispositivo está apagado o sin conexión, el servicio push guarda los mensajes durante su TTL y los entrega todos juntos al reconectar. Un portátil cerrado todo el fin de semana puede recibir el lunes tres promociones seguidas, ya caducadas, aunque tú enviaste una al día.
Ajusta el TTL a la vida útil del mensaje: una oferta que termina en tres horas debería ir con "ttl": 10800, no con un día. Para avisos que no corren prisa, una urgencia low o very-low permite al dispositivo esperar a un momento mejor para entregarlos. Lo explicamos con más detalle en TTL y urgencia en web push.
Cómo medir si estás enviando demasiado
Las bajas llegan por tres vías distintas y conviene contarlas por separado:
- Bajas explícitas: la persona desactiva los avisos en tu interfaz. Las registras tú, por ejemplo escuchando el evento
unsubscribeddel SDK. - Permisos retirados: bloqueo desde los ajustes del navegador, el botón de darse de baja que Chrome puede mostrar en la propia notificación o la retirada automática. No recibes ningún aviso en ese momento: lo notas cuando el siguiente envío a ese dispositivo responde 404 o 410. En castly esa suscripción pasa a caducada y se dispara el webhook
subscriber.expired(detalles en la documentación de webhooks). - Silencio: el aviso se entrega, pero esa persona no hace clic en ninguno de los últimos envíos.
Con eso, sigue una métrica simple por tipo de aviso y por semana: suscripciones caducadas por cada 1.000 entregas, junto a la tasa de clics (clics entre entregas). Hay caducidades naturales (alguien borra los datos del navegador o cambia de equipo), así que lo importante no es el valor absoluto sino cómo se mueve cuando cambias la frecuencia. Como la caducidad solo se detecta al enviar, mira la tendencia de varias semanas, no la de un día.
Si quieres comparar dos ritmos de forma justa, asigna al suscribirse una etiqueta aleatoria cohorte: 'a' o 'b' y envía la promoción extra solo a la cohorte b durante un mes. castly no incluye tests A/B, pero las etiquetas, los registros por dispositivo de GET /v1/notifications/:id (enviado, entregado, clic) y los webhooks bastan para este experimento.
Preguntas frecuentes
¿Cuántas notificaciones push por semana son demasiadas?
Depende del tipo de aviso y de lo que prometiste al pedir permiso. Para avisos promocionales, son demasiadas cuando al subir la frecuencia aumentan las caducadas por cada 1.000 entregas y la tasa de clics cae. Empieza con un tope bajo y súbelo solo si esos dos indicadores aguantan.
¿Las notificaciones transaccionales cuentan para el límite?
No deberían, porque las provoca el propio usuario y las espera. Lo que sí debes evitar es duplicarlas por reintentos y agrupar las ráfagas de alertas en un único resumen.
¿Cómo sé si alguien bloqueó las notificaciones en el navegador?
El navegador no avisa a tu servidor. Lo descubres cuando el siguiente envío a ese dispositivo falla con 404 o 410, o cuando la persona vuelve a tu web y lees Notification.permission, que valdrá denied.
¿A qué hora conviene enviar los avisos no urgentes?
En el horario de día de cada persona, nunca de noche en su zona horaria. Guarda la zona horaria al suscribirse y lanza los envíos por franjas desde tu propio programador de tareas.
¿Chrome puede quitarle el permiso a mi web sin que el usuario lo pida?
Sí. Chrome en Android y escritorio retira el permiso a sitios con mucho volumen de avisos y muy poca interacción, informa al usuario y le deja restaurarlo. Las web apps instaladas no se ven afectadas, pero lo sensato es no depender de esa excepción.