Consent Mode Testing: Why Europe Sees Different Defaults

Consent mode testing means checking which consent state Google tags start with on a page and whether a banner click updates it, in Tag Assistant or in the requests the tags send. The answer depends on where the test runs: a site can set different defaults per region, and in a standard setup Google infers a visitor's location from the IP address, so a check from Europe shows the European defaults, which a US visitor may never get (Google: region-specific behavior, Google: how location is set). Everything below was checked against Google's, Chrome's and Wix's help pages on October 3, 2026.

Why can a test from Europe show denied defaults?

Because the site may set them for Europe only. Consent mode lets a site give one default to visitors from listed regions, written as ISO 3166-2 codes, and another to everyone else. A default without a region covers every visitor no region-specific default covers, and when a region and a subregion both match, the more specific one wins (Google). Google recommends that split: since privacy laws are region-specific, apply denied only to visitors from the appropriate regions so you keep precise measurement everywhere else (consent mode best practices). A site set up this way works as designed when a tester in the EU sees every type denied and a visitor in New York does not.

How does Google decide which region a visitor is in?

From the IP address. Google's Tag Manager help says that in a standard tag setup the browser talks to Google directly and Google infers the user's location from their IP address (Google tag gateway location). The same page warns that when Google tag gateway serves your tags through your own domain, your CDN has to attach geolocation headers, or region-specific consent defaults may not work. So the region your test lands in is the region of the network you test from, not the one you meant to test.

What does Wix do for visitors from the EU?

It holds Google Analytics back. Wix's help says that if a site has no cookie banner and a visitor comes from a country that requires consent, such as those covered by GDPR, no data is sent to Google Analytics (Wix: troubleshooting Google Analytics). With a banner, Google Analytics and Google Ads gather data only after the visitor consents (Wix: Google Analytics, Wix: Google Ads). The Wix pages I read do not say how Wix decides where a visitor comes from, so I do not rely on a browser setting to change it.

What went wrong in my own check?

An agent checked a US site from Europe. While I researched practices for outreach, agents audited their public pages with headless Chrome and captured what each page loaded and sent: gtm.js, the gtag config, any conversion request. They worked read-only and never submitted a form. One finding said a practice's Wix site set consent to denied and showed no banner. It was true only because the check ran from Bulgaria: on that site the denied state applied to visitors in the EU, so a visitor in the US never got it. A fact-checker agent caught it, and I withdrew the finding.

Lauren Tan, an engineer at Cursor, said in a recorded talk that agents lose your trust when they confidently announce the "smoking gun" and it is not the real problem, and that the skill that matters most is verification: an agent that actually runs the thing. My agent had run the real page. It ran it from the wrong place, which is why I now treat any consent observation made from the EU as EU-only until it is re-checked from outside the EU.

What does a VPN or a US machine change?

The IP address, which is what Google reads in a standard setup. Connect through a VPN exit in the US, or use a machine in the US, and Google's tags should apply the defaults you set for that region, unless your tags run through a tag gateway whose CDN does not attach the geolocation headers. Do not take the VPN's word for the location. The proof is the Consent tab in Tag Assistant, where the On-page Default column should match the defaults you set for the US (Google: verify consent mode). If it still shows your EU defaults, the test never left the EU.

What does a simulated location in Chrome change?

What the page's own scripts can read from the browser. A DevTools location preset holds a latitude, a longitude, a timezone ID and a locale; you add one under Settings > Locations and pick it from the Geolocation list in the Sensors panel (Chrome: locations, Chrome: Sensors). None of these is the IP address your requests come from. Google's troubleshooting page still says to set a simulated location in Chrome to check regional defaults (Google), so try it, but trust the On-page Default column over the setting: if the defaults did not move, test from a network in that region.

How do I test each region honestly?

Run the same test from each place that matters and label every result with where it ran.

At each location, open Tag Assistant, enter the site's URL, open the banner if there is one and accept all. In the Summary, the earliest Consent event shows the defaults and the most recent one shows the update (Google: verify consent mode). If you capture network requests instead, consent travels in parameters such as gcs, which carries ad_storage and analytics_storage, and gcd, which Google sends whether consent mode is on or not; Google warns these fields may change (Google: consent mode HTTP parameters). Setting the region defaults themselves is check 5 of consent mode v2 in Google Tag Manager, and check 9 there repeats the Tag Assistant test per region.

Before you act on a consent finding

A consent result describes the visitors of the place it ran from and nobody else. Write that place next to the result, and repeat the test from every region you set a default for. If you want consent defaults set per region and verified from each one on your site, that is my consent-safe measurement work.