Short answer: with client-side tracking, the visitor’s browser sends data straight to Google, Meta and other platforms. With server-side tracking, the browser first sends the data to a server you manage, and that server forwards it. That gives you more control over what goes to which platform and less code in the browser. It does cost hosting and maintenance, and consent is still required.
By the TrackLead team. Technically reviewed by Pieter. Updated: October 2026.
Client-side tracking: the browser talks to every platform
With client-side tracking the website loads tags in the browser: the Google tag, the Meta Pixel, the LinkedIn Insight Tag. Each tag sends its own requests to its own platform. It is quick to set up and it is the default.
The downside: every tag is extra code on the page, you can’t see exactly what each script collects, and whatever the browser blocks never arrives. Safari deletes cookies set by JavaScript after seven days without interaction, and after a click from a known tracker’s link after just 24 hours.
Server-side tracking: one stream to your own server
With server-side tracking the browser sends data to a tagging server: a Google Tag Manager server container on a server that you or the client manage. In that container, clients turn incoming requests into events, and tags forward those events to GA4, Google Ads, Meta and other platforms.
Google mentions, among other things, better performance through less code in the browser, better security and more privacy control: you decide which data goes to which platform. For example, you can remove IP addresses before anything reaches a platform.
The difference at a glance
Where the code runs: client-side in the browser. Server-side mostly on your own server.
What platforms see: client-side, everything their script collects in the browser. Server-side, only what you forward.
Cookies and Safari: client-side, script-set cookies disappear in Safari after seven days without a visit. Server-side you can set cookies from your own domain. If that subdomain points to another party through a CNAME, or runs on a very different IP network, the seven days apply there too.
Ad blockers: a problem for both. Filter lists such as EasyPrivacy also block known server-side paths and subdomains of known hosts. Server-side helps less here than is often claimed.
Consent: required for both. You set up consent in the web container, and the state is passed on to the server.
Cost: client-side has no hosting cost. Server-side does: Google estimates roughly 45 dollars per server per month on Cloud Run, and recommends at least two servers for production. Managed hosts charge a monthly fee.
Maintenance: client-side, platforms keep their own scripts up to date. Server-side you manage an extra layer that can break when a platform changes something.
What server-side tracking doesn’t fix
Consent. Without consent you still can’t measure everything.
Ad blockers. Part of the requests is still blocked.
A poor data layer. If the website passes the wrong value, the server forwards the wrong value.
When client-side is enough
Client-side is fine if you mainly use GA4, spend little on ads and see no big gaps between your measurements and your backend. Chrome is keeping third-party cookies; Google decided that in April 2025. So there is no hard deadline forcing a switch.
A middle step is Google tag gateway. It loads the Google tag from your own domain through your CDN or web server, set up in a few clicks from the Google tag with Cloudflare. There is no server container, you can’t change the data and it only works for Google tags. If you already use server-side tagging, Google recommends using the gateway alongside it.
When server-side is worth it
The client steers ad budget on conversion data in Google Ads or Meta.
Platform numbers clearly differ from the online store or CRM.
The client advertises on Meta. Meta recommends sending events through both the Pixel and the Conversions API, so events the Pixel misses still arrive.
The client wants to decide which data goes to which platform.
You want to send offline conversions, such as deals from the CRM, back to the platforms.
How to choose, in five questions
How much ad budget depends on conversion data? Little: start client-side.
How big is the gap between platform and backend? Measure it for a week. If it’s large, look at consent and the data layer first, then at server-side.
Which platforms does the client advertise on? On Meta or LinkedIn, server-side lets you add the Conversions API.
Who manages it after go-live? Without monitoring and maintenance, a server-side setup breaks after a while.
Is there budget for hosting? Plan for at least two servers on Cloud Run or a subscription with a host. More in how much a server-side tracking setup costs.
Going server-side? Read what to sort out before you start with server-side tracking first. TrackLead then sets up the implementation in your client’s own GTM, on the host you already use, with monitoring included. Take a look at tracklead.eu.
Frequently asked questions
Is server-side tracking better than client-side?
Not always. It gives more control and can get more conversions through, but it costs hosting and maintenance. For a small site that mostly uses GA4, client-side is often enough.
Does server-side tracking bypass ad blockers?
No, not reliably. Filter lists such as EasyPrivacy also block known server-side paths and subdomains of known hosts.
Do I still need a cookie banner with server-side tracking?
Yes. Server-side changes the route the data takes, not whether you need consent.
Can I run client-side and server-side at the same time?
Yes, that is very common. Prevent double counting: use the same transaction_id for GA4 and the same event_id for Meta.