Cookie Compliance by Consent Tool

Who we scanned, and who we did not

We started from lists of sites we had already confirmed were running each tool, then scanned a balanced group of roughly 250 per tool: 241 on Cookiebot, 241 on OneTrust, 244 on Ketch, and 186 on CookieYes. Of 951 sites we tried, 912 returned a complete scan and 39 (4.1%) could not be reached or blocked our automated browser, which we set aside rather than count. The sites skew toward the United States and United Kingdom, in English.

Two things this cohort is not. It is not a random sample of any tool's customer base: these are sales-style lists matched to the kind of business we sell to, so they lean small and mid-sized and marketing-heavy, and they leave out the large enterprise deployments that tend to have a dedicated privacy team. If anything, that pushes the fail rates up relative to each tool's whole base. And it is not a product review: every number describes what a live site did, which is the tool and the setup together. We cannot split those from the outside, so we do not claim to have measured a product, and we do not claim to have cleared one either.

Installing a consent tool is not the same as being compliant

The clearest way to see this: unlike the web at large, almost every site here has a working banner. And it usually does not help. 91% of the 912 sites (829) fired a third-party tracker before the visitor answered the banner, even after setting aside the consent tool's own scripts. On the sites where our scanner independently re-confirmed the tool was running, the figure is higher still, between 93% and 97%.

Here is how all 912 sites split when tested as an EU visitor. The single largest group, on every one of the four tools, is the same: a consent tool is present, nothing fires after the visitor clicks Reject, and a tracker fires anyway before the visitor answers. That is a failure, not a footnote. The visitor's IP address and the page they were reading reached a third party before they agreed to anything, which is the exact thing the consent tool was bought to prevent.

^a "No banner shown" is a lower bound here. Signature-based detection can miss a banner rendered inline by a plugin or in the shadow DOM, so some of these sites do run a banner the scanner did not recognize. We do not treat the no-banner rate as a headline figure for that reason (see Limitations).

What the scan does not tell you is why the tracker fired. The scanner records requests and their timing relative to the banner. It never reads your page source, so it has no idea where a tag sits in your HTML. At least four different things produce an identical result on the wire: a tag hard-coded above the consent gate, a tracker the consent tool's blocking list does not recognize, automatic blocking that was never switched on, and a consent tool that loads too late to win the race. We cannot tell them apart from the outside, so we do not name one. An earlier version of this page did name one, tag placement, which the scan cannot support and which quietly put the fault on the site owner by default. That was wrong and we have removed it.

It is also worth being precise about what this group does not prove. "Nothing fires after Reject" is a weaker signal than it sounds, because the verdict looks only at what fires after the click. A tracker that fires once on page load and never repeats leaves a clean post-Reject record without the consent tool having blocked a thing. So read that top row for what it is. It is not a group where the tool worked and the owner slipped up. It is a group where a tracker got out ahead of the banner and nothing stopped it.

And the trackers getting out are not obscure. The three most common are Google Tag Manager, Google Analytics, and the Meta Pixel, which you can see in the leaderboard further down. Every one of these four tools sells automatic blocking, and automatic blocking only works if the tool recognizes the tracker in front of it. When the three most widely deployed trackers on the web are still reaching a third party before consent on roughly nine sites in ten, a blocking list that does not hold Google Analytics is not the customer's mistake. The site owner still has to fix it, because the site is the one answerable to a regulator. That is a different statement from saying the site owner caused it.

How the four tools compare

This is the table most people want, so here it is, with the neutral web-wide control beside it for scale. Two things to read carefully. First, the four tools land close together: on both measures the widest gap between them is not statistically significant, which is exactly why we do not crown a "worst" tool. Second, the control (the most-visited sites on the web) fails for a different reason, so it is context, not a like-for-like match: it fails mostly by having no banner at all, while the tool sites almost all have a banner and fail anyway.

"Failed the EU test" is a share of sites with a conclusive verdict; "fired a tracker before consent" is a share of all of a tool's sites and excludes the tool's own SDK. The control is the web's most-visited sites (the Tranco research ranking, list GQ4LK), scanned the same way; only 30% of them run any consent tool at all, so its failures are mostly "no banner," a different mechanism from the tool sites. Cookiebot is part of Usercentrics, so this row also reflects Usercentrics deployments.

We report the reject-behavior and clean-both figures pooled across all four tools rather than tool by tool, on purpose. Broken out per tool the counts get small and the differences stop being meaningful, and a per-tool reject leaderboard on a self-selected slice would imply a precision the data does not support. The pooled numbers are in the sections that follow.

Tracking usually fires before anyone chooses

These are the trackers most often firing before consent across the whole cohort. It is the familiar cast. Google Tag Manager tops the list, but a container load is a weaker example than an actual measurement or advertising call, so the sharpest cases are Google Analytics and the Meta Pixel below it.

^b Google Tag Manager is a container rather than a tracker in itself. Its load is still a third-party request to Google that carries the visitor's IP, but read the analytics and advertising rows below it as the sharper examples.

A word on the standard behind that number, because we hold it on purpose. We count any third-party request made before consent as a problem, even when the tag is set up for Google Consent Mode and sends a cookieless "denied" ping. The reason is simple: the request still travels to the third party, and it carries the visitor's IP address. Under EU law an IP address is personal data (the EU Court of Justice said so in the Breyer case), so data has already left before anyone agreed. The cookieless "denied" state changes what the third party may store; it does not stop the connection.

The banner is often theater, and Reject does not always work

A banner is only worth something if clicking Reject actually stops the tracking. Of the 741 sites across all four tools where the scanner could reach and click Reject, 178 (24%) kept a genuine third-party tracker firing afterward, which is 20% of all 912 sites we scanned. We report this figure pooled across the four tools, not tool by tool.

One tracker stands out. A request to Microsoft Clarity's endpoint was observed after Reject on 92 sites, more than three times the next most common (Meta Pixel, on 26), and it was the most common after-reject tracker on every one of the four tools individually. Clarity records session replays; the Meta Pixel sits at the center of the pixel and wiretap lawsuits. This describes what the sites did; it is not a claim about Microsoft or Meta.

This is also the one place where the scan does narrow the explanation. Before the banner is answered, a tracker can get out for several reasons and we cannot tell which. After an explicit Reject, the consent tool is loaded, running, and has just been handed a decision. A tracker that fires anyway is one the tool did not hold. We still cannot see whether it went unrecognized by the blocking list or was recognized and let through, and we are not going to guess. But a session replay recorder running on 92 sites whose visitors just said no is not a story about where somebody pasted a snippet.

Charted are the trackers seen leaking on five or more sites. A smaller tail (Klaviyo, ZoomInfo, Google Ads, LinkedIn Insight Tag, and Reddit Pixel) kept firing on a few sites each.

We publish the conservative count. We checked every one of the 597 flagged after-reject requests against the saved network logs, and all 597 were really there, not inert or blocked scripts miscounted as fired. We then set aside anything that was the consent tool's own call to record the rejection, an accessibility or chat widget, a video embed, or performance monitoring, and counted only genuine analytics and marketing trackers. The 178 above are the unambiguous cases.

Did the scanner actually see the tool?

Because we started from lists of confirmed installs, we can check the scanner against a known answer. When it loaded each site fresh, it independently re-detected the same tool on 73% to 86% of them, a strong agreement floor. That is also what makes the pre-consent numbers hard to wave away: on the sites where the scanner confirmed the tool with its own eyes, the pre-consent rate is 93% to 97%, so "you counted sites that don't really run the tool" does not explain the result.

Where the scanner did not see a banner on a site we knew had a tool installed, the honest reading is mixed: some are genuine deployment gaps (installed but not gating), and some are banners rendered in a way signature detection misses. We spot-checked and found both, so we keep the no-banner rate out of the headline numbers and treat it as an upper bound.

How we tested

Every result here is behavioral. The scanner describes what fired and when, not what a court would decide. For each site it opens a fresh browser, loads the page as an EU visitor and again as a US visitor, and records the third-party requests on page load and after clicking Accept and Reject. A region is marked non-compliant when there is no banner in front of trackers that need consent, when a tracker fires before the banner is answered, or when Reject does not stop tracking. It is the same scanner, with the same rules, behind our public tool and our earlier State of Cookie Compliance census. The instrument itself is tested too: Can You Trust a Free Cookie Scanner? runs it, alongside 11 vendors' free checkers, against a site with planted violations.

Each site is loaded from two real vantage points, both DigitalOcean servers on AS14061: a European one in Frankfurt, Germany (FRA1) and a US one in San Francisco, California (SFO3). The US vantage is a genuine California IP. Even so, the US figures are not a formal CCPA compliance rate: California law is opt-out, and the scanner does not send Global Privacy Control signals, so we hold the strict opt-in standard to the EU verdict only and the clean-under- both figure is behavioral.

Before publishing, we re-derived every headline number from the scanner's stored output on three separate code paths and got the same figures each time, and we checked all 597 after-reject flags against the raw network logs. Every figure on this page names its exact count and denominator, so you can check the arithmetic yourself.

How a verdict is decided

Every verdict on this page comes from a fixed set of rules, the same ones the public scanner applies to any site. Here they are in full, so you can trace how any single result was reached.

What counts as tracking that needs consent. A request to a third party, or a cookie, in an analytics, advertising, or marketing category. Strictly-necessary things are exempt and never count against a site: its own first-party cookies, security and anti-abuse cookies, and the consent tool's own files. A site running only those is treated as having nothing to consent about.

A region passes when a banner holds tracking until the visitor chooses and honors Reject, or when there is no banner because the site runs nothing that needs consent. A tool that is stricter than the law requires (it blocks even after Accept, or runs an opt-in flow in the US where opt-out would allow tracking by default) is treated as a usability quirk, not a violation, and is not counted against the site.