Skip to main content

Overview of Google Server Side Tagging sGTM

Overview of Google Server Side Tag Management (sGTM)

Published · Tags: Google Tag Manager, sGTM, Server Side Tagging, GA4, Stape.io, Amplitude, Mixpanel, ITP, Google Tag Gateway, Data Privacy

I finally sat down and took a real look at Google Tag Manager server side tagging (sGTM). Before getting into how it works, it's worth being clear about what sGTM is not — because most of the confusion I ran into online started from a misunderstanding right here.

What sGTM Is NOT

  • It is not a way to get around consent laws. You must still comply with applicable data-collection regulations, and you must still respect the consent choices a visitor makes. Moving a tag to a server doesn't move it outside the law.
  • It is not a replacement for client side GTM. Odds are you'll implement sGTM from inside your existing client side GTM setup. Only a portion of your tagging will end up supported by sGTM, and a lot of marketing-technology vendors still only ship a client side template — some of them probably always will.
  • Consent still flows from the client. Google Consent Mode settings are passed from client side GTM to sGTM. That means a working client side Consent Management Platform (CMP) implementation is a prerequisite for sGTM, not an alternative to it.

So What Do You Actually Want sGTM For?

  • Offloading work from the browser. Client side GTM is asynchronous, but every tag it fires still consumes CPU and memory on the visitor's device. sGTM moves supported marketing and analytics tags off the browser and onto a server, where they run independently of the page.
  • Tighter control over outbound data. Once a tag is running server side, you can transform the payload before it ever leaves your infrastructure — trimming or altering exactly what gets sent to each marketing and analytics platform.
  • First party server side cookies. Server side tagging lets you create 1st party server side cookies for those tag that support server side implementation.

Getting sGTM Off the Ground

Start with the basics: tag your site using client side GTM and GA4 — not sGTM yet. Go through the full effort of a normal tag management implementation. Test it. Debug it. Confirm everything fires correctly before you add another moving part.

Once that's solid, create a second, separate GTM container — this one is your sGTM container.


Next you need somewhere for that container to actually run. Google Cloud is one option, but I went with Stape.io. After creating a Stape.io account, create a "New Container" there to host your sGTM container.


Apply the sGTM Container Configuration values shown in your sGTM Admin → Installation instructions to that new Stape.io container.


At this point you have a live container on Stape.io where the tags inside your sGTM container will actually run. Stape.io gives you a default URL out of the box, but you'll want to swap in your own domain so the traffic reads as first-party rather than third-party.


Add that URL to the sGTM Admin → Container settings.


Then add that same URL to server_container_url in the client side GTM shared configuration settings. Like most things in GTM, I keep this as a variable rather than hard-typing the https:// URL directly.


At this point, GTM and sGTM are connected — but sGTM still isn't doing anything for you yet. That's the next step.

Adding Amplitude and Mixpanel

Amplitude and Mixpanel are both supported inside sGTM. First, add the required connection to your GTM GA4 stream.



Then enable Amplitude Analytics from within sGTM using the Amplitude Analytics template.


And just for good measure, I set up Mixpanel too, using the Mixpanel template.


Key sGTM & ITP Considerations

Getting a container talking to Stape.io is only half the job. Apple's Intelligent Tracking Prevention (ITP) treats a poorly configured server as just another tracking workaround — and it will quietly cap the value you get out of sGTM if you don't plan around it. A few things worth building into your implementation from day one:

ConsiderationWhy It Matters
Shared IP Addressing (Subnet Matching) Safari checks whether your tagging server's IP address — specifically the first two octets — falls within the same range as your primary website domain. If it doesn't, Safari treats the server as an off-site tracker and caps any cookie it sets to a 7-day lifespan, regardless of the expiration you configured. The fix is to host the tagging server on the same sub-domain as your site, or map a custom domain with matching A/AAAA record structure, rather than relying on a vendor's default shared URL.
Enhanced Conversions & Server-to-Server API Posting Safari and iOS will strip click identifiers like gclid and fbclid from the URL in certain sessions, so sGTM can't depend on URL parameters alone at the moment of conversion. The more durable approach is to capture and hash user-provided data — email addresses, phone numbers — and forward that hashed data directly to ad platforms through their server-to-server conversions APIs, such as Meta's Conversions API or Google Ads Enhanced Conversions.
Leverage a First-Party Data Strategy Persistent first-party identifiers — a custom user ID, a logged-in state flag, and similar signals — are worth passing into your server container. sGTM can store those identifiers safely and pass them along for more reliable, longer-lived attribution than anything dependent on a third-party cookie or a URL parameter that might get stripped mid-session.

A Newer Piece of the Puzzle: Google Tag Gateway

Since I originally wrote about sGTM, Google has rolled out a related feature worth knowing about: Google Tag Gateway (GTG). It's easy to confuse with sGTM, but the two solve different layers of the same problem.

Google Tag Gateway routes Google tag traffic — GA4, Google Ads, and standard GTM containers — through your own domain instead of googletagmanager.com, using a CDN (Cloudflare, Akamai, Fastly, or Google Cloud CDN) as a reverse proxy at the edge. In effect, it moves the client side GTM script itself onto your server's domain, so the request looks first-party rather than third-party. That helps it survive hostname-based ad blockers and tracking-prevention rules that specifically target third-party domains.

In practice, the two are complementary rather than competing:

  • Google Tag Gateway is a lightweight, low-effort upgrade for sites that are still purely client side and want better survivability for Google-specific tags, with minimal setup and no server to manage.
  • sGTM is a solution if you need move processing out of the client web browser for vendors / tags supporting server side, or longer-lived first party cookies for vendors / tags supporting server side tagging.

Google has also started supporting a combined pattern — CDN-based Tag Gateway serving Google scripts from your domain, paired with a full sGTM server handling collection, enrichment, and control — for anyone who wants both benefits at once.

What Got Me Here

Pivotal to getting all of this up and running were the following resources:

This post is a Google Blogger adaptation of my original "Overview of Google Server Side Tag Management (sGTM)", first published on my Weebly blog (DREW SPENCER) on February 7, 2024, updated with additional ITP considerations and a note on Google Tag Gateway.

Comments

Post a Comment

Popular posts from this blog

Site Landing & Site Referrer Preservation

Site Landing Page & Site Referrer to Cookies in Google Tag Manager — A Complete Recipe Without Custom JavaScript Persist the user's landing page host, landing page path, and referral source into session or long-lived persistent cookies using only GTM sandboxed Custom Templates. No Custom HTML tags. No new CSP hashes. Published · Tags: GTM, Google Analytics 4, Cookies, Site Referrer, Landing Page, First-Touch Attribution, User Journey, dataLayer, CSP, GA4 Where did this user first land on your site — and what referred them there? Those two pieces of information are foundational to understanding any user journey. But they only exist at the moment of the first page load. Navigate to a second page, return in a new browser session, or submit a form three days after the original visit, and the browser's native referrer is gone and the landing URL has long since changed. Without a persistence layer, you are flying blind. This recipe solves that problem cleanly...
Read more

GTM Browser Viewport Measurement

Browser Viewport Measurement in Google Tag Manager — A Complete Recipe Without Custom JavaScript Send the user's current browser viewport dimensions as an event-level parameter on every GA4 hit — using only GTM's built-in JavaScript Variable type and a Constant. No Custom HTML tags. No new CSP hashes. Published · Tags: GTM, Google Analytics 4, Browser Viewport, Window Size, JavaScript Variable, CSP, GA4, Shared Event Settings How big is the browser window when a user converts? Does your checkout funnel drop off more on narrow viewports than wide ones? These questions sound like they should be answerable from GA4's built-in device category dimension — but device category is derived from the User-Agent string and tells you nothing about how much screen space the browser is actually using. A desktop user with a browser snapped to half-screen is classified as "desktop" even though their experience is closer to a narrow tablet. This recipe measures ...
Read more

UTM & URL Query String 2 Cookies

UTM & URL Query String to Cookies in Google Tag Manager — A Complete Recipe Without Custom JavaScript Persist any URL query string parameter — UTM values, click IDs, or custom campaign codes — into session or long-lived persistent cookies using only GTM sandboxed Custom Templates. No Custom HTML tags. No new CSP hashes. Published · Tags: GTM, Google Analytics 4, UTM, Cookies, Query String, dataLayer, CSP, GA4, First-Touch Attribution, Lead Attribution UTM parameters tell you exactly how a visitor arrived at your site. But they only exist in the URL on the landing page. The moment a user navigates to a second page, clicks an internal link, or returns to the site in the same browser session, those parameters vanish from the address bar. If your marketing team needs to know which campaign drove a lead form submission that happened three days after the original visit — a common scenario in B2B with longer consideration cycles — you cannot read the UTMs from the URL. ...
Read more