Cuando una sesión termina con un cierre inesperado, pierdes más que la confianza del usuario. Pierdes todas las impresiones que se habrían mostrado durante el resto de la sesión, todos los postbacks que se habrían enviado al finalizarla y una parte importante de la retención al día siguiente. Las cuentas son incómodas.
La cadena de pérdidas
La duración media de una sesión en una app móvil que funciona bien es de 6–9 minutos. La media de impresiones por sesión, tras aplicar los límites de frecuencia, es de 2,4. Una sesión que sufre un cierre inesperado en el segundo minuto pierde unas 1,6 impresiones de media: desaparecen y no se pueden recuperar.
Si extrapolas esa pérdida a una tasa de cierres inesperados del 1 % y 5 millones de DAU, el resultado son 80 000 impresiones perdidas al día. Con un eCPM de 7 USD, son 560 USD de ingresos diarios atribuibles a un solo punto porcentual de estabilidad.
El modelo completo de pérdida de ingresos
La fórmula es sencilla: ingresos perdidos al día = DAU × tasa de cierres inesperados × (impresiones por sesión − impresiones antes del cierre inesperado) × eCPM / 1000. El resultado empieza a incomodar cuando introduces cifras realistas.
- 1 millón de DAU × 1,5 % de cierres inesperados × 1,6 impresiones perdidas × 6 USD de eCPM ≈ 144 USD/día, 52 000 USD/año
- 5 millones de DAU × 1,0 % de cierres inesperados × 1,6 impresiones perdidas × 7 USD de eCPM ≈ 560 USD/día, 204 000 USD/año
- 25 millones de DAU × 0,6 % de cierres inesperados × 1,6 impresiones perdidas × 8 USD de eCPM ≈ 1920 USD/día, 700 000 USD/año
- Y estas cifras solo incluyen las impresiones perdidas: no contemplan el impacto negativo en la retención, que suele ser mayor
Los ANR perjudican la monetización aún más que los cierres inesperados
Un ANR («la aplicación no responde») en Android es un enemigo silencioso. El usuario ve la interfaz congelada, fuerza el cierre y desinstala la app, pero no se genera ningún informe de cierre inesperado, así que el equipo que supervisa Crashlytics nunca se entera. Las tasas de ANR superiores al 0,5 % son habituales en apps que inicializan su SDK publicitario en el hilo principal.
El equivalente en iOS es la terminación por watchdog, con el código de salida 0x8badf00d, que generalmente tiene el mismo origen: tareas síncronas en el hilo principal durante el arranque. Trata ambos casos como los cierres inesperados: configura alertas, calcula la pérdida de ingresos con el mismo modelo y establece criterios de estabilidad que deban cumplirse antes de cada lanzamiento.
Patrones de programación defensiva por plataforma
Estos son los patrones que aplicamos por defecto en cada integración de Apps Kit SDK. Ninguno es sofisticado. Todos faltan en la mayoría de las bases de código que auditamos.
- Android: inicializa el SDK desde una tarea de WorkManager, no desde Application.onCreate
- Android: mantén las vistas de anuncios en WeakReference y asigna null a sus referencias en onDestroyView
- iOS: envía la inicialización del SDK a una cola con QoS de tipo utility desde didFinishLaunching, sin bloquear nunca el hilo principal
- iOS: invalida los delegados de anuncios y rompe los ciclos de retención en viewWillDisappear, no en deinit
- Ambas plataformas: condiciona cada solicitud de anuncio a una máquina de estados que controle el consentimiento, la conexión de red y si el SDK está listo
De dónde vienen los cierres inesperados
- Inicialización del SDK en el hilo principal: con diferencia, la causa más frecuente que encontramos
- Carga síncrona de anuncios en onCreate / didFinishLaunching
- Presión de memoria por mantener vistas de anuncios más allá de su vida útil
- Condiciones de carrera entre el estado del consentimiento y la solicitud de anuncios
Alertas de cierres inesperados según su impacto en los ingresos
Las alertas de tasa de cierres inesperados suelen configurarse con un umbral porcentual fijo y se ignoran cuando se activan. Vincúlalas al impacto en los ingresos: activa una alerta cuando la pérdida diaria estimada para una firma de error supere X USD. Así se convierte en una alerta por la que el ingeniero de guardia sí está dispuesto a despertarse. Incluimos una plantilla de Cloud Function que hace exactamente esto con los datos exportados a BigQuery.
El patrón de programación defensiva
Inicializa el SDK con un dispatcher en segundo plano, condiciona cada solicitud de anuncio a una máquina de estados de consentimiento y libera las referencias a las vistas de anuncios en cuanto se cierre el emplazamiento publicitario. Nada de esto es nuevo. Todo ello falta en la mayoría de las integraciones que auditamos.
Trata la tasa de cierres inesperados como una palanca de ingresos, no como una métrica de mantenimiento técnico, y la conversación sobre priorizar las mejoras de estabilidad será mucho más breve.
Qué hacer esta semana
Abre tu panel de cierres inesperados, aplica el modelo anterior a las tres firmas de error más frecuentes y anota junto a cada una la pérdida en dólares. La versión que corrija la más costosa habrá amortizado su desarrollo antes de que termine el siguiente periodo de revisión de App Store.
