Monitorización de fallos y rendimiento de una app móvil
Monitorizar los fallos permite ver los errores antes de que los usuarios se quejen: qué métricas vigilar, qué herramientas usar y cómo priorizar lo que llega.
Equipo de rabbitclipPublicación: 7 min. de lectura
En breve
La monitorización de fallos de una app móvil es una configuración que, cada vez que la app se cierra en el teléfono de un usuario, recoge automáticamente dónde ocurrió el error, en qué dispositivo y en qué versión, y se lo comunica a usted. La monitorización del rendimiento mide del mismo modo los problemas más difusos: tiempo de arranque, tirones y consumo de memoria. Con ambas ve la salud real de la app en manos de los usuarios. Sin ellas decide solo por las reseñas de las tiendas, y esas reseñas son la voz de una pequeña parte de las personas que se toparon con el problema.
Quien sufre un cierre inesperado de la app normalmente no le escribe. La cierra, lo intenta una vez más y luego la borra. Una app que funciona bien en sus teléfonos de prueba puede comportarse de otro modo en un dispositivo de hace tres años o con una conexión débil. La monitorización es la única manera de hacer visible a ese grupo invisible.
¿Son lo mismo la monitorización de fallos y la del rendimiento?
No, responden a preguntas distintas. La monitorización de fallos captura el momento en que la app se cierra: en qué línea de código, en qué dispositivo, en qué versión del sistema y qué estaba haciendo el usuario en ese momento. La del rendimiento mide lo que se siente mal incluso cuando la app no se cierra: una pantalla lenta, un desplazamiento con tirones, una memoria que se hincha.
En Android hay un tercer tipo de fallo, la aplicación que no responde, conocida como ANR. La app no se cierra, pero se congela, y el sistema ofrece al usuario la posibilidad de cerrarla. Una buena configuración de monitorización muestra por separado estos tres grupos: fallos, falta de respuesta y lentitud.
¿Qué métricas conviene vigilar?
Unos pocos indicadores con sentido son mejores que un muro de gráficos. El primero es la tasa de sesiones sin fallos: la probabilidad de que una sesión termine sin error una vez que el usuario abre la app. Compárela entre versiones; si baja en la nueva versión, esta ha introducido una regresión.
El segundo grupo son los indicadores de rendimiento. Los paneles de las tiendas ofrecen además sus propias cifras de salud. Google Play Console y las herramientas para desarrolladores de Apple muestran gratis datos de fallos y falta de respuesta recogidos de los usuarios, y para la mayoría de los negocios ese es el punto de partida.
- Tasa de sesiones sin fallos, comparada versión por versión
- Tiempo de arranque en frío: con qué rapidez abre la app cuando estaba totalmente cerrada
- Frecuencia de fotogramas lentos y congelados: la fluidez del desplazamiento y de las transiciones
- Eventos de falta de respuesta (ANR) y modelos de dispositivo afectados
¿Qué herramientas y datos conviene recoger?
Existen servicios listos para usar, muy extendidos, para informar de fallos; Firebase Crashlytics y Sentry son ejemplos conocidos. La elección depende de la infraestructura que el equipo ya utiliza y de lo que necesite monitorizar. Más que el nombre de la herramienta, lo que marca la diferencia es que la configuración sea correcta.
La parte de la configuración que más se omite es hacer legible el informe. El código de una app publicada está ofuscado y despojado de nombres; para que un informe de fallo sea legible, debe subir al servicio de monitorización, con cada versión, los archivos de símbolos y de mapeo correspondientes. Si no lo hace, el informe es una lista de direcciones sin sentido y nadie puede decir dónde está el error.
Los informes llevan también contexto: los últimos pasos del usuario, el número de versión, el modelo del dispositivo, el estado de la red. Cuide de que ese contexto no contenga datos personales; nombres, direcciones de correo y datos de tarjeta no deben entrar nunca en un informe. Cómo acaban los datos personales en los registros conviene hablarlo con un abogado o con un delegado de protección de datos.
¿Cómo se priorizan los fallos que llegan?
Una vez en marcha la monitorización, la primera semana produce una lista de decenas de fallos, y perseguirlos todos es imposible. La prioridad se apoya en dos pruebas: a cuántos usuarios afecta y en qué momento de su recorrido ocurre. Un solo fallo durante el pago, el inicio de sesión o el registro va antes que uno frecuente pero inofensivo en la pantalla de ajustes.
Un fallo que aparece con una nueva versión se trata aparte, porque es una regresión y suele ser el tipo más rápido de corregir. Cuando es posible, desplegar una nueva versión por etapas entre los usuarios permite detener el lanzamiento si aparece un problema.
- Número de usuarios afectados y frecuencia con que se repite
- El momento en que ocurre: primero pago, inicio de sesión y registro
- Si empezó con la nueva versión, es decir, si es una regresión
- El grupo de dispositivo y versión del sistema afectado
¿Qué errores son comunes en la monitorización de fallos y rendimiento?
El error más común es configurar la monitorización después del lanzamiento, de modo que la primera oleada de fallos pasa inadvertida. El segundo es recoger informes que nadie lee. Una persona o un rol debe revisar los fallos con regularidad y vigilar de cerca los primeros días tras cada versión.
El tercero es probar solo en los teléfonos más nuevos. La base real de usuarios incluye dispositivos más antiguos y conexiones lentas, y ahí es donde suelen aparecer los problemas de rendimiento.
- Configurar la monitorización después del lanzamiento
- No subir los archivos de símbolos y de mapeo y dejar los informes ilegibles
- Recoger informes sin que nadie los revise con regularidad
- Escribir datos personales en los informes o en los registros
¿Cuándo es innecesaria o prematura la monitorización del rendimiento?
Para una app que no se ha lanzado y no tiene usuarios, un panel detallado de rendimiento es prematuro; no hay datos que interpretar. En esa fase basta con configurar el informe de fallos, porque desde los primeros usuarios reales le da una protección casi gratuita que requiere poco mantenimiento.
Una pila de monitorización compleja también es innecesaria para una app corporativa sencilla, con pocos usuarios y que rara vez se abre; los datos de salud gratuitos de los paneles de las tiendas pueden bastar. La prueba es esta: si la monitorización no cambia una decisión que usted tomaría, sobra.
La monitorización de fallos y rendimiento es la manera de ver la app como los usuarios la viven de verdad, mientras que las reseñas de las tiendas solo muestran la parte más ruidosa del problema. Configure la monitorización antes del lanzamiento, suba con cada versión los archivos que mantienen legibles los informes, revise con regularidad unas pocas métricas con sentido y ordene los fallos según a cuántos usuarios afectan. Si desea ayuda para decidir cómo vigilar la salud de su app, puede concertar una conversación de descubrimiento con rabbitclip.
Preguntas frecuentes
¿Qué es la tasa de sesiones sin fallos?
Es la proporción de sesiones que van desde el inicio de la app hasta su cierre sin un fallo. Comparada entre versiones, ofrece una lectura rápida de la estabilidad de una nueva versión.
¿Debo usar una herramienta ya hecha para monitorizar fallos?
Para la mayoría de los negocios, sí. Servicios muy extendidos como Firebase Crashlytics y Sentry ofrecen una solución lista, y construir la propia rara vez aporta valor. La diferencia real está en configurarla bien y subir los archivos de símbolos.
¿Bastan por sí solos los paneles de las tiendas?
A menudo bastan para empezar, ya que muestran gratis datos de fallos y falta de respuesta. Para ver dónde y en qué paso ocurre un fallo, y para comparar entre versiones, suele hacer falta una herramienta de monitorización aparte.
¿Cuentan como datos personales los datos de monitorización?
Pueden serlo, si un informe incluye información que identifique al usuario. Procure no añadir a los informes nombres, direcciones de correo ni datos de pago, y consulte a un abogado sobre la situación legal de su app.
