Home Guides Server-side tracking
Server-side tracking Last reviewed July 2026

What is server-side tracking?

The short version is that you move the collection of analytics and advertising events out of the visitor's browser and into a server you control. The long version is why that matters, what it genuinely recovers, and the cases where it is not worth the money.

Short answer

Server-side tracking moves event collection from the visitor's browser to a server you control. Instead of a dozen vendor scripts each firing their own request from the page, the browser sends one event to your own domain, and a server container forwards it to GA4, Meta, Google Ads and anywhere else. Because that request is first-party and the forwarding happens outside the browser, ad blockers cannot match it, Safari's cookie limits do not apply to it, and you get one place to enforce consent and strip personal data before anything leaves.

What it actually recovers, and what it does not

Blocked requests come back, because the browser is no longer talking to googletagmanager.com or connect.facebook.net. Cookie lifetime improves, because identifiers are set by a server rather than by JavaScript, which takes them out of Safari's seven-day cap. What does not come back is anyone who declined consent — server-side is not a way around that, and any vendor implying otherwise is selling you a liability rather than a solution.

The bit that decides whether it works

A server container that forwards GA4 and nothing else recovers very little. The recovery comes from what you build around it: a Conversions API layer so Meta and the rest receive events server-side too, deduplication so a browser pixel and a server event collapse into one conversion, and first-party identity so returning visitors are still recognisable. Most disappointing implementations are disappointing because they stopped at the container.

What it costs to run

For most sites under five million events a month, the compute is $25–80 a month on Cloud Run or equivalent. Managed hosting from a vendor runs roughly $20–200 depending on volume. The larger cost is the build and the maintenance, and the largest hidden cost is nobody noticing when it breaks — which happens quietly, because a broken container still returns 200.

When it is not worth it

Under roughly ten thousand sessions a month the recovery will not pay for the running cost. If you spend nothing on paid media, better attribution buys you nothing to act on. And if your traffic is overwhelmingly non-EU and non-Safari, the two biggest loss vectors barely apply to you. A lighter first step in that case is Google Tag Gateway, which gives you first-party serving without a container to operate.

How to check yours is working
  1. 01 Count your monthly sessions — under ~10,000 the maths rarely works
  2. 02 Check what share of your traffic is Safari or EU; that is where the loss concentrates
  3. 03 Look at your ad spend: recovery is only worth what the improved bidding earns you
  4. 04 Confirm whether your current setup already sends Conversions API events, not just GA4
  5. 05 Ask who would notice if the pipeline stopped, and how long that would take
? Common questions
Is server-side tracking the same as server-side GTM? +

Server-side GTM is one way to do it — Google's server container product. Server-side tracking is the general approach, and it can also be done with a custom collector, a CDP, or a vendor platform like Stape, Addingwell or Taggrs.

How much data does server-side tracking actually recover? +

Published figures cluster between 18% and 45% more conversion events depending on how much of your traffic is Safari or EU and how blocked your audience is. The only number that means anything is yours, measured against your own traffic.

Does server-side tracking avoid the need for consent? +

No. It changes where processing happens, not whether you need a legal basis. Done properly it makes consent easier to enforce, because a denied signal can stop the outbound request being built at all.

Will it slow my site down? +

It usually speeds it up. Replacing several vendor scripts with one lightweight tag removes JavaScript from the critical path, which tends to improve Core Web Vitals rather than hurt them.

Want someone to just do this properly?

Consent enforcement in the container, wired to your CMP, with an audit trail — part of every build we ship.

Server Events
↑ TOP