sGTM in 2026: Cloud Run vs Stape vs Self-Hosted, Real Costs and Consent Mode v2 Pitfalls

What Is sGTM and Why Has It Become Essential?

Server-Side Google Tag Manager (sGTM) moves tag management from the browser to the server side, giving site owners control over the data collection process. With Safari 26 AFP, ITP cookie restrictions, and the Consent Mode v2 requirement, client-side tracking alone is no longer sufficient. For details on these changes and a comparison of different tracking approaches, refer to the related post.

This guide covers how to set up sGTM, available infrastructure options, and tag configuration for platforms like GA4, Google Ads, and Meta CAPI.

User browser
  -> Client-side GTM (web container)
    -> sGTM (server container)
      -> GA4, Google Ads, Meta CAPI, TikTok, Klaviyo...

Request Flow and Architecture

Before picking where to run sGTM, understand how a single request moves through it. The model is straightforward on paper and subtle in practice: clients evaluate in priority order, the first one to claim a request transforms it into one or more events, and those events flow through triggers and tags just like in a web container².

Browser / App / Backend
    |  (measurement request: GA4 /collect, MP, custom webhook)
    v
Tagging Server (Cloud Run, Stape, Docker)
    |  1. Clients ranked by priority, first match claims the request
    |  2. Claiming client transforms the request into events
    |  3. Triggers match events, fire tags
    |  4. Tags forward payload to vendors (GA4, Ads, Meta CAPI, BigQuery)
    v
Vendor endpoints

Three things this diagram makes explicit:

• Clients are adapters, not endpoints. A client reads the incoming HTTP request (any shape) and produces GTM events. Custom clients let you handle non-standard payloads like Shopify webhooks, CRM events, or native app SDKs.
• Priority matters. When two clients can both claim a request, the higher-priority one wins. Overlapping clients (stock GA4 plus a custom GA4 variant) are a common source of silent misrouting.
• One request can become many events. A GA4 batch payload produces N events; each event flows through triggers independently. Tag firing is per-event, not per-request.

Stock server containers ship with GA4 and Measurement Protocol clients. Everything beyond that (Meta CAPI, TikTok eAPI, custom webhooks) requires community templates or custom client code.

Infrastructure Options

sGTM runs as a Docker container. Where you run it directly impacts cost, maintenance overhead, and 1st-party cookie capabilities.

Google Cloud Run (Default)

Google’s recommended approach. Set up via automatic provisioning from the GTM interface or Terraform scripts³.

Setup steps:

1. Create a new Server type container in GTM
2. Select Automatic to connect your GCP project and choose a payment method
3. Once the container is created, you receive a transport_url
4. In the client-side GTM GA4 tag, enable Send to server container and enter this URL

Features:

• Automatic scaling (3+ instances at high traffic, each capped at 1 vCPU; extra vCPUs break auto-scaling)
• Usage-based billing (request + CPU/memory)
• GCP ecosystem integration (BigQuery, Logging)
• Docker image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

Note: Cloud Run bills can increase unpredictably with traffic spikes. Cost monitoring and alert mechanisms should be set up.

Stape (Managed Hosting)

If you don’t want to manage your own infrastructure, managed hosting solutions like Stape eliminate setup and maintenance overhead⁴.

Setup steps:

1. Create a Stape account
2. Connect your sGTM container and configure DNS
3. Starts working within minutes

Features:

• Fixed monthly pricing (based on request limits)
• Automatic sGTM version updates (such as v3.2.0)
• Own CDN: Routes the sGTM domain to the same subnet as your site’s IP address; recognized as true 1st-party by Safari and Firefox
• Log and monitoring system (including anomaly notifications)
• Chrome extension for easy debugging

Docker Self-Hosted (Local Dev and Production)

Google publishes sGTM as an official Docker image (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) that runs anywhere Docker does, including localhost. This is the fastest way to iterate on client templates, test consent flows, or reproduce production bugs without touching GCP.

Simo Ahava published a docker-compose stack in December 2025 that boots a full tagging server plus preview server locally⁵:

# In a repo with docker-compose.yml and a populated .env file
docker-compose up -d

# Tagging server:  https://localhost:8888
# Preview server:  https://localhost:8889

The .env file needs two values:

• CONTAINER_CONFIG, copied from GTM Admin, Container Settings
• GA4_PROPERTY, your GA4 Measurement ID (e.g., G-ABC123XYZ)

When localhost Docker is useful:

• Iterating on custom client templates without pushing previews
• Debugging webhooks from services that can’t reach a public staging URL
• Reproducing production bugs against a known-good container config
• Running integration tests in CI without spinning up Cloud Run

Known caveat: sGTM’s server_container_url strips ports from outgoing requests, so some vendor tags break when pointed at localhost:8888. The transport_url workaround covers most GA4 scenarios but has limited feature parity.

For production self-hosting (Hetzner, bare-metal, any non-managed environment), the same image applies; you take on DNS, TLS, autoscaling, log retention, and sGTM version upgrades yourself. Two containers minimum: one preview server and one or more tagging servers⁶.

Other Alternatives

Option	Compatible	Note
AWS ECS	Yes	Official guide available, ECS + API Gateway + Kinesis architecture7
Cloudflare Workers	No	sGTM is a Docker/Node.js application; Workers V8 isolate environment is incompatible. Can be used as a proxy

Cost Model Comparison

	Cloud Run	Stape	Docker Self-host
Cost model	Usage-based (request+CPU)	Fixed monthly package	Server cost (fixed)
Scaling	Automatic, grows with traffic	Fixed within package	Manual
Setup difficulty	High	Low	Very high
Maintenance	Medium	Low (managed)	High
1st-party cookies	Custom domain required	Own CDN included	Manual configuration
sGTM updates	Manual redeploy	Automatic (~1 week)	Manual

For a detailed comparison across maintenance capacity, data sovereignty, and traffic predictability axes, plus agency multi-client architecture, see the sGTM Hosting Decision Matrix.

Custom Domain and 1st-Party Cookie Setup

Since Safari ITP 2.1 (2019), the lifetime of JavaScript-created cookies has been limited to 7 days. Server-set cookies (Set-Cookie header) are exempt from this restriction, but Safari performs CNAME cloaking detection: if the tracking subdomain’s IP address resolves to a different subnet than the main domain, those cookies are also reduced to 7 days. For a detailed browser cookie behavior table, refer to the event tracking approaches post.

DNS Configuration

1. Choose a subdomain for sGTM (e.g., ss.yourdomain.com). It should not have been used before.
2. Point A and AAAA records for the subdomain to the sGTM server’s IP address.
3. IP addresses must be in the same subnet as the main domain. This bypasses Safari’s CNAME cloaking detection.

SSL Certificate

After DNS records are pointed, an SSL certificate must be created. Cloud Run provides automatic certificates. With Stape, this process is automatic. For self-host scenarios, Let’s Encrypt or an existing certificate must be configured.

Verification

Verify that the custom domain is working in GTM Preview mode. If the preview page opens without issues, DNS and SSL configuration is complete.

Tag Configuration

GA4

GA4 tag configuration changed with sGTM v3.2.0. Previously, the GA4 Client loaded gtag.js directly; now all Google JS libraries are loaded via the Web Container Client⁸.

Setup:

1. In the server container, activate the GA4 client under the Clients section
2. Create a Web Container Client and whitelist the relevant Google Tag Measurement IDs
3. Enable “Automatically serve all dependent Google scripts”
4. Create a GA4 tag under the Tags section
5. Set the trigger to Client Name = GA4

In client-side GTM, enable Send to server container in the GA4 tag and enter the transport_url:

<script>
  gtag("config", "G-XXXXXX", {
    transport_url: "https://ss.yourdomain.com",
    first_party_collection: true,
  });
</script>

Google Ads

Remarketing

Create a Google Ads Remarketing tag in the server container and enter the Conversion ID from the Ads panel. Trigger: All Pages⁹.

Conversion Tracking

The relevant event (e.g., purchase) must be forwarded to the server container for conversion tracking. Create a GA4 Event tag for this event in client-side GTM, then configure the Google Ads Conversion Tracking tag in the server container¹⁰.

Enhanced Conversions

Enhanced Conversions hash customer data collected at the point of conversion (email, phone, name, address) with SHA-256 and match it against Google’s signed-in user database. This enables cross-device conversion tracking without cookies¹¹.

Server-side setup:

1. Enable Enhanced Conversions in Google Ads (Settings > Conversions > relevant conversion > Enhanced Conversions)
2. Add a user_data object to the GA4 tag in client-side GTM (email, phone, name, address)
3. Data flows to the sGTM container with the GA4 hit
4. The Google Ads Conversion Tracking tag in sGTM reads user_data from Event Data, hashes it, and sends it with the conversion

// Client-side dataLayer push example
dataLayer.push({
  event: "purchase",
  user_data: {
    email: "customer@example.com",
    phone_number: "+905001234567",
    address: {
      first_name: "Ali",
      last_name: "Yilmaz",
      country: "TR",
    },
  },
});

All PII data must be normalized before hashing: lowercase, whitespace trimming, E.164 format for phone numbers.

Meta Conversions API (CAPI)

Meta CAPI integration via sGTM sends conversion data server-to-server, completely bypassing the browser¹².

Setup:

1. In Meta Events Manager, use Partner Integrations > Google Tag Manager > “Set up with Google”
2. Connect your GTM web and server containers
3. Enter your tagging server URL and GA4 Measurement ID
4. Meta automatically creates server-side tags
5. Generate an access token from Events Manager > Settings > Conversions API

Alternatively, the Facebook Conversions API template from the GTM Community Template Gallery can be used.

Event Deduplication (Critical):

Browser Pixel and server CAPI events must send the same event_id and same event_name. Meta uses these two fields to match and deduplicate events. If deduplication is not properly configured, conversions will be double-counted and ad optimization will be compromised¹³.

Event Match Quality (EMQ):

Meta’s matching quality score on a 0-10 scale. Target minimum 6, ideally 8+. To optimize: send hashed email, phone, IP address, user agent, fbp cookie, fbc cookie, and external_id¹⁴.

Multi-Platform Distribution with Scout

While sGTM alone is sufficient for GA4, Google Ads, and Meta CAPI, management becomes complex when distributing data to multiple platforms like TikTok, Pinterest, and Klaviyo on e-commerce sites. At this point, Scout, developed under dnomia, takes events collected from sGTM or Zaraz, processes them in batches, enriches them with profile data, and distributes them to multiple destinations from a single point.

sGTM Container
  -> Scout Collector (batch processing, enrichment, deduplication)
    -> Meta CAPI, GA4 MP, Google Ads, Klaviyo, TikTok, Pinterest...

This approach provides a centralized distribution layer for e-commerce sites using multiple ad platforms, rather than creating individual sGTM tags.

Consent Mode v2 Server-Side Configuration

Consent Mode v2 has been mandatory for EEA traffic since July 2025. In sGTM, consent signals are carried automatically¹⁵.

How it works:

1. The client-side CMP (Cookiebot, Usercentrics, etc.) sets all signals to denied on page load via gtag('consent', 'default', {...})
2. The user interacts with the consent banner
3. The CMP sends user preferences via gtag('consent', 'update', {...})
4. When events fire, consent status is embedded in the request payload as the gcs parameter
5. sGTM automatically receives these signals

Four consent signals:

Signal	Controls
ad_storage	Ad cookies (Google Ads, Floodlight)
analytics_storage	Analytics cookies (GA4)
ad_user_data	Sending user data to Google for ad purposes
ad_personalization	Personalized advertising

Google GA4 and Google Ads tags in sGTM natively understand consent signals. Even when consent is denied, Google estimates a portion of lost conversions through behavioral modeling.

Debugging

Preview Mode

The sGTM debug process follows a flow known as the “Two-Tab Dance”¹⁶:

1. Click Preview in the server-side GTM container (debug tab opens)
2. Enable Preview in the client-side GTM container as well
3. Open your website in a third tab and perform actions
4. Check incoming requests in the server-side preview tab

Common issues:

• Preview cookies blocked: Browser extensions, VPNs, or privacy settings may block preview cookies
• “No Client Claimed the Request”: No client template matched the incoming request format. Check client configuration
• Load balancer timeout: Timeout settings shorter than 20 seconds will break preview mode
• Unpublished changes: Tag changes in the server-side container that are not published will return 404 for requests from the client side

Debugging Non-Web Requests with X-Gtm-Server-Preview

Preview mode only catches requests the browser sends with the right cookies. For anything that cannot set cookies, webhooks from Shopify, Paddle, or your CRM, native mobile app events, server-to-server Measurement Protocol calls, the X-Gtm-Server-Preview HTTP header is the bridge¹⁷.

How to get the header value:

1. Open sGTM Preview mode
2. Top-right menu, Send requests manually
3. Copy the X-Gtm-Server-Preview value (a base64-encoded token shaped like env-XXX|...|...)

Using it from curl (common for debugging webhook payloads):

curl -X POST https://ss.yourdomain.com/mp/collect \
  -H "X-Gtm-Server-Preview: ZW52LTI1NXx2RVNkYnBiSFdzTVRTZXB..." \
  -H "Content-Type: application/json" \
  -d '{"client_id":"test.1","events":[{"name":"purchase","params":{"value":49.9,"currency":"USD"}}]}'

From a backend fetch call (Node, integration tests):

await fetch(`${SGTM_URL}/events`, {
  method: "POST",
  headers: {
    "X-Gtm-Server-Preview": process.env.SGTM_PREVIEW_HEADER,
    "Content-Type": "application/json",
  },
  body: JSON.stringify(payload),
});

What to watch for:

• The token is session-scoped. Closing Preview, switching workspace, clearing cookies, or opening Preview in a different browser regenerates it.
• Never commit it to source or bake it into production clients. It is a dev-time debugging aid.
• For team-shared debug sessions, re-copy the token after someone else opens Preview; only the most recent session is valid.
• On mobile apps, inject the header only in debug builds. Shipping a preview-enabled binary to production will send real traffic into your debug tab.

This header is what makes sGTM debuggable end-to-end: not just the browser side, but every other system that feeds data into your tagging server.

Debug Tools

• Chrome Extension: “sGTM - add X-Gtm-Server-Preview Header” automatically adds the X-Gtm-Server-Preview header and _dbg=1 parameter
• Stape Debugger: User-friendly debug interface for non-technical users
• GTM Preview + console: Preview both client and server containers simultaneously to verify end-to-end data flow

The Limits of sGTM: A Reality Check

Plenty of content sells sGTM as the single infrastructure that solves everything. Bietolini’s 2026 comparison highlights three practical realities worth seeing before taking on the complexity and monthly bill¹⁸.

Ad-blocker bypass doesn’t work on its own

Even when server-side container traffic flows through a custom subdomain, ad-blocker lists pick up subdomain patterns, payload shape, and behavioral signals. DataUnlocker’s 2025 analysis shows that roughly 80% of widely used ad-blocker software still detects and blocks custom-domain sGTM traffic¹⁹. The real win is at the CAPI layer: Meta Conversions API, Google Ads Conversion API, and similar server-to-server integrations operate independently of blocker lists. The 24-93% conversion recovery numbers reported in Stape Analytics case studies come from that layer, not from moving sGTM to a subdomain.

Performance claims are context-dependent

Stape’s own-site benchmark shows a 39-point gap on mobile PageSpeed, 56 vs 95²⁰. That is the best case: GA4, Facebook Pixel, HubSpot, Klaviyo and other heavy client-side tags all moved to the server side. Semetis’s controlled measurements with WebPageTest and PageSpeed Insights describe the outcome as “significant but not conclusive”: the gain depends on which tags are moved and how many there are²¹. On a site that only runs GA4, the PageSpeed delta is usually under 5 points.

Safari ITP doesn’t fully disappear

Setting up a custom domain isn’t enough. Since Safari 16.4 (April 2023), server-set cookies also drop to 7 days if the subdomain IP does not share the first 16 bits with the main-domain IP (WebKit cross-site IP check). A default Cloud Run setup comes with its own IP range, so Safari cookies still cap at 7 days. With proper IP alignment the window extends to 400 days, but skipping that step means sGTM’s core Safari selling point doesn’t actually materialize²². If Safari traffic in GA4 is below 15%, this gain alone isn’t a sufficient investment case.

The migration threshold

Combining the three constraints, the practical threshold emerges: sGTM complexity and cost make sense for sites spending above USD 5,000 a month on paid media where conversion-signal loss is a real budget line. Below that, client-side GTM with hybrid CAPI on selected tags (Meta’s own CAPI Gateway or Google Tag Gateway) is usually enough.

Data Sovereignty: “EU Company” Is Not the Guarantee

“We use an EU provider, so US laws don’t touch us” is a line you hear often during procurement. The technical reality is different: what matters is not the provider’s country of incorporation, but the jurisdiction of the hosting provider actually operating the infrastructure²³.

Two US statutes create remote access

• CLOUD Act (2018): Compels US-based companies to hand global data to US law enforcement without a local court order. Applies even when the server sits in the EU.
• FISA 702: Authorizes warrantless surveillance of non-US persons’ communications routed through or stored on US-owned services.

Both apply simultaneously whenever the infrastructure provider is US-owned, regardless of the physical server location²⁴.

Current state of sGTM hosting providers

From Bietolini’s public eu-martech-sovereignty table on Codeberg, data as of 2026-04-12²⁵:

Vendor	Legal domicile	Infrastructure	CLOUD Act / FISA 702
Stape	Cyprus	GCP europe-west1 (Belgium)	Yes
Addingwell	France	Dedicated EU infra (claim)	Unverified
Taggrs	Netherlands	Undocumented	Unclear
Self-host Hetzner, OVH	DE, FR	EU-owned	No

As of today, the only verifiable non-US path is self-hosting on Hetzner, OVH, or another EU-owned provider. Stape’s Brussels endpoint resolves to a Google LLC IP: the geography is in the EU, ownership is US.

Three procurement questions

When evaluating an sGTM provider, go beyond the KVKK/GDPR data processing agreement and ask:

1. Who owns the legal entity operating the infrastructure? Not the registered office, but the shareholding and ultimate beneficial owner.
2. In which jurisdictions is the hosting provider subject to disclosure orders?
3. Is there a non-US deployment option, and can it be verified?

After Schrems II, a meaningful transfer impact assessment has to interrogate the full provider chain, not just the country of the server.

Conclusion

sGTM has become a cornerstone of data collection strategy in 2026. In this new era where client-side tracking is insufficient due to browser restrictions, the server-side approach is inevitable for data quality, privacy, and platform integrations. Before committing, set the threshold correctly: for sites spending under USD 5,000 a month on paid media with Safari traffic below 15%, the maintenance burden of sGTM often costs more than a hybrid CAPI setup.

Infrastructure choice depends on your context:

• Full control and GCP experience: Cloud Run
• Quick setup and predictable costs: Stape
• Own server infrastructure: Docker self-host
• Verifiable sovereignty for GDPR and KVKK: self-host on Hetzner or OVH

Whichever path you choose, custom domain with IP alignment (for 1st-party cookies and Safari), Consent Mode v2 integration, event deduplication (especially for Meta CAPI), and due diligence on the provider’s jurisdiction are four critical steps that are expensive to skip.

Footnotes

1. sGTM v3.2.0 Release Notes ↩
2. An Introduction to Server-Side Tagging. Google for Developers ↩
3. Cloud Run Setup Guide. Google Tag Manager ↩
4. Stape sGTM Hosting Documentation ↩
5. Run Server-side Google Tag Manager On Localhost. Simo Ahava ↩
6. Manual Setup Guide. Google Tag Manager ↩
7. Using Google Tag Manager for Server-Side Analytics on AWS ↩
8. How sGTM loads Google JavaScript libraries ↩
9. Google Ads Remarketing. Google Tag Manager ↩
10. Google Ads Conversions. Google Tag Manager ↩
11. About Enhanced Conversions. Google Ads Help ↩
12. Meta CAPI with Server-Side GTM ↩
13. Event Deduplication for Meta Conversions ↩
14. Event Match Quality Score ↩
15. Implement Consent Mode with Server-Side Tag Manager ↩
16. The Two-Tab Debugging Dance ↩
17. Preview Requests In Server-side Google Tag Manager. Simo Ahava ↩
18. Server-side vs Client-side GTM: 2026 Reality Check. Paolo Bietolini ↩
19. Stop Thinking Server-Side GTM Protects You From Ad Blockers. DataUnlocker ↩
20. Improving Website Page Speed With Server-Side Tracking. Stape ↩
21. Does Server-Side Tagging Positively Impact Page Speed? Semetis ↩
22. Safari ITP and Server-Side Tagging. Stape ↩
23. sGTM Hosting Providers: Who Runs Where. Paolo Bietolini ↩
24. European Company vs European Infrastructure. Paolo Bietolini ↩
25. eu-martech-sovereignty public repository. Codeberg ↩

Key Takeaways

• 01 With sGTM v3.2.0, the GA4 Client no longer loads gtag.js; all Google JS libraries are loaded via the Web Container Client
• 02 Managed hosting solutions like Stape significantly reduce setup and maintenance overhead compared to Cloud Run
• 03 If event deduplication (event_id + event_name) is not properly configured in Meta CAPI integration, conversions will be double-counted
• 04 Enhanced Conversions send hashed customer data (email, phone) server-side, enabling cookieless cross-device attribution
• 05 Custom domain and same-origin configuration bypasses Safari ITP's 7-day JS cookie limit
• 06 Consent Mode v2 signals are automatically carried with GA4 hits as the gcs parameter; server-side tags can fire based on consent status
• 07 sGTM does not bypass ad-blockers on its own: roughly 80% of widely used ad-blocker software still detects custom-domain sGTM traffic. The real gain sits in Meta and Google's server-to-server Conversion API layer
• 08 A provider's EU legal domicile is not a data-sovereignty guarantee: if the infrastructure runs on US-owned cloud, the CLOUD Act and FISA 702 still apply. The only verifiable non-US path today is self-hosting on an EU-owned provider like Hetzner or OVH

Frequently Asked Questions (FAQ)

+ Is sGTM free?

The sGTM software is free, but infrastructure is required to run it. Google Cloud Run bills based on usage. Managed hosting solutions like Stape offer fixed monthly pricing.

+ Should I choose Cloud Run or Stape?

Cloud Run offers full control and GCP ecosystem integration but setup and maintenance are complex. Stape completes setup in minutes, provides automatic updates, and its Own CDN feature simplifies 1st-party cookie management. Technical team capacity and the need for predictable costs are the deciding factors.

+ What is the difference between sGTM and Zaraz?

sGTM runs the GTM container server-side, offering full data control, CAPI integrations, and complex trigger logic. Zaraz runs on the Cloudflare edge with zero JS overhead and easy setup, but integration variety and trigger flexibility are limited.

+ Is a custom domain required?

Not technically required, but strongly recommended because Safari ITP limits JS cookies to 7 days. With a custom domain, server-set 1st-party cookies are exempt from this restriction.

+ Can Meta CAPI be set up without sGTM?

Yes, it can be set up via Meta's own CAPI Gateway solution or direct API integration. However, sGTM reduces management overhead by distributing data to multiple platforms (Meta, Google, TikTok) from a single container.

+ How long does sGTM setup take?

Basic setup with Stape can be completed in 30 minutes. With Cloud Run, 2-4 hours (depending on GCP experience). Full setup including custom domain, CAPI integrations, and Consent Mode configuration can take 1-2 days.

+ Does sGTM bypass ad-blockers?

Not by itself. DataUnlocker's 2025 analysis shows that roughly 80% of widely used ad-blocker software still detects and blocks custom-domain sGTM traffic. Ad-blockers now inspect request patterns, payload structure, and behavioral signals. The real gain comes from server-to-server integrations like Meta Conversions API and Google Ads Conversion API; the 24-93% conversion recovery numbers in Stape Analytics case studies come from that layer.

+ Is an EU-headquartered sGTM provider enough for GDPR compliance?

The provider's country of incorporation is not the decisive factor; the jurisdiction of the hosting provider operating the infrastructure is. Stape, for example, runs on GCP's Belgium region and therefore remains in scope for the US CLOUD Act. Addingwell claims dedicated EU infrastructure, Taggrs's infrastructure is undocumented. Today, the only verifiable non-US path is self-hosting on an EU-owned provider like Hetzner or OVH. After Schrems II, a transfer impact assessment has to cover the full provider chain, not just the server location.

+ Is sGTM necessary for every site?

No. The practical threshold is sites spending above USD 5,000 a month on paid media where conversion-signal loss is a real budget line. If Safari traffic is below 15%, the IP-alignment benefit alone is not sufficient justification. Below that threshold, client-side GTM with selected server-side CAPI tags (hybrid) is usually enough.