Growth Notes

Real User Monitoring

Tags: web-dev analytics concept

Real User Monitoring

Date: 2026-08-16

Collecting performance measurements from actual visits, so you can segment them by the things that matter — template, device, country, traffic source. It’s the only performance data that answers who is having a bad time.

What it is

Real user monitoring (RUM) is instrumenting your own pages to record timing data from real sessions and send it somewhere you can query.

Public field data (CrUX) tells you whether you pass. RUM tells you which pages, which devices and which countries are failing, today rather than on a 28-day lag — see Field vs Lab Data.

What to collect

The browser exposes everything you need through standard APIs:

import { onLCP, onINP, onCLS, onTTFB } from 'web-vitals/attribution';
 
const send = ({ name, value, rating, attribution }) => {
  navigator.sendBeacon('/rum', JSON.stringify({
    metric: name, value, rating,
    page_template: window.PAGE_TEMPLATE,
    element: attribution.element,          // what caused it
    phase: attribution.lcpEntry,           // where the time went
  }));
};
 
onLCP(send); onINP(send); onCLS(send); onTTFB(send);

Collect attribution, not just values. A dataset of LCP numbers tells you there’s a problem. A dataset including which element was the LCP candidate and which phase dominated tells you what to do — that difference is most of RUM’s value.

Alongside the metrics, record the dimensions you’ll want to slice by:

  • Page template — not URL. Product pages as a class, not 40,000 individual products
  • Device category and, if available, an effective connection type
  • Country
  • Whether the visit was cached, if you can infer it
  • Traffic source, so performance connects to acquisition

Sending it without making things worse

RUM measures performance, so it must not cost any.

  • navigator.sendBeacon — fire-and-forget, survives page unload, doesn’t block. The right default
  • Batch and send once, on visibilitychange, not one request per metric
  • Sample if volume demands it. 10% of traffic is plenty for p75 on a busy site, and sampling must be random rather than by user characteristic or you bias the distribution — Sampling Methods
  • First-party endpoint. A third-party RUM script is subject to the same blocking as any other tag — Ad Blockers and Tracking Loss

Reading it

  • p75 by segment, never means — Percentiles in Performance
  • Template first. Site-wide numbers hide that the homepage is fine and category pages are terrible
  • Device second. Mobile and desktop are effectively different sites
  • Watch the histogram, not the point value. A bimodal LCP usually means cache hit versus miss
  • Annotate deploys so a step change has a candidate cause — Annotation and Change Logs

The measurement problems it inherits

RUM is analytics, so it has every analytics problem:

  • Consent gating. If RUM only runs after consent, your data excludes everyone who declined, and they aren’t a random sample — Consent Management
  • Blocking. A blocked beacon is a missing measurement, and blocking correlates with device and technical sophistication
  • Survivorship. Users who abandoned before the page finished loading may never send a metric, so the slowest experiences are systematically under-represented. Your RUM data is biased optimistic, and you cannot fix this — only know it. See Survivorship Bias
  • Bots. Filter them, or synthetic traffic skews the distribution — Bot and Internal Traffic

In plain terms: the people having the worst experience are the least likely to be in your performance data, because they left before it was sent. Whatever your p75 says, reality is slightly worse.

Where it goes

Options, roughly by cost:

  • A vendor RUM product — fastest to value, another third-party script
  • Your own endpoint into BigQuery — full control, segmentable against your other event data, and it joins to conversion, which is what makes Performance and Conversion analysable
  • CrUX in BigQuery — free, public, aggregated, no per-user detail

The second is the one worth building if performance is going to be a sustained programme, because joining performance to revenue in the same warehouse is what turns it from an engineering metric into a commercial one.

Graph View

Backlinks