The short answer

If you want to honor what visitors think they're agreeing to when they decline tracking, hard-block opt-in is the only configuration that delivers. Advanced Consent Mode keeps sending data to Google even when someone clicks "Reject." Basic Consent Mode holds everything until consent is granted. A hard-block setup goes one further and doesn't fire any third-party tags until a visitor explicitly says yes.

The rest of this article explains why the difference matters, how to verify your own configuration, and what good actually looks like in practice.

What the three configurations actually do

Advanced Consent Mode — Pre-consent behavior: sends "cookieless pings" immediately on page load. What Google receives before consent: truncated IP, page URL, referrer, browser/device info, consent state flags.

Basic Consent Mode — Pre-consent behavior: holds tags entirely until consent is granted. What Google receives before consent: nothing.

Hard-block opt-in — Pre-consent behavior: no third-party tags fire at all before consent. What Google receives before consent: nothing.

The distinction between Advanced and Basic is not subtle. With Advanced mode enabled, a visitor who loads your page and immediately declines your cookie banner has already transmitted data to Google before they ever saw the prompt. Their consent — or refusal — happened after the fact.

What "cookieless pings" actually contain

When a user denies consent under Advanced Consent Mode, Google documents that it receives reduced, cookieless signals. Independent analysis from Simo Ahava, one of the most respected voices in the analytics space, describes what those signals include:

- IP address (truncated after country determination, per Google's own documentation)
- Consent state flags via gcs and gcd parameters
- Page URL and referrer information
- Browser, device, and screen specifications
- Timestamp and session context
- "Random, ephemeral identifiers" that replace cookies but serve a similar function

Brian Clifton, former Google Head of Web Analytics for EMEA, put it plainly: "I cannot see any way of defining the cookieless pings from consent mode as being strictly necessary. They contain plenty of personal identifiers and these are specifically for Google's eyes only — it is a trivial matter for Google to stitch together these hits to identify individuals."

That's the honest picture. Advanced mode is a measurement tool designed to preserve Google's modeling capabilities in a consent-required environment. It's useful for that purpose. But it does not hold data until consent — and that's the distinction that matters when visitors think clicking "Reject" actually stops the data flow.

As of June 15, 2026, Google made the ad_storage consent parameter the sole gate controlling whether GA4 advertising data flows to Google Ads. The Google Signals admin toggle no longer restricts it. This means your consent configuration — and whether it actually holds before user approval — now carries more weight than it did a year ago. A setup that leaks pre-consent data is now leaking into a more consequential pipeline.

Privacy is about what visitors think "no" means

When someone clicks "Reject All" on a consent banner, they have a reasonable expectation: nothing is being tracked. That's the plain-language meaning of the interaction, and it's what the banner is implying.

Advanced Consent Mode breaks that expectation. The visitor said no. The site sent data anyway. The fact that the data is "reduced" or doesn't include a persistent cookie doesn't change the basic picture: the visitor's stated preference was not honored.

This matters for reasons that go well beyond compliance. Trust is a brand asset. Visitors who learn — through a privacy-savvy friend, a browser extension, or a news article — that sites using Advanced Consent Mode are still sending signals after a denial have a legitimate grievance. A privacy-first configuration is one where "no" means no, and a site owner can say with confidence: "When you declined, nothing went anywhere."

State privacy laws and regulators increasingly expect opt-outs to actually work. But beyond that, it's simply the right posture for an organization that wants its consent interface to mean what it says.

The honest trade-off

Yes, hard-block means less data. For users who don't consent, you won't have conversion tracking, and Google's modeling won't fill the gap the way Advanced mode's cookieless pings enable.

The reframe: you're measuring the people who said yes, and respecting the ones who didn't. Your analytics reflect a real, consented audience. You can optimize for them. You can report on them with confidence. The unconsented visitors aren't missing from your metrics — they've just told you they'd prefer not to participate, and you've honored that.

This is a better story to tell internally, and a better story to tell clients, than "we kept sending data anyway, just less of it."

What good actually looks like: a best-practices list

Opt-in by default. No pre-ticked boxes. No tags firing on page load. If someone hasn't interacted with the banner, treat them as non-consented.

Honor Global Privacy Control (GPC). If a visitor's browser sends a GPC signal, treat it the same as a manual opt-out. Detecting and respecting GPC is straightforward with most consent management platforms.

Opt-outs that actually stop tags. Verify this yourself (see next section). "Consent configured" and "consent working" are different things.

Plain-language banners, no dark patterns. The "Accept" and "Reject" buttons should be equally prominent. Burying the decline option in a settings submenu signals that you're trying to extract consent rather than earn it.

Basic or hard-block only — not Advanced. If you're using Google's Consent Mode infrastructure, use Basic mode. It holds all tags until consent is granted and provides the same post-consent measurement as Advanced, without the pre-consent data transmission.

Periodic self-audits. CMPs, GTM configurations, and third-party embed updates can silently break your consent gates. Run a network audit every quarter or when you make significant site changes.

How to verify your own site

This is the most practical thing in this article. Open Chrome DevTools, go to the Network tab, and reload your page without interacting with the consent banner. Filter by domain. You should see zero requests to:

- google-analytics.com
- googletagmanager.com (tag-firing requests)
- doubleclick.net
- connect.facebook.net
- analytics.tiktok.com
- snap.licdn.com
- Any other third-party analytics or advertising endpoint you've configured

If any of those domains appear before you interact with the consent banner, your pre-consent gate is not working.

Common failure points to check:

- GTM triggers set to fire on "All Pages" without a consent exception
- Consent Mode configured to Advanced instead of Basic
- Race conditions where tags fire before the CMP has initialized (especially common on fast connections where the CMP loads slightly after GTM)
- Third-party widgets — chat tools, social sharing buttons, video embeds — that initialize their own tracking independently of your CMP

If you find failures, the fix is almost always in GTM: add a consent check trigger exception to any tag that fires before consent is confirmed, and switch from Advanced to Basic consent mode in your Consent Mode configuration.

How we implement this with Termly

On a number of client sites we use Termly as the consent management platform — but a good CMP still needs a deliberate implementation to be genuinely hard-block. We don't drop in the banner and rely on auto-blocking. Instead, we route trackers through Google Tag Manager behind consent-based triggers, so tags are held until the visitor makes a choice. We then manually classify each gated service in Termly's cookie database so the cookie policy and banner disclose it accurately — Termly's auto-scanner can't see trackers that are properly gated, because they never load for an anonymous crawl. Finally, we verify in a real browser that nothing fires before consent and that category opt-outs actually stop the right tags.

ConsentLine: hard-block as the default

ConsentLine is our own consent management platform, built around exactly the philosophy this article recommends: nothing loads before consent — no pings, no "cookieless" requests. Tags are hard-blocked by default and gated until the visitor consents. It honors Global Privacy Control, adapts to the visitor's state privacy framework, keeps a consent evidence record, and continuously monitors live sites for consent drift — the quiet failure where a tag slips in front of the banner after a site update. Hosted policy pages and a client portal round it out. Every deployment is verified in-browser: decline consent, and the network tab shows zero requests to Google or any tracking domain. More on ConsentLine here.

The recommendation

For organizations that want their consent setup to mean what it says: maintain a hard-block opt-in configuration and do not enable Google Consent Mode v2 Advanced.

If you need Consent Mode for Google Ads conversion modeling, use Basic mode. It provides zero pre-consent data transmission while enabling full measurement for users who do consent. You sacrifice the cookieless modeling for non-consented visitors, and you gain the ability to say with confidence that your consent banner is not performative.

The right framing isn't "how do we technically satisfy the consent requirement while preserving as much data collection as possible." It's "when someone on our site declines tracking, does that actually work?" Advanced mode's honest answer is no. Basic mode and hard-block say yes.

That's the configuration worth building — and worth verifying.

Questions about your current consent setup? Start a conversation with our team.