Real User Monitoring

Real user monitoring (RUM) is a way of measuring how a website or application behaves for the people who actually use it. A small piece of code in the page, or an SDK in a mobile app, records timings and errors during each real visit and sends them to a collection service for analysis.

The word “real” is the point. A lab test shows how a page loads on one fast machine in one data center. RUM shows how it loads on a three-year-old phone on a train, over a weak network, with a browser extension injecting its own scripts. Those conditions are too varied to reproduce, so the only way to know them is to measure them where they happen.

RUM is passive: it adds no test traffic and only observes. It is one half of digital experience measurement, the other being synthetic monitoring, and it is one reading of the wider term end user monitoring, which also covers activity tracking. It belongs to the general practice of monitoring. Despite the name, the “user” here is a visitor session, not an employee under review.

Whatever the vendor, a RUM setup follows the same path from the visitor's device to a dashboard.

1. 1

   Instrument

   Add a script to the page or an SDK to the app. It registers observers for the performance data the browser already exposes.

2. 2

   Collect

   As the visit goes on, the script reads timings for navigation, resources, painting, and interactions, and notes JavaScript errors and failed requests.

3. 3

   Enrich

   Each record gets context: the page or screen, browser, device class, connection type, rough location, and a session identifier.

4. 4

   Send

   The script sends the data in small batches as a beacon, ideally when the page is hidden or closed, so the visit itself is not slowed down.

5. 5

   Aggregate

   The backend groups records by page, release, country or device and shows distributions, trends, and alerts.

RUM records many signals, but three are standard in web work. They are called Core Web Vitals, and Google publishes target values that count as good when they are met for at least 75 percent of visits. Beyond these, RUM usually tracks server response time (TTFB), JavaScript errors, the duration of API calls made by the page and, in mobile apps, crashes and start-up time.

RUM data is a distribution, not a single number. An average hides the visitors who suffer most, so teams read percentiles: the median shows the typical visit, while the 75th or 95th percentile shows the slow tail. Compare the same percentile across releases, or a change in the mix of visitors will look like a change in the site.

The real value comes from slicing. Break the data down by device class, browser, connection type, page template and geolocation, and the problem usually names itself: a heavy script that hurts only low-end phones, a region far from the nearest server, a release that raised the error rate for one browser version. The method has blind spots too. It sees only the visits that loaded the script, and blockers and consent choices remove some of them.

RUM is rarely used alone. Synthetic monitoring runs scripted checks from fixed locations on a schedule, and application performance monitoring (APM) traces what happens inside the servers. Each answers a different question:

Most disappointing RUM projects fail in familiar ways:

• Reading averages instead of percentiles, so the slowest visitors stay invisible
• Comparing periods with a different mix of devices, countries or traffic sources, then crediting the last release
• Collecting full URLs with query strings, form values or user identifiers the question never needed, a problem that anonymization at the source would remove
• Sampling so aggressively that rare pages and rare errors disappear
• Watching speed alone and never linking it to outcomes such as bounce rate, conversion or support requests

RUM data serves several teams, and each wants a different cut of it. It is also worth saying what RUM is not for: it is not a tool for watching individual employees, and that job belongs to user activity monitoring.

RUM is performance data, but it can still be personal data. IP addresses, device characteristics, session identifiers and URLs can point to a person, so data protection law may apply, and in the EU the ePrivacy rules on storing or reading information on a device can require consent. A privacy-friendly setup avoids persistent identifiers, shortens IP addresses, strips query strings, and respects the choice made in the consent banner. Check the details for your markets with legal counsel.

A sensible start is small. Pick the three or four pages that earn the most, measure the Core Web Vitals on them, set an alert on the 75th percentile and review it after each release. If your question is about what employees do rather than how a site performs, the right category is employee activity monitoring, which uses different data and different safeguards.