Skip to content
DATANOSTRO ACADEMY

Server-side tracking 101 — what it is and why you need it

An explanation of the difference between client-side and server-side tracking. Why ITP, ad-blockers, and iCloud Private Relay eat 25-40% of your conversions — and how server-side gives you clean data back.

10 min Read Začátečník Updated 5.6.2026

Server-side tracking moves event capture from the visitor's browser to your own server. That sounds dry, but in practice it means 20-40% of conversions recovered that Safari, Brave, and ad-blockers eat today.

Client vs. server

Client-side: GA4 / Meta Pixel run directly in the visitor's browser. Ad-block filters see them, Safari ITP deletes their cookies, and iCloud Private Relay hides the IP address. The result: a dataset with a leaky attribution model.

Server-side: the browser sends the event to your own server (typically track.yourstore.cz), which forwards it to GA4, Meta CAPI, and Google Ads. Ad-blockers miss it — it looks like a first-party request. ITP has nothing to delete — we issue the cookies, not a third party.

Why it's a necessity now

  • iOS 17 + iCloud Private Relay: anonymizes the IP, confuses attribution for Meta and Google Ads.
  • Safari ITP 2.3+: deletes _ga, _gid, and _fbp cookies within 7 days.
  • Brave + uBlock: block 100% of requests to analytics.google.com.
  • Consent Mode v2 in the EU: without a server-side model you have no way to capture "denied" events without PII.

What you gain

Real numbers from our onboardings: a store doing CZK 1M/month on Meta Ads saw +34% conversion match rate in the Events Manager after switching to server-side. That means CAPI got more data → the algorithm knows more → ROAS grows by 15-25% with no budget increase.

If you want a rough estimate for your case, use the ROAS calculator — it computes how much revenue you're missing due to lost tracking.

Did this article help you?
✓ Thank you for the feedback