OneTrust vs Osano vs Cookiebot: Consent Management for Headless Commerce and Google Consent Mode v2 (2026)

On a standard themed storefront, consent is close to a solved problem you never had to think about. The platform renders the page, a banner script loads, and the tags it governs live in the same document, so blocking them until a visitor agrees is a matter of dropping in a snippet. Decouple the frontend and every part of that quietly stops being true. Your headless storefront loads its own analytics, its own advertising pixels, and often its own tag manager, and by default they fire the instant the page hydrates, before anyone has clicked anything. A consent management platform in a headless build is not a banner. It is a gate that has to sit in front of tags your framework is loading on its own schedule, and getting it wrong means you are collecting data you had no permission to collect. This post compares OneTrust, Osano, and Cookiebot on how they behave in a decoupled storefront, and how Google Consent Mode v2 reshapes what compliant even means.

The Three Platforms At A Glance

Platform	Core approach	Consent Mode v2 support	Server side friendly	Pricing shape	Best for
OneTrust	Full privacy suite, granular policy engine	Native, certified	Yes, with server side SDK and APIs	Enterprise, seat and module based	Large brands with legal and multi region obligations
Osano	Consent plus vendor and liability management	Yes	Partial, mostly client driven	Mid market, flat tiers	Teams wanting compliance coverage without a suite
Cookiebot	Automated scanning and categorization	Yes, tight Google integration	Limited, client centric	Per domain, volume based	Storefronts wanting fast, low effort compliance

The columns that matter in a headless build are the middle two. Consent Mode v2 support decides whether the platform can speak the signal language Google now requires, and server side friendliness decides whether you can enforce consent where a headless stack increasingly does its tracking, which is on the server rather than in the browser. OneTrust is the heavyweight, built for organizations that treat privacy as a program with legal review and many jurisdictions, and it pays for that breadth in cost and setup effort. Cookiebot is the opposite, a scanner that crawls your site, categorizes cookies automatically, and gets you to a working banner fast, which is ideal until your architecture moves tracking server side where a client scanner cannot see it. Osano sits between them, pairing consent with vendor and liability management for teams that want more than a banner but less than a full suite.

Why Headless Breaks the Default CMP Setup

The failure mode is specific and it is the same on every platform if you install it naively. A consent tool blocks tags by recognizing them and holding them until consent is granted. On a themed site the tags are declared in a way the tool can intercept. In a headless storefront your analytics and pixels are frequently imported as modules or initialized in framework code, so they are not sitting in the DOM waiting to be blocked. They run because your own code ran them. Dropping a CMP script into that and assuming it will catch everything produces a banner that looks compliant and a set of tags that fire regardless, which is worse than no banner because it signals a control you do not actually have.

The correct pattern is to invert the control. Nothing that depends on consent should be initialized by your framework directly. Instead, tags are registered with the consent layer and only initialized in the callback that fires when consent state is known, whether that is a fresh choice or a stored one from a previous visit. This is the same discipline you already need for the tracking layer itself, and it is why consent and your customer data pipeline have to be designed together rather than bolted on separately, a point we made in the Segment versus RudderStack CDP analysis. Behavioral tools have the same requirement, since a session replay script that loads before consent is a privacy problem regardless of your banner, which is part of the setup detail in the Clarity versus Contentsquare comparison.

A minimal consent gated initialization looks like this, and the shape is the same across the three platforms even though the API names differ.

// Do NOT import and run analytics at module load.
// Register it, and let the consent layer decide when it runs.
import { onConsentChange } from './consent'

onConsentChange((consent) => {
  if (consent.analytics_storage === 'granted') {
    initAnalytics()
  }
  if (consent.ad_storage === 'granted') {
    initAdPixels()
  }
  // update Google Consent Mode signals either way
  gtag('consent', 'update', {
    ad_storage: consent.ad_storage,
    analytics_storage: consent.analytics_storage,
    ad_user_data: consent.ad_user_data,
    ad_personalization: consent.ad_personalization,
  })
})

Google Consent Mode v2 Changes the Question

Consent Mode v2 is the requirement that reframes this whole comparison. For any storefront serving visitors in the European Economic Area and using Google advertising or analytics, Google now requires that you pass four consent signals, ad_storage, analytics_storage, ad_user_data, and ad_personalization, and it modulates its own tags based on them. The important shift is that consent is no longer only about whether a tag loads. Even when a visitor declines, Consent Mode v2 expects the Google tags to still load in a restricted mode that sends cookieless pings rather than nothing, so that modeling can fill some of the gap without storing identifiers. A setup that simply blocks the tag entirely on decline is not Consent Mode v2 compliant, and it also throws away the modeled conversions Google will credit you for when the signals are wired correctly.

This is where the platforms genuinely differ rather than just cost differently. Cookiebot has an unusually tight Google integration and will emit the four signals with little custom work, which is its main advantage for a Google heavy storefront. OneTrust supports Consent Mode v2 natively and certified, and its value is that it does so alongside every other regional framework you might owe, so a brand selling into multiple jurisdictions gets one policy engine rather than a Google specific fix. Osano supports it competently in the middle. The wrong assumption is that Consent Mode v2 is a checkbox. In a headless build you still have to ensure the signals are updated in your own initialization code, as in the snippet above, because the platform can render the banner but only your frontend knows when your framework decided to load a tag.

The Server Side Wrinkle

The deeper issue is that modern headless stacks increasingly move tracking to the server, sending events from your backend or a server side tag manager rather than from the browser, which improves reliability and dodges ad blockers. Consent has to follow the data there. A purely client side CMP knows what the visitor chose but does nothing to stop a server side event that your backend fires on its own. Enforcing consent server side means propagating the consent state from the browser to your backend and checking it before any server side tag or warehouse write, which is an application concern your CMP can inform but cannot solve for you. OneTrust is the most comfortable here because it exposes server side SDKs and APIs meant for exactly this propagation. Osano and Cookiebot are more client centric, so a server side heavy architecture will lean on your own code to carry and honor the consent state. Which storefront framework you run shapes how cleanly this threads through, because the rendering and data boundaries differ, a distinction we worked through in the Hydrogen versus Next.js commerce comparison.

When This Applies to Your Stack

If your storefront is headless and you are running any advertising or analytics tags, your consent setup is only real if tags actually wait for consent and your Google signals actually change with the answer, and neither is guaranteed by installing a banner. Choose Cookiebot when your priority is a fast, low effort compliant setup on a Google centric, mostly client side storefront. Choose OneTrust when you have multi region legal obligations and a server side architecture that needs consent propagated through APIs, and you can absorb the cost and setup of a full suite. Choose Osano when you want real compliance coverage, including vendor and liability management, without committing to enterprise tooling. Across all three, the load bearing work in a headless build is the same: invert your tag initialization so nothing fires before consent is known, and wire the Consent Mode v2 signals in your own code, because the platform renders the choice but your framework controls the tags.

If your team is standing up or repairing a headless storefront and needs consent designed so tags genuinely honor it across client and server, Contra Collective builds headless commerce and platform migrations where privacy is architected into the tracking layer, not stapled on as a banner. A compliant looking banner over tags that fire anyway is the most expensive kind of wrong, because it looks solved.

FAQ

Why does a headless storefront need a different consent setup than a themed one? Because a headless frontend loads its own analytics, pixels, and tag manager in framework code, so those tags fire on your schedule rather than being declared where a consent script can intercept them. A banner dropped in naively will display while the tags fire regardless. The fix is to register consent dependent tags and initialize them only in the consent callback, so nothing runs before a choice is known.

What is Google Consent Mode v2 and do I have to support it? Consent Mode v2 is Google's requirement to pass four consent signals, ad_storage, analytics_storage, ad_user_data, and ad_personalization, for visitors in the European Economic Area when using Google advertising or analytics. It also expects Google tags to load in a restricted, cookieless mode on decline rather than being fully blocked, which enables modeled conversions. If you run Google ads or analytics into the EEA, supporting it is effectively mandatory.

Which consent platform is best for a headless commerce build? It depends on your architecture. Cookiebot is fastest for a Google centric, mostly client side storefront thanks to its tight Consent Mode integration. OneTrust suits multi region legal obligations and server side tracking because it exposes server side SDKs and APIs. Osano is the middle option for teams wanting compliance and vendor management without a full enterprise suite.

Can a consent platform enforce consent for server side tracking? Not on its own. A client side consent platform knows the visitor's choice but cannot stop a server side event your backend fires. You must propagate the consent state from the browser to your backend and check it before any server side tag or warehouse write. OneTrust provides server side SDKs to help, but honoring consent in server side code is ultimately an application responsibility.

Is blocking all tags on decline compliant with Consent Mode v2? No. Consent Mode v2 expects Google tags to still load in a restricted mode that sends cookieless pings on decline, rather than being blocked entirely, so that modeling can partially fill the gap without storing identifiers. Fully blocking the tags is both non compliant with Consent Mode v2 and wasteful of the modeled conversions Google will credit when the signals are wired correctly.