Server-side tracking means your website sends its events to a server you control, and that server forwards them to Google Analytics, Google Ads, Meta and other vendors. The browser talks to one endpoint on your own domain instead of to a dozen third parties. This guide explains why that matters, where the limits are, what hosting looks like in 2026, and how to set it up with server-side Google Tag Manager.
How the Data Flows
Browser-side, the default: the page loads scripts from Google, Meta, TikTok and others. Each script sets its own cookies and sends its own requests to its own domain. Blockers and browser privacy features see every one of them.
Server-side: the page loads GTM, which sends events to https://sgtm.yourdomain.com. A server container there receives them, decides what to send to each vendor, adds or removes data, sets first-party cookies, and forwards. The browser sees one first-party endpoint.
What It Actually Fixes
- Cookie lifetime. Cookies set by the server as HTTP cookies on your domain last the full duration you set, where Safari caps browser-set cookies at seven days or less. Attribution windows become real again.
- Partial blocker resilience. Requests to your subdomain are less likely to be blocked than requests to known tracking domains.
- Data control. You can strip, hash or enrich data before it reaches any vendor. IP addresses can be removed. Consent can be enforced in one place.
- Page speed. Fewer third-party scripts in the browser.
- Server events. Webhooks from your CRM, payment provider or store can enter the same container, so offline and backend conversions reach the ad platforms.
What It Does Not Fix
- If the browser blocks GTM itself, nothing is collected.
- Consent still applies in full.
- Vendors still apply their own matching; a server event without identifiers matches no better than a browser one.
- It adds infrastructure that someone must maintain.
Hosting Options in 2026
| Option | Setup | Monthly cost | Notes |
|---|---|---|---|
| Google Cloud Run | Technical | Varies, higher with the recommended two instances and logging | Google's own recommendation, full control |
| Stape | Managed, minutes | From about $20 | Most common choice for small and mid businesses, extra features such as cookie keeper |
| Addingwell and similar managed hosts | Managed | Comparable | Regional hosting options |
| Google Tag Gateway via Cloudflare | Very easy | CDN cost | Google-only first-party serving, no server container |
I usually recommend a managed host unless the business has engineers who want to own the infrastructure. A custom subdomain is essential whichever you choose.
Setup, Step by Step
Step 1: Create the server container
In Tag Manager, create a new container of type Server. Choose manual provisioning if you are using a managed host, and copy the container configuration string.
Step 2: Provision hosting and a subdomain
With a managed host, paste the configuration, choose a region close to your visitors, and add a custom domain such as sgtm.yourdomain.com by creating the DNS records they give you. With Cloud Run, deploy the tagging server image, set a minimum of two instances for production, and map the custom domain.
Confirm the server responds at https://sgtm.yourdomain.com/healthz.
Step 3: Point the browser at the server
In the web container, open the Google tag and add the configuration parameter server_container_url with your server URL. Every GA4 event now goes to your server instead of to Google directly. Also change the GTM script source to load from your server domain if your host supports it, which keeps the loader first-party.
Step 4: Clients
The server container needs a Client to receive and interpret requests. The GA4 client is built in and claims the requests from your Google tag. Add the Measurement Protocol client if you will send server events, and custom Clients for webhooks from Stripe, Shopify or your CRM.
Step 5: Tags
Add server tags:
- GA4 with your measurement ID, triggered on all GA4 client events. Set the GA4 server tag to set cookies and to redact or forward IP as your policy requires.
- Google Ads Conversion Tracking and Conversion Linker for conversions, with user-provided data from event data for Enhanced Conversions.
- Meta Conversions API template with event IDs for deduplication, user data from event data, and the fbp and fbc cookies.
- Additional vendors such as TikTok Events API, LinkedIn or Pinterest from their templates.
Step 6: Cookies and first-party settings
Enable server-managed cookies in the GA4 server tag and the Conversion Linker so _ga and _gcl_* cookies are set as HTTP cookies from your domain. Enable the same in the Meta template for _fbp and _fbc.
Step 7: Consent
Consent Mode signals are forwarded by the GA4 client in the event data. Add trigger conditions on vendor tags so that advertising tags fire only when ad_storage is granted and analytics tags only when analytics_storage is granted, or configure vendor tags to drop user data when consent is denied.
Step 8: Browser clean-up
Once server tags are verified, decide what stays in the browser. Typical result: the Google tag remains, sending to the server; Google Ads conversions move fully to the server; Meta Pixel stays for deduplicated browser events with the Conversions API server-side, or is removed if you send everything from the server.
Testing
- Open the web container in Preview and the server container in its own Preview. Load the site.
- In the server Preview, confirm incoming requests are claimed by the GA4 client, event data is populated, and each tag fires with the expected outgoing request.
- Check the response headers for Set-Cookie on your domain for
_ga,_gcl_awand_fbp. - GA4 DebugView should show the events, now arriving from your server.
- Meta Events Manager Test Events should show server events with the test code, deduplicated against the browser pixel.
- Google Ads Diagnostics the next day should show conversions recording.
- Run a test with an ad blocker enabled. Compare which events still arrive.
Common Problems
- Events arrive at the server but GA4 shows nothing. GA4 server tag not firing or wrong measurement ID.
- Cookies not set on your domain. Custom domain not configured, or the server tag's cookie option disabled.
- Double conversions. Browser and server tags both sending Google Ads conversions without deduplication, or Meta events without matching event IDs.
- High cloud bill. Request logging left on in Cloud Run.
- Consent ignored on the server. No trigger conditions on vendor tags.
Outcome
One first-party endpoint, longer-lived cookies, every vendor fed from one container with consistent data and consent, and a place for backend events to enter the system. For most businesses spending real money on ads, it is the single largest measurement upgrade available in 2026.