Real-User Monitoring
Real-user monitoring collects performance and error data from actual sessions, revealing the long tail of devices, networks, and geographies that labs miss.
Definition
Real-user monitoring measures performance and reliability from real user sessions in browsers or apps, capturing field data rather than controlled lab measurements.
Context and scope
Used to track Core Web Vitals, client-side errors, and journey performance across devices, networks, and regions.
Common misconceptions
- Real-user monitoring measures only page load time
- Lab and field measurements should always agree
- Collecting real-user data has no privacy implications
Anti-patterns
- Reporting averages while ignoring the slowest segment
- Capturing identifiers and full URLs without consent or scrubbing
- Using real-user data to reproduce defects rather than to detect and prioritize them
Related concepts
Authoritative source
Field data from real sessions
Real-user monitoring instruments actual sessions and reports what users experienced: load and interaction timing, resource failures, JavaScript errors, and sometimes API calls. Unlike lab tests on a fixed device and network, it captures the long tail: old phones, slow connections, browser extensions, and distant regions. That tail is often where complaints originate, even when average metrics look healthy.
What it captures
Common measurements include navigation timing, Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, and error counts. Tag data with route, release, device class, connection type, and region so regressions can be attributed. Page views alone are not enough; attach outcomes such as successful checkout or failed search. For single-page applications, instrument route transitions and client-side fetches, not only the initial document.
Percentiles, not averages
Averages hide the users who suffer. Report p75 and p95 by segment, and watch the slowest cohort separately. A median load time of 1.2 seconds can coexist with a p95 of 9 seconds on mobile in one region. Segmenting by device and geography turns a vague performance number into an actionable defect.
Privacy and sampling
Collect only what is needed. Avoid recording full URLs, form values, or identifiers without consent and scrubbing. Sample high-volume sessions to control cost, but keep enough slow and failed sessions to diagnose them. Be explicit about retention and access. Compared to synthetic monitoring, real-user data shows impact but is noisier and less reproducible.
Limits
Real-user monitoring cannot tell you why something failed, only that users experienced it. It also depends on client cooperation: blockers, offline users, and crashes can bias the sample. Pair it with synthetic checks and server-side traces for diagnosis. For example, a rising p95 may come from a new third-party script, a slow API, or a specific device, and only traces and release tags reveal which.