Notificaciones push que no molestan: permiso, timing y métricas

Las notificaciones push son el único canal de tu app que se juega a una sola carta. Un email malo te cuesta una apertura. Un push malo te cuesta el permiso, y el permiso se pide una vez: si el usuario lo deniega, tienes que convencerle de que entre a los ajustes del sistema y lo active a mano. Casi nadie lo hace.

En Docastix construimos apps móviles nativas en las que el push no es un añadido de marketing, sino parte del producto. Si tu problema de fondo es por qué se te van los usuarios, empieza por cómo las apps mejoran la experiencia del cliente.

Respuesta rápida: cómo se hacen notificaciones push que no molestan

No es cuestión de tono: es cuándo pides el permiso, si el mensaje habla de algo del usuario o de tu campaña, y si se puede apagar por tipos sin apagarlo todo. Un push sobre algo que el usuario configuró no molesta aunque llegue a diario. Uno genérico por calendario molesta aunque llegue una vez al mes.

Si necesitas tres cifras: la aceptación mediana del permiso ronda el 59% en Android y el 49% en iOS (Airship, 2024); un push contextual abre unas tres veces más que uno genérico; y lo que importa no es la apertura, sino cuánta gente te revoca el permiso cada mes.

La asimetría que lo explica todo

Casi todas las decisiones malas sobre push vienen de tratarlo como un canal más. No lo es: el resto tiene coste de fallo lineal y el push lo tiene escalonado. Si mandas un email flojo pierdes esa apertura. Si mandas tres push flojos seguidos, el usuario no baja su tasa de apertura: te desactiva. Y eso no es gradual, es un interruptor: pasa de recibirlo todo a nada, incluidas las notificaciones que sí le importaban.

Peor: es silencioso. El usuario sigue en tus activos, pero fuera de tu alcance. Si no mides cuántos permisos pierdes al mes, el canal se te muere sin aparecer en ningún dashboard.

Cómo pedir el permiso sin quemarlo

El error clásico se repite en la mayoría de apps que auditamos: la pantalla siguiente al splash lanza el diálogo del sistema. El usuario no ha visto nada, y la respuesta racional a una pregunta sin contexto es «no».

El patrón que funciona es el doble consentimiento, que separa dos preguntas que casi todo el mundo fusiona:

• Primero preguntas tú, con tu interfaz y tu texto, explicando qué vas a enviar y con qué frecuencia. Un «ahora no» aquí no cuesta nada: lo replanteas cuando quieras.
• Solo si dice que sí, lanzas el diálogo del sistema. Así la carta que solo juegas una vez se dispara sobre gente que ya ha aceptado.

Apple lo dice sin rodeos: hay que pedir la autorización «en un contexto que ayude a la gente a entender por qué tu app la necesita», y pone el ejemplo de una app de tareas que la pide tras programar la primera tarea, no al arrancar (Apple). Google recomienda lo mismo: engancharla a una acción del usuario, como pulsar una campana o hacer un pedido (Android Developers). El momento correcto no es un horario, es un estado: ahí el permiso no es una petición, es la continuación de lo que el usuario acaba de hacer.

iOS y Android ya no son el mismo problema

Durante años el push en Android era gratis: se activaba solo. Eso se acabó. Desde Android 13 (API 33) existe el permiso en tiempo de ejecución POST_NOTIFICATIONS y las notificaciones vienen desactivadas por defecto en instalaciones nuevas (Android Developers). Hoy hay que pedirlo explícitamente en las dos plataformas.

Con un matiz que mucha gente se salta. Con target Android 13 o superior controlas tú cuándo aparece el diálogo. Con target 12L o inferior lo muestra el sistema por su cuenta, y ahí viene el castigo: si el usuario pulsa «No permitir» una sola vez, no se le vuelve a preguntar hasta que reinstale la app o actualices el target. Mantener un targetSdk viejo te quema el permiso.

En iOS tienes algo que Android no tiene: la autorización provisional. Pides el permiso con la opción provisional y el sistema lo concede sin diálogo: las notificaciones llegan en silencio, solo al historial, con botones para mantenerlas o desactivarlas. El usuario decide después de ver lo que mandas. Así que en iOS cabe provisional al arranque más petición explícita en el momento de valor, y en Android tienes una sola bala. Conviene decidirlo con el stack: lo tratamos al comparar desarrollo nativo y multiplataforma.

Sobre las tasas de aceptación, honestidad: los benchmarks públicos no coinciden. Batch, sobre 10.000 apps entre julio de 2024 y julio de 2025, da 67% en Android y 56% en iOS, y atribuye la caída de Android (venía del 85%) al permiso explícito. Airship, con datos de 2024, sitúa la mediana por app en 59,5% en Android y 49,4% en iOS. Miden bases distintas: no los compares entre sí. Por sectores, Pushwoosh va del 79,87% en iOS para apps de negocio al 23,01% en juegos hipercasuales.

Qué separa un push útil de uno molesto

Llega cuando el usuario puede actuar, no cuando a ti te viene bien. Un «tu pedido sale de reparto» a las 8:40 es útil; el mismo aviso a las 23:00 es ruido. Este filtro solo ya elimina la mayoría de campañas.

Habla de algo suyo: su pedido, su rutina, su saldo. No de tu campaña de primavera. Batch encuentra un 14,4% de apertura en campañas contextuales frente a un 4,19% en genéricas, y poner el nombre de pila no cuenta como contextual.

Se puede apagar por partes, que es lo del apartado siguiente.

Granularidad de preferencias: lo que casi nadie implementa

Si tu app solo ofrece «notificaciones: sí / no», obligas al usuario a elegir entre aguantar tus promociones o perderse los avisos que le importan. Cuando llegue el push promocional que le sobra, apagará las dos cosas de golpe.

La alternativa es un centro de preferencias con las categorías reales de tu producto: en una app de reparto, estado del pedido, incidencias, promociones y novedades.

En Android tienes el mecanismo de serie: los canales de notificación son obligatorios desde Android 8.0 (API 26) y el usuario controla el comportamiento y la importancia de cada uno por separado (Android Developers). Ojo: creado un canal ya no puedes cambiar su comportamiento por código, así que el mapa se diseña antes de la primera versión.

En iOS no hay equivalente: el usuario ve un único interruptor por app, así que la granularidad la construyes tú, en tu pantalla de ajustes y en tu backend. Es trabajo que nadie valorará en una demo, y es la diferencia entre conservar el permiso tres años o perderlo en seis meses.

Push funcional y push promocional: el caso Dormus

Dormus es una app de sueño infantil que desarrollamos en nativo para las dos plataformas: Swift y SwiftUI en iOS, Kotlin y Jetpack Compose en Android, con Firebase por detrás. Va por las 50.000 descargas, más de 22.500 familias registradas y una media de 4,5 estrellas.

En un producto así el push no es marketing: es funcionalidad. Un recordatorio de rutina de sueño no es una campaña planificada en una hoja de cálculo, es la forma en que la app entrega su valor. Y llega en horarios que define el propio usuario al configurar la rutina, no cuando el equipo decide que es buen momento para hablar.

Esa distinción es la más útil que conocemos para decidir qué se envía:

• Push funcional: lo dispara un evento que afecta al usuario. La rutina que él programó, el pedido que hizo, el cargo en su tarjeta. Lo espera, y puede llegar a diario sin desgastar nada.
• Push promocional: lo dispara tu calendario. Ofertas, novedades, reactivación. No lo espera, y cada envío consume crédito.

El funcional se optimiza para fiabilidad, el promocional para escasez, y nunca comparten interruptor: mezclados, el promocional acaba matando al funcional. En una app de suscripción como Dormus importa el doble, porque el canal que sostiene el hábito es el que sostiene la renovación, un vínculo que explicamos al hablar de monetización de apps.

Y una nota de honestidad: no vamos a publicar métricas de notificaciones de Dormus, porque las que tenemos son de descargas, familias registradas y valoración. Desconfía de quien da porcentajes de apertura de un caso real sin decir cómo los midió.

Cuatro patrones que funcionan, con su contraejemplo

1. El disparador que el usuario configuró. Recordatorios de rutina, alertas de precio, avisos de disponibilidad: él definió la condición. Contraejemplo: el mismo recordatorio en el horario que decide la app «porque es el mejor momento medio».

2. El cambio de estado en algo que tiene en marcha. Pedido enviado, incidencia resuelta, plaza disponible. Contraejemplo: el estado que no cambia nada accionable. «Tu pedido sigue en tránsito» no es información, es ansiedad con formato de notificación.

3. La alerta de seguridad o de dinero. Un cargo inusual, un acceso desde un dispositivo nuevo, un vencimiento. Nadie las desactiva. Contraejemplo: un «última oportunidad» con el mismo formato de urgencia que un aviso de fraude: enseña a ignorar los dos.

4. El rescate de una acción a medias, una sola vez. Carrito abandonado o formulario sin terminar, mientras la intención sigue viva. Contraejemplo: tres recordatorios del mismo carrito en 48 horas. El primero recuerda, el segundo presiona, el tercero enseña a desactivar, y con él se va la alerta del punto 3.

Para enganchar por hábito y no por aviso, el push es solo una pieza: las técnicas de gamificación en aplicaciones móviles trabajan la otra mitad.

Los errores caros

Enviar por calendario de marketing en vez de por comportamiento. Se planifican dos push semanales porque hay dos huecos, y salen aunque el usuario no abra la app desde hace tres meses. El calendario coordina equipos, no dispara mensajes.

El push genérico a toda la base. El más barato de producir y el que peor rinde. El coste no aparece en la campaña: aparece dos meses después, en la tasa de permisos activos.

Frecuencia sin tope global. Cada equipo controla sus campañas y nadie cuántas recibe una persona. El usuario no distingue entre producto, ciclo de vida y transaccional: cuenta el total. Necesitas un límite por usuario y ventana en el backend.

El push que abre una pantalla que no tiene que ver con el mensaje. Prometes un descuento en zapatillas y abres la home. El deep link roto es el error más fácil de arreglar y el más caro en confianza: enseña que tus notificaciones mienten. Ciérralo en el proceso de desarrollo, no en el sprint de lanzamiento.

Push promocional en la UE: qué dice la norma

El permiso del sistema operativo y el consentimiento legal son cosas distintas, y cuando el contenido es publicitario hacen falta los dos.

En España, el artículo 21 de la Ley 34/2002 (LSSI), vigente, prohíbe «el envío de comunicaciones publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica equivalente que previamente no hubieran sido solicitadas o expresamente autorizadas por los destinatarios». Un push promocional encaja en ese «medio equivalente». El mismo artículo admite la excepción de relación contractual previa: con datos obtenidos de forma lícita en una compra puedes comunicar productos o servicios similares, siempre que ofrezcas un medio sencillo y gratuito de oponerse.

Tres consecuencias para el producto, no para el departamento legal:

• Aceptar el diálogo del sistema no es consentimiento para publicidad: el usuario autoriza notificaciones, no marketing. Recoge un consentimiento separado.
• Con el RGPD el consentimiento debe ser demostrable: registrar quién aceptó qué, cuándo y con qué texto es un requisito de arquitectura, no un log.
• La baja debe ser tan fácil como el alta y estar en cada comunicación. En push eso es el centro de preferencias: la buena práctica y la obligación legal apuntan al mismo sitio.

Resuélvelo antes de la primera campaña, con el resto de decisiones de seguridad y datos en la app. No es asesoramiento jurídico: el detalle depende del caso.

Cómo medirlo bien: retención y desactivación, no aperturas

La tasa de apertura es la métrica más citada del sector y una de las menos útiles: se sube haciendo cosas malas, como titulares alarmistas, falsas urgencias o mensajes ambiguos que obligan a abrir para entender de qué van. Y en iOS el usuario puede leerlo entero en la pantalla de bloqueo, actuar y no abrir nunca: cuenta como fallo y fue un éxito.

Efecto sobre la retención, con grupo de control. Reserva un porcentaje de usuarios con permiso concedido que no reciben campañas y compara su retención a 7, 30 y 90 días. Quien acepta notificaciones ya era más comprometido antes de aceptarlas, así que sin control cualquier correlación es sospechosa.

Tasa de desactivación del permiso. El coste real del canal: usuarios con permiso activo que lo revocan en un mes. Instrumentarla exige comprobar el estado de autorización en cada arranque, porque ninguna plataforma te avisa cuando alguien te apaga. Si sube tras una campaña, esa campaña fue cara aunque convirtiera bien.

Aperturas y conversión, solo como diagnóstico. Sirven para comparar dos versiones del mismo tipo de mensaje. En los benchmarks de Airship con datos de 2024 la apertura directa mediana es del 3,4% en Android y del 3,1% en iOS —casi la misma— y en el 10% de apps que mejor va, del 10,7% y el 8,0%. La diferencia entre plataformas aparece arriba, no en la mediana, así que no sirve para justificar nada de tu app.

Y una métrica de rescate que casi nadie usa: la recuperación de permiso. Batch reporta que los mensajes in-app pidiendo reactivar las notificaciones consiguen un 11% de clic en Android y un 9% en iOS: sobre usuarios que ya te habían apagado, es dinero tirado.

Conclusión

El push no se arruina por escribir mal los mensajes. Se arruina por pedir el permiso demasiado pronto, por enviar lo que le interesa a la empresa en vez de lo que le pasa al usuario, y por no dejar apagar una parte sin apagarlo todo. Tres decisiones de producto que se toman antes de la primera campaña.

Si lo montas ahora, el orden es: mapa de tipos y canales primero, centro de preferencias segundo, estrategia de permiso tercero, campañas al final. Si ya está en producción, instrumenta la tasa de desactivación: en dos meses sabrás qué campaña te cuesta el permiso. Ese trabajo lo hacemos dentro de nuestro mantenimiento evolutivo desde 500 €/mes: cuéntanoslo. Y si el canal que necesitas no es el push sino una conversación, mira lo que da un agente de IA en WhatsApp.