Usa las notificaciones push para mensajes breves y urgentes que tienen que llegarle a alguien que no está en tu app, los mensajes in-app para todo lo que esté ligado a lo que el usuario está haciendo en ese momento, y el email para el detalle, los registros y las personas que dejaron de abrir la app. Los tres canales no compiten: el push trae a la gente de vuelta, el in-app la guía una vez que está ahí, y el email lleva todo lo que haya que conservar o leer con calma.
Push vs email vs in-app: ¿cómo se comparan los tres canales?
Cada canal se define por dónde aparece el mensaje y quién puede recibirlo. Todo lo demás se desprende de esos dos hechos.
| Notificación push | Mensaje in-app | ||
|---|---|---|---|
| Dónde aparece | Pantalla de bloqueo, banner y centro de notificaciones, fuera de la app | Dentro de la app, durante una sesión | La bandeja de entrada del usuario, fuera de la app |
| Quién puede recibirlo | Usuarios que tienen la app instalada y permitieron las notificaciones | Usuarios que abren la app | Cualquier persona cuya dirección de email tengas y que no se haya dado de baja |
| ¿La app tiene que estar abierta? | No | Sí | No |
| ¿El usuario tiene que permitirlo antes? | Sí, mediante un aviso del sistema | No | Tiene que darte una dirección y puede darse de baja |
| Cuánto puede decir | Un título y una o dos líneas | Desde una oración hasta una pantalla completa, con botones e imágenes | Todo lo que necesites |
| Cuánto dura | Hasta que se descarta o queda sepultada por notificaciones más nuevas | Hasta que el usuario lo cierra, salvo que construyas una bandeja de entrada | Hasta que el usuario lo elimina o lo archiva |
| Qué tan intrusivo es | Alto | Medio, el usuario ya está participando | Bajo, se lee cuando el usuario decide |
| Para qué sirve mejor | Traer al usuario de vuelta por algo que está pasando ahora | Guiar, anunciar o invitar a actuar en contexto | Explicar, confirmar, resumir, recuperar |
| Riesgo principal | Los usuarios desactivan las notificaciones | Nunca lo ven los usuarios que no regresan | Queda sin leer o cae en la carpeta equivocada |
¿Cuál es la diferencia entre las notificaciones push y las notificaciones in-app?
Una notificación push la entrega el sistema operativo del teléfono y aparece fuera de tu app. Una notificación in-app la dibuja tu propia app y aparece solo mientras alguien la está usando. Esa única diferencia decide quién ve el mensaje, cuándo, y si tuvo que aceptarlo antes.
Dónde aparece cada una
Las notificaciones push se envían al dispositivo a través de los servicios de entrega de Apple y de Google, y ahí el sistema las muestra en la pantalla de bloqueo, como banner o en el centro de notificaciones. Tu app no necesita estar en ejecución.
Las notificaciones in-app son parte de tu interfaz. Firebase In-App Messaging, la herramienta de Google para esto, describe su función como enviar mensajes segmentados y contextuales a los usuarios activos de tu app, y los ofrece como tarjetas, banners, modales o imágenes. Los tooltips, las pantallas completas y una bandeja de notificaciones dentro de la app son variaciones comunes de la misma idea.
Quién puede recibir cada una
El push solo llega a las personas que dijeron que sí. En iOS, la documentación para desarrolladores de Apple indica que debes obtener permiso para usar notificaciones, y que el sistema le muestra el aviso a la persona la primera vez que tu app lo solicita y no vuelve a mostrarlo en solicitudes posteriores. En Android, la documentación de Google indica que en Android 13 o superior las notificaciones de una app están desactivadas de forma predeterminada hasta que el usuario concede el permiso.
Los mensajes in-app no necesitan ningún permiso del sistema, porque simplemente son parte de la app. El límite es otro: un usuario que nunca abre la app nunca los ve.
Así que las dos audiencias se superponen, pero no son la misma. El push llega a los usuarios que tienen la app instalada y permitieron las notificaciones, estén activos o no. El in-app llega a los usuarios activos, hayan permitido las notificaciones o no.
Qué pasa después de que se ve el mensaje
Una notificación push se pierde con facilidad. Un deslizamiento la borra, y un centro de notificaciones lleno la sepulta. Un mensaje in-app puede ser igual de breve (un banner que desaparece) o puede quedar guardado, si construyes una bandeja de entrada o un feed de notificaciones donde los mensajes anteriores sigan disponibles. Si el usuario puede necesitar la información la próxima semana, ni un push ni un banner pasajero bastan por sí solos.
Notificaciones push vs in-app: ¿cuándo deberías usar cada una?
Usa push cuando el usuario no está y el mensaje no puede esperar. Usa in-app cuando el mensaje solo tiene sentido en el contexto de lo que el usuario está haciendo, o cuando puede esperar hasta su próxima visita.
Cuándo el push es la opción correcta
- Algo está pasando ahora o está por pasar: una sesión en vivo que empieza, una entrega que llega, una oferta que fue superada.
- Otra persona hizo algo que al usuario le importa: una respuesta, una mención, un amigo que se une.
- Un recordatorio que el usuario pidió: un entrenamiento, una lección, la hora de un medicamento.
- Una alerta breve de la cuenta, como una renovación que falla, con el detalle enviado también por email.
El push es la opción equivocada para cualquier cosa larga, cualquier cosa que no sea oportuna y la promoción general. La guía de Apple sobre la gestión de notificaciones dice que no uses las notificaciones para contenido de marketing o promocional a menos que las personas hayan aceptado explícitamente recibirlo, y que reserves su nivel Time Sensitive para eventos que ocurren ahora o dentro de la próxima hora.
Cuándo el in-app es la opción correcta
- Pasos de onboarding y consejos relacionados con la pantalla en la que está el usuario.
- Anunciar una función en el punto donde resulta útil.
- Invitaciones a mejorar de plan y paywalls, mostrados cuando el usuario llega a un límite.
- Encuestas y solicitudes de opinión, justo después de la experiencia sobre la que estás preguntando.
- Invitaciones de referidos, en un momento en que el usuario está contento con la app.
El in-app es la opción equivocada para llegar a personas que se fueron alejando, y para cualquier cosa sobre la que el usuario deba actuar fuera de la app.
Notificación push vs email: ¿cuál deberías enviar?
Envía un push cuando el valor del mensaje está en el momento. Envía un email cuando el valor está en el contenido. Si un mensaje sería inútil mañana, es un push. Si el usuario puede querer encontrarlo de nuevo dentro de un mes, es un email.
Lo que el email hace y el push no puede
- Perdura. Los recibos, los avisos de renovación, los restablecimientos de contraseña y los cambios en tus términos pertenecen a un lugar donde el usuario pueda buscarlos después.
- Lleva detalle. Un registro de cambios, un resumen semanal de progreso o una guía paso a paso no caben en una notificación.
- Llega a personas sin la app. A alguien que la desinstaló, cambió de teléfono o nunca permitió las notificaciones todavía se le puede contactar por email.
- Funciona en cualquier dispositivo. El usuario puede leerlo en un escritorio y actuar desde ahí.
Lo que el push hace y el email no puede
- Llega a la pantalla de bloqueo en instantes, sin que el usuario abra nada.
- Abre la app en la pantalla correcta con un toque.
- Se adapta a una sola invitación breve, donde un email se sentiría pesado.
Lo que el email necesita de ti
El email tiene sus propios requisitos de entrada. Los proveedores de correo esperan que los remitentes autentiquen su dominio de envío: las directrices de Google para remitentes de email piden a todos los remitentes que configuren SPF o DKIM, y piden que los mensajes de marketing admitan la baja con un clic. Un email que no está bien configurado puede no llegar nunca a la bandeja de entrada, lo que equivale, en email, a que un usuario desactive las notificaciones.
Mensajes que merecen ambos
Algunos mensajes son urgentes y detallados a la vez. Un pago fallido es el ejemplo habitual: envía un push breve para que el usuario se entere hoy, y un email con el monto, la fecha y el enlace para solucionarlo. El push se encarga de avisar, el email se encarga de explicar. Evita enviar un texto idéntico por ambos, porque el usuario lo leerá dos veces y aprenderá a saltarse uno de ellos.
¿Cómo eliges un canal para un mensaje específico?
Haz tres preguntas en orden y detente en la primera que te dé una respuesta.
- ¿Solo tiene sentido dentro de la app, en un momento en particular? Usa in-app.
- ¿Pierde su valor en cuestión de horas? Usa push, con in-app como respaldo para los usuarios que tienen las notificaciones desactivadas.
- ¿Necesita detalle, o el usuario va a querer conservarlo? Usa email.
Si un mensaje no pasa ninguna de las tres, quizá no haga falta enviarlo.
Así se aplica a los mensajes que envía la mayoría de las apps:
| Mensaje | Primera opción | Agrega un segundo canal cuando |
|---|---|---|
| Alguien te respondió | Push | Muéstralo in-app si el usuario está en una sesión |
| La prueba termina mañana | Push | Email el mismo día con lo que pasa después |
| Recibo de compra | Confirma en pantalla justo después de la compra | |
| Restablecimiento de contraseña | Nunca, mantenlo en un solo lugar | |
| Función nueva | In-app | Email a los usuarios que no han abierto la app recientemente |
| Invitación a mejorar de plan | In-app | Rara vez, una oferta por email para usuarios de prueba que no continuaron |
| Resumen semanal o mensual | Un push solo si el usuario lo pidió | |
| Encuesta de opinión | In-app | Email para encuestas de investigación más largas |
| Recuperar a un usuario inactivo | Push si todavía tiene las notificaciones activadas | |
| Invitación a referir a un amigo | In-app | Email como seguimiento con su enlace |
¿Cómo usas email, push e in-app juntos sin molestar a los usuarios?
Decide el orden de los canales para cada mensaje, envía primero por el menos intrusivo y solo escala para las personas que no lo han visto. Enviar todo por todos lados al mismo tiempo es la forma más rápida de perder el permiso de push.
Envía en cascada en lugar de difundir a todos
Toma el lanzamiento de una función como ejemplo práctico. Podrías:
- Mostrar un anuncio in-app a todos los que abran la app en la primera semana.
- Enviar un email a los usuarios que no abrieron la app en esa semana, con la explicación completa.
- Enviar un push solo a los usuarios que no vieron ninguno de los dos, y solo si la función es algo por lo que te darían las gracias.
Cada paso omite a las personas a las que el paso anterior ya llegó. El mismo patrón funciona en la dirección contraria para los mensajes urgentes: primero push, luego in-app en la siguiente sesión, luego email si el asunto sigue pendiente.
Pide el permiso de push en un momento sensato
Como iOS muestra su aviso de permiso una sola vez, el momento de esa primera solicitud importa más que cualquier optimización posterior. Apple sugiere hacer la solicitud en contexto, por ejemplo después de que alguien programa su primera tarea en una app de tareas, para que las personas puedan ver para qué sirven las notificaciones. Google da un consejo similar para Android y sugiere que el aviso siga a una acción del usuario, como tocar un ícono de campana o hacer un pedido.
Deja que los usuarios elijan por tema, no todo o nada
Si el único interruptor que tiene un usuario es "desactivar todas las notificaciones", ese es el que va a usar. Dale categorías. En Android esto viene integrado: los canales de notificaciones permiten a los usuarios cambiar la configuración de cada tipo de notificación que envía tu app, y una vez creado un canal, su comportamiento queda bajo el control del usuario. En iOS, Apple pide a las apps que envían notificaciones informativas o de marketing que ofrezcan una pantalla de configuración dentro de la app donde las personas puedan cambiar su elección. Haz lo mismo con el email, con opciones separadas para novedades del producto, resúmenes y ofertas.
¿Qué canal funciona mejor para las invitaciones de referidos y las novedades para afiliados?
Las invitaciones de referidos funcionan mejor in-app, y las novedades para afiliados o socios funcionan mejor por email, porque las dos audiencias están en lugares distintos.
Es más probable que un usuario comparta tu app justo después de que esta hizo algo por él: una racha completada, una meta alcanzada, un proyecto terminado. Ese momento solo existe dentro de la app, así que la invitación pertenece ahí, con un botón de compartir que abra el menú de compartir del teléfono. Tenemos un artículo aparte sobre cómo convertir a los usuarios en afiliados con referidos in-app. Si prefieres no construir la pantalla tú mismo, los referidos in-app de Insert Affiliate incluyen una pantalla Recomienda a un amigo lista para usar que le da a cada usuario su propio código y enlace con botones Copy y Share. Hay un resumen en la página del programa de referidos para apps móviles.
Los afiliados y los creadores son distintos. No viven en tu app, y lo que necesitan (una oferta nueva, un cambio de comisión, sus resultados del mes) es detalle que van a querer volver a consultar. Ese es el trabajo del email, idealmente respaldado por una bandeja de entrada a la que puedan entrar con su cuenta. Así funciona la mensajería con afiliados en Insert Affiliate: un mensaje directo o una difusión a todos los afiliados se envía como notificación por email y también aparece en la sección Mensajes del panel del afiliado. Los afiliados pueden dejar de recibir los emails de difusión y seguir recibiendo los mensajes directos, que es el mismo principio de "elegir por tema" descrito arriba. Lectura relacionada: mantener la comunicación con afiliados en un solo lugar.
Preguntas frecuentes
¿Las notificaciones in-app son lo mismo que las notificaciones push?
No. Una notificación push la entrega el sistema operativo y aparece fuera de la app, en la pantalla de bloqueo o en el centro de notificaciones. Una notificación in-app la muestra la propia app y solo se puede ver mientras la app está abierta. A menudo las dispara el mismo evento, y la app elige una u otra según si el usuario está en una sesión en ese momento.
¿Las notificaciones in-app necesitan el permiso del usuario?
No se necesita ningún permiso del sistema, porque los mensajes in-app son parte de tu propia interfaz. El push es distinto: iOS exige que el usuario permita las notificaciones, y en Android 13 o superior las notificaciones están desactivadas de forma predeterminada hasta que el usuario concede el permiso.
¿El push es mejor que el email?
Ninguno es mejor en general. El push es mejor para mensajes breves cuyo valor depende del momento, y puede abrir la app con un toque. El email es mejor para el detalle, para todo lo que el usuario necesita conservar, y para las personas que ya no tienen la app o tienen las notificaciones desactivadas.
¿Qué canal debería usar para reactivar a los usuarios inactivos?
Empieza por el email, porque no depende de que la app esté instalada ni de que las notificaciones estén permitidas. El push puede funcionar con los usuarios que todavía tienen las notificaciones activadas, siempre que el mensaje ofrezca una razón real para volver. Los mensajes in-app no pueden ayudar aquí, ya que los usuarios inactivos no los van a ver.
¿Qué debería hacer con los usuarios que desactivaron las notificaciones push?
Trata el in-app y el email como tus respaldos. Muestra el mensaje in-app en su siguiente sesión, y envía un email cuando no pueda esperar tanto. Si el push claramente les ayudaría, explica el beneficio dentro de la app en un momento relevante y dirígelos a la configuración de su dispositivo, ya que iOS no mostrará el aviso del sistema por segunda vez.
Tu siguiente paso
Haz una lista de todos los mensajes que tu app envía hoy y pasa cada uno por las tres preguntas de arriba. Primero mueve los push que deberían ser mensajes in-app, y luego agrega preferencias por categoría para que los usuarios puedan bajar el volumen sin desactivarte por completo.