Server-Side Tracking Migration.

// 01Why server-side tracking

Classic client-side tracking — browser firing direct requests to Google, Meta, TikTok — has three problems:

• Cookie loss: Safari ITP expires 3rd-party cookies in 7-30 days. iOS 14.5+ ATT kills tracking for 75% of users. Ad-blocker usage exceeds 30%.
• Page speed: 5-10 third-party tags load serially. LCP +1.5-3s.
• Data control: everything goes directly to third parties — GDPR/CCPA exposure, no PII filtering.

Server-side GTM solves most of these.

// 02Architecture overview

Classic (client-side)

Browser → Google Analytics, Meta Pixel, Google Ads (parallel third-party requests).

sGTM

Browser → Web Container → 1st-party endpoint (e.g. track.yourbrand.com) → Cloud Run Server Container → Google/Meta/TikTok (server-to-server).

Critical: the browser only fires one request, to your own domain. From there fan-out happens server-side. Browser sees everything as 1st-party.

// 03Step 1: create Server Container in GTM

1. Go to tagmanager.google.com, select your workspace.
2. Admin → Container Settings → "Create Container" → Target: Server.
3. Note the Container ID (GTM-XXXXX format).
4. Choose "Manually provision" for Cloud Run control.
5. Note the Server URL placeholder (will be replaced post-deploy).

// 04Step 2: Cloud Run deploy

In Google Cloud Console:

1. Create or select GCP project.
2. Enable Cloud Run API.
3. "Create Service" → Container Image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
4. Region: pick close to your user base (us-central1, europe-west1, etc.).
5. Authentication: "Allow unauthenticated invocations."
6. Container port: 8080.
7. Environment variables:
   • CONTAINER_CONFIG — config string from GTM Server Container.
   • RUN_AS_PREVIEW_SERVER — false (preview gets a separate service).
8. CPU 1 vCPU, Memory 512MB to start. Min instances 1 (avoid cold starts).
9. Max instances: 10-100 by traffic.

// 05Step 3: 1st-party subdomain

Cloud Run's native URL (your-service-xxx.run.app) is third-party — ITP still hits it. Always serve via your own domain.

1. Open DNS provider (Cloudflare, Route53, etc.).
2. Add CNAME: track.yourbrand.com → ghs.googlehosted.com.
3. Cloud Run console → Domain Mappings → Add Mapping → track.yourbrand.com.
4. SSL cert auto-provisions (5-30 min).
5. GTM Server Container settings → Server URL = https://track.yourbrand.com.

// 06Step 4: route web container to sGTM

Update the GA4 Configuration tag in your web GTM container:

• "Send to server container" — true.
• Server container URL — https://track.yourbrand.com.
• Fill the Transport URL field.

Add corresponding server-side tags:

• GA4 Client: parses incoming GA4 requests.
• GA4 Tag: server fan-out to Google Analytics.
• Meta Conversions API Tag: sends same event to Meta.
• Google Ads Conversion Tag: for Ads conversion reporting.

// 07PII filtering + GDPR compliance

The biggest server-side advantage: clean data before sending to third parties.

What to do

• Email hashing: SHA-256 instead of raw email (already required for Enhanced Conversions).
• IP truncation: zero last octet (anonymized IP for GDPR).
• Phone normalization: hash + country-code normalize.
• URL params: filter PII-bearing query strings (e.g. ?email=).

Implement via "Custom Variable" + Transformation server-side. Showing this structure in GDPR audit qualifies as compliance evidence.

// 08Test and observe

1. GTM Server Preview mode: test in preview first. Verify each event reaches the server and fires correct tags.
2. GA4 DebugView: confirm server-sent events appear in GA4.
3. Meta Events Manager: "Test Events" tool to confirm CAPI events arrive. Compare match rate before/after sGTM.
4. Google Ads: "Conversion Diagnostics" — observe Enhanced Conversions match rate climbing.

Expected improvements (4-6 weeks in)

• GA4 vs Google Ads conversion gap shrinks from 20-30% to 5-10%.
• Enhanced Conversions match rate rises from 45-55% to 70-80%.
• Page LCP improves 0.3-0.8s.
• Meta CAPI match quality climbs to 6-8.