Replacing OneTrust: five things to check if you run ads
Which consent platform you move to matters less than whether it can do five specific things. Four of them never appear on a vendor comparison page.
On this page
- We sell one of these products, which is why we won't rank them
- Check one: all four Consent Mode signals, not the two storage ones
- Check two: one global rule is the wrong shape for US state law
- Check three: a privacy string nobody reads is an artefact, not a control
- Check four: auto-blocking can't reach tags the container injects later
- Check five: consent records don't migrate, and your consent rate resets
- What the feature table tells you, and what the page tells you
- Certification tells you about the product, not about your installation
- Run the test before you sign, not after
- The decision that actually matters
Short answer: pick on integration behaviour, not on the vendor's feature table. Five things decide whether a consent platform can carry advertising data properly: whether it emits all four Consent Mode signals, whether it can hold a different rule per region and honour a browser opt-out in the regions where that is binding, whether the privacy string it writes is read by anything downstream, whether its blocking reaches tags Google Tag Manager injects after the page has loaded, and what happens to your existing consent records on the day you switch. Test each one by loading your own site and watching what fires. And read the disclosure below before you take a vendor recommendation from us, or from anyone.
We sell one of these products, which is why we won't rank them
Perfmetrix is a Cookiebot partner. We earn money when a client buys that product.
That makes any ranking we publish worth less than the time you would spend reading it. The uncomfortable half of that sentence is that it's true of nearly every consent platform comparison you'll find — vendor pages, affiliate round-ups, "top 10 CMPs in 2026" listicles that reliably place the author's partner first. The difference is that we're saying so.
So this isn't a list of replacements. It's the test we run when someone asks us to pick, and you can run it against any shortlist, including ours. A product either does these five things on your site or it doesn't, and you can watch it happen in a browser.
Check one: all four Consent Mode signals, not the two storage ones
Google's consent API takes four values that matter to an advertiser: ad_storage, analytics_storage, ad_user_data and ad_personalization. The last two were added for Consent Mode v2 — ad_user_data sets consent for sending advertising-related user data to Google, and ad_personalization sets consent for personalised advertising (Google, consent mode documentation, checked 23 September 2026).
Plenty of installations still send two. That usually isn't the platform's limitation; it's a template configured before v2 existed, or a hand-rolled banner that was never updated. Either way the effect is the same: Google receives no signal for the two parameters that govern whether your data can be used for ad personalisation at all.
What to check on a shortlisted product: does its Tag Manager template expose all four, and does it send them on the default call as well as the update? The default has to run before the container does. A platform that only updates consent after the banner interaction leaves every pre-interaction pageview undefined.
Check two: one global rule is the wrong shape for US state law
Google's tag API lets you set a default consent state per region, and the more specific region wins — set ad_storage granted for US and denied for US-CA, and a Californian visitor gets the denied setting (Google, consent mode documentation, checked 23 September 2026). Your consent platform needs to be able to express that, because US state privacy law is not uniform and an opt-out state is not an opt-in state.
The second half of this check is the browser opt-out signal. In the states that treat one as a legal opt-out, the platform has to honour it — and in most products that support is a property of an individual banner rather than of the account, so it can be enabled on the banner you tested and disabled on the one that matters. We've published the mechanism and the failure mode in the setting that quietly disables Global Privacy Control, and the state-by-state position in which states make you honour a browser opt-out signal.
Ask for a demo with two geo rules configured, then load the site from each region and read the resulting consent state. A vendor page that says "geo-targeting supported" is answering a different question.
Check three: a privacy string nobody reads is an artefact, not a control
The IAB's Global Privacy Platform defines a US National section and per-state sections for carrying opt-out signals. Google Ads supports the GPP US National, California, Virginia, Colorado, Connecticut and Florida strings — and Google states plainly that using GPP "isn't required by Google, and is just one of multiple methods" (Google Ads Help, US states' privacy laws, checked 23 September 2026).
Read the same page for what actually happens on an advertiser's site, because it's more specific than the marketing. Google's tags interact with the page to retrieve the us_privacy string and apply restricted data processing when it indicates the user has opted out. Separately, for users in applicable states, Google says it receives Global Privacy Control signals directly and triggers restricted data processing for those ad requests. And restricted data processing is a limitation, not a blackout: it stops additions to remarketing lists and similar-audience seeds, while conversion tracking and campaign measurement continue to work (same page, checked 23 September 2026).
So the question to put to a vendor isn't "do you write a GPP string". It's "which consumer of that string, in my stack, changes its behaviour because of it" — and then confirm it on the network tab rather than in the answer.
Check four: auto-blocking can't reach tags the container injects later
Automatic blocking works by rewriting script tags the platform can see in the page. Tags injected by Google Tag Manager after that scan aren't in that set. Cookiebot's own documentation draws the line explicitly: use Tag Manager triggers and Consent Mode for the container's tags, and let automatic blocking control "all other cookies not set by Google Tag Manager" (Cookiebot Support, Tag Manager and automatic cookie blocking, checked 23 September 2026).
This is architectural, not a defect in any one product, and it catches people who read auto-blocking as coverage. We wrote up the full set of causes in Cookiebot is installed but tags still fire before consent; the short version is that the banner and your container are two systems, and installing the first changes nothing about the second.
On a shortlist, this collapses into one measurable question: with the candidate installed and nobody having clicked anything, do your GA4 and Ads tags fire? Blocking coverage is a claim you test, never a box you tick.
Check five: consent records don't migrate, and your consent rate resets
The user's choice lives in storage written by the platform that collected it. Google's documentation is direct that consent mode itself doesn't save consent choices, and that it's on you to persist the user's decision in a first-party cookie or local storage and replay it on subsequent page loads (Google, consent mode documentation, checked 23 September 2026).
Swap platforms and the new one starts with no record for anyone. Every returning visitor is prompted again, and whatever consent rate you had reverts to first-visit numbers while the new base rebuilds. Plan for it: expect a visible dip in granted rates and in measured conversions in the days after cutover, don't schedule the switch across a peak trading week, and don't read the dip as a bidding problem.
We can't tell you how large the dip is. No independent data exists on re-prompt rates after a CMP migration — the figures that circulate come from vendors describing their own product, and we've not found a study anyone has audited. If you want a number, instrument your own: record consent rate daily for two weeks before the switch and four weeks after.
What the feature table tells you, and what the page tells you
| Check | What the vendor page says | What to watch on your own site |
|---|---|---|
| Consent Mode v2 | "Consent Mode v2 certified" | All four parameters present on the default call, before the container loads |
| Regional rules | "Geo-targeting supported" | Load from two regions; read the consent state each returns |
| Privacy strings | "GPP and US National supported" | Which downstream consumer changes behaviour when the string says opt-out |
| Blocking | "Automatic cookie blocking" | Whether container-injected tags fire before any interaction |
| Migration | Not mentioned | Consent rate for two weeks before and four weeks after cutover |
Certification tells you about the product, not about your installation
Google maintains a list of consent platforms integrated with its consent APIs, OneTrust and most of its competitors included (Google Tag Manager Help, checked 23 September 2026). That list is useful for one thing: knowing a supported template exists. It says nothing about whether the copy running on your domain is configured correctly.
Run the test before you sign, not after
Shortlist two or three products. For each, get a trial on a staging copy of your own site — not the vendor's demo page — and run the same five checks in a fresh private window each time, because a stored consent record from a previous visit will suppress the banner and hand you a false pass.
- Load with no interaction. Watch the network tab for your GA4, Ads and any third-party marketing tags.
- Read the consent state in the console. Confirm all four parameters exist and are denied by default.
- Repeat from a second region with a different rule, and confirm the state differs.
- Enable a browser opt-out signal and repeat in the region where it's binding.
- Accept, reload, and confirm the choice is remembered and the tags now fire.
If the same specifics matter to you on the product you already run, what to check before replacing Cookiebot applies the same test in the other direction.
The first two steps are the ones people skip, so we automated them: the Consent Mode v2 detector loads your live site and reports what fires before any consent interaction, and whether the four consent signals are genuinely present. Run it against your current platform first — the result is the baseline you'll judge the replacement against.
The decision that actually matters
Choosing between two competent consent platforms is a smaller decision than configuring either one properly. Most of the failures we find are configuration, not product: a template from before Consent Mode v2, one global rule serving several jurisdictions, a signal enabled on the wrong banner, blocking that never reached the container.
So budget for the migration work rather than the licence comparison. The switch itself is a week; the part that decides whether your advertising data survives it is the configuration afterwards, and the verification after that.
If you'd rather have the five checks run properly — on your live site, against your shortlist, with the downstream path followed rather than assumed — that's the work we do.
Sources
- 1.Google — Set up consent mode on websites (consent types, region-specific behaviour, persistence) · Checked 2026-09-23; page last updated 2026-07-30
- 2.Google Ads Help — Helping advertisers comply with the U.S. states' privacy laws in Google Ads · Checked 2026-09-23
- 3.Google Tag Manager Help — Obtain user consent, including the list of integrated CMP partners · Checked 2026-09-23
- 4.Cookiebot Support — Google Tag Manager and automatic cookie blocking · Checked 2026-09-23
- 5.IAB Tech Lab — Global Privacy Platform, US National section specification · Checked 2026-09-23