La tasa de sesiones sin fallos es la métrica de estabilidad principal de la app: el porcentaje de sesiones (o usuarios) que NO experimentaron un fallo. Los fallos son eventos de UX catastróficos — la app se cierra de golpe, el usuario pierde su estado y la confianza en la app se erosiona. Las apps con altas tasas de fallos pierden usuarios por desinstalación más rápido de lo que la adquisición puede reemplazarlos, independientemente de lo bueno que sea el resto del producto.
Dos variantes
- Sesiones sin fallos: porcentaje de todas las sesiones que finalizaron sin un fallo. Usado para el reporte de estabilidad agregado. Métrica de límite inferior — si alguna sesión falla para un usuario, «sufrió un fallo» aunque sus otras sesiones estuvieran bien.
- Usuarios sin fallos: porcentaje de usuarios que no experimentaron NINGÚN fallo en un período definido (normalmente los últimos 7 o 30 días). Listón más alto — una vez que un usuario sufre un fallo, es «afectado por fallos» hasta que se reinicia la ventana.
Reporta ambas; cuentan historias diferentes. Las sesiones sin fallos es la métrica operativa diaria; los usuarios sin fallos es la métrica de experiencia de usuario.
Benchmarks modernos
- Apps de consumo: el 99,5 %+ es la línea base operativa. Las apps de primer nivel alcanzan el 99,9 %+.
- Banca / sanidad / apps de alto riesgo: mínimo del 99,9 %+; los usuarios tienen tolerancia cero a la inestabilidad en flujos de trabajo críticos.
- Juegos hyper-casual: el 98-99 % es más habitual (iteración rápida, menos QA). Compensación aceptable dado el formato del producto con sesiones cortas.
- Por debajo del 99 %: problema grave. Investiga de inmediato, publica correcciones urgentes diariamente hasta resolverlo.
- Por debajo del 97 %: existencial. Pausa las nuevas funciones, centra la ingeniería en la estabilidad hasta recuperarse.
Una tasa de fallos del 1 % no es «solo un 1 %» — es catastrófica. Si 1 de cada 100 sesiones falla y el usuario promedio tiene 5 sesiones por semana, aproximadamente el 5 % de los usuarios sufrirá un fallo en cualquier semana, más del 20 % a lo largo de un mes. Cada evento de fallo aumenta significativamente la probabilidad de desinstalación — impacto típico: una tasa de fallos del 1 % (99 % de sesiones sin fallos) reduce la retención D7 entre un 10 y un 20 % y aumenta la tasa de desinstalación D30 entre un 15 y un 30 % frente a una línea base del 99,5 %+. Número absoluto pequeño, enorme impacto en el negocio.
Herramientas de seguimiento de fallos
- Firebase Crashlytics — seguimiento de fallos gratuito de Google. Líder del mercado por adopción (estimado ~70 % de las apps Android; cuota sustancial en iOS). Simbolización sólida de stack traces, alertas en tiempo real, integración con BigQuery para análisis más profundo.
- Sentry — potente monitorización de fallos y errores multiplataforma con alcance más amplio (no solo fallos, también errores no fatales). Popular en equipos con cultura de ingeniería fuerte.
- Bugsnag (ahora SmartBear) — funcionalidades equivalentes a Sentry; habitual en enterprise.
- Apple App Store Connect / Google Play Console — paneles de fallos nativos de las tiendas. Úsalos como verificación cruzada; no dependas solo de ellos (detalle de stack trace limitado, agregación más lenta).
Disciplina de proceso: cada versión debería tener un umbral documentado de tasa de sesiones sin fallos antes del despliegue amplio. Los despliegues por fases (staged rollout de Google Play, lanzamiento por fases del App Store) te permiten detectar una regresión de estabilidad en el 1-5 % de los usuarios antes de que afecte al 100 %. Establece un umbral claro (p. ej., «pausar el despliegue si la tasa de sesiones sin fallos cae por debajo del 99,3 % en el primer 1 % de usuarios») y cúmplelo.