Guide

Set up server-side Google Tag Manager, step by step

Converting CSVs fixes last month's data. Server-side tagging fixes the pipeline: conversions flow from your own subdomain to Google, browsers stop blocking your tags, and the next API migration becomes a config change instead of a fire drill. This guide goes from zero to a verified setup.

How the pieces fit

The browser sends each event once, to a subdomain you own. The server container receives it, then fans it out to every ad platform from the server side. Ad blockers and browser tracking prevention see first-party traffic to your own domain, not calls to google-analytics.com.

Before you start

• A Google Tag Manager account with a web container already running on your site (or plain gtag.js)
• Access to your domain's DNS (you will create one subdomain record)
• A decision on hosting — if you haven't made it, read where to run the server first. Short version: managed hosting like Stape for most teams, Cloud Run if you live in Google Cloud anyway, self-hosting only with real DevOps capacity.

Step 1 — Create the server container

1. In Google Tag Manager, open Admin and click + next to your containers.
2. Name it (e.g. yourdomain — server) and choose Server as the target platform.
3. GTM offers to automatically provision a tagging server on Google Cloud, or lets you manually provision. Choose manual — it keeps the hosting decision in your hands, and every hosting route below starts from it.
4. Copy the container config string (a long base64 value). You can always find it again under Admin › Container Settings.

Step 2 — Deploy the tagging server

The container config string is the only thing the server needs. Pick one route:

Route A — Managed hosting (Stape and similar)

1. Create an account with a managed provider such as Stape (a free tier covers about 10,000 requests per month — enough to validate the setup on low-traffic sites).
2. Create a new sGTM container in their dashboard and paste the container config string.
3. The platform provisions the server and gives you a default URL within a few minutes. TLS, scaling, and image updates are their problem, not yours.

Route B — Google Cloud Run

1. In Google Cloud, create (or pick) a project with billing enabled.
2. Deploy Google's official image with the config string as an environment variable:

gcloud run deploy gtm-server \
  --image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
  --platform managed --region us-central1 \
  --min-instances 2 --max-instances 10 \
  --set-env-vars CONTAINER_CONFIG=<your container config string>

• Google recommends a minimum of 2 instances to reduce data-loss risk, and estimates roughly $45/month per server (1 vCPU, 0.5 GB, CPU always allocated) as of mid-2026 — set a billing alert.
• You also need a second, smaller service as the preview server for debugging (same image, RUN_AS_PREVIEW_SERVER=true).

Route C — Self-hosted

The same Docker image runs anywhere: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable on a VPS behind your own TLS terminator. Cheapest in cash, most expensive in responsibility — the hosting comparison covers when this actually makes sense.

Step 3 — Put the server on your own subdomain

This step is the point of the whole exercise: first-party context.

1. Pick a subdomain, conventionally gtm.yourdomain.com or ss.yourdomain.com.
2. Add the DNS record your host asks for (managed platforms show you the exact CNAME/A record; Cloud Run uses domain mapping).
3. In GTM, open the server container's Admin › Container Settings › Add URL and enter https://gtm.yourdomain.com.

Step 4 — Point your web tags at the server

1. In your web GTM container, open your GA4 Google tag.
2. Set the server container URL parameter (server_container_url, shown as "Send to server container" in the tag settings) to https://gtm.yourdomain.com.
3. Publish the web container. From this moment, GA4 hits go to your subdomain instead of directly to Google.

If your site sets a Content Security Policy, allow the subdomain in img-src, connect-src, and frame-src.

Step 5 — Add clients and tags in the server container

1. The GA4 client is pre-installed (server container › Clients in the left navigation). It receives the incoming hits and turns them into an event stream.
2. Add a GA4 tag that forwards events to Analytics.
3. Add Google Ads Conversion Tracking (and Remarketing, if used) tags, triggered by your purchase/lead events. They read the click IDs the GA4 client already parsed.
4. Other destinations (Meta CAPI, TikTok Events API) are one tag each from the community template gallery — the event stream is already there.

Step 6 — Verify the pipeline

1. Open Preview on the server container — it shows every incoming request and which tags fired.
2. Trigger a test conversion on your site and confirm the GA4 client claims the request and the Google Ads tag fires.
3. In your browser's network tab, confirm hits go to gtm.yourdomain.com and nothing still calls the old endpoints directly.
4. Within a day or two, check that conversions appear in Google Ads with status "Recording conversions".

What about offline conversions?

Server-side GTM covers conversions that happen on the site. Conversions that close later — in your CRM, over the phone — still travel the upload path that changed on June 15, 2026: the Data Manager API, or manual imports. For historical files, the converter reformats legacy CSVs in your browser; for an ongoing pipeline, platforms like platforms like Stape can forward CRM events server-side so there is no monthly upload at all.