What Is Real User Monitoring (RUM)?
RUM defined: field performance data from actual visitors, how it differs from synthetic testing, and what a RUM setup captures.
Real User Monitoring (RUM) is performance measurement collected from actual visitors during actual visits — load times, Web Vitals, errors, as experienced on real devices over real networks. Its opposite is synthetic monitoring: scripted tests from data centers (Lighthouse, WebPageTest, uptime checkers) running on schedules in idealized conditions.
What RUM captures
- Navigation timing per pageview: TTFB through full load.
- Core Web Vitals from the field — LCP, CLS, and especially INP, which synthetic tools structurally cannot measure (no robot clicks like a frustrated human).
- The distribution dimensions: device class, country, connection — the data that turns 'the site is slow' into 'Android visitors in Brazil wait 6 seconds'.
RUM vs synthetic: both, for different jobs
| Question | Tool |
|---|---|
| What do users actually experience? | RUM |
| Did this code change regress performance, pre-deploy? | Synthetic (CI Lighthouse) |
| What does Google rank us on? | Field data (RUM-class, via CrUX) |
| Is the site up at 3 AM? | Synthetic |
The integration argument
Standalone RUM products exist, but performance data divorced from behavior answers only half of any real question. 'p75 LCP is 3.1 s' is a fact; 'visitors who experienced >3 s LCP converted at half the rate' is a budget decision. That join requires performance and behavior on the same record — which is why Clycyo treats RUM as a built-in dimension of analytics rather than a separate subscription: the same 1.1 KB tracker that counts the pageview times it, and the journey timeline shows the slow load next to the abandonment it caused.
If you run synthetic checks in CI and RUM in production analytics, you have the full loop: prevention before deploy, truth after.