Consent Mode Doesn't Have to Apply Everywhere

One of the most common Consent Mode v2 mistakes is applying a single strict, all-denied default to every visitor on earth. It feels safe. It isn't: you needlessly throw away measurement from regions that don't require prior consent, and you can even suppress data you're legally entitled to collect. Google built the region parameter precisely so you can gate strict behaviour to the traffic that needs it, the EEA, the UK and Switzerland, and let the rest of your audience be measured normally.

This is a targeting decision layered on top of your implementation choice. Haven't picked a mode yet? Start with advanced vs basic Consent Mode, then come back to scope it by region.

Why Only the EEA, UK and Switzerland?

Google's requirement to collect and transmit the Consent Mode v2 signals, specifically the two newer ones, ad_user_data and ad_personalization, comes from its EU User Consent Policy and the EU Digital Markets Act. Those obligations attach to users in the European Economic Area, the UK and Switzerland. A visitor from the United States, Brazil or Japan isn't covered by that particular Google policy, which is why Google's own guidance is to scope your strict consent defaults to the regions where you show a consent banner.

That doesn't mean those other regions have no privacy law. It means their requirements are different, and your own regional banner logic handles them, not Google's EEA-specific consent enforcement. More on that distinction below. For the policy itself, see Google's EU User Consent Policy explained.

How the Region Parameter Works

You set defaults with gtag('consent', 'default', {...}), and you can attach a region array of ISO 3166-2 codes to make a command apply only to those locations. Issue a scoped, strict command first, then a looser fallback command for everyone else:

// Strict defaults for EEA + UK + Switzerland
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500,
  'region': ['AT','BE','BG','HR','CY','CZ','DK','EE','FI','FR','DE','GR','HU','IE','IT','LV','LT','LU','MT','NL','PL','PT','RO','SK','SI','ES','SE','IS','LI','NO','GB','CH']
});

// Fallback for everyone else
gtag('consent', 'default', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

The EEA is the 27 EU member states plus Iceland, Liechtenstein and Norway; GB and CH extend the same strict treatment to the UK and Switzerland, where Google's consent requirement also applies.

Precedence: Most Specific Region Wins

When a visitor's location matches more than one command, Google applies the one with the more specific region. A command scoped to US-CA (California) overrides a broader US command for California visitors, and a country-scoped command overrides the unscoped fallback. This lets you build layered rules, for example a stricter posture for a single US state, without disturbing the EEA block. Order your commands from most specific to least, and remember that a command with no region is the catch-all default for everywhere not otherwise matched.

The Trap: Granting Everything Outside the EEA

The fallback command in the example above grants consent by default for non-EEA traffic. That's a legal decision, not a default to copy blindly. Several jurisdictions outside the EEA also require consent or an opt-out before non-essential cookies fire:

US state laws increasingly require honouring opt-out signals and, in some cases, opt-in for sensitive data. See US state privacy laws 2026.
Switzerland sits inside Google's consent requirement (hence CH above) and has its own revised data protection law.
Brazil, Canada and others impose their own consent rules.

The right mental model: use Google's region parameter to satisfy the EEA/UK/Swiss Consent Mode obligation, and use your consent management platform's regional banner logic to satisfy every other jurisdiction's rules. The two systems cooperate; neither replaces the other.

One Banner, Many Regions

In practice you rarely hand-code these lists. A regional consent system detects the visitor's location and both shows the appropriate banner and sets the matching Consent Mode defaults, so a single deployment behaves strictly in the EEA and appropriately elsewhere. That architecture, running one banner across a global audience without maintaining separate sites, is covered in regional consent: one cookie banner across a global audience.

Common Region-Scoping Mistakes

Forgetting UK and Switzerland. The EEA is not the UK, and neither is Switzerland. Google's consent requirement covers all three, so your strict block needs GB and CH in addition to the EEA codes. Leaving them out understates your obligations.
Setting the fallback to granted without a legal review. A blanket "granted everywhere else" is a decision your privacy counsel should sign off on, because several non-EEA regions have their own consent or opt-out rules.
Setting defaults after tags load. The default command must run before any Google tag fires. If a tag beats the default, it may fire with an assumed state, defeating the point of the gating.
Testing only from your own location. If your office is outside the EEA, you'll never see the EEA behaviour unless you deliberately simulate an EEA visitor. Regional bugs hide from anyone who doesn't test across regions.

Verify the Gating Actually Works

Regional bugs are silent, because you only see them if you test from the right location. Use your tag manager's preview with a geo override, or a VPN, to load the page as an EEA visitor and confirm all four signals default to denied before any tag fires. Then load as a non-EEA visitor and confirm your intended fallback applies. A default that silently grants ad signals to EEA users is both a compliance failure and a data-integrity problem, so this check isn't optional. For method, see how to debug Consent Mode v2.

Consent Mode v2 for EEA vs Non-EEA Traffic: Regional Gating