On September 15, Chrome added four experimental ad metrics to the Chrome User Experience Report (CrUX): Ad Count, Ad Density, Ad Weight: CPU and Ad Weight: Network. Each is a p75 value over a rolling 28-day window, reported at the origin and page level. All four are live now in the CrUX API, the CrUX History API, CrUX Vis and the DevTools Ads panel; adding them to the CrUX dataset on BigQuery is still in progress. Chrome says data availability should “increase over the coming month.”
The Four Metrics and Their API Keys
Chrome’s announcement post, by Alex Cone, opens with the problem: “We’ve all encountered overwhelming ad experiences on the web. We know them when we see them, but they’re hard to quantify.” Each metric ships its own API key and unit.
| Metric | API key | Unit | What it measures |
|---|---|---|---|
| Ad Count | experimental_ad_count | unitless (number) | Average number of distinct ad frames visible in the viewport as a user scrolls |
| Ad Density | experimental_ad_density | integer percent | Average fraction of the visible viewport area occupied by ad frames |
| Ad Weight: CPU | experimental_ad_cpu | integer milliseconds | Cumulative JavaScript CPU time consumed by ad frames and their subresources, excluding main-frame ad scripts |
| Ad Weight: Network | experimental_ad_kilobytes | integer kilobytes | Cumulative compressed network transfer to load ad-related resources such as scripts, images and stylesheets |
The ad metrics share the CrUX pipeline with Core Web Vitals, but the announcement keeps the two apart: “While inspired by Core Web Vitals, which help provide visibility into websites’ speed, responsiveness and visual stability, CrUX ad metrics are not part of Core Web Vitals and don’t have suggested targets or thresholds.”
Why Your Own Analytics Can’t Collect the Same Number
Every one of the four per-metric pages carries the same two sentences, word for word: “There are challenges reporting across cross-origin iframes which most ads are delivered through. Therefore, there is no JavaScript API to allow similar detection for Real User Monitoring (RUM) tooling.” The docs name cross-origin iframes as the obstacle. DevTools gives a local reading only, and Chrome’s detection doc says that local reading “may differ from CrUX aggregate reports due to the nature of field reporting and depending on the presence of ads.txt with authorised sellers.”
What Are CrUX Ad Metrics, and Can Analytics Tools Collect Them?
CrUX ad metrics are four experimental values, Ad Count, Ad Density, Ad Weight: CPU and Ad Weight: Network, describing ad load on a page’s viewport, CPU time and network transfer. They are field data: Chrome measures them in the browser during page visits, and CrUX reports the 75th percentile (p75) across page views from eligible Chrome users; no JavaScript API exists for RUM tools to reproduce them, since most ads load through cross-origin iframes. Chrome reports them only for origins whose ads.txt file lists at least one authorized seller.
Coverage Depends on ads.txt, Not Just on Having Ads
Chrome’s methodology doc states the gate plainly: it includes “only those sites that list at least one authorized seller in their ads.txt,” and “Origins with no ads.txt, or those containing only a placeholder record, are excluded from CrUX ad metrics reporting.” Each metric page adds: “Only pages with ads are considered for the CrUX ad metrics.” The filter runs “during CrUX data aggregation, not within the browser.” ads.txt is not the only condition: a page also has to be publicly discoverable and “sufficiently popular,” a bar for which Chrome says “an exact number is not disclosed.”
| Requirement | What Chrome’s docs say |
|---|---|
| ads.txt | At least one authorized seller listed; placeholder-only files are excluded |
| CrUX eligibility | Publicly discoverable and “sufficiently popular”; no threshold disclosed |
| Chrome platform | Windows, macOS, Android, ChromeOS or Linux; iOS Chrome, Android WebView apps and other Chromium browsers are excluded |
How Chrome Decides What Counts as an Ad
Classification runs on two signals, per Nour Nabil’s detection doc: a filter list, “a condensed version of EasyList,” and a JavaScript-stack check, where a subresource requested while an ad script runs on the stack gets the same label. Once an iframe is flagged, the label sticks, “even if the iframe later navigates to a new destination unrelated to advertising.” One frame is permanently exempt: “The main frame itself will never be classified as an ad frame,” though subresources used in the main frame can be. The CPU page adds its own boundary: the time “is measured for ad frames only and excludes CPU time for main frame ad scripts.”
Sampling Choices That Shape the Value
Chrome samples the viewport once per second. An idle visitor on an infinite-scroll page keeps generating identical samples, which “may skew the overall session average depending on the duration of the idle state.” A single-page app that swaps screens without a reload doesn’t reset the counter: soft navigations fold into “a single, cumulative session score,” and the doc adds: “This will likely change in the near future.” Collection “pauses” in a backgrounded tab or a locked screen; on Android it also stops once the app is backgrounded.
Where the Numbers Live, and Where They Don’t Yet
The CrUX API returns the latest 28-day snapshot, “updated daily.” The CrUX History API returns a weekly history, “typically returning 40 weekly data points,” released every Monday, and CrUX Vis plots the past 40 weeks for users without engineering knowledge. BigQuery is still missing; Chrome says only that it is “working on adding the ad metrics to the CrUX dataset on BigQuery.” The sample API responses in the tooling doc use example.com figures, not live data. And since Chrome tells developers to “expect data availability to increase over the coming month,” an empty response for an eligible origin today is not yet a verdict.
What Google Told Digiday, and What It Didn’t
Bill Reardon of Google Ads, one of six supporters Chrome’s post quotes, framed any use of the signals in the future tense.
“Display & Video 360 supports this initiative to bring transparency to page layout quality. We look forward to exploring with the industry how these signals can improve quality and support advertiser goals.”
— Bill Reardon, Google Ads
Digiday, which called the release an “ad detection tool” in its own headline, put follow-up questions to Google. Per Digiday, Google told the publication that independent ad platforms will receive access to the data at the same time as Google’s own advertising businesses. On DV360, Digiday reports that Google “did not disclose whether DV 360 is currently testing the signals for inventory evaluation, bidding or reporting,” and Search Engine Land notes that Google “hasn’t said” either.
A Pattern: Numbers You Can Read but Not Rebuild
CrUX ad metrics join other Google-defined figures a publisher can look up but not reconstruct from its own logs. Search Console works the same way: every link inside an AI Overview is reported at the block’s single position, not the position of the link itself. Ad Manager adds a related case: Google’s planned switch to begin-to-render impression counting moves the moment a display impression is counted.
The four ad metrics fit that pattern: an origin gets a record only if it clears the ads.txt and CrUX eligibility gates, and the ad-frame definition, the sampling rate and the 28-day window all sit inside Chrome, outside any tag a site could add.