La versión corta
Estos dos canales se parecen porque los dos muestran mensajes breves en tu producto, pero están en lados opuestos de dos líneas: el alcance y el consentimiento. El web push sale de tu web y llega al dispositivo después de que el usuario concede un permiso del navegador. Los mensajes in-app se quedan dentro de una sesión activa y no necesitan ningún permiso aparte. Trátalos como dos herramientas, no como una.
Cómo funciona el web push
El web push se apoya en tres piezas del navegador que trabajan juntas: un service worker (un script en segundo plano que el navegador mantiene en ejecución), la Push API (que suscribe el navegador a un servicio de push y recibe los mensajes) y la Notifications API (que muestra la notificación del sistema). El usuario tiene que hacer clic explícitamente en Permitir en la solicitud de permiso del navegador; hasta que lo haga, no puedes enviar nada. Tras el opt-in obtienes un endpoint de suscripción y unas claves de cifrado, y tu servidor envía a través del servicio de push del navegador incluso con la pestaña cerrada. Como el mensaje llega fuera de tu web, el web push es el canal de reactivación del grupo: por su función, se parece más al SMS o al email que a cualquier cosa que viva dentro de tu app. El inconveniente: depende de la compatibilidad del navegador y del sistema operativo, y el usuario puede revocar el permiso en cualquier momento.
La salvedad de iOS
En iPhone y iPad, el web push no funciona en una pestaña normal de Safari. Apple añadió el web push solo para las web apps que el usuario ha añadido a la pantalla de inicio, a partir de Safari 16.4 (marzo de 2023). La solicitud de permiso debe llegar como respuesta a un toque directo —por ejemplo, un botón Suscribirse—, no al cargar la página. Así que en iOS tu audiencia alcanzable es el subconjunto de usuarios que instalaron tu sitio como web app y luego concedieron el permiso. Planifica teniendo en cuenta esa diferencia en lugar de dar por hecho que equivale al escritorio.
Cómo funcionan los mensajes in-app
Los mensajes in-app se muestran dentro de una sesión activa: un banner, un modal, un panel lateral o un tooltip que tu producto dibuja mientras el usuario lo está usando. No hay un opt-in aparte porque el usuario ya está en tu producto; el mensaje forma parte de la experiencia. La contrapartida es el alcance: el in-app solo llega a quienes están presentes en ese momento. No puede traer de vuelta a un usuario que se ha alejado, y un usuario que se ha ido nunca lo verá.
Cuándo usar cada uno
| Objetivo | Usa |
|---|---|
| Recuperar a un usuario inactivo | Web push (o email / SMS) |
| Anunciar una función a los usuarios activos | Banner o modal in-app |
| Guiar a un usuario nuevo en la configuración | Tooltip o panel lateral in-app |
| Avisar fuera de tu web de un evento urgente | Web push |
| Proponer un upgrade en mitad de una tarea | Modal in-app |
El reparto, siendo honestos: el in-app se ocupa de quienes ya están en la sala y el web push sale a buscar a los que se fueron. La mayoría de los productos usan los dos, coordinados dentro de un customer journey para que la misma persona no reciba un aviso in-app y un push por lo mismo con minutos de diferencia. Decidir qué canal lleva cada mensaje, en qué orden y sin solaparse es el paso de gestionar muchos canales a gestionarlos como uno solo, el tema de multicanal frente a omnicanal. Herramientas independientes como OneSignal o Novu se especializan en la entrega de push y notificaciones; una plataforma de customer engagement integra el push y el in-app en la misma lógica de journeys que el resto de tus canales.