Is Google Consent Mode v2 mandatory?

For any site using Google Ads or Analytics with visitors in the European Economic Area, effectively yes. Since March 2024, Google requires Consent Mode v2 signals for remarketing, audience lists, and enhanced conversions to function on EEA traffic. Sites without it lose those features silently. It is a Google requirement layered on top of the legal consent requirement, not a law itself.

Does Consent Mode replace a cookie banner?

No. Consent Mode only communicates consent state to Google tags. You still need a banner that collects a real choice and blocks non-Google trackers, which Consent Mode does not touch. BannerBulwark is the banner and the Consent Mode integration in one, so the two never drift out of sync.

What is conversion modeling?

When visitors decline cookies, Google cannot observe their conversions directly. Modeling uses the behavior of consented visitors to estimate what the declined share likely did, and fills the gap in your reports. It only activates when Consent Mode is implemented correctly, and it typically recovers a large share of otherwise invisible conversions.

Will this work with my existing Google Tag Manager setup?

Yes. BannerBulwark ships a GTM template that slots into your container as the consent default and update layer. Your existing tags stay where they are; the template controls when they may fire. There is also a direct script option if you do not use Tag Manager.

How do I know Consent Mode is actually working?

The dashboard shows a live signal inspector: load your site, accept or decline, and watch the four consent states change. It also flags common misconfigurations, like tags firing before the default state loads, which is the most frequent reason implementations fail verification.

What does BannerBulwark cost?

Start with the free consent audit: we check your banner, your Consent Mode signals, and what fires before consent, then show you the gaps. Plans are sized by sites and traffic after that. The audit carries no charge and no card.

When to Show a Consent Banner Without Covering the Transaction

October 29, 2026

Show the banner instantly and it blocks the first purchase a visitor tries to make. Delay it carelessly and tags fire before a choice exists. Here is how timing, placement, and checkout behaviour should fit together.

Banner timing is a trade that gets made by whoever configures the CMP, often once, often without watching a checkout afterwards. The failure looks like this: a returning visitor with a cart, a banner that spawns over the payment area because consent expired or the version changed, and a modal with no reachable dismissal at phone size.

The tag side of the trade is strict. Non essential tags wait for consent, full stop. But nothing in that requirement says the consent interface has to interrupt a transaction already underway, or reappear aggressively for a version bump that changed a vendor list and nothing the user would recognise.

First visit and return visit are different problems

On a first visit, present the banner promptly, keep it out of the centre of a phone screen where it swallows the whole viewport, and let the visitor keep browsing content that needs no consent while they decide. Blocking an article behind an undismissible wall teaches people to click accept to make it stop, which is consent as surrender, and regulators read it that way.

On a return visit, respect the stored state within its validity, and when a material change does require a new choice, ask at a natural break: after purchase, or on the next content visit, not as an overlay on a payment form the visitor is actively completing.

Protect the payment step explicitly

Write it into the CMP configuration and the release checklist: no consent modal spawns on checkout, payment, or account deletion flows. If consent state is missing for a visitor who reaches checkout, default the tags to off, keep the transaction clean, and surface the choice after completion or in account settings.

Test this the way failures happen. Clear consent, add to cart quickly, reach payment, and watch for late loading banner code. Async loading races are why this failure survives staging tests and appears in production, where the banner arrives after the page, right on top of the card fields.

Measure refusal, not just acceptance

A banner whose timing and placement are fair shows a stable, believable refusal rate. One that interrupts shows acceptance spikes that are really dismissal clicks. Look at acceptance by placement and by page type, and be suspicious of any configuration that produces near total acceptance. That number usually means the no path is hard to find, hard to reach, or covered by something else.

Keep the preference centre one click from the banner and from the footer, so a mistimed interruption is never the visitor's only chance to change a choice they made to clear their screen.

Frequently asked questions

Can a site delay showing a consent banner?

Non essential tags must wait regardless of when the banner shows. Within that constraint, timing and placement can be designed not to interrupt active transactions. Delayed interface is a design choice, firing tags early is a compliance failure, and the two should not be confused.

What should happen if consent is missing at checkout?

Default to not firing non essential tags, do not spawn a modal over payment fields, and offer the consent choice after purchase or in account settings. The transaction should never depend on dismissing a banner.

Does re asking after a banner change require interrupting the user?

Material changes can justify asking again, but the ask can wait for a natural break in the session. A vendor list update does not need to block a payment that is already in progress.

How can a team tell if banner timing is coercive?

Compare acceptance rates by placement and page, and test the refusal path on a phone. Near universal acceptance plus a hard to reach reject control is the signature of a banner people accept to make it go away.