The difference in client-side vs server-side tracking is one of place: where the measurement is sent from. Everything else people attach to it — accuracy, privacy, speed — follows from that one change, and not always in the direction they expect.
Client-side: the browser does the sending
In the classic setup your page loads a script for each service you measure with, and each script sends its data straight from the visitor’s browser to Google, Meta or TikTok.
It works, and it happens in the place where you have the least control. A content blocker recognises the destination and stops the request. The browser’s tracking prevention discards or shortens the cookie. The visitor closes the tab before the request leaves. Each of those is silent — the event simply does not arrive, and nothing tells you it was supposed to.
Server-side: your own subdomain does the sending
In a server-side setup the browser sends to an address on your own domain — something like t.yoursite.com — and a server there decides what goes on to each platform.
Three things change as a result. The request goes to your own domain, so blocklists built around known tracker domains do not match it. The data arrives at your server first, so you can see and limit what leaves. And cookies are set by the server in its response rather than by a script in the page.
What is server-side tracking has the full version, including the diagrams.
What actually changes
Less is stopped on the way. That is the honest headline, and it is worth having.
You decide what leaves. This is the most underrated one, and the only benefit entirely within your control: the data reaches your server before it reaches anyone else’s, so you can drop fields, round values, or switch a destination off.
Your page gets lighter, because the scripts that used to run in it do not have to.
What does not change
Consent still applies. Moving the send to a server does not change what you are allowed to collect. It makes passing a consent choice on cleanly easier, which is a different thing.
Safari still caps your cookies. This is the one that gets oversold. WebKit treats a first-party subresource that resolves elsewhere via CNAME as third-party cloaking and caps cookies in that response at seven days. Since Safari 16.4 an A record does not automatically escape it either. That applies to every hosted setup, ours included — the limits section spells out why.
A bad measurement plan stays bad. If you are measuring the wrong event, you will measure it wrong more reliably.
Client-side vs server-side tracking: which one
Both, in practice. The advertising platforms expect a browser signal and a server signal and deduplicate between them; sending only one is the common mistake. The Meta Conversions API post covers what that looks like for Meta specifically, and Google Ads server-side tracking does the same for Google.
If you have decided you want a server-side setup and are choosing where to run it, server-side tracking tools compared is the next one. If the deciding question is where the data ends up, read server-side tracking and the GDPR.