For years the default way to track conversions was a pixel in the browser, often managed through Google Tag Manager. It is familiar and flexible. It is also the layer that ad blockers, Safari and iOS spend the most effort limiting. Server-side tracking sends the same events from your server instead. Here is how the two compare, and why most brands end up running both.
The problem is where the code runs
A client-side pixel and a GTM tag both execute in the visitor's browser. That location is exactly where tracking is now constrained:
- Ad blockers stop the script from loading, so the event never fires.
- Safari's ITP caps the cookies these tags rely on at 7 days.
- iOS removes the cross-app signals that used to connect a journey.
You can configure browser tags carefully, but you cannot opt out of the environment they run in.
What server-side changes
Server-side tracking reports the event from your own server or edge, directly to each platform's conversions API. The browser is no longer in the path, so the event cannot be blocked or shortened. Identity lives in a first-party cookie on your domain, which survives ITP far better than a third-party one.
| Client-side pixel / GTM | Server-side | |
|---|---|---|
| Where it runs | In the browser | On your server / edge |
| Ad blockers | Can block it | Cannot block the server event |
| Safari ITP | Cookies capped at 7 days | First-party, durable |
| Purchase reliability | Depends on a tag firing | Recorded from the event itself |
| Setup | Tags and triggers to maintain | One snippet or store app |
You do not have to choose
This is not pixel versus server as an either or. The two work best together:
- Keep the browser events for the signals only the browser has, like on-page interactions.
- Add server-side delivery for the conversions that matter, so a blocked script does not cost you the sale.
- Browser and server events share the same event id and are deduplicated, so nothing is double-counted.
Where GTM still fits
Google Tag Manager remains a useful way to manage browser tags, and server-side GTM exists too. The distinction that matters is not the tool, it is whether the conversion depends on a tag firing in the browser. If it does, it is exposed to the same limits.
SetRoasFlow sends your conversions server-side and unifies them into first-party profiles, then deduplicates against whatever browser tracking you keep. You get the coverage of server-side without giving up the signals the browser still provides.