Server-side tracking, explained in plain English
What server-side tracking actually is, why browsers broke the old way, and how to decide whether you need it — without the jargon.
Every marketing measurement conversation eventually arrives at "should we go server-side?" Here's the honest, jargon-free version of what that means.
How tracking used to work
A visitor lands on your site. A little piece of JavaScript — the pixel — fires from their browser directly to Google, Meta and friends. Simple, free, and for fifteen years it worked.
Then three things broke it:
- Ad blockers now block a quarter or more of these requests outright.
- Safari and Firefox cap cookie lifetimes to 7 days (sometimes 24 hours), so returning visitors look like strangers.
- iOS privacy prompts removed a large slice of mobile data entirely.
Result: the average e-commerce site's pixel sees maybe 60–80% of what actually happens. Your ads optimise on the visible fraction and your reports understate reality.
What server-side changes
Instead of the browser talking to fifty vendors, the browser talks to one endpoint you own — typically a server-side Google Tag Manager container running on your own subdomain (data.yourbrand.com). Your server then forwards events to Google, Meta, TikTok and the rest.
Why this helps:
- First-party context. Requests to your own subdomain aren't treated as third-party tracking, so they survive blockers and browser restrictions far better.
- Longer-lived cookies. Cookies set server-side on your domain get normal lifetimes, so returning visitors stay recognised.
- One place to govern data. You decide exactly which fields each vendor receives — great for privacy compliance.
- Faster pages. One network call from the browser instead of dozens.
Do you actually need it?
A blunt decision rule we use with clients:
| Situation | Verdict |
|---|---|
| Spending under ~£5k/month on paid | Probably not yet — fix basics first |
| Meta/Google spend is material and scaling | Yes — the data quality gain pays for itself |
| Heavy Safari/mobile audience | Yes, and sooner |
| No consent management in place | Fix consent first — server-side doesn't exempt you from GDPR |
Server-side tracking is plumbing, not magic: it recovers signal that browsers were dropping, it doesn't invent data you're not allowed to collect. Anyone who pitches it as a "GDPR workaround" should worry you.
The realistic project shape
A proper implementation is around two to four weeks: container hosting, event mapping, deduplication between pixel and server events (so you don't double count), consent integration, and — the step everyone skips — validation against source-of-truth orders. Skip that last step and you've just built a faster way to be wrong.