GTM Server-Side Container: What It Is, When to Use It, and How to Set It Up.

Standard Google Tag Manager loads JavaScript in the browser. Every tag fires from the user's device, and every vendor you work with — Google Ads, Meta, LinkedIn, Hotjar — gets a direct view of user behavior: IP address, full page URL, device fingerprint, and the referrer chain. The user's browser makes dozens of outbound requests to third-party domains before the page is fully loaded, and each of those requests carries raw behavioral data.

Server-side GTM changes the architecture. A tagging server sits between the browser and your vendors. The browser sends a single event to a URL you control — for example, sgtm.yourdomain.com — and your server forwards that event to however many tools you use, with only the data fields you decide to share. This guide covers what server-side GTM actually does under the hood, when the infrastructure cost makes sense, and how to go from zero to a working server container.

How Server-Side GTM Works

The Architecture

A server-side setup involves two containers working together: your existing client container (the web container) and a new server container hosted on infrastructure you control.

In a standard GTM setup, the client container sends events directly to third-party endpoints. A GA4 event goes to google-analytics.com. A Meta Pixel fires to facebook.com. The browser handles all of it.

With server-side GTM, you redirect this flow. The client container is reconfigured to send events to your tagging server instead of directly to Google or Meta. Your tagging server receives the incoming event, parses it using a "client" (typically a GA4 client that understands the GA4 hit format), and routes it through server-side tags. Each server-side tag forwards the event to a vendor — but only with the fields you configure. The user's browser never directly touches Facebook Pixel, Google Ads, or any other third-party vendor domain.

What the Client Container Sends

The client container sends GA4 hits to your tagging server using the GA4 hit format. You configure this by overriding the transport_url parameter in your GA4 Configuration Tag — pointing it to your server endpoint instead of the default Google endpoint.

Your tagging server receives these hits and a "client" component parses them. The GA4 client is the standard starting point: it reads the incoming GA4 hit format and surfaces the event data as a unified event model that your server-side tags can consume. From there, each server-side tag reads the fields it needs and forwards them to its respective vendor API.

Hosting Options

Google provides a one-click deployment path to Google Cloud Run from inside the GTM interface. Cloud Run is a managed container service — you don't manage servers directly, and the infrastructure scales with your traffic. This is the easiest starting point for most setups.

The tagging server can also run on AWS, Azure, or any infrastructure that supports containerized Node.js workloads. The GTM server image is publicly available. If your organization already has infrastructure conventions, you're not locked into Cloud Run.

For most sites, Cloud Run costs roughly $10–50 per month. The cost depends primarily on request volume. At high traffic scale, the compute cost is worth profiling — but for the majority of setups it's a small fixed overhead relative to the ad spend the tags support.

Benefits of Server-Side GTM

Privacy and Data Control

The core benefit is that you become the chokepoint between user behavior and every vendor. That chokepoint lets you enforce data minimization that isn't possible with client-side tags.

You can strip IP addresses before forwarding to advertising platforms — sending conversion signals without exposing which IP address generated them. You can remove sensitive URL parameters (email addresses appended to landing page URLs, order IDs in confirmation page URLs) before they reach analytics. You can drop personally identifying fields from the event payload before it reaches any third party. Each server-side tag is independently configurable, so you can give Google Ads exactly the conversion signal it needs while giving your analytics platform a different, less sensitive version of the same event.

This is the architecture GDPR compliance frameworks increasingly expect: data processing happens under your control, with documented field-level decisions, rather than client-side tags sending unconstrained data to third parties.

Ad Blocker Bypass

Ad blockers and browser privacy features (Safari's ITP, Firefox Enhanced Tracking Protection) work by blocking requests to known third-party tracking domains. When your GA4 events go to google-analytics.com, an ad blocker can intercept that request. When they go to sgtm.yourdomain.com, there's no known third-party domain to block.

Conversion signals reach advertising platforms for users who would otherwise be invisible. For sites with a privacy-conscious audience — developer tools, security products, B2B SaaS — this is often the primary reason to implement server-side GTM. Ad blocker adoption in those segments routinely runs at 30–40% of visitors, which means a significant share of conversions are simply missing from the data without a server-side implementation.

Page Performance

Client-side tags load third-party JavaScript. Each vendor script adds network requests, parse time, and main-thread blocking during page load. Moving tags to the server side means the browser no longer loads those scripts. The browser makes one request to your first-party endpoint and the server handles the rest.

The performance gain is real but varies by how many client-side tags you're replacing and how large they are. Moving the Meta Pixel and a Google Ads remarketing tag to server-side is more impactful than moving a single GA4 tag. If your tag count is low, the performance difference may not be the deciding factor.

Data Freshness for Advertising

Server-to-server conversion data is the foundation of GA4 enhanced conversions and Meta's Conversions API. These integrations send hashed first-party data directly from your server to the advertising platform — independently of what the browser does. They're more durable than pixel-based tracking because they don't depend on the browser completing a request to a third-party domain.

Browser restrictions are a direction, not a ceiling. As privacy controls tighten further, server-side conversion paths become the reliable baseline while client-side pixels become supplementary. Building on server-side infrastructure now means the conversion data architecture doesn't need rebuilding as the browser environment continues to change.

When Server-Side GTM Is NOT the Right Choice

The infrastructure cost is real. You're adding a hosted service that needs monitoring, occasional maintenance, and a monthly compute bill. For sites with under roughly 50,000 monthly sessions, the engineering time to set up and maintain a server container rarely pays off against the benefits. The conversion tracking improvements matter most when advertising spend is high enough that attribution accuracy translates directly to budget decisions.

The debugging experience is genuinely harder than client-side. With client-side GTM, GTM's preview mode lets you inspect every tag, trigger, and variable in the browser. With server-side GTM, you're working with server logs and the server container's preview mode, which requires a different mental model. Teams without someone comfortable reading server logs and working with HTTP requests will find troubleshooting slow.

Start with server-side GTM only if you have at least one of: active advertising spend where attribution accuracy directly affects budget allocation; specific GDPR or CCPA requirements about which data fields reach third-party vendors; or measurable page performance issues caused by third-party scripts that simpler interventions haven't resolved. If none of those apply today, a well-maintained client-side container is the right infrastructure.

Setting Up a Server-Side Container

Step 1 — Create the Server Container in GTM

In your GTM account, go to Admin → Create Container and select Container type: Server. Give the container a name that makes its purpose clear — the GTM account name will appear on the server-side container select screen, so naming it something like "YourSite — Server" avoids confusion with your web container.

Once created, GTM generates a tagging server URL. This is the internal endpoint that your server container's preview mode uses. You'll replace it with your custom domain in a later step.

Step 2 — Deploy to Cloud Run

Inside the server container, GTM offers a "Manually provision tagging server" option that generates the configuration needed for Cloud Run. You need a Google Cloud project with billing enabled. The tagging server runs as a managed Cloud Run service — Google handles the container runtime and scaling.

The deployment flow gives you a Cloud Run service URL in the format https://[service-name]-[hash]-[region].a.run.app. This URL is the raw endpoint you'll put behind your custom domain. Test it directly first to confirm the server is running before touching DNS.

Step 3 — Set Up Your Custom Domain

Create a subdomain on your site — sgtm.yourdomain.com is the conventional choice, though the specific subdomain doesn't matter. Point it to your Cloud Run service by adding a CNAME or mapped domain in your DNS settings and configuring the Cloud Run service to accept the custom domain.

This step is not optional. Using the raw Cloud Run URL defeats the first-party purpose — ad blockers can still identify requests to a.run.app as tracking infrastructure. The custom domain on your own site is what makes these requests genuinely first-party from the browser's perspective.

Step 4 — Update the Client Container

In your web container, find your GA4 Configuration Tag. Add a tag configuration field: set transport_url to your custom tagging server domain — for example, https://sgtm.yourdomain.com.

With this change, GA4 events from the browser will route through your tagging server instead of going directly to Google. You can verify this is working by opening your browser's network panel and confirming that GA4 collect requests go to your domain rather than to google-analytics.com. Publish the client container after verifying in preview mode.

Step 5 — Add Server-Side Tags

With the routing working, add server-side tags in the server container. Each vendor typically has a template in the GTM Community Template Gallery. The most common starting set:

GA4 server tag — forwards the event to Google Analytics. Add your Measurement ID. This replaces the direct browser-to-Google path and is required to keep GA4 data flowing after the client container's transport_url override takes effect.

Meta Conversions API tag — sends conversion events to Meta using the CAPI endpoint. Requires a Meta Pixel ID and a Conversions API access token. Configure it to send only the events and fields you want Meta to receive.

Google Ads enhanced conversions tag — sends conversion events with hashed first-party data. Requires your Google Ads conversion ID and conversion label. Enhanced conversions use hashed email or phone data to match conversions to signed-in Google users, improving attribution accuracy without sending raw PII.

For each tag, use triggers scoped to the events that matter for that vendor. Don't send every event to every vendor — server-side tags make field-level and event-level control explicit, so use it.

FAQ

What is GTM server-side container?

A GTM server-side container is a tagging server you host (typically on Google Cloud Run) that sits between your website and your analytics or advertising vendors. Instead of the browser sending data directly to Google, Meta, or other platforms, your website sends events to your server, and the server forwards them to each vendor — with only the data fields you choose to share.

Is server-side GTM free?

The GTM software itself is free. The cost comes from the server infrastructure required to run the tagging server. Using Google Cloud Run — the standard deployment path — typically costs between $10 and $50 per month for most sites, depending on traffic volume. High-traffic sites will pay more; the cost scales with request volume.

Does server-side GTM bypass ad blockers?

Yes, when set up with a custom subdomain on your own domain. Ad blockers work by blocking requests to known third-party tracking domains. When your GA4 and pixel events go to sgtm.yourdomain.com instead of google-analytics.com, there's no known tracking domain for the blocker to target. The custom domain on your own site is required — using the raw Cloud Run URL does not achieve the same result.

How is server-side GTM different from client-side GTM?

Client-side GTM runs in the user's browser and fires tags that send data directly to vendors. Server-side GTM runs on a server you control — the browser sends events to your server, and the server forwards them. Server-side gives you control over what data each vendor receives, avoids third-party JavaScript loading in the browser, and makes events unreachable to ad blockers. The tradeoff is infrastructure cost and added complexity in debugging.

Can I use server-side GTM without hosting?

No. Server-side GTM requires a running server to receive and forward events. Google Cloud Run is the lowest-friction hosting option — GTM's UI includes a one-click deploy path. There is no hosted version of server-side GTM provided by Google for free.

What does server-side GTM cost per month?

For most sites on Google Cloud Run, expect $10–50 per month. The primary cost driver is request volume (number of tag server hits). A site handling several hundred thousand monthly sessions should stay well within that range on the default Cloud Run configuration. At very high scale — millions of monthly sessions — costs can be meaningfully higher, and it's worth reviewing the Cloud Run pricing calculator before committing.

Does server-side GTM help with GDPR compliance?

It helps significantly with data minimization, which is one of GDPR's core principles. With server-side GTM, you control exactly which fields reach each vendor — you can strip IP addresses, remove identifying URL parameters, and limit the personal data that flows to third-party processors. This makes it easier to document and enforce the data processing boundaries required under GDPR. That said, server-side GTM is infrastructure, not a compliance solution on its own. You still need a consent management platform, a lawful basis for the processing, and updated data processing agreements with each vendor.

Do I need a developer to set up server-side GTM?

For the initial setup, yes — at minimum for the Cloud Run deployment and DNS configuration. These steps involve Google Cloud, command-line tooling, and DNS records. Someone comfortable with those tasks can complete the infrastructure setup in a few hours. Ongoing tag management in the server container (adding and modifying server-side tags) is more accessible and follows the same GTM interface patterns most practitioners already know.