Notificaciones multicanal en tu app a medida: push web, email y SMS sin volverte loco

Mandas un email importante y desaparece entre 200 correos sin leer. Lanzas una push y el navegador estaba cerrado. Envías un SMS y el usuario lo agradece, pero te cuesta diez céntimos por mensaje. Ningún canal por sí solo basta, y depender de uno es un riesgo de negocio.

Por eso, cuando alguien nos pregunta cómo implementar un sistema de notificaciones multicanal con push web, email y SMS integrados en tu aplicación a medida, la respuesta nunca es "elige el mejor". Es: combínalos bien, deja decidir al usuario y diseña la arquitectura para que añadir WhatsApp dentro de seis meses no te obligue a reescribir medio backend.

Te cuento cómo lo hacemos en proyectos reales.

Por qué un solo canal ya no te llega

Las bandejas de entrada están saturadas. Los filtros antispam tiran mensajes legítimos. Y una alerta urgente que espera tres horas a que el usuario abra Gmail deja de ser urgente.

Combinar canales no es redundancia. Es resiliencia:

• Si la push no aparece, queda el email.
• Si el email rebota, decides si el contenido merece un SMS.
• Si el usuario prefiere WhatsApp, le envías ahí y dejas en paz al resto.

¿La diferencia en métricas? En proyectos donde hemos pasado de email único a un esquema diversificado, las tasas de lectura suben entre un 30% y un 70%, según el sector. No es magia: es estar donde el usuario está.

La arquitectura que sí escala

El error más común que vemos es meter la lógica de envío directamente en el servicio que dispara el evento. Funciona dos meses. Luego, cuando quieres añadir un canal o cambiar de proveedor, toca tocar veinte archivos.

La regla es simple: separa el "qué ha pasado" del "cómo se comunica".

Tres piezas, ni una más

Event bus. Tu aplicación publica eventos de negocio: "pedido enviado", "factura vencida", "intento de login sospechoso". Una cola en Redis te puede valer al principio. Si esperas volumen serio, mira Kafka o RabbitMQ.

Cola de procesamiento. Aquí viven las notificaciones pendientes. Permite reintentos, garantiza que nada se pierda y aísla picos de carga. Si tu proveedor de SMS se cae diez minutos, los mensajes esperan en cola en lugar de perderse.

Dispatcher. El cerebro. Consulta las preferencias del usuario, decide canal y plantilla, y delega en el worker correspondiente. Cada canal tiene su propio worker con su propia cola, para que un fallo en email no bloquee las push.

El flujo, paso a paso

Un usuario cancela una suscripción. El servicio de facturación publica el evento. El servicio de notificaciones lo consume, busca al destinatario, elige plantilla y consulta preferencias. El dispatcher encola tareas en los canales activos. Cada worker procesa lo suyo y registra el resultado: entregado, rebotado, abierto.

Con esta separación, mañana añades Slack o WhatsApp creando un worker nuevo. Cero cambios en facturación.

Push web: gratis, potente, fácil de cargarte

Las push web son el canal con mejor relación coste-impacto. No pagas por mensaje y llegas al usuario aunque tenga la pestaña cerrada. El problema es que casi todo el mundo las implementa mal.

Necesitas dos piezas: un Service Worker corriendo en segundo plano y la Web Push API para enviar desde tu servidor con claves VAPID firmadas.

El flujo técnico es directo:

1. Registras el Service Worker al cargar la app.
2. Pides permiso al usuario, nunca al entrar por primera vez. Espera a que haga algo significativo: completar un perfil, ver tres páginas, dar un like.
3. Llamas a PushManager.subscribe() y guardas el endpoint en tu backend, asociado al usuario y dispositivo.
4. Cuando quieres notificar, tu servidor envía un POST firmado al endpoint.
5. El Service Worker recibe el evento push, muestra la notificación y captura el clic con notificationclick.

El error letal: pedir permiso nada más entrar. Si el usuario rechaza, ese navegador queda quemado para siempre. Pídelo cuando ya entiende el valor que le das.

Y limpia tu base de suscripciones. Cada mes, una parte caduca, cambia o se desinstala. Si no purgas, tu tasa de error sube y los proveedores te penalizan.

Email: olvídate de montar tu propio SMTP

El email sigue siendo insustituible para resúmenes, confirmaciones, facturas adjuntas y cualquier comunicación que el usuario quiera archivar. Pero no intentes enviarlo desde tu servidor.

Las opciones serias son tres:

• Amazon SES si ya estás en AWS. Coste irrisorio, configuración algo árida.
• SendGrid si quieres una API cómoda, plantillas decentes y analítica integrada.
• Postmark si tu volumen no es enorme y la entregabilidad es prioridad absoluta.

Para entregabilidad real, no hay atajos: configura SPF, DKIM y DMARC en tu dominio. Tres registros DNS que la mitad de las empresas tiene mal puestos. Si tu DMARC no está alineado, Gmail y Outlook te mandan a spam sin avisar.

Separa diseño y contenido con MJML o Handlebars. Tu equipo de marketing podrá cambiar copys sin pedirte un deploy, y tú podrás cambiar el HTML sin romper sus textos.

Y dale de baja al instante a quien rebote duro. Mantener una lista limpia es lo que separa una reputación de envío sana de una IP en blacklist.

SMS: caro, brutal, úsalo con cabeza

El SMS tiene una tasa de apertura superior al 95% y se lee en los primeros tres minutos. Es el canal perfecto para códigos de verificación, alertas críticas y poco más. ¿Por qué poco más? Porque a 4-8 céntimos por mensaje, mandar promos por SMS arruina la cuenta de explotación.

Los proveedores habituales son Twilio (el estándar de facto), Vonage (mejor para cobertura internacional) y AWS SNS (barato si ya vives en AWS).

Tres cosas a vigilar:

• Formatea siempre los números en E.164 antes de enviar. Un "+34 600..." mal escrito te cuesta el envío.
• Gestiona los webhooks de estado de entrega. Sin eso, mandas a ciegas.
• Cuidado con los 160 caracteres. Si te pasas, el mensaje se fragmenta y pagas el doble o el triple.

Y por favor, consentimiento explícito antes de mandar nada comercial. La ley es clara y las multas, dolorosas.

Preferencias del usuario: el detalle que marca la diferencia

Aquí es donde un sistema bueno se separa de uno malo. Da al usuario un panel donde pueda activar y desactivar cada canal por separado, elegir qué tipos de avisos quiere (seguridad, producto, marketing) y definir horarios de silencio.

Define también una jerarquía de fallback configurable por tipo de notificación. Una alerta de fraude sigue la cascada completa: push, email y SMS si los anteriores fallan. Una promo, en cambio, se queda en email y punto.

¿Suena obvio? Lo es. Y aun así, nueve de cada diez apps que auditamos no lo tienen bien resuelto.

Timing, deduplicación y otras manías necesarias

Mandar la notificación adecuada por el canal adecuado no sirve de nada si llega a las tres de la mañana o se repite cinco veces.

Respeta las zonas horarias. Un SMS a deshora no es solo molesto: rompe la confianza y dispara las bajas. Agrupa eventos cuando tenga sentido: cinco cambios de estado en diez minutos se cuentan mejor en un resumen único. Y pon límites de frecuencia por canal y por tipo, aunque el evento técnicamente lo justifique.

Para deduplicar, genera un hash con evento + usuario + canal y mantén una ventana de tiempo configurable. Si ya enviaste esa notificación hace cinco minutos, descártala. Te ahorrarás muchas disculpas.

Monitoriza o no existe

Un sistema de notificaciones que nadie mira falla en silencio. Y los fallos silenciosos son los caros.

Mide para cada canal la tasa de entrega, de apertura, de clic y de rebote. Monta un dashboard con el estado en vivo y configura alertas cuando algo se sale del rango normal. Si tu tasa de entrega de email cae del 98% al 85% un martes a las once, quieres enterarte antes de que te lo cuente un cliente.

Para los fallos, tres categorías:

• Transitorios (timeout, 503): reintenta con backoff exponencial.
• Permanentes (número inválido, email inexistente): marca el canal como muerto para ese usuario.
• Fallos de proveedor: ten un secundario configurado para canales críticos. Twilio cayendo un viernes por la tarde no puede tumbar tus 2FA.

El siguiente paso

Un buen sistema multicanal no se nota. Los usuarios reciben lo que necesitan, por donde lo necesitan, sin saturarse. Pero detrás de saber cómo implementar un sistema de notificaciones multicanal con push web, email y SMS integrados en tu aplicación a medida hay decisiones de arquitectura que, si no tomas bien al principio, te van a doler durante años.

Si estás diseñando o reescribiendo tu app y quieres montar la capa de notificaciones desde una base sólida, hablemos de tu proyecto con el equipo de Tangram y vemos qué arquitectura encaja con tu volumen, tus canales y tu hoja de ruta.

El consejo que más repetimos: empieza desacoplado aunque hoy solo envíes emails. Cuando dentro de un año añadas push o SMS, agradecerás haber puesto el bus de eventos desde el primer día.