CrUX or your own RUM: when free field data stops being enough

The short answer

The Chrome User Experience Report (CrUX) gives you real user data for free, with no code to install. It is the dataset behind Google's page experience signal, and it is public for every eligible site, including your competitors. That makes it the right place to start and a permanent reason to keep watching.

You move to your own real user monitoring when CrUX stops answering the question you actually have. That moment arrives sooner than most teams expect, because CrUX aggregates over a rolling 28 days at the 75th percentile, covers one browser, and excludes any page that is not publicly discoverable. Your checkout is usually invisible to it.

Moving does not mean giving up the score you already report on. The UX Score is a weighted composite of five Web Vitals, so once those metrics are in your own platform it is a formula in a query. We do exactly that for Frasers Group in Honeycomb.

What CrUX gives you for free

• Real users, no instrumentation. No tag to place, no consent flow to build, no data volume to pay for.
• The number Google uses. The page experience signal reads CrUX, not your RUM. Whatever else you measure, this is the scoreboard for search.
• Public competitor data. Every eligible origin is in the dataset, so you can benchmark against direct competitors without their cooperation. Our UX Score benchmark and e-commerce scorecards are built on exactly this.
• Both origin and page level. You can look at a whole site or at individual URLs.

If you are not yet looking at CrUX at all, start there. Everything below is about the point where it runs out, not a reason to skip it.

Where CrUX stops

Each of these is a documented property of the dataset, not a flaw. They are simply the trade-offs that come with free, privacy-preserving, publicly shared data.

1. A rolling 28-day window

CrUX aggregates over a 28-day rolling window, updated daily and running roughly two days behind. The data itself is not 28 days old: what takes 28 days is for the window to turn over completely.

The consequence is easy to misread. Because the reported figure is the 75th percentile rather than an average, a fix does not show up as steady daily progress. While your improved traffic is a quarter of the window, you are effectively reading the 67th percentile of the old data; at half the window, the 50th percentile. The number looks stuck, then drops sharply somewhere in the second or third week. Teams routinely conclude a fix did not work and revert it during exactly that flat stretch. Joan León documented this effect in detail in a walkthrough of the 28-day window.

None of that is a reason to distrust CrUX. It is a reason not to use it as your feedback loop while you are actively fixing something.

2. The 75th percentile, and nothing else

The assessment reports the value at which 75% of page loads were at or below. That single number hides the shape of the distribution. You cannot see whether your worst quarter of users sits just over the threshold or far beyond it, and those two situations call for completely different work.

3. One browser, and not even all of it

CrUX covers desktop Chrome on Windows, macOS, ChromeOS and Linux, plus Chrome on Android including Custom Tabs and WebAPKs. It explicitly excludes Chrome on iOS, Android WebView and other Chromium browsers such as Edge. Safari and Firefox are absent entirely. On top of that, only users who have enabled usage statistic reporting, sync their browser history and do not use a sync passphrase are counted, so it is a self-selected subset even within Chrome.

For a Dutch or UK e-commerce audience with a large share of iPhone traffic, that is a significant part of your customers who are never represented.

4. Your checkout is probably not in it

To appear at all, a page must be publicly discoverable: it has to return HTTP 200 and carry no noindex header or meta tag. Checkout steps, account pages and anything behind a login are therefore usually excluded regardless of traffic. The pages where performance costs you the most revenue are the pages CrUX is least likely to show you.

There is a second eligibility rule: a page or origin needs a minimum number of visitors, and Google does not publish the threshold. Origins with more than 20% of their traffic excluded are dropped entirely.

5. No segments

You get origin level and page level, split by phone, tablet and desktop. You cannot ask how logged-in customers compare to anonymous visitors, how one product template compares to another, how an A/B variant performed, or how the experience differs by country beyond the country-level datasets.

6. No attribution

CrUX tells you INP is 400ms. It does not tell you which interaction, which element or which script was responsible. Attribution is the part that turns a metric into a task for a developer, and it only exists in data you collect yourself.

7. Single-page apps are misattributed

For applications that change routes in JavaScript, CrUX attributes the experience to the initial page view rather than to the route the user actually landed on. If you run an SPA storefront, the numbers are assigned to the wrong pages. Query strings and fragments are also stripped from URLs.

CrUX and RUM side by side

Read the last two rows together with the rest. They are the reason this is not a migration: CrUX keeps doing something your own data never can, which is telling you where you stand against everyone else and what Google sees.

You keep the UX Score

The most common objection to moving is that teams have finally agreed on one number, and nobody wants to renegotiate that. You do not have to.

The UX Score is a weighted composite of five Web Vitals: LCP 25 points, INP 25 points, CLS 25 points, FCP 15 points and TTFB 10 points, for 100 in total. Nothing in that definition requires CrUX as the source. Once those five metrics arrive in your observability platform, the score is a formula in a query.

We compute the UX Score this way across our engagements. For Frasers Group it runs in Honeycomb, usually per week, across flannels.com, sportsdirect.com and houseoffraser.co.uk. Same formula, same 0 to 100 scale, different source.

What changes is what the score can do:

• It moves at the speed of your releases. A weekly score shows a step change the week after a deploy, instead of being diluted across a rolling 28-day average.
• It splits by anything you record. Per brand, per template, per country, per logged-in state.
• It covers the pages that matter commercially, including the checkout steps CrUX excludes.
• It sits next to your traces. When the score drops, the same platform holds the sessions that caused it.

You then have the same number in two places, which is the useful part. Your own score tells you what happened this week and why. The CrUX score tells you what Google will have concluded four weeks from now.

What running your own RUM costs

An honest account of the trade-offs, because they are real:

• Instrumentation. Someone has to place and maintain the SDK, and the collection script itself must not slow the pages you are measuring.
• Data volume. Browser telemetry scales with page views rather than with server count. High-traffic sites need a sampling strategy before rollout, not after the first invoice.
• Content blockers. Telemetry sent to known third-party collector domains is blocked for a share of your visitors, which biases your data. Collecting through a first-party endpoint reduces the loss.
• Privacy. Browser telemetry is personal data under the GDPR when it can identify users. Consent, PII masking and EU data residency belong in the design, not in a later audit.
• It is your number. Nobody else can verify it, which is exactly why the public CrUX score keeps its value alongside it.

When CrUX is enough

Plenty of sites do not need their own RUM, and it is worth saying so:

• Your site is mostly public content pages, and the pages that matter are all in the dataset.
• You release monthly or less often, so a 28-day window is not a bottleneck.
• Your traffic is small enough that a week of your own data would not be statistically meaningful anyway.
• You have no development capacity to act on attribution even if you had it.

In those cases, a free UX Score benchmark and Search Console will tell you what you need. Come back to this page when a deploy cycle gets faster than your measurement does.

If you are past that point, we implement observability using OpenTelemetry and compute the UX Score inside your own stack. See the observability service, the tools comparison if you are still choosing a platform, or get in touch.

Related resources

• Frontend Observability Guide: what to collect and how to implement it
• Frontend Observability Tools: platforms compared
• End-to-End Observability: linking browser telemetry to backend traces
• UX Score: the formula and how it is calculated

Frequently asked questions