To set up server-side tracking, you move your tags out of the visitor’s browser and onto a server you control. The browser sends one stream of events to that server, and the server forwards it to GA4 and your ad platforms.
This guide shows how to set up server side tracking for GA4 in Google Tag Manager, in six steps with code. It starts with whether you need it at all. If you would rather have it built, our server side tracking service does the whole setup.
Before you set up server-side tracking, check you need it
Server-side tracking helps only when browser tags lose data you are allowed to collect. It cannot recover visitors who declined cookies, and it cannot fix tags that already send the wrong events.
| Signal in your data | What it usually points to | Will server-side tracking help? |
|---|---|---|
| Platforms record fewer sales than your store, and few visitors decline consent | Browser blocking and lost cookies | It can, once the tags are clean |
| Most of the gap is visitors who declined cookies | Consent choices | No: a compliant server respects the same choice |
| Duplicate or inflated purchases | Tag setup errors | No: fix the tags first |
| No GA4 or Conversion tracking yet | Missing basics | Not yet: set up browser tracking first |
| Several ad platforms and Smart Bidding at scale | Signal quality matters to bidding | It can, alongside deduplication |
Our service page is direct about this. It says server-side is probably not yet worth it in three cases. You spend under $1,000 a month and track the basics. You rely on organic or referral traffic. Or you have no GA4 or Conversion tracking at all.
Two audits, two different answers
Two of our client audits reached opposite conclusions about moving to a server. The difference was what was causing the gap.
Orbital Clothing asked whether moving its Meta tracking to GTM and Stape would improve Purchase reporting. Our audit found the store already sent server events through the Conversions API, with an Event Match Quality of 8.8. About 27% of orders never reached the server because shoppers had declined consent. A compliant server setup must respect that choice too, so we recommended against the migration.
Toolab’s audit put a server-side implementation down as the longer-term opportunity. Two critical fixes came first: a Consent Mode setting that did not persist between pages, and malformed Microsoft Ads revenue. The order matters: a server forwards whatever the browser sends it, errors included.
Server-side tracking requirements
Server-side tracking requirements are a Tag Manager account, a server for the container, and a subdomain.
- Working browser tracking through the Google tag or a GTM web container. The server forwards what the browser sends.
- A server container in Google Tag Manager.
- Hosting for the tagging server: Google Cloud Run, your own servers, or a managed platform.
- DNS access to point a subdomain, such as sgtm.example.com, at the server.
- A consent setup that already works in the browser.
Hosting has a monthly cost and the setup a one-time one. We price both in server-side tracking cost, and compare hosts in best server-side tracking tool.
Step 1: create a server container in Tag Manager
A server container is its own container type in Google Tag Manager. In your Tag Manager account, choose Create Container, select Server under Target platform, and click Create (Google for Developers).
A dialog to set up the tagging server then opens. You can return to it later from Admin, Container Settings.
The new container uses the same tags, triggers and variables as a web container. It runs on a server rather than in the browser (Google for Developers).
Step 2: provision the tagging server
The tagging server is what runs your server container, and Google can provision it automatically. Google recommends automatic provisioning. It creates a Google Cloud project and a Cloud Run tagging server for you (same source as Step 1).
| Automatic on Cloud Run | Manual, your own servers | Managed platform | |
|---|---|---|---|
| Who runs the servers | Google Cloud, in a project in your account | You | The platform |
| How it is set up | Tag Manager provisions it for you | Google’s Docker image, as a preview server and a tagging cluster | The platform’s setup flow |
| Cost basis | About $45 per server a month; Google recommends at least 2 | Your own infrastructure | Monthly plans by request volume |
| Best fit | Teams that want Google’s default | Strict hosting or data residency rules | Most single sites and stores |
Google’s Cloud Run guide says each server costs approximately $45 a month. It recommends a minimum of 2 instances to reduce the risk of data loss (Google for Developers). The same guide sets up two services: a preview server for Preview mode, and the tagging server that handles live traffic.
Manual provisioning runs Google’s Docker image on your own infrastructure. It has two parts: a preview server and a tagging cluster (Google for Developers).
Step 3: map a subdomain to the tagging server
A subdomain of your own site makes the tagging server first party. The new server starts on a default run.app address. On that address it delivers data but runs in a third-party context (Google for Developers).
Google gives two ways to serve it from your own domain:
- A subdomain, such as sgtm.example.com, pointed at the tagging server in your DNS.
- A path on your main domain, such as example.com/metrics, forwarded by a CDN or load balancer.
Google’s overview gives the reason. On a subdomain of your website, the server can use cookies that page scripts cannot see. The subdomain is the simpler of the two for most sites. Add the new URL to the container’s settings once DNS has updated.
Step 4: point the Google tag at your server container
The Google tag sends data to your server once the server_container_url setting points at it. With gtag.js, Google’s own example adds one option to the config call (Google for Developers):
<!-- Google tag (gtag.js) sending to a server container -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXX', {
server_container_url: 'https://sgtm.example.com'
});
</script>Replace G-XXXXXXX with your tag ID and the URL with your subdomain. In a GTM web container, add server_container_url as a configuration parameter on the Google tag. Google notes that configuration parameters can only be set on the Google tag or the Google Analytics destination tag (Google for Developers).
If your site sends a Content Security Policy, allow the server URL. Google lists three directives, because the tag can send by image, by fetch or through an iframe:
img-src https://sgtm.example.com
connect-src https://sgtm.example.com
frame-src https://sgtm.example.comStep 5: add tags in the server container
Server containers come with a Google Analytics client pre-installed, so GA4 requests are claimed on arrival. A client is the adapter that receives a request and turns it into events for your tags (Google for Developers).
Add a Google Analytics tag next. Google says the tag pulls its configuration from the events coming out of the client (same source). Then add a tag for each platform you forward to, such as Google Ads conversions or the Meta Conversions API.
Every event sent from both the browser and the server needs one shared event ID, or Meta counts the sale twice. We cover the rules and the code in Meta Pixel and Conversions API deduplication.
Step 6: test in Preview and publish
Tag Manager’s server Preview mode shows each incoming request and what the container did with it. In your server container, click Preview, then open your website in another browser window (Google for Developers).
- Request tab: check that the expected client claimed each request.
- Tags tab: check which tags fired and which did not.
- Event Data and Variables: check the values each tag received.
- Console: read any tag errors.
When every event behaves, publish the server container, then the web container change. Google strongly recommends first-party serving and production mode before any live traffic reaches the server (Google for Developers).
Mistakes to avoid when you implement server-side tracking
When you implement server-side tracking, most failures come from running old and new tags at once. These are the ones we find most.
| Mistake | What happens | Fix |
|---|---|---|
| Browser and server tags both send the same event | Every sale counts twice | Share one event ID, or remove the browser tag |
| The default run.app address stays in use | Data runs in a third-party context | Map a subdomain before going live |
| Consent is not passed to the server | Declined visitors are still sent on | Test the server with consent declined |
| The old web tags are never removed | Duplicates, or two sources disagreeing | List and retire each replaced tag |
| No one compares counts after launch | Errors run for weeks unseen | Compare a week of events and orders |
The Orbital audit named the first risk directly: rebuilding Meta tracking alongside a live integration risked double counting and lower match quality.
How to check it is working after launch
A working setup sends the same events as before, through your subdomain, without double counting. Check three things in the first week.
- Network tab: event requests go to your subdomain, not straight to Google or Meta.
- Event counts: GA4 events per day stay close to the week before the switch.
- Orders: purchases or leads in each platform stay close to your store or CRM records.
A sudden rise usually means duplicates; a fall usually means a tag that did not move. Our conversion tracking audit checklist covers the full comparison.
Frequently Asked Questions
Can I use Google Tag Manager for server-side tagging?
Yes. Server-side tagging is a Google Tag Manager feature. You create a server container, which works like a web container but runs on a server you control. Your web container or the Google tag then sends its events to that server instead of straight to each platform.
Can you give me an example of server-side tracking?
A store’s purchase is a common example. The Google tag in the browser sends the purchase to the store’s own subdomain, such as sgtm.example.com, instead of straight to Google. The GA4 client in the server container claims it. Server tags then forward the purchase to GA4, Google Ads and the Meta Conversions API.
Sources (8)
All checked on 15 October 2026.
- Google for Developers, Set up server-side tagging with Tag Manager
- Google for Developers, An introduction to server-side tagging
- Google for Developers, Set up server-side tagging with Cloud Run
- Google for Developers, Manual setup guide
- Google for Developers, Custom domain configuration
- Google for Developers, Send data to server-side Tag Manager
- Google for Developers, Preview and debug server containers
- BlazeByte client audit reports, named with permission: Orbital Clothing (1 July 2026) and Toolab (May 2026).
