If you have used Google Tag Manager (GTM) before, you know how it works: you add a snippet of code to your website, and GTM fires your tracking tags from the visitor's browser. That browser-based version of GTM is called the web container. It works fine — until ad blockers, Safari privacy restrictions, or third-party cookie deprecation start eating your data.
In 2020, Google introduced a second type of GTM container: the server-side container. It solves those exact problems by moving your tracking off the browser entirely. This guide explains what it is, how it works, and what you actually need to set one up.
What Is a GTM Web Container (The One You Already Know)?
Before explaining the server-side container, it helps to clearly understand what the web container is doing.
When you add a GTM web container to your website, a JavaScript snippet loads in every visitor's browser. That snippet listens for events — page views, button clicks, form submissions, purchases — and fires your tracking tags in response. Those tags (the Meta Pixel, the Google Ads conversion tag, the GA4 snippet) then send data directly from the visitor's browser to Meta, Google, and any other platforms you use.
The browser is the workhorse. It loads the tracking scripts, collects the data, and delivers it to each ad platform. The problem is that the browser is also the most exposed link in the chain. Ad blockers run in the browser and can see every outbound request to third-party tracking domains. Safari's Intelligent Tracking Prevention (ITP) runs in the browser and shortens cookie life to 7 days. The browser is where your tracking data gets lost.
What Is a GTM Server-Side Container?
A GTM server-side container (also called sGTM) is a second GTM container that runs on a cloud server you control, rather than in your visitor's browser.
Here is the key architectural shift. With a web container, your visitor's browser sends data directly to each ad platform — one request to Meta, one to Google, one to GA4. With a server-side container, your visitor's browser sends a single request to your server. Your server then processes that data and forwards it to Meta, Google, and GA4 via their server-to-server APIs.
Think of it this way: instead of your browser being the delivery driver who has to make five separate trips, your server is a central sorting hub. The browser drops off one package. The server routes it to every destination.
This single architectural change has significant consequences for your tracking quality.
How Does the Data Flow Work?
Here is the step-by-step path data takes in a server-side GTM setup:
- A visitor interacts with your website. They load a page, add a product to cart, or complete a purchase.
- Your web GTM container fires. It is still present in the browser — but instead of sending data directly to Meta and Google, it sends a single event payload to your sGTM server URL (typically a custom subdomain like
data.yoursite.com). - The sGTM server receives the request. Inside the server container, a "client" component receives the incoming data and parses it into a format that tags can use.
- Tags inside the server container fire. These are the server-side equivalents of your browser tags: a Meta CAPI tag, a Google Ads Enhanced Conversions tag, a GA4 server-side tag. They take the event data, format it according to each platform's API specification, and send it out.
- Data arrives at ad platforms via server-to-server API calls. Meta receives it via the Conversions API. Google Ads receives it via Enhanced Conversions. GA4 receives it via the Measurement Protocol. None of these outbound calls go anywhere near the visitor's browser.
Because the visitor's browser never makes those outbound requests to Meta or Google, ad blockers never see them. Because cookies are set from your own subdomain rather than from googletagmanager.com, they count as first-party cookies and last up to 400 days in Safari instead of 7.
The Architecture Inside a Server Container
The sGTM container has the same building blocks as a web container — tags, triggers, and variables — but with one additional component: clients.
Clients handle incoming requests. When your web container sends data to the sGTM server, a client receives it, parses the request format (GA4 format, custom format, etc.), and creates an event model that tags can read. The GA4 client is the most common — it accepts the GA4 event format that your web container sends.
Tags handle outgoing requests. Once the client has processed the incoming data, tags take over. The Meta CAPI tag reads the event data and sends a formatted API call to Meta. The GA4 server tag forwards the event to Google Analytics. You configure these the same way you configure tags in a web container — with tag type, event name, parameters, and triggers.
Variables work exactly as they do in a web container. They store reusable values — event name, page URL, user email hash, order value — that tags reference.
Triggers control when tags fire, also unchanged from web GTM.
If you already know how to work in web GTM, the learning curve for sGTM is mostly about learning the new concepts of clients and server-to-server API formats, not relearning how tagging works.
Why Does the Custom Domain Matter?
One of the most important steps in setting up sGTM is pointing a custom subdomain of your website at the server. This is not optional for serious implementations.
When your sGTM server URL is something like data.yoursite.com rather than a Google Cloud URL, two things happen:
First, ad blockers are less likely to block it. Ad blockers maintain lists of known tracking domains. googletagmanager.com and similar third-party domains are on those lists. Your own subdomain is not. Requests going to data.yoursite.com look like first-party requests to your own site.
Second, cookies set from your subdomain are first-party cookies. Safari's ITP treats cookies very differently based on whether they are first-party or third-party. Cookies set from your own domain can last up to 400 days. Cookies set by third-party scripts get shortened to 7 days. This is the difference between capturing a conversion from a customer who bought two weeks after clicking your ad and completely missing it.
Benefits of the Server-Side GTM Container
You recover missing conversions. Events that were previously blocked by ad blockers or lost due to ITP now reach your ad platforms. Most businesses see 15–30% more reported conversions after switching.
Your ad algorithms get better data. Meta and Google Ads use your conversion signals to train their bidding models. More complete data leads to better targeting and lower cost per acquisition.
Your pages load faster. Each tracking script in the browser adds load time. Moving those scripts to the server reduces the JavaScript weight in the browser, which improves your Core Web Vitals scores and organic rankings.
You control what each platform receives. Client-side pixels collect whatever they can grab. With sGTM, you decide exactly which fields go to Meta, which go to Google, and which are stripped before leaving your server. No accidental PII leakage to third parties.
Privacy compliance becomes easier. When a user opts out via your consent banner, you update one rule on the server. Data stops flowing to all platforms at once, rather than hunting down every pixel in your web container.
What Are the Drawbacks?
It costs money. Running the server-side container requires hosting — either on Google Cloud Platform (GCP) or a managed provider. Self-hosting on GCP typically costs $50–$150 per month for medium-traffic sites.
It requires GTM knowledge. Setting up sGTM is not plug-and-play. You need to understand how to configure tags, triggers, variables, and clients inside the server container. If you have never used GTM before, there is a learning curve regardless of what hosting platform you use.
GCP setup is complex. Google's own documentation walks you through setting up a Cloud Run service on GCP — which involves managing a GCP project, configuring autoscaling, and monitoring infrastructure costs. This is not a task for marketers without technical support.
How to Get Started
The setup path has two parts: the GTM configuration and the server hosting.
On the GTM side: you create a new server container in your GTM account (under Admin, add a new container and select "Server" as the platform), copy the container config string, and set up a custom subdomain in your DNS records to point at your server URL. You then update your web container to send data to the server container URL instead of directly to ad platforms.
On the hosting side: your options are self-hosting on GCP or using a managed platform.
Self-hosting on GCP gives you full control but requires you to create a GCP account, deploy a Cloud Run instance, configure autoscaling, and manage ongoing infrastructure. Most marketers without a DevOps background find this step the hardest part.
Firstag removes the hosting complexity entirely. You paste in your container config string, choose your subdomain, and your sGTM server is running in under 15 minutes — no GCP account, no Cloud Run configuration, no infrastructure management. You still configure your GTM tags yourself, but the server is handled for you. Firstag offers flat INR pricing with no dollar conversion surprises, which makes it particularly practical for Indian businesses.
For pricing details and a comparison to self-hosting on GCP, see Firstag's pricing page.
FAQ
What is the difference between a GTM web container and a server-side container? A web container runs JavaScript in your visitor's browser and sends data directly from the browser to ad platforms. A server-side container runs on a cloud server you control. Your browser sends one request to your server, and your server forwards the data to each ad platform via their APIs. This removes the browser from the outbound tracking calls, making it immune to ad blockers.
Do I need to remove my web GTM container when I set up a server-side container? No. Both run together. The web container is still responsible for capturing events in the browser and sending them to the server container. You do not replace the web container — you add the server container as an additional processing layer.
Can I use sGTM without Google Cloud Platform? Yes. GCP is Google's default hosting option for sGTM, but you are not required to use it. Managed hosting platforms like Firstag run the server container on your behalf, so you never need to touch GCP.
What tracking platforms can I run through sGTM? Any platform that has a server-to-server API. This includes Meta (via Conversions API), Google Ads (Enhanced Conversions), GA4 (Measurement Protocol), TikTok (Events API), LinkedIn (Conversions API), Snapchat (Conversions API), and more.
How long does it take to set up a server-side GTM container? The GTM configuration itself — creating the server container, setting up clients and tags — takes a few hours if you are familiar with GTM. The server infrastructure, if you use a managed platform like Firstag, takes under 15 minutes. DNS propagation for your custom subdomain can take 2–24 hours.
Is sGTM the same as the Meta Conversions API? They are related but different. sGTM is the container that runs on your server. The Meta Conversions API (CAPI) is the Meta platform's server-to-server API for receiving event data. sGTM is the tool you use to send data to Meta CAPI, along with all your other platforms.
Conclusion
The server-side GTM container is not a replacement for web GTM — it is an additional layer that moves your outbound tracking calls off the browser and onto a server you control. The result is more complete conversion data, longer cookie lifespans, faster pages, and better control over what each ad platform receives.
If you want to set one up without managing cloud infrastructure, Firstag gets you running in under 15 minutes with a custom domain and INR pricing included.
Start your Firstag container free for 14 days at firstag.io.