Point11

Server-side tracking setup

Architect and deploy Google Tag Manager Server-Side for reliable, privacy-compliant conversion tracking that survives browser restrictions.

Server-side tracking moves tag execution from the user's browser to a server you control. This architectural shift is no longer optional for enterprises running significant Google Ads spend. Safari's Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection, and the growing adoption of ad blockers mean that client-side tags lose between 10% and 30% of conversion data depending on audience composition. Server-side tracking recovers that data.

Why Server-Side Tracking Matters

Traditional client-side tracking loads JavaScript tags in the user's browser. Every tag competes for bandwidth, slows page rendering, and is subject to browser privacy restrictions and ad blockers. Server-side tracking fundamentally changes this model.

With Google Tag Manager Server-Side (sGTM), the browser sends a single request to a first-party endpoint on your domain. A server-side container processes that request, enriches it with server-side data, and forwards events to Google Ads, GA4, and any other downstream platforms. The browser never communicates directly with third-party ad servers.

Key Benefits

  • Data accuracy: Server-side tags are not blocked by ad blockers or browser privacy features. Conversion data completeness improves by 15-30% in most deployments.
  • Page performance: Removing third-party JavaScript from the browser reduces page load time. Fewer client-side tags mean better Core Web Vitals scores, which directly impacts Quality Score and ad auction performance.
  • First-party data control: All data flows through your server. You control what is forwarded, enriched, or redacted before it reaches any third-party platform.
  • Cookie longevity: Cookies set by a first-party server endpoint are not subject to the same expiration restrictions as third-party cookies or client-side JavaScript cookies. Safari limits client-side cookies to 7 days. Server-set first-party cookies persist for their full expiration period.

Architecture Overview

A production sGTM deployment consists of three layers:

1. Client-Side Data Layer: A minimal client-side GTM container or gtag.js snippet sends events (page views, purchases, form submissions) to your first-party server endpoint instead of directly to Google.

2. Server-Side Container: The sGTM container runs on your infrastructure and processes incoming requests. It parses event data, applies server-side tags (Google Ads Conversion Tracking, GA4, Floodlight, etc.), enriches events with server-side data (CRM data, margin data, customer lifetime value), and forwards the processed events to their destinations.

3. Infrastructure: Google recommends Cloud Run on Google Cloud Platform as the default deployment target. The container image is maintained by Google and auto-scales based on request volume. For AWS environments, sGTM can be deployed on ECS or Fargate behind an Application Load Balancer. The key requirement is a container runtime that can scale horizontally and handle HTTPS traffic on a custom domain.

Deployment on Cloud Run

The recommended production setup uses a minimum of three Cloud Run instances for high availability. Configure a custom domain that is a subdomain of your main website (e.g., sgtm.yourdomain.com) to ensure cookies are treated as first-party. Enable automatic scaling with a maximum instance count appropriate for your traffic volume.

Google provides a provisioning script that automates Cloud Run deployment. The script creates the Cloud Run service, configures the custom domain mapping, and sets up SSL certificates. For enterprise deployments, use Terraform or Pulumi to manage infrastructure as code rather than relying on the provisioning script.

Consent Mode v2 Integration

Server-side tracking must respect user consent. Google Consent Mode v2 introduces two new parameters, ad_user_data and ad_personalization, which must be passed from the client-side consent banner through to the server-side container. When consent is denied, sGTM should still fire tags in consent mode, sending cookieless pings that enable Google's conversion modeling to fill data gaps.

The server-side container can enforce consent decisions as a centralized control point. This is more reliable than depending on every client-side tag to individually respect consent signals.

Monitoring and Debugging

Use the sGTM Preview mode to inspect incoming requests, trace how each tag processes data, and verify that outbound requests to Google Ads contain the correct parameters. In production, monitor container health metrics (CPU, memory, request latency) through Cloud Run's built-in monitoring or your observability platform.

Set up alerting for error rate spikes. A failing sGTM container means zero conversion data flows to Google Ads, which will rapidly degrade automated bidding performance.

Sources

Enhanced conversions configuration

Need help implementing this?

Our team can walk you through the setup.

Talk to Sales