Blog · Producto
Notificaciones push o email: cuándo usar cada canal
Push para lo urgente y breve, email para lo que hay que conservar. Una tabla por caso de uso y dos patrones para combinar ambos canales sin duplicar avisos.
Usa la notificación push para lo que es corto, urgente y pierde valor con las horas, y el email para lo que hay que conservar, leer con calma o hacer llegar aunque la persona no tenga ningún dispositivo suscrito. La mayoría de productos necesitan los dos canales: lo importante es decidir, mensaje a mensaje, cuál va por cada uno y no mandar lo mismo dos veces sin motivo.
En resumen:
- La push llega a un navegador concreto que dio permiso; el email llega a una persona, en cualquier dispositivo.
- Elige push si el mensaje deja de servir mañana y pide una acción breve ahora.
- Elige email para facturas, recuperación de contraseña, contenido largo y avisos que deben quedar por escrito.
- Combínalos con reglas: push si el usuario tiene dispositivos activos, email como respaldo o como registro.
- Un mal uso de la push se paga caro: retirar el permiso desactiva el canal entero de un clic.
Qué diferencia de verdad a los dos canales
La diferencia de fondo no es el formato, sino el destinatario. Una suscripción push identifica a un navegador en un dispositivo: si alguien usa tu producto en el portátil y en el móvil, puede tener dos suscripciones, una o ninguna. Una dirección de email identifica a una persona y la sigue a cualquier dispositivo. De ahí salen casi todas las demás diferencias.
| Aspecto | Notificación push web | |
|---|---|---|
| Requisito | Permiso del navegador; en iPhone y iPad, además, la web instalada en la pantalla de inicio (iOS 16.4 o posterior) | Una dirección válida |
| Tamaño | Título y texto cortos; el estándar garantiza al menos 4096 bytes de carga cifrada | Largo, con formato y adjuntos |
| Permanencia | Desaparece al tocarla o descartarla | Queda en la bandeja, se busca y se archiva |
| Momento | Segundos si el dispositivo está conectado; si no, espera el tiempo que marque el TTL | Cuando la persona abre su correo |
| Baja | Un interruptor en los ajustes del navegador; no te enteras hasta el siguiente envío | Un enlace de baja, normalmente por tipo de mensaje |
Fíjate en la última fila. Con el email, la persona suele darse de baja de un tipo de comunicación y conserva el resto. Con la push, si se cansa, revoca el permiso y pierdes todos los avisos de ese navegador a la vez, incluidos los útiles.
Cuándo gana la notificación push
La push gana cuando el mensaje tiene fecha de caducidad corta y la acción que pide cabe en un toque. Una buena prueba: si el aviso llegara mañana por la mañana, ¿seguiría sirviendo? Si la respuesta es no, es un candidato claro a push.
- Mensajería y colaboración: alguien te ha respondido en un hilo o te ha mencionado en un documento.
- Estado de un pedido en tiempo real: «Tu pedido sale ahora del almacén» o «El repartidor está a 5 minutos».
- Alertas operativas: un despliegue ha fallado o un monitor ha detectado una caída.
- Recordatorios cercanos: «Tu cita empieza en 30 minutos».
- Cambios con plazo: ha bajado el precio de un producto guardado y quedan pocas unidades.
En todos estos casos conviene ajustar el tiempo de vida del mensaje para que no llegue cuando ya no tenga sentido. Lo explicamos en la guía sobre TTL y urgencia en web push.
Cuándo gana el email
El email gana cuando el mensaje tiene que durar, ser largo o demostrar algo. Nadie busca en su centro de notificaciones una factura de hace tres meses, y la push no sirve para verificar identidad.
- Registros y documentos: facturas, recibos, contratos, cambios en las condiciones de uso.
- Verificación de identidad: confirmar una dirección o restablecer una contraseña. El objetivo es demostrar que la persona controla ese buzón, y una push no lo demuestra.
- Contenido largo: newsletters, resúmenes semanales, informes con tablas o enlaces múltiples.
- Usuarios sin suscripción: quien no ha dado permiso, usa un navegador sin soporte o tiene un iPhone sin la web instalada. En iOS y iPadOS la push web solo está disponible para webs añadidas a la pantalla de inicio, como detalla el anuncio oficial de WebKit.
Hay un matiz de privacidad: el texto de una push puede verse en la pantalla bloqueada. No pongas importes, códigos ni datos personales en el título o el cuerpo; usa la push como aviso («Tienes un nuevo pago») y deja los detalles detrás del inicio de sesión.
Una tabla de decisión por caso de uso
Esta tabla resume cómo repartiríamos los mensajes más habituales. No es una regla universal, pero sirve como punto de partida para revisar los avisos de tu producto uno a uno.
| Mensaje | Canal | Por qué |
|---|---|---|
| Nuevo mensaje en un chat | Push; email solo como resumen si sigue sin leer horas después | Pierde valor rápido |
| Pedido enviado | Ambos | Push en el momento; email con el seguimiento como registro |
| Restablecer contraseña | Solo email | Verifica el control del buzón |
| Factura mensual | Solo email | Documento que hay que conservar |
| Bajada de precio con stock limitado | Push | Plazo corto, acción de un toque |
| Inicio de sesión desde un dispositivo nuevo | Ambos | Urgente y conviene que quede constancia |
| Resumen semanal de actividad | Largo y sin prisa |
Cómo combinarlos sin duplicar avisos
El patrón más útil es enrutar por disponibilidad: antes de avisar, comprueba si la persona tiene algún dispositivo suscrito y activo. Si lo tiene, push; si no, email. Con castly puedes hacerlo con el listado de suscriptores filtrado por tu ID de usuario y enviar después al destino users, que alcanza todos sus dispositivos. Los parámetros están en la referencia de la API.
const API = 'https://castly.sh/v1';
const headers = {
Authorization: `Bearer ${process.env.PUSH_SECRET_KEY}`,
'Content-Type': 'application/json',
};
async function notify(user, msg) {
const res = await fetch(
`${API}/subscribers?userId=${encodeURIComponent(user.id)}&status=active&limit=1`,
{ headers }
);
const { data } = await res.json();
if (data.length === 0) return sendEmail(user.email, msg); // tu proveedor de email
await fetch(`${API}/notifications`, {
method: 'POST',
headers,
body: JSON.stringify({
to: { type: 'users', userIds: [user.id] },
title: msg.title,
body: msg.body,
url: msg.url,
}),
});
}El segundo patrón es push primero y email de respaldo: si nadie ha tocado la notificación en unas horas, envías el email. castly no envía emails ni programa envíos, así que el temporizador vive en tu backend: guardas el envío, escuchas el webhook notification.clicked para marcarlo como visto y una tarea revisa después los que siguen pendientes. Como los webhooks son de mejor esfuerzo y no se reintentan, un clic no registrado puede provocar un email de más; para mensajes de bajo riesgo es un coste aceptable.
Y deja elegir a la gente. Un panel de preferencias con categorías («actividad de mi equipo», «novedades del producto») y canal por categoría reduce las bajas en los dos canales.
Preguntas frecuentes
¿Puede la notificación push sustituir al email en mi producto?
No del todo. La push no llega a quien no está suscrito, no deja un registro duradero y no verifica identidad. Sí puede sustituir a muchos emails cortos y urgentes que hoy se pierden en la bandeja.
¿Qué pasa si el dispositivo está apagado cuando envío la push?
El servicio push guarda el mensaje durante el TTL que indiques y lo entrega cuando el dispositivo se conecta. Si el TTL vence antes, se descarta sin avisarte. El email, en cambio, espera en la bandeja indefinidamente.
¿Debo mandar el mismo aviso por los dos canales a la vez?
Solo cuando importan a la vez la inmediatez y el registro, como en una alerta de seguridad o un pedido enviado. En el resto de casos, duplicar solo añade ruido y empuja a la gente a desactivar uno de los dos.
¿Qué canal tiene mejor tasa de clics?
No hay una cifra universal que valga para todos los productos, así que desconfía de las comparativas genéricas. Mide tus propios avisos; para la push, calcula los clics sobre las notificaciones entregadas, como explicamos en cómo medir la tasa de clics.
¿Necesito un consentimiento distinto para cada canal?
El permiso del navegador es el requisito técnico de la push y se pide por separado. La base legal para comunicaciones comerciales depende de tu jurisdicción y no se hereda de un canal a otro, así que revísala para cada uno.