TL;DR

Server-side tracking is genuinely useful when you've got real signal loss to recover, real PII concerns, or a measurement layer that needs to outlive a single platform. It is also frequently a project that costs more than it pays back. Here's how to tell which side of the line you're on.

Every six months or so, server-side tracking has another wave of conference talks, vendor pitches, and "your tracking is broken" LinkedIn posts. We've now built it for enough clients to have a clearer view of where it's worth the engineering cost - and where it's a polished version of a problem you didn't have.

This piece is the framework we walk clients through before recommending it. The TL;DR is that server-side is real, useful, and underrated for some businesses - and an expensive distraction for others.

What server-side actually is

The model people start with: tags fire from the user's browser, sending data directly to Google Analytics, Meta, LinkedIn, and so on. This is "client-side" tracking. It's been the default for fifteen years.

Server-side tracking inserts a step in the middle. Instead of the browser firing tags directly to every platform, it fires a single event to a server you control - typically a Google Cloud container running GTM Server, or a hosted equivalent like Stape. That server then forwards the event onward to the platforms.

From the browser's perspective, only one tag fires. From the platform's perspective, the data arrived from your server, not the user's browser. From your perspective, you've inserted a layer where you can enrich, filter, and audit every event before it leaves your environment.

Why this matters now

  • Browsers are restricting client-side cookies. Safari ITP, Firefox ETP, and Chrome's eventual third-party cookie deprecation all reduce the lifespan and reach of cookies set by client-side tags. Cookies set by your server, on a first-party subdomain, last meaningfully longer.
  • Ad-blockers target known tag endpoints. Meta Pixel and Google Analytics URLs are blocked by every popular ad-blocker. Server-side tags routed through your own subdomain are not, because the blocker can't tell what they are.
  • Conversion APIs need server-side data anyway. Meta CAPI, Google Enhanced Conversions, LinkedIn CAPI - all of these are server-side feeds at heart. Building a server-side container often makes the CAPI work cleaner.
  • Privacy and PII concerns are real. Server-side gives you a place to hash, redact, or enrich data before it leaves your environment. For regulated sectors that's not a nice-to-have.

When it's worth the work

The honest test we apply on every account:

  1. Is your tracking visibly leaking? If 25%+ of your client-side conversions don't match your server-side records (orders, leads, sign-ups), there's signal loss server-side will recover.
  2. Is the platforms' optimisation getting starved? If Meta or Google have flagged your event volume as "limited" or you're seeing big gaps between platform-reported and analytics-reported conversions, more durable signal will help.
  3. Are you in a regulated sector? Financial services, healthcare, education - server-side gives you the audit trail and PII control your compliance team needs.
  4. Is your spend big enough? Below ~£20-30k/month total media, the engineering cost rarely pays back inside 12 months. Above £100k/month, the maths usually works.

If two or more of these are true, server-side will likely earn its keep. If none are, you may be solving a problem you don't have.

What it actually costs

Specific to GTM Server / Stape / Google Cloud Run, in our experience:

  • Initial setup: 4-6 weeks for a clean implementation that covers GA4, Meta CAPI, Google Enhanced Conversions, and consent integration. Less if you already have a healthy GTM container; more if you don't.
  • Hosting: £100-£600/month for the server container, depending on traffic and provider. Stape is the simplest path; Google Cloud Run is cheaper at scale.
  • Ongoing maintenance: Real but small. The container needs occasional updates, the tags drift, the platforms change their APIs. Budget half a day a month.

The total cost of ownership is meaningfully more than client-side. The honest question is whether the recovered signal pays back.

A reality check

For a £50k/month account, recovering 15% of lost signal typically translates to a 5-10% improvement in CPA over 3-4 months as the platforms re-learn on cleaner data. That's a meaningful number. For a £5k/month account, the same percentage gain doesn't justify the build. Be honest about scale.

What to actually build

If you've decided it's worth doing, the order we usually recommend:

  1. First, fix client-side. A messy client-side container will produce a messy server-side container. Audit and clean GTM before you migrate anything.
  2. Stand up the server container. Stape is the fastest path - 2-3 days from sign-up to events flowing. Google Cloud Run is more work up-front but cheaper at scale.
  3. Set up custom subdomain + first-party cookies. The whole point is that the browser sees first-party requests; configure DNS and cookies accordingly.
  4. Migrate one platform at a time. GA4 first - it's the lowest risk. Then Meta CAPI. Then Google Enhanced. Don't try to migrate everything in one cut.
  5. Run client + server in parallel for 2-4 weeks. Compare event counts daily. The tracking should agree within ±5% before you turn off the client tags.

Things to avoid

  • Don't migrate without consent integration. Server-side does not bypass consent. Consent Mode v2 needs to flow through the server container, and tags need to respect it.
  • Don't over-enrich. The temptation is to attach every available customer attribute to every event. Just because you can doesn't mean it's GDPR-defensible.
  • Don't pretend it's a privacy upgrade by itself. Server-side gives you control over what's sent. It doesn't reduce what's sent unless you actively choose to.

If you'd like a clear read on whether server-side is worth the work for your account specifically, that's a typical strand of the strategic review. We'll look at where signal is leaking, what it's costing you, and whether the engineering investment will pay back.

Read next
Why most paid search accounts waste budget on the wrong intent