Monitoreo de Usuarios Reales (RUM)

El monitoreo de usuarios reales (RUM, por Real User Monitoring) es una forma de medir cómo se comporta un sitio web o una aplicación para las personas que de verdad los usan. Un pequeño fragmento de código en la página, o un SDK en la aplicación móvil, registra tiempos y errores en cada visita real y los envía a un servicio de recopilación para su análisis.

La palabra «reales» es la clave. Una prueba de laboratorio muestra cómo carga una página en una sola máquina rápida, en un solo centro de datos. El RUM muestra cómo carga en un celular de tres años, dentro de un tren, con una red débil y una extensión del navegador que inyecta sus propios scripts. Esas condiciones son demasiado variadas para reproducirlas, así que la única manera de conocerlas es medirlas donde ocurren.

El RUM es pasivo: no genera tráfico de prueba, solo observa. Es una de las dos mitades de la medición de la experiencia digital, y la otra es el monitoreo sintético; además, es una de las lecturas del término más amplio monitoreo de usuarios finales, que también abarca el seguimiento de la actividad. Forma parte de la práctica general del monitoreo. A pesar del nombre, el «usuario» aquí es la sesión de un visitante, no un empleado bajo evaluación.

Sea cual sea el proveedor, una implementación de RUM sigue el mismo camino, del dispositivo del visitante al panel de control.

1. 1

   Instrumentar

   Agrega un script a la página o un SDK a la aplicación. Registra observadores de los datos de rendimiento que el navegador ya expone.

2. 2

   Recopilar

   Durante la visita, el script lee los tiempos de navegación, recursos, renderizado e interacciones, y anota los errores de JavaScript y las solicitudes fallidas.

3. 3

   Enriquecer

   Cada registro recibe contexto: la página o pantalla, el navegador, la clase de dispositivo, el tipo de conexión, la ubicación aproximada y un identificador de sesión.

4. 4

   Enviar

   El script envía los datos en lotes pequeños como un beacon, de preferencia cuando la página se oculta o se cierra, para no retrasar la propia visita.

5. 5

   Agregar

   El servidor agrupa los registros por página, versión, país o dispositivo y muestra distribuciones, tendencias y alertas.

El RUM registra muchas señales, pero tres son estándar en el trabajo web. Se llaman Core Web Vitals, y Google publica valores objetivo que se consideran buenos cuando se cumplen en al menos el 75 % de las visitas. Además de estas, el RUM suele seguir el tiempo de respuesta del servidor (TTFB), los errores de JavaScript, la duración de las llamadas a API que hace la página y, en las aplicaciones móviles, los cierres inesperados y el tiempo de arranque.

Los datos de RUM son una distribución, no una cifra única. El promedio oculta a los visitantes que más sufren, por eso los equipos leen percentiles: la mediana muestra la visita típica, mientras que el percentil 75 o 95 muestra la cola lenta. Compara el mismo percentil entre versiones, o un cambio en la mezcla de visitantes parecerá un cambio en el sitio.

El valor real viene de segmentar. Separa los datos por clase de dispositivo, navegador, tipo de conexión, plantilla de página y geolocalización, y el problema suele delatarse solo: un script pesado que perjudica únicamente a los celulares modestos, una región lejana al servidor más cercano, una versión que subió la tasa de errores en una sola versión del navegador. El método también tiene puntos ciegos. Solo ve las visitas en las que se cargó el script, y los bloqueadores y las decisiones de consentimiento eliminan algunas.

El RUM rara vez se usa solo. El monitoreo sintético ejecuta verificaciones con guion desde ubicaciones fijas y en horarios programados, y el monitoreo del rendimiento de aplicaciones (APM) rastrea lo que ocurre dentro de los servidores. Cada uno responde una pregunta distinta:

La mayoría de los proyectos de RUM que decepcionan fallan de maneras conocidas:

• Leer promedios en lugar de percentiles, de modo que los visitantes más lentos quedan invisibles
• Comparar periodos con una mezcla distinta de dispositivos, países u orígenes de tráfico y atribuir el cambio a la última versión
• Recopilar URL completas con parámetros, valores de formularios o identificadores de usuario que la pregunta nunca necesitó, un problema que la anonimización en el origen eliminaría
• Muestrear de forma tan agresiva que desaparecen las páginas y los errores poco frecuentes
• Mirar solo la velocidad y no vincularla nunca con resultados como la tasa de rebote, la conversión o las solicitudes de soporte

Los datos de RUM sirven a varios equipos, y cada uno quiere un recorte distinto. También conviene decir para qué no sirve el RUM: no es una herramienta para vigilar a empleados individuales, y esa tarea corresponde al monitoreo de la actividad de los usuarios.

El RUM trata datos de rendimiento, pero aun así pueden ser datos personales. Las direcciones IP, las características del dispositivo, los identificadores de sesión y las URL pueden señalar a una persona, por lo que puede aplicarse la ley de protección de datos, y en la UE las reglas de ePrivacy sobre almacenar o leer información en el dispositivo pueden exigir consentimiento. Una configuración respetuosa de la privacidad evita los identificadores persistentes, acorta las direcciones IP, elimina los parámetros de las URL y respeta la decisión tomada en el banner de consentimiento. Confirma los detalles de tus mercados con asesoría jurídica.

Un buen comienzo es pequeño. Elige las tres o cuatro páginas que más ingresos generan, mide en ellas los Core Web Vitals, configura una alerta sobre el percentil 75 y revísala después de cada versión. Si tu pregunta es qué hacen los empleados y no cómo rinde un sitio, la categoría adecuada es el monitoreo de la actividad de los empleados, que usa otros datos y otras salvaguardas.