GetServerSide Setup Guide

This guide walks you through setting up server-side tracking for your GA4 property. You'll deploy a server container on Cloud Run that sits between your website and Google Analytics. Once live, your GA4 events travel from the browser to your server container, then from your server to GA4 — giving you control over the data path.

The process:

  • Scan your existing GTM web container to understand what you have.
  • Deploy a server container on Cloud Run.
  • Set up a temporary test GA4 property and validate the server-side path — without affecting production.
  • Switch your production GTM setup to route through the server container.

After the switch, your existing GA4 property receives the same events with the same names and parameters — but the data arrives via your server infrastructure instead of directly from the browser.

The temporary test property is retired after go-live. You end up with your original GA4 property, your original GTM web container, and a new server container in between.

What you need: This guide assumes you have an existing GTM web container and GA4 property in production. GTM is required — server-side GTM runs as a GTM server container on Cloud Run, with your web container routing traffic through it.

One domain at a time: Each project covers one GTM web container and one GA4 property. If you have multiple domains sending to the same GA4 property, set up each domain as a separate project. They can share the same server container.

Article

How server-side GTM works

The higher-level explanation of why this setup uses one web container, one server container, Cloud Run, and a temporary property. Start here if you want the architecture rationale before the stage-by-stage path.

The setup path

The sections below cover the full setup from prerequisites through ongoing health checks. The app automates the scanning, classification, validation, and health check portions.

Inside the app, Setup → Setup Overview is the landing page for this path. It frames every stage with four columns: Purpose, Question to answer, Expected result, and Proof to continue — so you always know what a stage is meant to prove before the next one unlocks. The app's left sidebar mirrors the same six stages (Audit, Build, Cloud, Connect, Publish, Go Live), with each stage's steps nested under the current stage.

Getting Started

  • Confirm GA4 admin access and existing production property
  • Confirm GTM access and existing web container
  • Prepare a GCP project with billing and required APIs
  • Connect Google in the app and confirm required APIs
1

Audit

  • Select your GA4 property and GTM web container
  • Scan the live container — tags, triggers, variables, events
  • Review the readiness report: what moves, what needs review, what stays
  • Acknowledge reviewed items and approve the audit
2

Build

  • Pick or create the GTM server container
  • Pick or create the test server GA4 property
3

Cloud

  • Confirm GCP project and required APIs
  • Deploy Cloud Run preview + tagging services
  • Attach the tagging endpoint at a custom subdomain
4

Connect

  • Configure GTM web container (canonical variables, tags, triggers)
  • Configure GTM server container (GA4 client + All Pages trigger + GA4 Forwarder tag)
  • Optionally verify cross-container wiring in GTM Preview
5

Publish

  • Review and confirm the staged setup
  • Publish web and server GTM containers
  • Confirm live traffic reaches the test GA4 property
6

Go Live

  • Update the production Google tag to route through the server container
  • Verify the change and clean up the temporary forwarding route
  • Confirm critical events are healthy in production
  • Capture an immutable post-cutover baseline

Health Monitoring

  • Check routing liveness and sGTM confirmation
  • Detect web and server container drift
  • Verify critical events are still arriving
  • Re-scan if a container version changes

Monitoring

  • Check uptime-check, alert-policy, and notification-channel readiness
  • Understand how Monitoring differs from Health
  • Use Cloud Monitoring, Cloud Run metrics, and Log Explorer links for operations

How stage pages work

Most setup work happens on step pages — one per step in Build, Cloud, and Connect. They share a common anatomy: resource bindings at the top, a validation toolbar in the middle, and automated and manual sections below. Each step page in this guide opens with a small schematic of the app page it documents so you can pair each section here with what you see in the app. The one below is the reference layout:

APP PAGE

How stage pages work

Connect, Server, and Tagging step pages share this anatomy. Other stages (Audit, Publish, Go Live) use different layouts covered in each stage.

Reference: anatomy of a Connect, Server, or Tagging stage page Configured values, binding panel, Validate toolbar, sections with automated and manual checks, bottom next-stage link. Configured valuesResource bound by this stage example valueWorkspace or configuration example value Binding panel Option AOption B Validate Validate Clear validations » Automated validation section0 of N verified1. pending Check 1 -- description2. pending Check 2 -- description3. pending Check 3 -- description Manual attestation sectionPerform the action, then tick each item you verified. Manual check 1 Manual check 2Next Stage → Next stage

Audit, Publish, and Go Live screens use different layouts, covered in each stage.