¿Cuándo una notificación push devuelve al jugador y cuándo solo se desliza para descartar?
La mayoría de los equipos trata el push como un problema de redacción: escribe mejor copy, envía más, mira subir la tasa de apertura. Ese marco es incorrecto. El push es un problema de tiempo y segmentación disfrazado de redacción, y casi todos los mini-juegos envían de más porque la única métrica en el panel es la apertura. Esto es lo que realmente decide si una notificación consigue una sesión o una desinstalación.
Q: ¿Por qué la mayoría de las campañas de push fracasan en silencio aunque la tasa de apertura se vea sana?
Porque la tasa de apertura mide lo incorrecto. El jugador que abre tu notificación a las 9am probablemente ya iba a abrir el juego a las 9am — te adjudicaste un retorno que no causaste. Lo que importa es el retorno incremental: segmento notificado menos un holdout que no recibió nada. Corre esa comparación y un número sorprendente de pushes "exitosos" muestra un lift cercano a cero. El segundo fallo es la hora de envío. Una notificación entregada a las 3am hora local —porque tu servidor corre en UTC— se desliza, no se toca, y entrena al jugador a ignorarte. El tercero, y el que nadie quiere oír: la notificación no es el producto. Si el deep link suelta al jugador en una pantalla de inicio genérica en lugar de la misión exacta que dejó a medias, gastaste el capital de atención y lo convertiste en nada.
Q: ¿Cuándo envías realmente, y a quién?
Casi nunca envías a todos. Segmenta por estado del ciclo de vida, porque un jugador D2 y uno dormido D40 necesitan mensajes opuestos. La cohorte temprana (D1–D3) recibe avisos de onboarding —pero solo los que se atascaron, no los ya enganchados. El segmento dormido (D14+) es donde el push justifica su costo y donde te consigues desinstalaciones, así que es el que más restraint necesita. Usa una lente RFM-lite: recencia de la última sesión, frecuencia antes de caer, y el valor que dejaron sobre la mesa —una misión sin terminar, un saldo, una racha por expirar. Dispara por comportamiento donde puedas; los envíos de calendario son el default perezoso y se notan. Y respeta las horas de silencio locales por zona horaria, no por tu oficina.
Q: ¿Cómo evitas la fatiga que dispara una desinstalación?
La fatiga es acumulativa e invisible hasta que los opt-out y desinstalaciones disparan —para cuando los ves, ya pagaste. El bug estructural es que cada equipo posee un trigger y nadie posee el total. Una campaña limita a dos por semana; otros tres equipos limitan a dos cada uno; el jugador recibe seis. Necesitas un tope global de frecuencia, por usuario por semana, en un solo lugar. Luego divulgación progresiva: empieza suave y escala solo con señales de alta intención. Y mide la desinstalación atribuible al push —la mayoría de paneles no lo tiene, así los equipos siguen enviando de más hacia una fuga que no ven. Si no aislas ese número, operas el leverage más destructivo a ciegas.
Q: ¿Cómo se ve un programa de push que realmente mueve la retención?
Un experimento controlado, no un boletín. Mantén fuera al 5–10% de usuarios para siempre y observa el retorno incremental D7 y D30 contra ellos; mata cualquier trigger que no supere al holdout. Los deep links aterrizan a mitad del loop, nunca en inicio. Copy y hora de envío localizados, no traducidos y olvidados. Y la parte incómoda para un mini-juego casual: el mayor leverage de retención casi siempre es el propio diseño del loop del juego —lo siguiente que hacer—, no el CRM. El push es un impuesto que pagas a un cubo con fuga, no la reparación. Gasta el primer dólar en el loop; gasta el push en los jugadores que el loop ya ganó pero que se desviaron.
| Tipo de trigger | Retorno incremental | Riesgo de fatiga | Cuándo vale la pena |
|---|---|---|---|
| Aviso onboarding (solo atascados) | medio | bajo | D1–D3, por comportamiento |
| Recordatorio corte de hábito | alto | medio | D5–D10, antes de la racha |
| Recuperación dormidos | alto | muy alto | D14+, tope estricto |
| Envío masivo / calendario | ~cero | alto | casi nunca |
