Google Tag Gateway (GTG), Google Tag Manager Server-side (sGTM) with Addingwell, or both?

James Ensor, Head of Sales UK at Addingwell by Didomi, explains the difference between GTG and sGTM, and why the distinction matters for anyone making decisions based on attribution data.

9
min read
Summary

Google recently made it easier to set up first-party tagging for Google tags. You can configure Google Tag Gateway (GTG), effectively routing your scripts through your own domain.

It's a starting point, and if you're not doing anything server-side yet, it's a meaningful improvement from doing nothing.

But, if you're a marketer, digital or analytics professional that is concerned about the reliability of your conversion data, it's worth understanding exactly what GTG does and (more importantly) what it doesn't do.

What Google Tag Gateway actually does

In a standard setup, your site loads Google scripts (GTM, GA4 and Google Ads) directly from Google's own domains. Ad blockers know this, and block accordingly. GTG changes the routing so those same scripts load from your domain instead; your CDN acts as a gateway in the middle.

The result: some ad blockers that relied purely on recognising the Google domain are avoided.

Where Google Tag Gateway falls short

Here is the bit that often gets overlooked when it comes to GTG.

Since Safari 16.4+, simply setting cookies server-side isn't automatically enough. Safari now compares the IP address of your main domain with the IP of your tracking server. If the first 16 bits differ, it caps the cookie at 7 days even though it was set via an HTTP header. A standard sGTM setup on a separate cloud (e.g. Google Cloud) fails this check too.

GTG addresses the first part of the problem, getting Google scripts loaded from your domain. But Safari's ITP has a second check it doesn't touch: how cookies are set. With GTG, cookies are still written by the Google tag's JavaScript, which puts them straight back into the 7-day cap. To extend cookie lifetimes properly, the cookies need to be set via a server-side HTTP Set-Cookie header and that requires sGTM.

Combining GTG with sGTM gets you both, but it's sGTM doing the Safari work, not GTG.

A Safari user who converts 10 days after their first visit may well look like a new user in your reporting, and your campaigns won't attribute that correctly. Safari accounts for 25–30% of UK web traffic so this gap materially understates campaign ROAS for most UK advertisers.

  • Ad blocker bypass is partial, not complete. More sophisticated blockers don't just filter by domain; they filter by request patterns, URL structures, and known tracking signatures. A request that looks like a GA4 collection is still recognisable to many blockers, even when routed through your own domain.
  • It only covers Google. GTG is a Google product. It loads the GTM container first-party, which benefits your Google tags, but Meta, TikTok, Pinterest, or affiliate pixels inside that container still fire as third-party requests to their own domains. The Safari and ad blocker problems you thought you'd fixed are still there for everything that isn't Google. If you're running any meaningful paid social alongside Google, half of your measurement stack is untouched.
  • No data control. With GTG, data flows from browser to Google in essentially the same way as before; you haven't gained the ability to filter, enrich, or govern what gets sent. PII stripping, consent enforcement, deduplication... none of that is within scope.

GTG changes which domain serves the script. sGTM changes where data is processed, and that's fundamentally a different thing.

The hidden cost: it's not just about reporting

There's a consequence to all of this. Broken measurement doesn't just mean inaccurate dashboards; it compounds through other areas of a business.

Ad platforms optimise on broken data

Ad platforms are all fed by the conversion signals you send back. When 20% of Safari users go missing, those algorithms aren't just reporting the wrong numbers; they're optimising on them. They bid harder against audiences that look like the converters they can see, and ignore the ones they can't. Your media budget is being misallocated in real time.

Onsite experience and merchandising suffer

Ecommerce teams use tracking data to personalise homepage modules, power recommendation engines, trigger cart abandonment flows, and decide which products get surfaced on category pages. When attribution breaks, the signals feeding those systems get noisier: "frequently bought together" logic becomes less accurate, abandonment triggers miss returning users, and merchandising decisions get made off incomplete session data.

CAC looks worse than it is

When conversions go untracked, reported cost-per-acquisition inflates. Channels that are genuinely performing get under-invested in. Channels that happen to attribute better (usually bottom-of-funnel) get disproportionate credit. Over time, this pushes your mix toward easily-measured channels and away from the brand work that's actually driving demand.

Remarketing audiences shrink

Pixel-built audience lists lose members every seven days on Safari. Lookalike seeds degrade. Retargeting pools you spent months building quietly deflate, and the algorithms building audiences off them are working from shallower, less representative data.

CRM and lifecycle marketing lose context

If you can't identify returning visitors reliably, you can't stitch web behaviour to CRM records. Lead scoring, email triggers, product recommendations, journey analytics... they all rely on knowing today's visitor is last month's converter. Broken cookies break that chain.

Tracking breaks silently, and nobody notices

On a client-side setup and GTG, which executes in the browser, a broken tag can go undetected for weeks. A site deployment wipes a GTM trigger, a consent banner update blocks an event, a third-party script changes its API. The first anyone finds out is when someone queries why GA4 numbers look odd. A managed server-side setup like Addingwell surfaces those failures in real time, with alerts when event volumes drop or tags start failing. For digital teams who already own site uptime and performance SLAs, measurement deserves the same operational rigour.

Board reporting understates commercial performance

The numbers presented at board level (ROAS, CAC payback, marketing contribution to revenue) are all built on this same attribution data. A marketing team can be doing genuinely excellent work and have it invisible in the numbers because of a tracking gap nobody investigated.

Fixing the measurement layer isn't about cleaner reports. It's correcting the inputs that budget allocation, channel mix, onsite experience, lifecycle, and board conversations are built on.

What server-side GTM actually solves

Server-side GTM, running through a managed platform like Addingwell, moves data collection and processing out of the browser, where most of these limitations originate. It addresses the root cause rather than the symptoms.

On Safari, the key is not just setting cookies server-side but doing so in a way that passes Safari's IP-matching check. Addingwell offers two approaches:

  1. Reverse-Proxy DNS setup that routes the tracking server through the same CDN edge as your main domain to ensure the IPs align and Safari accepts cookies as genuine first-party with up to a 13-month lifetime.
  2. Cookie Restoration fallback using a server-side Master Cookie that restores marketing cookies on each return visit, for sites that can't use a reverse proxy.

On ad blockers, sGTM goes further than GTG. Rather than switching the serving domain, the request signatures themselves are transformed so the calls no longer look like standard GA4 collection to a blocker scanning for such patterns.

Most importantly, because everything flows through a server container you control, you gain real data governance: you can enrich events with CRM data, apply consent rules consistently, strip PII before it reaches any third party, and send to any destination: Google, Meta, TikTok, Snapchat, affiliates, etc.

Let's talk about costs

It would be disingenuous not to mention cost. GTG is free to use, and if you're on Cloudflare's automatic integration, setup is genuinely quick. One caveat worth flagging for European businesses: the automatic Cloudflare integration doesn't route traffic within Europe. Manual EU routing requires a Cloudflare Enterprise plan, which comes with a monthly cost. Outside that specific scenario, GTG is essentially free.

Addingwell is a paid platform. Pricing scales with traffic and the features you need, but it's worth being upfront that it's a real ongoing cost, not free infrastructure. What that buys is everything GTG doesn't do: the Safari fix, multi-platform support across Meta, TikTok and the rest, data enrichment, consent governance, and monitoring when something breaks. Whether that's worth it depends on how much those gaps are costing you in attribution, lost audiences, and broken tracking you can't see.

Comparison table: Google Tag Getaway vs. Addingwell (sGTM)

Does that mean Google Tag Gateway is pointless?

No, GTG and sGTM aren't mutually exclusive. They can work together, with GTG serving as the "front door" handling first-party loading of Google scripts and Addingwell operating as the server-side engine behind it. That's a genuinely solid setup.

But it's not the only way. If you're already running sGTM properly, Addingwell already does the first-party Google script loading natively and adding GTG on top is more architectural overhead than uplift. So depending on where you're starting from, there are three practical paths:

Option A: the simpler path. GTG handles first-party script loading via the measurement path. Events continue to be sent to your Addingwell endpoint exactly as in a standard sGTM setup; nothing changes on the Addingwell side.

Option B: more technically involved. All tracking flows through a single path (e.g. example.com/8kpl/). CDN routing rules then split the traffic: script requests go to Google, event collection goes to Addingwell. More consistent with GTG's measurement path, but requires more careful CDN configuration to avoid breaking the tracking.

Option C: Addingwell standalone (no GTG). If you're already running sGTM properly, or you're moving directly from a client-side setup with meaningful ad spend across multiple platforms, there's a strong case for skipping GTG altogether. Addingwell already handles first-party Google script loading, Safari resilience, advanced ad blocker bypass, multi-platform coverage, and data governance in one place. Adding GTG on top is a marginal gain at best. For most businesses past the threshold where sGTM makes sense, this is the cleanest path.

Who is it actually for?

Not every site needs sGTM. If you're a small local business doing a few hundred visits a month and light advertising spend, GTG on its own is probably enough. The absolute volume of lost attribution isn't going to change your decisions. The case for sGTM strengthens as your numbers grow: meaningful ad spend across Google and at least one other platform, enough Safari traffic that 7-day attribution loss is actually affecting reported ROAS, and complex enough customer journeys that a few percentage points of data accuracy translate to real money.

A good rule of thumb: if you're spending more than a few thousand a month on paid media, running anything beyond Google Ads, and making optimisation decisions based on attribution data, you are past the point where GTG alone is sufficient.

The bottom line

GTG only: A good first step for first-party delivery of Google scripts. Quick to enable, low friction, but partial ad blocker bypass, no Safari resilience (cookies remain capped at 7 days), and limited to the Google ecosystem.

Addingwell standalone (no GTG): For most businesses with meaningful ad spend across multiple platforms, this is the right path, whether you're already on sGTM or coming directly from client-side. You get everything GTG offers plus full ad blocker bypass, Safari resilience, multi-platform coverage, and data governance, with no need for a separate GTG layer.

GTG + Addingwell together: A compatible combination. GTG serves as the first-party front door; Addingwell provides the Safari resilience and advanced ad blocker bypass that GTG alone doesn't cover. Option A or Option B depending on your CDN setup and how closely you want to align with GTG's measurement path approach.

If you're trying to make your measurement stack reliable, server-side tagging is where the real gains are. GTG can coexist with that, but it's not a substitute for it. This is more than a workaround: Google's own documentation recommends combining GTG with server-side GTM as the most robust tagging setup.

Addingwell is a server-side GTM hosting and management platform. If you're working through any of the above for your own setup, feel free to get in touch.

The author

James Ensor
Head of Sales UK at Addingwell by Didomi
Head of Sales UK at Addingwell by Didomi
Resources

Google Tag Gateway (GTG), Google Tag Manager Server-side (sGTM) with Addingwell, or both?

Thank You for Your Interest !
Your request has been successfully submitted. You can now download and explore the document.
Download
Download
Oops! Something went wrong while submitting the form.

Intuitive, Complete
and Powerful.

Addingwell’s interface is designed to save you time and streamline your server management and tag debugging processes.

No credit card required
addingwell interface