Real-user monitoring setup

What real-user monitoring adds

The Chrome UX Report gives a free, aggregated view of how Chrome users experience your origin and popular pages, updated over a rolling 28-day window (source 1). It is a good health check but leaves gaps: it covers Chrome users who meet its eligibility rules, it does not tell you which element or script caused a poor value, and low-traffic pages may not appear at all.

Your own monitoring fills those gaps. With the attribution build of Google's open-source web-vitals library, each LCP, INP and CLS report can carry the element involved, the phase breakdown and, for INP in Chromium browsers, the Long Animation Frames entries and scripts that overlapped the interaction (source 2). That is the information that turns a dashboard into a fix list.

What we set up

• The collector. A small script using web-vitals that reports metrics when the page is hidden or unloaded, with attribution fields you choose.
• Context fields. Route template, device class, connection type where available, app version and whether the visit happened during start-up or later.
• Sampling. A sampling rate that keeps data volume and cost reasonable while still giving stable 75th percentile values for important routes.
• Transport and storage. An endpoint you control or an analytics tool you already use. We have no affiliation with any monitoring vendor and do not resell one.
• Dashboards. Views by route and device class at the 75th percentile, matching how Core Web Vitals thresholds are defined (source 3).
• Alerts. Optional alerts for regressions after releases.

Privacy by design

Performance data can still contain personal information. URLs may include identifiers or search terms, element selectors may include user-generated text, and IP addresses reach whatever endpoint receives the data. We design collectors to avoid sending these: URLs are reduced to route templates, selectors are truncated, and no user identifiers are attached.

In Canada, PIPEDA's fair information principles, including limiting collection and openness, generally apply when businesses handle personal information in their commercial activities (source 4). In Quebec, section 8.1 of the private-sector privacy act, introduced by Law 25, requires businesses using technology that can identify, locate or profile a person to inform them and explain how to activate those functions, which some commentators read as requiring such functions to be off by default (source 5). A carefully stripped performance collector is designed to fall outside that category, but your legal advisers should confirm how it fits your own privacy notice and consent setup. We are not lawyers and this is not legal advice.

How the engagement runs

1. 01

   Decide what to measure

   Agree the metrics, attribution fields, context fields and routes with your team.

2. 02

   Build and review the collector

   We write the collector in your codebase or as a small package, and you review it like any other pull request.

3. 03

   Wire up storage and views

   Connect to your endpoint or tool and build the first dashboards.

4. 04

   Check the data

   After a week of traffic, we check sample sizes, look for gaps and adjust sampling.

Keeping the collector healthy

A collector is code like any other and can break silently. We add a simple check that alerts when the number of reports per day drops sharply, which catches a broken release or a blocked endpoint, and document how to update the web-vitals library when new versions change attribution fields.

What you receive

The collector code, documentation for your team, the dashboard definitions, a short note describing what data is collected for your privacy notice, and a call to walk through the first week of data.

What good dashboards show

A dashboard should answer three questions quickly: which routes are outside the "good" thresholds at the 75th percentile, whether that changed after the last release, and what the attribution says about the worst routes. We build views that put the 75th percentile per route and device class next to the sample count, so thin data is visible, and that let you drill from a route into its slowest interactions and their phases.

We avoid averages for these metrics. A mean hides the slow tail that the 75th percentile is designed to capture, and Core Web Vitals thresholds are defined at that percentile.

Sample sizes and patience

Percentiles need enough samples to be stable. A route with a few dozen visits a day will show a noisy 75th percentile from one day to the next, so dashboards should aggregate over longer windows for quiet routes and flag when a sample is too small to trust. Planning for this from the start avoids false alarms after releases and stops teams from chasing changes that are only noise.

Questions about monitoring