¿Cómo funciona un mensaje in-app?
El SDK de tu producto hace el trabajo. Los mensajes se asocian a condiciones de activación (un evento concreto, una página vista, la pertenencia a un segmento) y se muestran directamente en la interfaz cuando se cumplen. Como la entrega se apoya en código que ya ejecutas, no hay solicitud de permiso ni suscripción; a cualquiera que esté activo en el producto se le puede mostrar uno. Herramientas como Braze sincronizan los mensajes aplicables con el dispositivo al iniciar la sesión y luego dejan que las reglas de entrega y los límites de frecuencia decidan qué aparece de verdad.
Mensaje in-app o web push: ¿qué diferencia hay?
Una notificación web push llega a las personas fuera de tu sitio, a través del sistema de notificaciones del navegador, pero solo después de que concedan un permiso explícito, algo que muchas rechazan. Un mensaje in-app es justo lo contrario: no necesita permiso, pero no llega a nadie que se haya ido. Los dos canales cubren el punto ciego del otro: el push hace volver a la gente y el in-app la guía cuando llega. La guía de web push y mensajes in-app explica cómo gestionarlos como un solo programa.
¿Cuándo conviene usar un mensaje in-app?
Siempre que la persona a la que quieres llegar ya esté en el producto: listas de pasos de onboarding, anuncios de funciones, invitaciones a mejorar el plan, consejos contextuales, encuestas breves. Los mensajes in-app también funcionan bien como pasos de un customer journey más amplio: por ejemplo, un tooltip que solo aparece para quien llegó al panel pero nunca creó un proyecto. La segmentación es lo esencial; un mensaje que ve todo el mundo es solo interfaz.
¿Qué límites tienen los mensajes in-app?
- Alcance limitado a la sesión: alguien que se ha ido o está inactivo nunca verá uno; la recuperación corresponde al email, al SMS o al push.
- Costo de atención: un modal en el momento equivocado interrumpe trabajo real; usa por defecto banners y tooltips, y sube de nivel solo cuando el mensaje lo justifique.
- Riesgo al renderizar: el contenido se inserta en una página activa, así que la plataforma debe sanear el HTML del mensaje; un renderizado a prueba de XSS es un requisito, no una función extra.
- Sin archivo: una vez cerrado, el mensaje desaparece; todo lo que la persona pueda necesitar más tarde también debe ir en un email o en la documentación.