No ser molesto: relevancia, frecuencia y desinstalaciones

Todo lo anterior de este nivel era mecánica: canales, constructores, permisos, tokens. Esta lección trata de la única decisión que determina si esa mecánica produce valor o lo destruye, y es una decisión que ninguna API te va a ayudar a tomar. Enviar una notificación es gratis para quien la envía y caro para quien la recibe, y ese desajuste explica por qué prácticamente todas las aplicaciones acaban emitiendo de más. El mecanismo es siempre el mismo y siempre parece razonable desde dentro: cada notificación nueva se justifica individualmente, cada una produce un pico medible de sesiones, cada una la pide alguien con un objetivo trimestral, y nadie mide el agregado. Al cabo de dos años la aplicación emite once avisos semanales, la mitad de los usuarios los ha desactivado, la tasa de apertura ha caído a la mitad y el equipo concluye que necesita enviar más. Esta lección trata de romper ese bucle con criterio y con números.

El criterio de relevancia

La pregunta habitual antes de añadir una notificación es si el usuario querría saber esto. Es una pregunta defectuosa porque siempre se responde que sí. La pregunta correcta tiene tres partes y las tres deben cumplirse a la vez: si la información es importante para esta persona en concreto, si lo es ahora en lugar de la próxima vez que abra la aplicación, y si requiere una acción o decisión suya.

El tercer criterio es el que más candidatos elimina, porque separa el aviso del anuncio. Alguien te ha enviado un mensaje pasa las tres pruebas. Tu paquete sale a reparto hoy pasa las tres. Descubre nuestras novedades de esta semana no pasa ninguna, y sin embargo es el tipo de mensaje que más volumen genera en la mayoría de los sistemas.

Existe una prueba complementaria que resuelve casi todos los casos dudosos y que conviene aplicar literalmente: imagina que este aviso llega a las once y media de la noche y despierta a quien lo recibe. Si la respuesta es que se sentiría razonablemente informado, la notificación merece existir. Si la respuesta es que se sentiría irritado, no merece ser una notificación aunque sí merezca ser una entrada en el centro de avisos dentro de la aplicación.

La aritmética de la frecuencia

Los datos de la industria son consistentes en su forma general aunque varíen en su magnitud según el sector: la relación entre número de notificaciones y valor obtenido no es creciente sino que tiene un máximo, y más allá de ese máximo cada envío adicional reduce el resultado total. La razón es que el usuario no responde al aviso individual sino a la reputación acumulada del emisor. Una aplicación que ha enviado nueve avisos irrelevantes esta semana no consigue que el décimo se lea aunque sea excelente, porque la decisión de ignorarla ya está tomada.

Ese punto de saturación está para la mayoría de las categorías en unos pocos avisos por semana, y muy por debajo de lo que la mayoría de los sistemas emite. Conviene medirlo empíricamente en lugar de asumirlo, y el experimento es sencillo: dividir la base en cohortes con distintos topes de frecuencia y comparar, a treinta días, no la tasa de apertura de cada envío sino la retención y la proporción de usuarios que siguen con las notificaciones activas.

Hay un matiz que evita aplicar el tope de forma torpe: no todas las notificaciones consumen el mismo presupuesto. Un mensaje de otra persona es contenido que el usuario espera y su coste reputacional es prácticamente nulo; una reactivación automática de usuario inactivo tiene el coste más alto de todo el catálogo. Por eso el tope debe repartirse en presupuestos por canal en lugar de aplicarse como un contador único, y por eso el canal transaccional —pedidos, seguridad, mensajes— debe quedar fuera de la cuota promocional. Mezclarlos produce el peor resultado posible, que es descartar un aviso importante porque una campaña ya gastó el cupo de la semana.

La herramienta técnica es un tope agregado por usuario, aplicado en el servidor y por encima de cualquier campaña. Sin él, la frecuencia real de una aplicación no la decide nadie: es la suma no coordinada de lo que emiten producto, marketing, el sistema de mensajería y los recordatorios automáticos, y esa suma solo se conoce cuando ya es un problema.

La ventana de silencio merece un apunte técnico porque suele implementarse mal. Programar el envío en la hora del servidor y confiar en que coincidirá con la del usuario produce mensajes de madrugada para una fracción de la base que crece con la internacionalización. La zona horaria del destinatario debe formar parte de su perfil, y el envío debe planificarse contra ella. Y para el contenido no urgente, la política correcta no es enviar y esperar, sino retener hasta la siguiente ventana válida.

Agrupar: menos interrupciones, la misma información

La agrupación es la única técnica que reduce interrupciones sin reducir contenido, y por eso es la primera que hay que aplicar. Consiste en asignar una clave de grupo a las notificaciones relacionadas y publicar además una notificación resumen que las represente cuando hay varias. El sistema muestra entonces una sola entrada expandible en lugar de seis independientes.

private const val GRUPO_MENSAJES = "com.ejemplo.GRUPO_MENSAJES"

fun publicarMensaje(contexto: Context, id: Int, autor: String, texto: String) {
    val individual = NotificationCompat.Builder(contexto, "mensajes_directos")
        .setSmallIcon(R.drawable.ic_chat)
        .setContentTitle(autor)
        .setContentText(texto)
        .setGroup(GRUPO_MENSAJES)
        .setAutoCancel(true)
        .build()

    val resumen = NotificationCompat.Builder(contexto, "mensajes_directos")
        .setSmallIcon(R.drawable.ic_chat)
        .setStyle(
            NotificationCompat.InboxStyle()
                .setSummaryText("Mensajes nuevos")
                .addLine(autor + ": " + texto)
        )
        .setGroup(GRUPO_MENSAJES)
        .setGroupSummary(true)
        .setGroupAlertBehavior(NotificationCompat.GROUP_ALERT_SUMMARY)
        .build()

    with(NotificationManagerCompat.from(contexto)) {
        notify(id, individual)
        notify(ID_RESUMEN_MENSAJES, resumen)
    }
}

El detalle decisivo es el comportamiento de alerta del grupo. Sin configurarlo, cada notificación individual sigue sonando y la agrupación solo mejora el aspecto visual del cajón, que es la parte menos importante del problema. Al declarar que solo alerta el resumen, seis mensajes producen una interrupción en lugar de seis, que es exactamente el objetivo.

A partir de Android 7 el sistema agrupa automáticamente las notificaciones de una misma aplicación cuando hay cuatro o más, pero ese agrupamiento automático es genérico y no permite controlar la alerta ni el texto del resumen. Declarar el grupo explícitamente sigue siendo netamente superior.

Existe además una forma de agrupación conceptual más potente que la técnica: fusionar en el servidor. Tres cambios en el mismo pedido en veinte minutos no son tres avisos, son uno que se actualiza; y cinco personas que reaccionan a la misma publicación no son cinco avisos sino uno que dice cuántas. Este trabajo ocurre antes del envío y reduce el volumen en origen, que es donde más barato sale.

flowchart TD
A[Evento candidato a notificacion] --> B{Pasa las tres pruebas de relevancia}
B -->|no| C[Va al centro de avisos dentro de la app]
B -->|si| D{El usuario ya lo sabe}
D -->|si| C
D -->|no| E{Hay algo pendiente del mismo asunto}
E -->|si| F[Se fusiona o se contrae con lo anterior]
E -->|no| G{Queda cuota semanal y estamos en ventana valida}
G -->|no| H[Se retiene para la siguiente ventana]
G -->|si| I[Se emite agrupada con alerta solo en el resumen]
style C fill:#89b4fa,color:#11111b
style I fill:#a6e3a1,color:#11111b

La cadena que termina en la desinstalación

El coste del ruido es real y es medible, pero no aparece donde se le busca. Nadie desinstala una aplicación por una notificación concreta; el proceso es acumulativo y tiene cuatro fases que conviene instrumentar por separado porque cada una avisa antes que la siguiente.

La primera fase es la indiferencia: la tasa de apertura cae mientras el volumen se mantiene. La segunda es el descarte activo: el usuario desliza los avisos sin leerlos, señal que el propio sistema operativo observa y usa para degradar tu posición en el cajón y para sugerirle al usuario que te silencie. La tercera es la desactivación, que es la más grave de todas porque es prácticamente irreversible: recuperar a un usuario que apagó tus notificaciones exige que entre voluntariamente en los ajustes del sistema, cosa que casi nunca ocurre. La cuarta es la desinstalación, y para cuando llega hace tiempo que el problema era visible.

Lo que hace peligrosa esta cadena es que la métrica que casi todos los equipos vigilan —sesiones generadas por notificación— sube durante las dos primeras fases. Un envío adicional siempre produce un pico inmediato de aperturas, y ese pico es lo que se presenta en la revisión mensual. El deterioro se acumula en variables que nadie mira en la misma pantalla.

El panel mínimo honesto tiene cinco números y conviene medirlos como series y no como instantáneas. La proporción de usuarios con notificaciones activas, que es el activo real y el único que no se recupera. La tasa de descarte sin apertura, que es el indicador adelantado más fiable. Las notificaciones recibidas por usuario y semana, agregadas sobre todos los emisores. La retención a treinta días segmentada por volumen recibido. Y la correlación entre volumen y desinstalación, que solo se ve comparando cohortes.

Conviene además separar dos métricas que suelen confundirse y que significan cosas opuestas. La tasa de apertura mide cuántas personas actuaron sobre un envío concreto y responde a la calidad de ese envío. La proporción de usuarios con notificaciones activas mide cuántas personas siguen dispuestas a escucharte y responde al comportamiento acumulado de la aplicación entera. La primera es un indicador de campaña y se recupera; la segunda es un indicador de reputación y no se recupera. Un sistema que optimiza la primera a costa de la segunda está vendiendo capital como si fuera ingreso.

La plataforma añade además su propia presión, y esto es relativamente reciente y poco conocido. El sistema observa cómo interactúa cada usuario con las notificaciones de cada aplicación y ajusta su tratamiento en consecuencia: baja en el orden del cajón lo que se descarta sistemáticamente, sugiere de forma proactiva silenciar a las aplicaciones cuyos avisos nunca se abren, y clasifica como silenciosas las notificaciones de las que ha aprendido que no importan. Es decir, además del castigo del usuario existe un castigo automático del sistema operativo, y opera sobre la aplicación entera y no sobre el canal culpable.