Google Tag Gateway — What It Is and How to Set It Up

Google Tag Gateway is one of those features that most analytics teams have heard of but relatively few have actually implemented. It sits in a confusing middle ground between standard client-side tagging and full server-side GTM — and that confusion has stopped many teams from getting the data completeness benefits it genuinely provides.

This guide explains exactly what it is, how it works, when it is worth setting up, and how to configure it correctly.

What is Google Tag Gateway?

Google Tag Gateway is a proxy configuration that routes your Google tag requests through your own domain instead of directly to Google's servers. When a visitor's browser sends analytics data or conversion events, those requests go to a subdomain you control — say gtag.yourdomain.com — which then forwards them to Google.

From the browser's perspective, the request is going to your own domain. From Google's infrastructure perspective, the data arrives the same way it always did. The gateway is transparent to both sides — it just changes the routing path.

The problem it solves

Two things hurt your Google Analytics and Google Ads data completeness:

Ad blockers and browser privacy extensions block requests to known third-party analytics domains like www.google-analytics.com and www.googletagmanager.com. When a request is blocked, that visit or conversion is simply not recorded.

Safari's Intelligent Tracking Prevention (ITP) limits the lifetime of cookies set by third-party JavaScript to 7 days. The GA4 client ID cookie, which is what ties all events to a single user, expires after 7 days on Safari — even if the user visits daily. This causes returning users to appear as new users in your reports, inflating new user counts and breaking attribution.

How it works technically

When you configure Tag Gateway, GTM automatically updates your Google tag to send requests to your gateway subdomain instead of directly to Google. Your server — configured as the gateway — receives those requests and proxies them to Google's collection endpoints.

The key change is in how the GA4 client ID cookie is set. Without Gateway, the cookie is set by third-party JavaScript, which Safari's ITP classifies as a tracking cookie and limits to 7 days. With Gateway, the request originates from your own domain, so the cookie is treated as a first-party cookie and can persist for the full duration you configure — typically 2 years.

Tag Gateway vs server-side GTM — understanding the difference

Setting it up — step by step

DNS and server configuration example

Here is a minimal nginx configuration for the reverse proxy. Place this on the server your gateway subdomain points to:

server {
  listen 443 ssl;
  server_name metrics.yourdomain.com;

  # SSL config here (use certbot/Let's Encrypt)

  location /gtag/ {
    proxy_pass https://www.googletagmanager.com/gtag/;
    proxy_set_header Host www.googletagmanager.com;
    proxy_ssl_server_name on;
  }

  location /g/ {
    proxy_pass https://www.google-analytics.com/g/;
    proxy_set_header Host www.google-analytics.com;
    proxy_ssl_server_name on;
  }

  location /collect {
    proxy_pass https://www.google-analytics.com/collect;
    proxy_set_header Host www.google-analytics.com;
    proxy_ssl_server_name on;
  }
}

If you are using Cloudflare, you can configure this as a Worker instead — which avoids the need for a dedicated server entirely and handles the SSL automatically.

// Cloudflare Worker script for Tag Gateway
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)

  // Route GTM requests
  if (url.pathname.startsWith('/gtag/')) {
    url.hostname = 'www.googletagmanager.com'
  }
  // Route GA4 collect requests
  else if (url.pathname.startsWith('/g/')) {
    url.hostname = 'www.google-analytics.com'
  }

  return fetch(url.toString(), {
    method: request.method,
    headers: request.headers,
    body: request.body
  })
}

Verifying it works

After publishing, open Chrome DevTools → Network tab on your site. Filter by your gateway subdomain. You should see GA4 collect requests going to metrics.yourdomain.com/g/collect instead of www.google-analytics.com/g/collect.

To verify the cookie is being set correctly, check Application → Cookies in DevTools. The _ga cookie should show your domain in the Domain column — not .google-analytics.com. The expiry should reflect your full configured duration, not the 7-day ITP limit.

Limitations and when not to use it

Tag Gateway is not a complete solution to every data collection problem. Be clear about what it does and does not do:

• It does not bypass all ad blockers. Sophisticated blockers like uBlock Origin maintain dynamic lists of proxied tracking subdomains. If your gateway subdomain gets added to these lists, requests will be blocked again. Server-side GTM with data enrichment is more resilient.
• It does not give you server-side data enrichment. Tag Gateway is a pure proxy. If you need to add server-side data to events — user tier, CRM attributes, server-confirmed purchase values — you need full server-side GTM.
• It does not replace consent management. Data collected through the gateway still needs to respect user consent. The gateway changes the routing path, not the consent obligations.
• It requires ongoing maintenance. Your proxy server or Cloudflare Worker needs to be kept running and updated if Google changes their collection endpoint paths.

For most organizations running GA4 with Google Ads, Tag Gateway is absolutely worth the setup effort. The improvement in cookie persistence and the reduction in ITP-related attribution errors delivers meaningful data quality improvement — especially if a significant portion of your traffic comes from Apple devices.