TL;DR, Respuesta rápida
9 min de lecturaLa monitorización de usuarios reales son datos de campo: medidas de rendimiento y de error recogidas de forma pasiva desde visitas que personas reales hicieron con sus propios dispositivos y redes. La monitorización sintética son datos de laboratorio, recogidos por un navegador con script en un dispositivo fijo y una conexión fija. Lee el RUM en el percentil 75, porque una media esconde la cola lenta que decide si una página aprueba las Core Web Vitals.
¿Qué es la monitorización de usuarios reales (RUM)?
Los equipos de rendimiento web usan la monitorización de usuarios reales (real user monitoring, RUM) para recoger datos de rendimiento y errores de forma pasiva desde visitas reales en navegadores reales, de modo que cada medición lleva detrás un dispositivo, una red y una ubicación reales. El navegador informa las cifras a través de APIs estándar como PerformanceObserver, y el script las envía de vuelta cuando la página ya ha hecho su trabajo. Nada de la medición está simulado: si un visitante con un teléfono Android de cinco años esperó seis segundos en el Wi-Fi de un hotel, esos seis segundos entran en el conjunto de datos tal como se vivieron.
La palabra "pasiva" concentra casi todo el significado. La monitorización de usuarios reales no conduce el navegador, no elige la URL ni decide cuándo medir. El tráfico decide las tres cosas. Eso convierte al RUM en un censo de lo que ocurrió, no en una prueba de lo que podría ocurrir.
¿Cuál es la diferencia entre datos de campo y datos de laboratorio?
Los datos de campo vienen de visitas que hicieron personas reales, y los datos de laboratorio vienen de un navegador con script que tú configuraste y programaste. La monitorización de usuarios reales son datos de campo. La monitorización sintética son datos de laboratorio: un navegador headless carga una URL elegida con un perfil de dispositivo fijo, una limitación de CPU fija y una forma de red fija, cada pocos minutos, haya o no alguien en el sitio.
Las dos responden preguntas distintas, y el fallo habitual en la mayoría de equipos es pedirle a una la pregunta de la otra.
| Pregunta | Monitorización de usuarios reales | Monitorización sintética |
|---|---|---|
| A quién se mide | A cada visitante que carga la página | A un único agente con script |
| Dispositivo y red | Lo que tenga el visitante | Fijados por configuración |
| Cuándo se ejecuta | Solo cuando llega tráfico | Según un calendario que tú fijas |
| Forma del resultado | Una distribución entre visitas | Un número único repetible |
| Clase de dato | Campo | Laboratorio |
Si quieres el cara a cara completo, la comparación entre RUM y monitorización sintética va más a fondo que esta tabla.
¿Qué puede demostrar la monitorización de usuarios reales que la sintética no?
La monitorización de usuarios reales demuestra qué experimentaron tus visitantes, segmentado por las condiciones con las que llegaron. Como cada muestra lleva un dispositivo, un país, un tipo de conexión, una página y una versión, el RUM responde preguntas que un agente de laboratorio no está en posición de responder: si Safari en iOS es más lento que Chrome para tu checkout, o si el despliegue del martes empeoró la página de precios para usuarios de Brasil.
La monitorización sintética demuestra la clase opuesta de cosas. Un agente con script detecta un despliegue roto a las 3 de la madrugada cuando no hay nadie en el sitio, mantiene fija cada variable para que dos builds se comparen con honestidad, y se ejecuta contra una URL de staging antes de que la vea un solo usuario. La monitorización de usuarios reales no puede hacer nada de eso, porque no tiene datos hasta que alguien visita.
Usa ambas y enrútalas distinto. Los fallos sintéticos despiertan a un ingeniero de guardia. Las regresiones de RUM abren un ticket con el segmento afectado adjunto.
¿Cuáles son los umbrales de Core Web Vitals con los que se puntúa el RUM?
Google puntúa las tres Core Web Vitals en tres niveles, y los cortes publicados en web.dev por el equipo de Chrome siguen sin cambios en septiembre de 2026. Una página aprueba solo cuando las tres métricas son buenas en el percentil 75, medidas por separado para móvil y escritorio.
| Métrica | Qué mide | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | Tiempo hasta que se renderiza el elemento de contenido más grande | 2.5s o menos | 2.5s a 4.0s | Más de 4.0s |
| INP | Retardo entre una interacción y el siguiente pintado | 200ms o menos | 200ms a 500ms | Más de 500ms |
| CLS | Movimiento de diseño inesperado durante la vida de la página | 0.1 o menos | 0.1 a 0.25 | Más de 0.25 |
Cada métrica tiene sus propias causas de fallo, por eso Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift se depuran por separado y no como una sola puntuación. La visión general de las Core Web Vitals cubre cómo encajan las tres.
¿Por qué la monitorización de usuarios reales se lee en p75 y no como media?
Una media deja que una mayoría rápida esconda a una minoría lenta, y el percentil 75 no. El equipo de Chrome eligió el p75 para las Core Web Vitals para cumplir dos condiciones a la vez: la cifra tiene que describir la experiencia de la mayoría de las visitas, y tiene que resistir la distorsión de un puñado de valores atípicos. En p75, tres de cada cuatro visitas cumplieron el objetivo, y sesgar el resultado en un conjunto de 100 muestras exige 25 muestras malas en lugar de 5.
El índice de percentil para una lista ordenada de forma ascendente es:
index = ceil(0.75 × N)
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Veamos un ejemplo. Una página recoge 1,000 muestras de LCP. 700 de ellas caen en 0.9s en conexiones de escritorio rápidas, y 300 caen en 6.0s en móvil lento.
La media es (700 × 0.9 + 300 × 6.0) / 1000 = 2.43s, que se lee como buena frente al umbral de 2.5s.
El índice p75 es ceil(0.75 × 1000) = 750. Ordenada de forma ascendente, la muestra 750 cae dentro del grupo de 6.0s, así que el p75 de LCP es 6.0s. Eso es deficiente, y es la cifra que usa Google.
Mismo conjunto de datos, dos veredictos. La media aprobó la página mientras 300 personas reales esperaban seis segundos. Por eso un informe de monitorización de usuarios reales que solo muestra medias es peor que ningún informe, y por eso todo gráfico de rendimiento que merece la pena lleva p75, p90 y p99 junto al recuento.
- Mezcla 700 cargas rápidas de escritorio con 300 lentas de móvil
- Se lee como buena frente al umbral de 2,5 s
- La muestra 750 cae dentro del grupo lento de móvil
- Se lee como mala, y es la cifra que usa Google
¿Qué recoge un script de monitorización de usuarios reales?
Un script de RUM recoge eventos de tiempo y de error que emite el navegador, más contexto suficiente para segmentarlos: las Core Web Vitals, los tiempos de navegación y de recursos, los errores de JavaScript con sus trazas de pila, la ruta, y atributos gruesos de dispositivo, navegador y conexión. Nada de eso necesita una cookie ni un identificador persistente.
El peso es la restricción que decide si vale la pena ejecutar el script, porque cualquier cosa que retrase la página que mide corrompe la medición. Flowsery entrega un solo script de menos de 10 KB, sin cookies y alojado en la UE, y no aplica muestreo de datos, así que el p75 se calcula con cada sesión y no con un subconjunto. Junto a los tiempos registra la propia sesión y marca rage clicks, dead clicks, errores de JavaScript y abandonos, lo que convierte un p75 lento en un session replay que puedes ver en lugar de una cifra que tienes que adivinar.
¿Qué se le escapa a la monitorización de usuarios reales?
A la monitorización de usuarios reales se le escapa todo el que nunca llegó y todo el que se fue antes de que se disparara el beacon. Un visitante que abandona una página a los cuatro segundos no produce ninguna muestra de LCP, lo que sesga el conjunto de datos hacia los pacientes. Las páginas sin tráfico no producen datos, así que una ruta nueva o una pantalla de administración poco usada sigue invisible hasta que alguien la usa.
Otras dos brechas importan en la práctica. Los bloqueadores de contenido descartan algunas peticiones de analítica, así que la población recogida es un subconjunto de la real. Y el soporte de métricas difiere según el motor del navegador, así que una audiencia con mucho Safari da menos muestras para algunas vitals que una con mucho Chrome.
Cubre las brechas a propósito: ejecuta comprobaciones sintéticas en las rutas que aún no tienen tráfico, mantén el endpoint de recogida como first-party, y lee el RUM junto a la analítica web para ver si las sesiones que desaparecieron del gráfico de rendimiento también desaparecieron del funnel.
Preguntas frecuentes
¿Es la monitorización de usuarios reales lo mismo que la analítica web?
No. La analítica web cuenta visitas, fuentes, funnels y conversiones para responder preguntas de negocio. La monitorización de usuarios reales mide con qué rapidez y con qué fiabilidad se renderizaron y respondieron esas visitas. En la mayoría de herramientas las dos comparten un script y un identificador de sesión, y por eso un p75 de LCP lento y una caída en el cierre del funnel se pueden leer en la misma línea temporal.
¿Cuánto tráfico necesita la monitorización de usuarios reales para ser útil?
Muestras suficientes para que el percentil 75 sea estable en el segmento que estás leyendo. Una página con 40 visitas por semana produce un p75 que oscila con cada dispositivo poco común, así que agrega a nivel de plantilla o amplía la ventana antes de sacar conclusiones. Los cortes por segmento multiplican el requisito: leer el p75 por país y dispositivo a la vez necesita mucho más tráfico que leerlo a nivel de sitio.
¿La monitorización de usuarios reales ralentiza el sitio que mide?
Un script de RUM añade bytes y tiempo de ejecución, así que el tamaño del script decide la respuesta. Cargarlo de forma asíncrona, mantenerlo pequeño y enviar los beacons después de que la página se haya renderizado evita que la medición cambie lo medido. Un script de monitorización pesado que bloquea el renderizado empeora cada métrica que reporta.
¿Por qué mis datos de RUM no coinciden con Lighthouse?
Lighthouse son datos de laboratorio de un dispositivo simulado en una conexión limitada, y el RUM son datos de campo de una distribución de dispositivos reales. Un LCP de Lighthouse de 1.8s y un p75 de campo de LCP de 5.2s son ambos correctos: la ejecución de laboratorio describe una máquina que configuraste, la cifra de campo describe a tu audiencia. Corrige regresiones en el laboratorio, juzga el éxito en el campo.
¿Puede funcionar la monitorización de usuarios reales sin cookies?
Sí. Los beacons de rendimiento llevan tiempos, una ruta y atributos gruesos de dispositivo, y ninguno requiere un identificador persistente. Flowsery funciona sin cookies y alojado en la UE por esta razón, lo que mantiene intacto el conjunto de datos de campo en regiones donde los banners de consentimiento suprimirían la recogida.
¿Debo alertar sobre el p75 o sobre sesiones lentas individuales?
Alerta sobre el p75 del sitio y de las rutas de alto valor, porque esa es la cifra ligada al veredicto de las Core Web Vitals. Las sesiones lentas individuales van al triaje, no al alerting: una carga de 12 segundos en un teléfono dentro de un túnel no es una regresión. Agrupa primero las sesiones lentas por causa común y luego alerta cuando el grupo crezca.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
¿Puede la monitorización de usuarios reales mostrar si una regresión afecta solo a un país?
La monitorización de usuarios reales adjunta un país, una página y una versión a cada muestra, así que un equipo puede filtrar por esa combinación exacta. Comprobar si un despliegue del martes ralentizó la página de precios para los usuarios de Brasil es el tipo de pregunta que solo pueden responder datos de campo con ese contexto, porque un agente sintético se ejecuta desde una ubicación fija.
¿Cuenta la monitorización de usuarios reales a un visitante que abandona la página antes de que termine de cargar?
No, una visita que abandona antes de que se dispare el beacon no genera ninguna muestra, ni rápida ni lenta. Esto sesga el conjunto de datos recogido hacia los visitantes con paciencia para quedarse, así que la experiencia real de los impacientes nunca llega al informe.
¿Por qué los sitios con mucho tráfico de Safari muestran menos muestras de RUM?
Los motores de navegador difieren en qué APIs de Core Web Vitals exponen, así que el soporte de cada métrica no es igual en todos los motores. Un público con mucho Safari genera menos muestras para algunas métricas que uno con mucho Chrome con el mismo volumen de tráfico, lo cual es un hueco de cobertura y no una señal de mejor rendimiento.
¿Cuánto pesa el script de monitorización de usuarios reales de Flowsery?
Flowsery distribuye un único script de menos de 10 KB, sin cookies y alojado en la UE. No aplica muestreo de datos, así que el p75 que reporta se calcula con cada sesión y no con un subconjunto, y su tamaño reducido evita que la medición ralentice la página que mide.
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario
Cómo se calcula realmente el Cumulative Layout Shift
Cada puntuación de Cumulative Layout Shift es impact fraction por distance fraction, y Google reporta la mayor ráfaga de desplazamientos, no su suma.
Cómo Interaction to Next Paint puntúa tu peor clic
Chrome puntúa Interaction to Next Paint por la peor interacción de una página: input delay, processing y presentation delay hasta el siguiente frame pintado.
¿Cuánto ralentiza el session replay la velocidad de un sitio web?
La respuesta real a si el session replay ralentiza un sitio web, con cifras publicadas de rrweb y Sentry sobre script, CPU y ancho de banda de subida.
Cómo Largest Contentful Paint se divide en cuatro partes que puedes arreglar
La métrica Largest Contentful Paint se puntúa como bueno en 2.5 segundos o menos y se divide en cuatro subpartes, y la división dice cuál cuesta los segundos.
En qué se diferencian de verdad rage clicks vs dead clicks
La distinción rage clicks vs dead clicks va de causa, no de gravedad. Umbrales publicados por PostHog, Hotjar, FullStory, LogRocket y Clarity.
Dónde los valores por defecto de la redacción de PII en session replay dejan datos expuestos
Los valores por defecto de la redacción de PII en session replay varían: rrweb solo enmascara contraseñas, Sentry todo el texto, Clarity números y correos.
Artículos relacionados
Qué significa realmente el tráfico Unassigned en GA4
Un canal sin regla que lo recoja: el tráfico Unassigned en GA4 no es un valor ausente como (not set). Las reglas de Google explican la diferencia.
Por qué el significado de visitantes únicos cambia según la herramienta
El significado de visitantes únicos depende de la herramienta: GA4 lo estima, Matomo no lo calcula en rangos largos y Adobe deduplica en todo el informe.
Cómo las reglas de canal de GA4 resuelven utm_source vs utm_medium
Google define utm_source vs utm_medium en una línea cada uno. Las reglas de canal de GA4 deciden qué parámetro ordena de verdad tu tráfico. Ambas, citadas.