Imagínese: ha lanzado una campaña de notificaciones push dirigida a sus usuarios de Android. El panel de control dice «enviado». Pero las aperturas son la mitad de lo que esperaba, y no puede saber si el problema es una mala creatividad o una entrega fallida.
En Android, la respuesta a menudo no es ninguna de las dos. Los canales de notificación, los ajustes de prioridad y las agresivas políticas de batería de los OEM pueden eliminar silenciosamente sus mensajes antes de que los usuarios los vean. El panel de control no lo marcará. Sus analíticas no lo explicarán. Los mensajes simplemente desaparecen.
Esta es una guía de diagnóstico: dónde se rompe realmente el embudo de entrega de Android y qué puede hacer al respecto, sin semanas de investigación por parte de los desarrolladores.
¿Dónde se pierden realmente sus notificaciones push?
La mayoría de los equipos de aplicaciones móviles rastrean 2 números: enviados y abiertos. Pero en Android, hay 4 etapas, y las mayores pérdidas ocurren en el medio, donde nadie está mirando.
Cada transición tiene su propio modo de fallo:
Enviado → Entregado. El mensaje salió de su servidor pero nunca llegó al dispositivo. Causas comunes: tokens de FCM caducados, dispositivo desconectado durante largos períodos, aplicación desinstalada con tokens obsoletos todavía en su base de datos.
Entregado → Mostrado. El mensaje llegó al dispositivo pero nunca se mostró al usuario. Aquí es donde residen los problemas específicos de Android: la optimización de la batería del OEM elimina la notificación, el canal de notificación está silenciado o desactivado, los ajustes de prioridad causan una entrega silenciosa.
Mostrado → Abierto. El usuario vio la notificación pero no la tocó. Aquí es donde la creatividad, el momento y la relevancia realmente importan, pero solo después de haber confirmado que las 2 primeras etapas funcionan.
La clave: si su ratio de entregado a mostrado es bajo, ninguna cantidad de A/B testing en el texto ayudará. Está optimizando un mensaje que nadie ve. A continuación, le explicamos cómo encontrar y solucionar el problema real en 3 pasos.
Los 3 principales asesinos silenciosos de la entrega de notificaciones push en Android
Canales de notificación: 1 canal predeterminado ≠ una estrategia
Desde Android 8.0, cada notificación debe ser asignada a un canal. Los usuarios pueden controlar cada canal de forma independiente: silenciarlo, cambiar su comportamiento o desactivarlo por completo.
El problema: cuando todos los mensajes (promociones, alertas transaccionales, recordatorios) pasan por 1 canal predeterminado, un solo usuario molesto silencia todo. Quería menos promociones; en su lugar, también perdió confirmaciones de pedidos, recibos de pago y alertas de seguridad.
Qué hacer: Estructure los canales por caso de uso. Como mínimo, separe los mensajes transaccionales (estado del pedido, confirmaciones de pago) de los promocionales (ofertas, recaptación). Cada canal obtiene su propio nivel de importancia.
Señal de diagnóstico: si las tasas de abandono son idénticas en todos los tipos de mensajes (promocionales y transaccionales), es probable que la estructura de su canal sea el problema. Los usuarios están silenciando el único canal que lo transporta todo.
Prioridad e importancia: por qué su mensaje llega silenciosamente
Hay 2 capas que controlan cómo se comporta una notificación, y confundirlas es uno de los errores más comunes.
Prioridad de FCM determina con qué urgencia el sistema entrega el mensaje al dispositivo. La prioridad ALTA despierta el dispositivo inmediatamente; la NORMAL puede ser agrupada y retrasada.
Importancia del canal determina cómo aparece la notificación al usuario una vez que está en el dispositivo. La importancia ALTA activa un banner de aviso y sonido. La PREDETERMINADA se muestra silenciosamente en el área de notificaciones.
La trampa: Prioridad de FCM ALTA + importancia del canal PREDETERMINADA = el mensaje llega al dispositivo inmediatamente, y luego se queda invisible en la bandeja de notificaciones. Las analíticas dicen «entregado». El usuario nunca se dio cuenta.
Políticas de batería de los OEM
El Android de serie es solo una parte de la historia. Samsung, Xiaomi, Huawei, Oppo y Vivo aplican cada uno su propia optimización agresiva de la batería además de los valores predeterminados de Android. Estas políticas pueden impedir que su aplicación reciba notificaciones push por completo, incluso cuando el token de FCM es válido y la entrega «tiene éxito».
Así es como se desglosa por fabricante:
- Xiaomi (MIUI): El inicio automático está desactivado por defecto. Después de un reinicio del dispositivo, su aplicación no puede recibir notificaciones push hasta que el usuario la abra manualmente, a menos que haya concedido el permiso de inicio automático.
- Huawei (EMUI/HarmonyOS): La terminación agresiva de aplicaciones finaliza los procesos en segundo plano. Las notificaciones push dejan de llegar después de un período de inactividad, incluso si la aplicación se usó recientemente.
- Samsung (One UI): Las listas de «Aplicaciones en suspensión» y «Aplicaciones en suspensión profunda» retrasan o bloquean las notificaciones para las aplicaciones que el usuario no ha abierto recientemente.
- Oppo/Vivo (ColorOS/Funtouch): Las restricciones de actividad en segundo plano suprimen silenciosamente las notificaciones. La aplicación parece funcionar normalmente cuando está abierta, pero la entrega en segundo plano falla.
El hilo común: en todos estos OEM, el usuario debe permitir explícitamente que su aplicación se ejecute en segundo plano. Sin ese permiso, la entrega «tiene éxito» en el papel, pero la notificación nunca se muestra.
Señal de diagnóstico: si las tasas de entrega o de apertura varían drásticamente según el fabricante del dispositivo dentro de la misma campaña, las restricciones del OEM son casi con toda seguridad la causa.
Encuentre dónde está el fallo y soluciónelo
Usted entiende lo que puede salir mal. A continuación, le explicamos cómo encontrar su problema específico y resolverlo.
1. Configure sus instrumentos de diagnóstico
Segmente por dispositivo. Cree segmentos específicos de Android por versión del sistema operativo y fabricante del dispositivo. Esta es su herramienta de diagnóstico más importante. Le permite ver si los problemas de entrega son universales o están aislados a un OEM específico.
Rastree el embudo completo. Asegúrese de que su SDK esté configurado para informar no solo de «enviado», sino también de «entregado» y «abierto» como eventos distintos. Sin esto, está ciego a la mitad del embudo.
Estructure los canales de notificación por caso de uso. Como mínimo, separe los transaccionales (estado del pedido, alertas de seguridad) y los promocionales (ofertas, recaptación). Cada canal debe tener su propio nivel de importancia.
Solicitudes para desarrolladores (configuración única):
- Pasar el fabricante del dispositivo, la versión del SO y el modelo como atributos de usuario para la segmentación
- Verificar que el seguimiento de la entrega esté configurado correctamente en el SDK
- Definir canales de notificación en el código con los niveles de importancia adecuados
2. Ejecute un recorrido de diagnóstico
Envíe la misma campaña a sus segmentos de Android (divididos por fabricante) y a su audiencia de iOS. Compare los abandonos y las aperturas del recorrido paso a paso.
Para este propósito, recomendamos usar un Creador de Customer Journeys de Pushwoosh amigable para los especialistas en marketing (puede registrarse gratis y probarlo):
- ⚠️ Los segmentos de Android caen en el paso de entrega, iOS se mantiene estable → el problema es la infraestructura: restricciones de OEM, problemas de tokens o mala configuración del canal.
- ⚠️ Ambas plataformas caen por igual en el paso de apertura → el problema es su mensaje: creatividad, momento o relevancia.
- ⚠️ Un fabricante cae desproporcionadamente → ha encontrado un problema específico del OEM.
- ⚠️ La entrega está bien, pero las aperturas son bajas en todos los dispositivos → verifique sus ajustes de prioridad/importancia. Es posible que esté enviando mensajes de ALTA prioridad en un canal de importancia PREDETERMINADA, lo que significa que llegan rápidamente pero aparecen silenciosamente.
3. Evite pérdidas futuras
Haga coincidir la prioridad con la importancia. Mensajes urgentes (ventas flash, alertas de seguridad) → prioridad ALTA, importancia ALTA. Contenido no urgente (resúmenes, consejos) → NORMAL/PREDETERMINADA.
No ponga todo en ALTA, es un atajo para que los usuarios silencien sus canales por completo.
Aplique límites de frecuencia y horas de silencio. El exceso de mensajes es el camino más rápido hacia un canal silenciado. Establezca límites de frecuencia por canal y respete las zonas horarias locales con horas de silencio. Esto no arregla la entrega, la protege.
Use las notificaciones push silenciosas con prudencia. Las notificaciones push silenciosas le permiten actualizar el contenido de la aplicación y sincronizar datos en segundo plano sin alertas visibles para el usuario. Esta es una herramienta poderosa para mantener su aplicación actualizada, pero también tiene sus propias restricciones de entrega en los OEM con optimización de batería.
Construya un recorrido de respaldo. Esta es su red de seguridad. Si una notificación push no se abre en N horas, active un seguimiento a través de un canal diferente: mensaje in-app, correo electrónico o SMS. Esto le cubre en caso de fallos de entrega del OEM, canales silenciados y segmentos de bajo compromiso.
Solucione la entrega de sus notificaciones push de Android con Pushwoosh
El objetivo es un ciclo repetible: segmentar → medir → identificar el punto de fallo → arreglar la capa correcta. No la creatividad cuando el problema es la entrega. No la entrega cuando el problema es la creatividad.
¿Listo para empezar? Cree su primer segmento en Pushwoosh para probar dónde se rompe realmente su embudo.
