Monitoreo de usuario real: por qué el promedio te miente

El reporte del mes dice que el tiempo de carga promedio del ERP de la emperesa es de 1.8 segundos. Nadie se puede quejar de 1.8 segundos.

Y aun así el gerente de una sucursal insiste en que el sistema está lentísimo, y lleva tres meses insistiendo, y cada vez que alguien de TI va a revisar encuentra todo normal. La conversación se repite hasta que se vuelve un tema de carácter: unos dicen que exagera, él dice que nadie le hace caso.

Los dos tienen razón. El promedio es cierto y la queja también. Lo que falta es la medición que las reconcilia.

Qué mide el monitoreo de usuario real

El monitoreo de usuario real —RUM, por sus siglas en inglés— mide lo que experimentaron los usuarios reales, en sus equipos, con su red, sus elnaces, mientras trabajaban. No una prueba, no una simulación: la sesión de cada persona.

Eso lo distingue del monitoreo sintético, que ejecuta pruebas programadas desde ubicaciones definidas. Los dos hacen falta y ya explicamos por qué en monitoreo sintético contra real user. Aquí va a fondo el segundo, porque es el que responde la pregunta que trae a la gente a esta conversación: ¿de verdad está lento, o son ganas?

Por qué el promedio te miente

Este es el punto que cambia todo lo demás.

Imagina cien sesiones. Noventa cargan en un segundo y diez tardan diez segundos. El promedio da 1.9 — un número tranquilizador. Pero hay diez personas cuya experiencia fue inaceptable, y son diez personas que van a llamar.

Un promedio bajo no significa que nadie sufre. Significa que los que sufren son minoría, y una minoría que se queja tiene teléfono.

Por eso el RUM se lee en percentiles, no en promedios:

1. p50 es la mediana: la mitad de las sesiones estuvo peor que ese número. Sirve para ver la tendencia general.
2. p75 es el que suele usarse como objetivo. Tres de cada cuatro sesiones estuvieron mejor.
3. p95 es donde vive la queja. Es la experiencia del peor cinco por ciento — y ese cinco por ciento no es aleatorio, casi siempre tiene algo en común.

Esa última frase es la parte útil. El p95 no está repartido al azar: se concentra en una sucursal, en un tipo de equipo, en un horario o en un proveedor de enlace. Cuando lo segmentas, la queja deja de ser una impresión y se vuelve un caso con alcance.

Lo que ninguna otra medición te dice

El valor del RUM no es el número, es de quién es el número. Al segmentarlo aparecen cosas que ni el sintético ni el monitoreo de infraestructura pueden ver:

1. Una sola ubicación es la lenta. Si la aplicación responde bien para todos menos para una sucursal, el problema no es la aplicación. Es el camino hasta esa sucursal. Quizá sea que están conectados vía VPN con un enlace residencial.
2. Un tipo de dispositivo es el lento. Los equipos de cinco años con el navegador cargado de extensiones son un mundo aparte, y nadie los usa en TI para probar.
3. Un horario es el lento. Si la degradación coincide con un proceso de sincronización entre DBs o con un respaldo, ya sabes contra qué está compitiendo.
4. Un proveedor de enlace es el lento. Cuando la ubicación lenta cambia según quién le da el enlace, la conversación se traslada al carrier con evidencia en mano.

Ese último caso es el que más veces hemos visto terminar bien. En operación, buena parte de lo que se reporta como "el sistema está lento" resulta ser un enlace degradado, no la aplicación — y sin datos por ubicación, esa discusión se pierde en suposiciones. Y ojo con la trampa de creer que un segundo enlace resuelve esto por sí solo: dos cables no son dos caminos.

Dónde el RUM no sirve

Y aquí está su límite, que conviene aceptar antes de montarlo:

El RUM necesita usuarios. A las tres de la mañana no hay nadie usando el sistema, así que no hay dato. Si el proceso de inicio de sesión se rompió a esa hora, el RUM te lo va a decir cuando llegue el primer usuario a las siete — que es exactamente cuando ya no era necesario que te lo dijeran.

En una aplicación interna con veinte usuarios pasa algo parecido durante todo el día: el volumen es tan bajo que un percentil no significa nada. Diez sesiones no hacen estadística.

Por eso los dos enfoques no son alternativas. El sintético cubre el silencio; el RUM cubre la realidad. Quien elige uno de los dos está eligiendo cuál mitad de los problemas no va a ver.

Las métricas que ya están estandarizadas

No hace falta inventar indicadores. Para aplicaciones web hay tres que ya son estándar y que se miden precisamente con datos de campo, no de laboratorio:

1. LCP — cuánto tarda en aparecer el elemento principal de la pantalla. Es la métrica de "ya puedo ver algo útil".
2. INP — cuánto tarda la página en responder a una interacción. Es la de "ya puedo trabajar", y en aplicaciones de captura es la que más duele.
3. CLS — cuánto se mueve el contenido mientras carga. Es la que hace que alguien le dé clic al botón equivocado.

Que estén estandarizadas tiene una ventaja práctica: dejan de ser discutibles. Un objetivo de p75 en una métrica pública es un acuerdo verificable, no una opinión sobre si el sistema se siente rápido — la misma diferencia que separa a un SLA que significa algo de uno decorativo.

Eso sí: un objetivo sin criterio de alerta se vuelve ruido en dos semanas. Dónde poner el umbral para no alertar por todo ni callar lo importante lo tratamos en umbrales de monitoreo.

Lo que hay que cuidar al instrumentarlo

El RUM se alimenta de sesiones de personas reales, así que trae obligaciones que el sintético no tiene:

1. No recolectes lo que no vas a usar. Para diagnosticar rendimiento necesitas tiempos, ubicación aproximada, tipo de dispositivo y ruta. No necesitas el contenido de los campos ni el texto que la persona escribió.
2. Cuidado con las URL. En muchos sistemas la ruta lleva identificadores dentro. Esa ruta se guarda en tu medición, y ahí puede quedar dato personal sin que nadie lo haya decidido.
3. Documenta qué se captura. Si mañana alguien pregunta qué guardas de sus empleados, la respuesta debe existir por escrito antes de la pregunta.

Cómo se ve esto en la práctica

La secuencia que a nosotros nos funciona es corta: instrumentar primero los dos o tres flujos que de verdad importan —el que factura, el que despacha, el que cobra—, leerlos por percentil y no por promedio, y segmentarlos por ubicación desde el primer día. Con eso, la siguiente vez que alguien diga "está lento" la respuesta es un dato con nombre y no una revisión a ciegas.

Y esa es la diferencia que justifica el trabajo: pasar de "no encuentro nada raro" a "tu sucursal está en el p95 desde el martes y las demás no, vamos a ver el enlace". Es la misma conversación, pero una se puede cerrar.

Nosotros lo operamos como parte del Centro de Operaciones, junto con el monitoreo de infraestructura y de enlaces.

Y la pregunta con la que conviene revisar tus tableros de hoy: ¿tu medición te dice qué tan lento estuvo, o te dice para quién estuvo lento? Si solo sabes lo primero, el gerente que lleva tres meses quejándose probablemente tiene razón.