Google Tag Gateway loads Google's scripts from your own domain instead of Google's servers. Your tags go from third-party to first-party, and become hard to block again. It is official, it is free, and it is available today. But on the two sites I audited, only one was actually recovering its conversions: the other showed a green status and sent back nothing. Here is how to turn it on, and more importantly how to check that yours is doing its job.

This is one of the jobs I handle as a freelance Google Tag Manager consultant, and the one that pays off fastest when it is done properly.

What actually changes

Before, your container loaded from googletagmanager.com. After, it loads from yourdomain.com/metrics/?id=GTM-XXXX.

Picture a bouncer at the door. Your script used to show up in a uniform from an outside company: easy to turn away. Now it wears yours.

  • The tag does not change function, it changes shipping address.
  • This is not a grey-area workaround: Google documents it officially, with two implementation paths, a CDN or a tagging server.
  • The rule: a script served from your own domain stops being an easy target for blockers and browser restrictions.

It is already available

This is the question that comes up most often, and it starts from a false premise. The gateway is not coming: the one-click Cloudflare integration works, Google's documentation is live and maintained, and sites are running on it right now.

Where each integration stands, verified in August 2026:

  • Cloudflare: one click, the simplest and most common path.
  • Google Cloud: generally available since 1 June 2026. Note that it requires the global external Application Load Balancer, the classic one is not supported.
  • Akamai and Fastly: shipped, integrated inside the Google interface since May 2026, but still labelled beta in the documentation.
  • Amazon CloudFront: supported since June 2026, with a guided flow in Tag Assistant.
  • Webflow and Duda: gateway on by default for tags placed through the native integration. Three caveats: incompatible with custom-code installs, republishing required if the tag ID was already in place, and unavailable if you export your site to host it elsewhere.

Shopify, Wix, Squarespace and WordPress all have the Google tag integration, but I found no default-on gateway for any of them so far.

What it costs

The feature is free. What can cost you is the infrastructure carrying it.

  • On Cloudflare: free, you use the plan you already pay for. Zero marginal cost.
  • On another CDN: free on the gateway side, variable depending on your CDN and volume.
  • With a tagging server: free on the gateway side, you pay for the cloud server.

Whether it is worth it for you

One question decides it: are you losing conversions today?

  • You are concerned if a meaningful share of your traffic is on Safari or iOS, if your audience is technical so it runs blockers, or if the gap between your platform conversions and your actual sales keeps widening with no explanation.
  • You can wait if your tracking has problems further upstream: badly declared events, shaky consent, duplicates. The gateway carries a correct measurement better. It does not repair a wrong one.
  • In ecommerce, the effect is immediate: transactions that had stopped being attributed become attributed again.
  • In lead generation, the effect is indirect but often more profitable: a more complete signal feeds automated bidding better, so your cost per acquisition settles before volume even moves.

On the numbers going around, let me be straight. Google reports an average of +14% conversions, and now "up to 7% lower cost per acquisition". Both come from the party selling the feature, so treat them as sales arguments, not as expected results. The published case studies, an insurer around 15 to 30% of conversions recovered, a cosmetics brand around 22%, are selected cases: they prove such a result is possible, never that it is likely for you. Nobody publishes the rollouts that changed nothing.

The only number worth anything is the one you measure on your own account, before and after.

Which path to pick

Place yourself in three questions.

  • No tag installed at all? Put the Google tag and a CDN in place, the gateway follows. Nothing to undo, this is the simplest scenario.
  • A standard client-side tag? It all depends on your CDN. On Cloudflare, one-click integration. On another CDN, a manual but documented setup. With no CDN, you choose between moving to a free CDN or standing up a tagging server.
  • Already running a tagging server? You install nothing new, you switch your serving from third-party to first-party. Shortest path to the best result.

My take, and it is a clear one: if you are on Cloudflare and hesitating, take the one-click integration today. A tagging server is a better tool, but it is a project. A real benefit beats a perfect plan that keeps waiting.

Turning it on with Cloudflare

A few clicks, no code: the tag rewrite happens at the edge.

One counter-intuitive point first. Google states that your page source will show the correct first-party URL even if your original server files still point to googletagmanager.com. Do not worry if your source HTML has not moved: what counts is what the visitor receives.

The reverse, though, is a real failure mode. If the page delivered to the visitor still references googletagmanager.com, the rewrite did not fire. This is documented in the community, notably with protocol-relative snippets (//www.googletagmanager.com/...). When that happens, go check your zone configuration.

Turning it on by re-tagging manually

You replace the source of every Google script with your measurement path. The official syntax uses a relative path with no filename:

  • For Google Tag Manager: j.src='/metrics/?id='+i+dl;
  • For gtag: <script async src="/metrics/?id=G-XXXXXXX">

Three details that save time:

  • Avoid /metrics/gtm.js?id=.... It works, but it keeps patterns (/gtm.js, .js?id=GTM-) that blocking rules recognise. You give up part of the benefit for nothing.
  • Leave the <noscript> iframe as is. It is not served by the gateway and its impact is negligible.
  • Do not re-tag your tags one by one. The container served by your measurement path already carries that path, so dependent tags, Google Ads conversion and GA4 alike, follow automatically.

Turning it on with a tagging server

If you already run one, you switch your serving from third-party to first-party. Heavier, and you gain full control of the data before it leaves: modification, enrichment, anonymisation, and server-managed cookies whose lifetime no longer depends on browser restrictions.

The trap: active does not mean carrying

Here is the heart of it.

Scripts and measurement hits are two independent axes. A gateway can serve your scripts first-party while routing no data at all. You see a green status, your tags load, and your conversions still go straight to Google. So they stay blockable.

Loading the script is letting the delivery driver in. Sending the hits is letting him leave with your order. A gateway that does the first without the second had you install a door for nothing.

On the two sites I audited in July:

  • A client account: scripts first-party and Google Ads hits first-party. The conversion signal survives blocking. That is the nominal case.
  • My own site: scripts first-party, no hits at all. Gateway active, zero benefit.

Yes, my own site. I found the problem while building the audit tool.

I have fixed it since, and the new audit shows exactly what that changes: my Google Ads conversion hits now leave from my own domain, and they survive blocking. One thing did not move, and it is instructive: my GA4 hits still go straight to Google. That matches the documentation, which says "some" requests will go through your domain. The gateway is not a switch, it is a destination-by-destination configuration.

And the first time I ran that audit, I got it wrong. I was looking for scripts by URL pattern, filtering on gtm.js. Result: nineteen first-party loads counted as zero, a completely false "scripts not working" diagnosis, and a re-tagging recommendation that had no reason to exist. The reason is interesting: the gateway serves its scripts under random paths, along the lines of /metrics/OvgO--ioXpMMINbFsRy..., precisely to escape pattern-based blocking rules. No filename search will ever see them.

The trap nobody mentions: your geolocation

I never saw this written anywhere before I hit the documentation.

Once your requests go through your CDN, Google no longer receives your visitor's IP address, it receives the CDN's. With no extra configuration, your reports show wrong geography, and consent mode defaults, which depend on country, go off track.

  • On Cloudflare, geolocation headers are forwarded automatically. Nothing to do.
  • On CloudFront and Azure Front Door, it is manual: skip it and you trade a blocking problem for a data problem.

Two more limits worth knowing before you route traffic:

  • On Akamai, only one Google tag is supported. Multiple tags expose the gateway to script injection and can break it. The documented fix is to consolidate everything into a single container.
  • The gateway only carries Google cookies. Non-Google cookies routed through it are dropped.
  • Manual Cloudflare setup requires an Enterprise plan. Without Enterprise, use the in-interface integration.

Reading the Google panel without panicking

The gateway shows a status in your account admin. Three values, and the third one worries people for nothing.

  • Owned (or first-party): the gateway is active on this domain. It says nothing about hits.
  • Not started: nothing is enabled.
  • Incomplete: at least one detected domain is not covered. Often cosmetic. The typical case: Google detects your naked domain alongside the www, while the naked domain permanently redirects to www and never serves a single page. Check the redirect before starting a project.

Two false signals to know:

  • gtg_health=1 is not a failure. A request to googletagmanager.com carrying that parameter is the gateway's health probe. It fires even when everything works.
  • Not every request routes, by design. The official documentation says "some" measurement requests will go through your domain. A few direct requests do not mean it is broken. Zero first-party requests, that does.

The five-minute check

  1. Open your browser's Network tab on a conversion page.
  2. Filter by resource type "Script", not by filename, you just saw why.
  3. Then look at where the measurement requests come from, the ones containing collect or conversion: your domain, or a Google domain?

If the scripts sit on your domain but every measurement request goes to Google, your gateway loads without carrying. Usually the destinations are not properly declared in the panel.

Two details to read what you see correctly:

  • Two URL shapes coexist and both are valid. Manual re-tagging produces /<path>/?id=XXX, the Cloudflare rewrite tends to produce /<path>/gtag/js?id=XXX. Seeing the second when you thought you did the first is not an error: the edge took over.
  • The default measurement path is not /metrics. Google generates a four-character alphanumeric one, something like /a7x2. If you search for /metrics and find nothing, look instead for a meaningless four-character string.

The gateway changes nothing about your obligations.

  • Advanced consent mode: no extra configuration.
  • Basic consent mode: restrict advertising data transmission, which amounts to tag blocking.

It carries the data you are allowed to collect better. It does not allow you to collect more.

What I cannot promise you

No quantified adblock recovery rate is verifiable today. The numbers going around are either isolated cases or orders of magnitude with no published methodology. I looked, I found nothing that holds up.

Two blind spots no browser inspection covers, and they deserve naming:

  • Seeing a request leave your domain does not prove Google ingested it. Confirmation happens platform-side, in the GA4 realtime report or the gateway panel.
  • Your exact CDN zone configuration stays invisible from the page. If the rewrite does not fire, that is where the cause sits.

Verdict

  • Turn it on now if you are on Cloudflare: zero cost and a few clicks.
  • Check the hits, not the scripts. A green status and loading tags prove nothing. The only test that counts is where your measurement requests come from.
  • Measure on your own account: a baseline over a clean period, then activation, then a comparison on comparable volumes. And re-check after every change, this feature moves fast.

If you want to know what your tracking is actually losing today, before touching anything, that is exactly the kind of diagnosis I run in a Google Ads audit.