Does Google tag gateway need cookie consent?

All posts

Yes. Google tag gateway changes where your Google tag loads from, not what consent it needs. The tag is served from a path on your own domain, but it still reads Consent Mode, so your banner, your consent defaults and each tag’s consent settings still apply. The one thing to check is load order: your defaults must still be set before any Google tag fires.

That last point is the one worth your time. The legal side of the question has a short answer, and the practical side has a short checklist. Both are below.

What does Google tag gateway actually change?

Google tag gateway for advertisers loads your Google tag or your Tag Manager container from a path on your own domain, such as /metrics/, instead of from googletagmanager.com. The measurement requests go to that path too, and your CDN or load balancer forwards them to Google. Google’s developer page describes it as running your tag on your own first party infrastructure.

There are two ways to switch it on. If your site sits behind Cloudflare, you can do it from Tag Manager under Admin, Google tag gateway, then authorise Google in Cloudflare and pick the domains. On any other CDN you route the measurement path to your tag’s fps.goog address, forward the visitor’s location headers and change the src in your snippet to the new path.

Either way, three things change: the address the script comes from, the address the requests go to, and who forwards them. Nothing in that list touches consent.

Does serving tags from your own domain change your consent obligations?

No. The EU consent rule in Article 5(3) of the ePrivacy Directive is about storing or reading information on the visitor’s device. It does not ask which domain the script came from. A Google Analytics cookie set by a tag loaded from /metrics/ is still a cookie that needs consent where consent is required.

Google says the same thing in its own setup page. The Cloudflare setup guide for tag gateway warns that enabling the feature affects how Google tags fire, and tells you to adopt Consent Mode and review your consent settings if consent already shapes your tags.

So a gateway is not a way around a cookie banner. If your banner was needed before the switch, it is needed after it.

Can tag gateway break your consent setup?

It can, through order rather than law. Consent Mode only works when the default consent state is set before any Google tag fires, which Google’s consent setup guide spells out. Whether the gateway disturbs that depends on where your defaults come from.

• Your consent platform runs inside Tag Manager. The template sits on the Consent Initialization trigger, which runs before every other trigger in the container. The container still loads as one piece, just from a different address, so the defaults still come first.
• Your consent platform is a separate script in the page. Here the order depends on the page. If the CDN now serves or injects the Google tag earlier than before, it can run ahead of your consent script. Google’s tools then report the default as set late.

We see the first case on our own site. veloconsent.com loads its Tag Manager container from a path on its own domain through a Cloudflare Worker. That is our own proxy rather than Google’s gateway, but the idea is the same, and the Velo template on Consent Initialization still sets the denied defaults before any other tag runs.

If you are in the second case, the fix is in your page or your set up, not in the consent rules. Any one of these restores the order:

• Load the consent script above the Google snippet, so its defaults run first.
• Move the consent defaults into Tag Manager, on the Consent Initialization trigger.
• If the automatic Cloudflare set up is what moved the tag, use the manual set up instead. You edit the snippet yourself, so you decide where it sits.

Then confirm it in Tag Assistant, as in the checks below. Our post on whether to block Google tags until consent covers how basic and advanced Consent Mode treat tags that load before a choice.

What stays the same after you switch?

Almost everything you configured for consent carries over, and none of it is done for you by the gateway.

• Google Analytics, Google Ads and Floodlight tags read Consent Mode on their own. Custom HTML tags and most community templates do not, so their consent settings in Tag Manager still matter.
• Enhanced conversions still depend on ad_user_data. If the visitor refuses advertising, that data should not be sent, whichever path the tag uses.
• Your consent platform’s own script keeps loading from where it did. With Velo, that is Velo’s address, and that is expected.
• A server container still receives the consent state with each request. Google’s server tags follow it. Other vendors’ server tags need their own consent checks, as our guide on passing consent to a server side container explains.

Our help guide walks through the setup in order, from serving Google tags through tag gateway to carrying consent into server side tagging.

How do you check consent still works after switching?

Run the same consent test you ran before the switch, plus two checks for the gateway itself. Start every test in a fresh browser session on the published site.

1. Check the gateway is healthy

   Open /metrics/healthy and /metrics/?validate_geo=healthy on your domain, using your own path. Both should return ok. If only the second fails, the location headers are not being forwarded.

2. Confirm the new path is in use

   In your browser’s network tab, the Google tag and its requests should go to your measurement path. If they still go to googletagmanager.com, an old copy of the snippet is still on the page.

3. Check the defaults come first

   In Tag Assistant, the consent default should appear before any Google tag fires. A default reported as late means your consent script now loads after the tag.

4. Test accept, reject and a partial choice

   Check the consent state on each tag for all three. Tags with extra consent settings should stay blocked after a rejection.

5. Change your mind on a later page

   Reopen the banner, change the choice, and check that the update reaches the tags on the next page.

Does tag gateway bring back the data consent hides?

No. A visitor who refuses is treated the same way whichever domain the tag loads from. Google presents the gateway as a way to make measurement more durable, which is about the script loading at all, for example where a blocker would stop it. That is a separate problem from consent, and the gateway does not change it. If you want to understand what a refusal does to your reports, start with what happens to GA4 data when users reject cookies.

Velo’s Tag Manager template sits on Consent Initialization, so the defaults come first whichever address serves your container. Switching on the gateway is then a routing change, followed by one round of testing.