First-party tagging without the server bill.
Google Tag Gateway serves Google's tag scripts from your own domain, using the CDN you already run. It's the cheapest durability improvement available to most advertisers — and the fastest way to find out whether you need a full tagging server at all.
The cheapest thing you can do about first-party measurement
Google describes it as deploying a Google tag using your own first-party infrastructure, hosted on your website's domain — set up through your existing CDN, load balancer or web server. No container to provision, no always-on compute to pay for.
Your domain
Scripts served under your hostname, so the easiest blocking signal — a third-party domain — is gone.
No new infrastructure
Runs on CDN capacity you already pay for. Live in days, with a rollback that takes minutes.
Consent unchanged
Delivery moves; your obligations don't. We verify the consent layer survives the change intact.
Configured, verified, and honestly measured
Gateway on your existing CDN
Configured through the CDN, load balancer or web server you already pay for — Cloudflare, Fastly, Akamai, Cloud CDN or your own nginx. No new infrastructure and no monthly server bill.
First-party script delivery
Google's tag scripts served under your own hostname instead of googletagmanager.com, so the easiest blocking signal disappears and the cookies they set are unambiguously first-party.
Consent Mode kept intact
Moving delivery changes nothing about your legal position. We verify the consent default still fires before your tags and that ad_user_data and ad_personalization survive the change.
Before/after measurement
A scan and a tag-firing baseline before we touch anything, and the same again after. You get the actual delta on your own traffic, not an industry benchmark.
Ad-blocker reality check
We test against the extensions your visitors actually run and tell you which still block. Some do. Anyone promising you otherwise hasn't checked.
Handover and rollback
Documented configuration, a rollback path that takes minutes, and a clear answer to who owns it when your CDN config changes next.
They fix different things
This is the question we get asked most, and the answer is usually 'both, in this order'. Google's own documentation recommends running them together.
| What you need | Gateway | Server-side GTM |
|---|---|---|
| Scripts served first-party | Yes | Yes |
| Monthly infrastructure cost | None — uses your CDN | ~$45/server/month, plus egress |
| Reshape or strip payloads | No | Yes |
| Enrich from your CRM | No | Yes |
| Meta CAPI, TikTok Events API | No | Yes |
| Time to live | Days | Days to weeks |
| Recovers consent-denied users | No | No |
The last row is the one that matters most and gets advertised least. Neither technology recovers a visitor who declined consent — that isn't a delivery problem, and routing around it is how a measurement project turns into a compliance one. The full argument is in Google Tag Gateway vs server-side GTM.
We don't quote a recovery percentage before looking at your site. No independent study establishes one, every circulating figure traces back to a vendor selling the service, and the real number depends on your browser mix, your consent rate and how much of your tracking was broken to begin with. We baseline first, change one thing, and measure. If the gain isn't there, that's the finding.
Baseline, configure, verify, hand over
- 1
Baseline
We record what your site fires today, from which hostnames, under what consent state — so the after-picture means something.
- 2
Configure
Gateway set up on your existing CDN or load balancer, mapped to your domain, with staging verification before it touches live traffic.
- 3
Verify
Re-scan, compare against the baseline, and test against real blocking extensions. If the gain isn't there on your traffic, we say so.
- 4
Hand over
Configuration documented, rollback tested, and a recommendation on whether server-side GTM is the right next step for you.
Google Tag Gateway, answered
No, and Google doesn't present it as one. Its documentation labels the combined setup — Gateway serving scripts from a CDN, plus a server-side container handling data collection and enrichment — as the recommended architecture. Gateway improves how scripts are delivered. It doesn't transform payloads, talk to your CRM, or let you strip personal data before it reaches Meta. If you need those, you need a tagging server.
It raises the cost of blocking; it doesn't end it. Blocklists match request patterns, endpoint paths and payload signatures, not only hostnames. Some extensions no longer block through Gateway and others — Ghostery among them — still block Google Analytics through it. We measure the effect on your traffic rather than quoting a number at you.
Neither. Gateway changes how data travels, not whether you're allowed to collect it. If your banner records a refusal and you collect anyway, first-party delivery makes that a better-engineered compliance problem. We check the consent layer as part of the work, because moving delivery is a good moment to find out it was never wired properly.
Usually nothing extra. It runs on CDN capacity you already have, which is the main reason to start here rather than with a tagging server — Google's own guidance puts a Cloud Run tagging server at roughly $45 per server per month before load balancing and egress, and you need more than one.
Days, not weeks, for most sites. The configuration itself is quick; the time goes into baselining beforehand and verifying afterwards, which is the part that tells you whether it worked.
Google supports setup through a CDN, load balancer or web server, so most stacks are viable — including Cloudflare, and self-managed nginx. We confirm against your specific setup during scoping rather than assuming.
Find out if it's worth it on your traffic
A scan tells you what your site fires today and from where. That's the baseline any honest before-and-after starts from.