Un solo pedido de Rappi o PedidosYa puede disparar entre 5 y 7 notificaciones push entre el “confirmado” y el “entregado”. Multiplica eso por dos o tres pedidos por semana, y la app empieza a verse como spam puro. El usuario promedio ya recibe 46 notificaciones push al día, y el 43% las desactiva cuando una app envía apenas 2 a 5 por semana.
Los usuarios quieren saber qué pasa en cada momento, no que los interrumpan cinco veces en el camino. La diferencia entre engagement y desinstalación es saber qué momentos realmente necesitan una push y cuáles solo necesitan estar visibles.
Esta guía explica la diferencia entre alerta y estado en vivo, la regla de las 3 notificaciones para flujos en tiempo real, ejemplos reales por vertical (delivery, ride-hailing, FinTech, e-commerce, gaming, medios) y cómo empezar sin reconstruir tu stack. Y en el camino vas a ver cómo Pushwoosh te permite orquestar push + Live Activities en un solo canvas de customer journey.
Alerta vs. estado en vivo: la única distinción que importa
La mayoría de los equipos usa las push notifications como canal por defecto para todo lo que pasa en tiempo real. Pedido confirmado, push. Repartidor asignado, push. Repartidor en camino, push. Repartidor llegando, push. Entregado, push. Cinco interrupciones para un evento que el propio usuario inició y que ya está esperando.
Cada una de esas actualizaciones importa, pero no cada una necesita ser una push. Hay 2 trabajos de comunicación fundamentalmente distintos en escenarios en tiempo real:
Las alertas dicen “Pasó algo. Mira ahora.” Interrumpen y exigen atención. Pertenecen a los momentos que genuinamente requieren una decisión o un cambio de comportamiento: cambió la puerta de tu vuelo, falló tu pago, ya llegó tu DiDi.
El estado en vivo dice “Esto es lo que está pasando ahora, míralo cuando quieras.” Es ambiental y se actualiza continuamente. El estado en vivo cubre lo que los usuarios quieren seguir sin necesidad de reaccionar: ubicación del repartidor, tiempo de preparación, ETA de entrega, marcador del partido, distancia del entrenamiento.
Las push notifications fueron construidas para alertas. Las Live Activities fueron construidas para estado en vivo. Usar push para tracking de estado significa interrumpir a tus usuarios para contarles algo que nunca pidieron que los interrumpieran.
La regla de las 3 notificaciones
Para cualquier escenario en tiempo real, necesitas como máximo 3 push notifications.
Inicio. Confirma que el proceso arrancó. “Tu pedido fue confirmado.” “Pago iniciado.” “Tu viaje está en camino.” Esto fija expectativas, le da confianza al usuario y activa la Live Activity que llevará el resto.
Excepción. Algo salió mal o requiere atención. “Producto no disponible.” “Tu repartidor no encuentra la entrada.” “Pago rechazado, actualiza tu tarjeta.” “Vuelo retrasado 2 horas.” Estas son interrupciones genuinas porque requieren una acción.
Cierre. El proceso terminó. “Tu pedido fue entregado.” “Pago recibido.” “Llegaste.” Esto cierra el ciclo y termina la Live Activity.
Todo lo que va entre Inicio y Cierre vive en la pantalla de bloqueo como una Live Activity: el tiempo de preparación en cuenta regresiva, el repartidor moviéndose en el mapa, el marcador actualizándose, el ETA recalculándose. Actualizado automáticamente, con cero interrupciones.
Cómo se ve en la práctica: un pedido de delivery
Tomemos un flujo típico de delivery, antes y después.
Antes (solo push), 5 notificaciones en ~45 minutos:
- 🔔 “Tu pedido fue confirmado”
- 🔔 “Tu pedido se está preparando”
- 🔔 “Tu repartidor recogió tu pedido”
- 🔔 “Tu repartidor está cerca”
- 🔔 “Tu pedido fue entregado”
Cinco interrupciones por un solo almuerzo. Multiplica eso por dos o tres pedidos a la semana y una sola app te está mandando 10 a 15 notificaciones. Ese es el umbral donde los usuarios empiezan a apagar las notificaciones por completo.
Después (regla de 3 pushes + Live Activity):
- 🔔 Push: “Tu pedido fue confirmado” -> arranca la Live Activity
- 📱 La Live Activity se actualiza en silencio: preparando -> recogido -> ubicación del repartidor -> cuenta regresiva del ETA
- 🔔 Push (solo si hace falta): “El repartidor no puede entrar al edificio, revisa tu teléfono”
- 📱 Live Activity: sigue la cuenta regresiva del ETA
- 🔔 Push: “Tu pedido fue entregado” -> termina la Live Activity
El usuario pasa de 5 interrupciones a 2, o tres si hay algún problema. La pantalla de bloqueo queda limpia, y la visibilidad en tiempo real es de hecho mejor. En lugar de cinco pings desconectados, el usuario ve un tracker continuo y vivo con la ubicación del repartidor y el ETA, refrescándose cada pocos segundos.
El resultado: menos desinstalaciones, menos tickets de “¿dónde está mi pedido?” al soporte, y la app se queda visible en la pantalla de bloqueo 30 a 45 minutos seguidos en lugar de parpadear cinco veces y desaparecer.
Adapta la regla a tu app
La misma regla funciona donde sea que los usuarios sigan algo en tiempo real.
| App | Push: Inicio | Live Activity | Push: Excepción | Push: Cierre |
|---|---|---|---|---|
| Ride-hailing (DiDi, Cabify) | Conductor asignado | Ubicación, ETA, datos del vehículo | Conductor canceló / cambió ruta | Viaje finalizado + tarifa |
| E-commerce (Mercado Libre, Linio) | Pedido enviado | Empacando -> en tránsito -> en reparto -> cerca | Demora o intento de entrega fallido | Entregado |
| FinTech (Nubank, Mercado Pago) | Transacción iniciada | Estado de procesamiento (transfronteriza, verificación) | Pago rechazado / actividad inusual | Transacción completa |
| Gaming | Torneo comienza / energía llena | Posición en ranking, timer de jefe, progreso | Rival encontrado / racha en riesgo | Resultado del match |
| Medios (Clarín, El Tiempo) | Noticia de último momento / evento en vivo | Ticker en vivo: marcador, conteo de votos, titular | Desarrollo importante | Evento finalizado |
En cada caso, la notificación push marca las transiciones que importan. La Live Activity carga el estado entre ellas.
Cómo empezar sin reconstruir tu stack
La objeción típica: “Necesitaríamos un refactor gigante para agregar Live Activities.” En la práctica, un enfoque de tres pasos cabe dentro de un solo sprint:
-
Audita tu flujo actual de push
Elige un journey en tiempo real (tracking de pedido, un viaje, un partido) y lista cada notificación push que dispara. Marca cada una: requiere que el usuario haga algo o sepa algo nuevo, o es una actualización de estado que podría consultar por su cuenta? Lo típico es que sobrevivan 2 a 3 de 5 a 7 pushes después de este filtro.
-
Suprime y reemplaza
Apaga las pushes de actualización de estado. Lanza una Live Activity en el push de Inicio, ciérrala en el push de Cierre. Actualízala vía API en cada punto donde antes mandabas una notificación push.
-
Mide
Trackea tres cosas durante 2 a 4 semanas. La tasa de desinstalación debería bajar. El volumen de tickets de soporte por preguntas tipo 'donde esta mi pedido' baja cuando las Live Activities le dan al usuario visibilidad self-serve. Y la frecuencia de sesiones suele subir en lugar de bajar: los usuarios con una Live Activity activa tienden a abrir la app más seguido, porque la pantalla de bloqueo se vuelve un punto de re-entrada.
