Commonly Referenced Metrics Appearing in Our Reports

Commonly Referenced Metrics Appearing in Our Reports

CrUX (Chrome User Experience) Scores

We test across 5 important metrics to measure which are commonly available in Chrome UX Reports, those being:

  • First Contentful Paint (FCP): measures the time from when the page starts loading to when any part of the page’s content is rendered on the screen.
  • Largest Contentful Paint (LCP): measures the time from when the page starts loading to when the largest text block or image element is rendered on the screen.
  • Interaction to Next Paint (INP): measures the latency of every tap, click, or keyboard interaction made with the page, and—based on the number of interactions—selects the worst interaction latency of the page (or close to the highest) as a single, representative value to describe a page’s overall responsiveness.
  • Cumulative Layout Shift (CLS): measures the cumulative score of all unexpected layout shifts that occur between when the page starts loading and when its lifecycle state changes to hidden.
  • Time to First Byte (TTFB): measures the time it takes for the network to respond to a user request with the first byte of a resource.

Information above sourced from: https://developer.chrome.com/docs/crux/methodology/metrics

Heaviness & Busyness of a Site

Heaviness is a measure of the number of bytes downloaded every time a page is rendered. Heavier pages are particularly punishing for mobile users, or users with bandwidth restrictions.

Busyness is a measure of the number of requests created during our visits; fewer requests mean less load on the server. This is particularly important for high-traffic sites, as it can reduce the chances of server overload and ensure that the site remains responsive and available to all users

As a general guidance, the Chrome Developer team recommends that sites “keep request counts low and transfer sizes small.”

Ads.txt Metrics

Ads.txt is an industry-wide initiative, championed by the Interactive Advertising Bureau (commonly known as the IAB), which aims to reduce the prevalence of domain spoofing. Publishers host a file at the “{domain}/ads.txt” directory, and this file lets buyers known exactly what combinations of ad system & publisher ID may announce their inventory for sale.

There is an complementary dataset hosted by ad platforms called sellers.json, which allows buyers to map publisher/seller IDs to the human readable name of the seller making inventory available during the course of an auction.

Any valid supply chain should be listed in an ads.txt file, and be verifiable by matching to the relevant sellers.json file.

Currently, the following related metrics/signals are used in compliance tests:

  • Simple presence of an Ads.txt file: any publisher doing programmatic advertising is expected to host this file. If they do not, it’s a significant issue
  • Ads.txt file size: a large file size indicates an unfocused monetization strategy. A higher number of integrated SSPs can mean more requests, slower pages, and worse carbon footprint. While the size itself is not an issue, it’s more of an issue for a website to be listed in every exchange on the planet, multiple times (by many resellers who all have their own take rate). Buyers are increasingly doing supply path optimization: looking for the most efficient path to inventory with the least number of intermediaries all taking a cut. A huge ads.txt file with many resellers can work against a publisher.
  • Ads.txt file verifiability: Essentially, buyers should only be transacting via transparent / verifiable supply paths; such paths can be confirmed by taking the publisher ID from an ads.txt file, and searching for it within the relevant ad system’s sellers.json file. If the ad system does not authorize the seller, this makes it an Unauthorized supply path, and these should be avoided. This can mean either:
    • The seller was booted from the exchange, or was never authorized in the first place
    • The ad system in question does not follow best practices about hosting a sellers.json file

There can be more nuance to this verification process, but our criteria here is as simple as can possibly be: we are simply looking for the presence of the ID in both files for it to be called “verifiable.” If a domain is flagged as “Partially Unverifiable,” it can be resolved by removing inactive / unauthorized supply chains from its ads.txt file.

Ad Density

Ad density refers to the proportion of page space occupied by advertisements compared to content on a web page or within a mobile app. It is a critical metric in digital advertising and user experience design, as it affects how users perceive and interact with content. High ad density can lead to a cluttered and potentially frustrating user experience, detracting from the quality of the content and potentially leading to higher bounce rates.

We measure the % of the screen occupied by ads each time we move further down the page, resulting in many snapshots of the density for each crawl we do. Our Advertising report shows average density in terms of 3 discrete phases of our crawls:

  1. Initial: this is the first thing we see when we arrive at a page. Also commonly known as the “Above The Fold” area.
  2. Mid-journey: this is generally the “in-article” area, or the area between the header & footer of a page.
  3. Final: this is generally the bottom of the page, or the footer area. In cases where the publisher has infinite scroll enabled, we choose a point to take one final snapshot after we’ve reached the time limit we assigned for a given crawl.

We also break down ad density by media type of the ad creative. The currently supported types are: display, video, and native.

It’s more common for us to under-count density, and this most commonly occurs when we have not yet mapped the naming conventions of a certain ad server / monetization solution. We always appreciate a heads up if you suspect we’re under-counting; chances are we can resolve that pretty quickly!

Ad Unit Refresh

Currently, our refresh insights are related to display ad units only.

Ad unit refresh refers to the process of automatically reloading and displaying a new advertisement in a specific ad unit without requiring the user to refresh the webpage or navigate to a new page. This technique is used to increase the number of impressions generated from a single user session, potentially leading to higher ad revenue for publishers.

Current guidance to publishers is that a 30 second refresh timer be applied to any add unit, and that it should only refresh when the ad-unit is in view. Both triggers should be in place; it’s not acceptable to call new ads each time an ad unit is scrolled into view if the timer requirement has not also been met.

Malware

We take several approaches to flagging malware:

  • We maintain a database of all scripts and links on any given page we visit. By matching this information to open-source threat databases like Alienvault, or the open source feeds from Abuse.ch, we can flag known indicators of compromise.
  • We maintain our own database of risk IP ranges & script names related to browser-hijacking, fake error warning (usually linked to pop-unders) & drive-by-install threat actors. We trigger those redirections / pop-unders on purpose in order to properly flag them in the future, and also to identify the ultimate destinations of hijacking campaigns.

Occasionally, malware can be delivered via ad-creatives, unknown to the publisher; this is known as “Mal-advertising.” From our perspective, this is still a significant risk to visitors, and there are solutions a publisher can leverage to reduce the occurrences of mal-advertising. If we see malware more than 20% of time we’ve visited a site, we apply a high risk label. Incidental occurrences that happen less often are still flagged, but with a less severe importance assigned.

AI Generated Content

The field of Generative AI is seeing explosive, unprecedented growth. Such growth presents new challenges for advertisers needing to separate great content from the rest. The category of Gen AI detection overall is challenging as there are perfectly valid uses for both text and image generation, that atop the fact that the state of the art moves forward at a blistering pace.

Our approach is multi-factorial, Instead of relying on a single model to try and probabilistically flag text that is made using Gen AI, we focus on collecting a group of signals that indicate that a particular publisher is engaging in mass generation of low quality content on one or across a network of sites. You can learn more about that on our Templated Sites blog post.

AI Image Detection Beta

The Publisher Search Content tab now includes aggregate metrics for AI image detection, focusing on images from models like Stable Diffusion. This feature is evolving and should be used alongside other content signals.

A high proportion of detected AI-generated images can indicate low-quality or low-effort content, though false positives are possible. Over a large sample size, this metric, combined with Authoring metrics, can be a strong indicator of overall content quality.

Table of Contents