The problem with browser-based tracking

For most of the last decade, web analytics worked the same way: a JavaScript snippet loaded in the browser, collected data about what a user did, and sent it directly to Google Analytics, Facebook, or whichever platform was tracking. Simple, effective, and increasingly broken.

The combination of ad blockers, browser-level Intelligent Tracking Prevention (ITP), consent requirements, and privacy-focused browsers has eroded the signal significantly. Conservative estimates put signal loss at 25–35% for typical B2C sites. For sites with a privacy-aware audience — developers, technical users, European traffic — it is higher.

Server-side tagging is the structural fix. Instead of the browser sending data directly to third-party platforms, it sends it to a server you control first. That server then forwards it to GA4, Meta, Google Ads, or wherever else it needs to go.

What changes when you go server-side

Three things improve meaningfully:

  • Ad blocker resistance. Most ad blockers target known third-party domains like www.google-analytics.com. When your tagging endpoint is a subdomain of your own domain (e.g. metrics.yoursite.com), blockers are much less likely to catch it.
  • Consent Mode accuracy. Consent Mode v2 — mandatory for European traffic since early 2026 — uses modelled conversions to fill gaps when consent is declined. Those models work better with cleaner, more complete server-side signals going in.
  • Data control. You decide what gets forwarded and what gets stripped. Personally identifiable information can be removed server-side before it ever reaches a third party.

How server-side GTM works

Google Tag Manager has two container types: the standard web container (client-side JavaScript) and the server container (runs on a server). The server container listens for incoming HTTP requests, processes them using tags and triggers just like the web container, and forwards data to downstream platforms.

The typical setup looks like this:

  1. Web container sends events to your server container endpoint instead of directly to GA4
  2. Server container receives the request, applies your tags and triggers
  3. Server container forwards to GA4 via the Measurement Protocol, Meta via CAPI, etc.

Getting started — the minimum viable setup

The server container needs somewhere to run. Google Cloud Run is the simplest option for most teams — GTM will provision it automatically if you use the built-in setup. AppEngine is the alternative if you want more control.

The basic steps:

  1. Create a server container in Google Tag Manager
  2. Deploy to Cloud Run using the provisioning wizard
  3. Point a subdomain (e.g. t.yourdomain.com) at the container URL via CNAME
  4. In your web GTM container, update your GA4 configuration tag to send to https://t.yourdomain.com instead of the default Google endpoint
  5. Verify in GTM Preview that events are arriving at the server container

What to be realistic about

Server-side tagging is not a silver bullet. It adds infrastructure cost (Cloud Run is inexpensive but not free), it increases setup complexity, and it requires maintenance. It is also not a workaround for consent — you still need to respect user choices, you just get cleaner data from consenting users.

For most sites with meaningful ad spend or conversion tracking requirements, the signal improvement justifies the overhead. For small sites with minimal tracking, it is probably not worth the complexity yet.

Where to go next

Once the basic setup is working, the next meaningful step is implementing the Google Analytics 4 client in the server container properly — handling session data, user IDs, and ensuring cross-device tracking works as expected. That is a longer topic covered separately.