Do You Need a Paid CMP for Google Consent Mode v2?

💡 Quick Summary (TL;DR):

• Google Consent Mode v2 does not make a paid or Google-certified CMP mandatory for every site. A normal site using GA4, Google Tag Manager and Google Ads can use a commercial CMP, an open-source tool or its own implementation, provided the consent signals and regional rules are implemented correctly.
• Publishers are a different case. AdSense, Ad Manager and AdMob use in the EEA, UK and Switzerland can bring Google-certified CMP and IAB TCF requirements into the decision. Do not apply that rule indiscriminately to an ordinary analytics and conversion-tracking setup.
• The subscription is rarely for the banner. It pays for scanning, classification, regional behavior, consent records, policy maintenance, multi-domain administration and somebody else carrying part of the operational burden.
• My shortlist is deliberately small: Cookiebot and CookieYes for hosted operation, iubenda when policy tooling matters, Consenti for a more complete self-hosted approach, and Orest Bida's CookieConsent when a developer wants a small library and accepts owning everything around it.

At the company where I work, we are gradually moving an estate of WordPress sites to a Next.js stack. The old sites use Complianz. Inside WordPress, that is a fairly comfortable arrangement: the scanner, banner, consent records and integrations live in the same administrative world as the site.

The moment the frontend leaves WordPress, that convenience does not travel with it.

We now have to replace it with a hosted service, operate something ourselves, or build a smaller consent layer into the new stack. Because these sites serve many countries, the question is not merely whether a banner can call gtag('consent', ...). We also need to decide who will maintain regional defaults, prove what a visitor chose, discover new cookies added by marketing teams, and follow changes in the advertising ecosystem.

That was the context in which I found Consenti. Its proposition immediately appealed to the developer in me: open source, self-hostable, designed for modern applications, and much closer to a complete consent system than the usual banner library.

It also revived an uncomfortable question. If the visible product is a notice, a preferences dialog and four Google consent signals, why should a company pay €10, €30 or considerably more every month, per site, forever?

I started this research expecting the answer to be mostly about implementation. It turned out to be about where we wanted the ongoing responsibility to live.

This is a technical and product assessment based on the state of the market on August 18, 2026. A CMP supports a privacy program; it does not make a website legally compliant by itself. This article is not legal advice.

First, Consent Mode Is Not a CMP

Google Consent Mode is a protocol between the site's consent interface and Google tags. It tells those tags which kinds of storage and advertising use are allowed. A CMP may produce those decisions, but Consent Mode itself neither draws the banner nor determines whether the wording and choices satisfy the law.

Version 2 revolves around four signals:

The important part is the sequence, not the banner design:

1. The page starts.
2. A default consent state is established before measurement commands and tags run.
3. Google tags initialize according to that state.
4. The visitor makes or changes a choice.
5. The site sends a consent update.
6. Tags change their behavior for the rest of the page and subsequent navigation.

Google's implementation guide is explicit about setting the default before any measurement command. This is where many home-grown banners fail. They eventually send the right answer, but only after GA4 or an advertising tag has already executed under the wrong default.

There are also two operating models that are often confused.

With Basic Consent Mode, Google tags are blocked until the visitor interacts with the consent interface. If consent is denied, those tags do not load. This is the easier model to reason about because "denied" means no request from the blocked tag, but Google has less data available for modeling.

With Advanced Consent Mode, Google tags load with the default state set to denied. They can send consent-aware, cookieless pings while storage remains unavailable, then change behavior after an update. Google says this can provide richer advertiser-specific modeling than Basic mode. It does not mean that Advanced mode is automatically the correct legal choice in every country. It means the technical behavior under denial is different. Google documents that distinction directly; the lawful basis and interface still need to match the regions in which the site operates.

This distinction matters when comparing products. "Supports Google Consent Mode v2" may mean anything from setting all four signals correctly to publishing a short callback example that the customer must integrate and verify.

The Certification Confusion

The most useful finding in this research was also the simplest: Google does not require every advertiser using Consent Mode to buy a Google-certified CMP.

Google's own CMP requirements page separates advertisers from publishers. For an ordinary website using GA4, Google Tag Manager and Google Ads for analytics, conversions or remarketing, a custom or non-partner CMP can pass Consent Mode signals. Google says advertisers are not required to use a CMP from its partner program.

The publisher case is materially different. If a site uses AdSense, Ad Manager or AdMob to serve personalized ads in the EEA, the UK or Switzerland, Google's publisher rules can require a Google-certified CMP integrated with the IAB Transparency and Consent Framework (TCF). A non-certified implementation may restrict the traffic to non-personalized or limited ads rather than preserve the intended monetization path.

So the first question is not "Does this tool support Consent Mode v2?" It is:

Are we an advertiser measuring our own site, or a publisher selling advertising inventory through Google's publisher products?

That single answer eliminates a great deal of bad advice. A small SaaS landing site running GA4 and conversion tracking does not automatically need the same consent infrastructure as a media property serving programmatic ads across Europe.

TCF is not a generic synonym for a cookie banner either. The current IAB Europe TCF v2.3 standard coordinates purposes, vendors and consent signals across the advertising supply chain. Only a registered CMP can write a valid framework consent string under the TCF policies. IAB Europe had already announced the v2.4 transition timeline in July 2026, another reminder that this is maintained infrastructure rather than a one-time banner integration. That capability is valuable—sometimes mandatory—for publishers, but can be unnecessary weight for a developer-owned site with three known tags.

Certification also should not be mistaken for a legal guarantee. Google explicitly says its certification checks compliance with Google's CMP requirements, not full compliance with privacy law. A certified product can still be configured badly; an attractive banner can still use invalid defaults; a privacy policy can still describe something the code does not do.

“It Is Just a Banner and Four Calls”

For the smallest site, that objection is partly correct.

If I control every script, know which countries I serve, can block tags before consent, store the visitor's choice, expose a way to withdraw it, and test every deployment, I do not need to rent a dashboard merely to execute four JavaScript values. A mature library can remove most of the interface work. A small backend endpoint can record consent if records are necessary. This can be an entirely rational engineering decision.

But that is not the complete product a commercial CMP is selling. The recurring fee usually buys some combination of:

• scheduled crawling and discovery of newly introduced cookies;
• a maintained database that attempts to classify what was found;
• region-aware defaults and geolocation;
• consent and policy records that can be retrieved during an audit;
• IAB vendor-list and TCF integration;
• translated interfaces and policy material;
• one administration surface across multiple sites and domains;
• an interface that marketing or legal colleagues can operate without a deployment;
• continued changes when browsers, Google products or regulatory expectations move.

None of those features proves compliance. Some are also much less reliable than the sales page implies: a scanner cannot understand every first-party storage key, and automatic categorization still needs human review. Yet they address real work. The subscription is an operating-cost trade: pay the vendor, or assign engineers and privacy stakeholders to keep doing it.

This is familiar territory when leaving WordPress. As I wrote in my own move from WordPress to a Git-based Nuxt stack, removing the old platform's maintenance burden also means rebuilding conveniences that its plugin ecosystem supplied. Complianz is one of those conveniences. Its annual price is not the relevant comparison if the alternative requires an internal service owner, monitoring, release work and support for every regional exception.

How I Reduced the Market

I looked at more products than belong in a useful final table.

Complianz remains a strong WordPress baseline, but it is fundamentally a WordPress plugin. It informed what we were accustomed to—scanning, proof-of-consent snapshots, regional behavior—but it is not the natural control plane for a group of Next.js applications.

OneTrust represents the enterprise end: broad governance, many jurisdictions and a sales-led product with no useful public price. It may be the right benchmark for a compliance organization, but it is not a meaningful answer to the developer asking whether a small consent layer needs another subscription.

Termly is a credible hosted alternative with a documented Next.js installation path. Klaro remains an interesting self-hosted library, but its public release cadence and its manual Consent Mode integration made Orest Bida's CookieConsent a stronger library representative for this comparison. Silktide Consent Manager v2 has unusually good Consent Mode support for an open-source package, but as a new major version it overlaps with the same maturity question that Consenti already forces us to examine.

That left five choices which represent genuinely different purchases rather than five nearly identical banners.

The Shortlist, as of August 2026

Prices below are public list prices checked on August 18, 2026, excluding tax and enterprise negotiation. Pageview and page limits change often; verify them again before buying.

The current Cookiebot pricing, CookieYes pricing and iubenda pricing pages are clearer evidence than third-party comparison sites, but they are still only a snapshot. The self-hosted rows have no subscription price precisely because the expense moves into engineering and operations; it does not disappear.

Consenti: The Most Interesting Question Mark

Consenti deserves more attention because it prompted the investigation and because it tries to occupy an unusual middle ground.

The project is Apache-2.0 licensed. It can run as a frontend-only integration or use its backend packages with Express, Fastify, Next.js or a general Node.js service. The repository currently gives conflicting storage guidance—its examples use SQLite while a technical-decision note describes file-backed JSON as the default and SQLite as optional—so I would verify the intended production adapter before adopting it. It persists preferences, can synchronize browser tabs, recognizes Global Privacy Control, offers an optional backend-assisted location path and can keep consent records.

Most importantly, its Consent Mode support is not just a badge on the home page. The implementation maps categories to analytics_storage, ad_storage, ad_user_data and ad_personalization, establishes defaults and publishes updates. If Google Tag Manager is loaded while those values are denied, the result resembles Advanced Consent Mode. If scripts are gated until permission, it can be used in a Basic-style setup.

There are meaningful caveats.

At the time of this review, the public repository had only nine commits and its packages were still in the 0.x series. The scanner code exists, but its distribution and documentation are not yet as complete as the UI and API packages. Region handling can use backend IP information, while a browser-only deployment necessarily falls back to weaker signals such as locale or timezone. Its TCF/GPP support is partial, and Consenti is not itself a registered IAB CMP or a Google-certified publisher CMP. An operator would have to solve that organizational requirement separately; adding a cmpId field to code does not create registration.

That does not make Consenti a bad choice. It makes it a young infrastructure dependency. For a technically capable team that wants control, can review the source and does not need the certified publisher path, it is one of the most complete open-source attempts I found. For a global company, I would treat adoption as owning a service: pin versions, test every region, monitor releases, review the database model, define retention, and decide who responds when Google or IAB changes the contract.

The strongest thing about its documentation is that it does not pretend self-hosting removes that responsibility. The weakest thing is simply time: no documentation can manufacture years of production use for a project that was not yet two months old when I reviewed it.

What the Lightweight Route Looks Like

At the other end, CookieConsent v3 is a good example of a library rather than a platform. It gives an application an accessible preference interface, persistence, script gating and revision behavior. Its official Consent Mode example covers all four v2 values.

What it deliberately does not give you is more important. It does not discover the marketing team's new pixel, decide which legal region a visitor belongs to, retain an auditable server-side history, maintain IAB vendor lists or notify a privacy team when a policy needs review. The official consent-logging example shows how to send a record to your own endpoint because storage and retention are your job.

For a personal site, that restraint may be exactly right. For fifty international properties managed by several teams, it can quietly turn into an internal CMP product. The code for the banner remains small while the ownership surface grows.

A Minimal Consent Mode v2 Flow

The conceptual implementation is indeed short. The default must execute before GTM, GA4 or other Google measurement commands:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }

  gtag('consent', 'default', {
    analytics_storage: 'denied',
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied'
  });
</script>

After the visitor grants the relevant categories, update the same signals:

gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Real implementations rarely grant all four as one block. Analytics permission may only update analytics_storage; advertising permission controls the other three. A visitor can also withdraw a previous grant, so the update path must work in both directions.

In Next.js, this default must be emitted early enough that framework hydration, route transitions and third-party script components cannot race ahead of it. If the team implements Consent Mode through a GTM custom template rather than page code, Google recommends the template consent APIs (setDefaultConsentState and updateConsentState) rather than queuing gtag commands from the template. Timing is not an optimization detail here. It determines whether the default protected the first request at all.

Region-specific defaults complicate the clean example. A global site may deny by default in one group of countries, apply a different notice model elsewhere, and honor GPC in relevant US states. That logic should be a documented policy input, not a collection of country codes invented by the frontend team.

How I Would Verify It

A CMP's dashboard saying "connected" is not enough. For each material region and consent path, I would check:

• In Google Tag Assistant, does the earliest Consent event contain the intended defaults, and do later events contain the expected updates?
• In GTM Preview, which tags fired or were blocked before interaction, after accept-all, after reject-all and after a granular choice?
• In browser DevTools, do network requests and cookies match the selected Basic or Advanced model—not just the banner state stored in localStorage?
• Does a returning visitor receive the stored choice before tags initialize, and does a policy/version change ask again when intended?
• Can the visitor reopen preferences and withdraw consent as easily as granting it?
• Does navigation inside the Next.js application preserve state without accidentally refiring tags under stale consent?
• If server-side records are claimed, can the team retrieve a useful record with policy version, choices and timestamp, under a defined retention policy?
• Do automated scans and a manual tag inventory agree? If not, which one is wrong?

Google's consent debugging guide makes Tag Assistant the starting point. I would add repeatable integration tests around the site's own consent adapter. Third-party configuration can change without a code diff, which is exactly why the production behavior needs periodic verification.

The Recommendation Changes With the Site

There is no honest universal winner because each option prices a different kind of risk.

Cookiebot is compelling when mature scanning, cross-domain consent and retrievable consent data matter. CookieYes has the clearest public tiers and one of the more practical documented Next.js paths. iubenda makes more sense when the organization also wants privacy documents and a consent database, not only tag state. Consenti is the most ambitious self-hosted option in this group, provided the team accepts its youth and the absence of publisher certification. CookieConsent is the cleanest answer when the real requirement genuinely is only a well-made interface plus application-owned logic.

For publishers, I would not rely on a table in a blog post—including this one. Check Google's live certified list, the current IAB policy and the exact Google product being used before implementation. TCF v2.3 is the current framework version as of this review, but this is one of the facts most likely to age.

What This Research Changed for Me

I began with a pricing question: what justifies paying every month for something a developer can reproduce in a small amount of JavaScript?

The better question is: which parts of the consent system do we want to turn into our own product?

For one controlled site, the answer can reasonably be "most of them." For a global estate moving from WordPress to Next.js, the banner is the least interesting component. Inventory, regional policy, evidence, withdrawal, deployment order, publisher status and organizational ownership dominate the decision.

We used this research to make our own choice against our own traffic, countries, Google products, internal skills and appetite for maintenance. I am intentionally not naming that choice here. Publishing a winner without publishing the full organizational context would encourage exactly the shortcut this article is trying to avoid.

A paid CMP is not automatically safer. Open source is not automatically cheaper. Custom code is not automatically simpler. They are three different places to put the same responsibility.

Choose the place where your team can still own that responsibility a year from now—after the developer who enjoyed building the banner has moved on, a marketer has added six more tags, and the next version of the consent framework has arrived.