Real user monitoring
Core Web Vitals from real visitors: what the script collects, what it never collects, sampling, quotas and how to read the dashboard.
Updated
What it measures
A 2 KB script observes the browser's Performance APIs and sends one beacon per sampled page view when the page is hidden: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, Time to First Byte, First Contentful Paint and the load event, plus the count of uncaught JavaScript errors. The dashboard shows p75 values and the share of good, needs-improvement and poor views using the published Web Vitals thresholds.
What it never collects
- No cookies, local storage or fingerprinting; no user or session identifiers.
- No query strings or fragments: only the path, with long numbers, UUIDs and e-mail-like segments replaced by placeholders.
- No form contents, no error messages, no stack traces, no IP addresses. Country appears only if your reverse proxy adds a geo header.
- Visitors with Do Not Track enabled are skipped by the script.
Installing
Create a site, list the origins that may send data and paste the snippet before the closing body tag. Beacons from other origins are dropped. Lower the sample rate on busy sites: the allowance counts accepted events per calendar month across the account.
Field data versus lab data
RUM values come from real devices, networks and locations and vary widely; synthetic browser checks run from a fixed probe. Use RUM to learn what visitors experience and synthetic checks to detect regressions quickly. The two are shown in separate places and never averaged together.
What counts as an event
One quota-counted event is one beacon that parses, names an enabled site, arrives from an allowed origin, carries a page-view id not seen in the previous 15 minutes and fits the account's monthly allowance. Invalid payloads and unknown keys are dropped silently, duplicates are dropped without touching the quota, and beacons beyond the allowance are counted as rejected and never stored. Raw events are kept 7 days and hourly aggregates 400 days.
Trust limits of field data
- The site key in the snippet is public by design: it identifies a site, it does not authenticate anyone. Anyone who can read your page can send beacons with it, which is why origins are checked, duplicates are discarded and per-key and per-address rate limits bound what a forged client can make the account consume.
- Sampling runs in the browser and cannot be verified by the collector; treat view counts as sampled estimates, never as traffic analytics.
- Metric values are reported by the browser and could be forged by a hostile visitor; percentiles are robust to a few outliers, but RUM is not a security signal or an SLA source.
- Device, browser and country are coarse classifications; country appears only when a trusted reverse proxy adds it.
Limits
- Beacons are limited to 4 KB, 600 per minute per site key and 120 per minute per source address; each page-view id is accepted once per 15 minutes.
- Raw beacons are kept 7 days and aggregated hourly per path, device and country; aggregates are kept 400 days.
- Percentiles use bounded samples per hourly cell and are approximate. INP needs an interaction, so some views carry no INP.