If you’ve made it this far, you’ve presumably accepted the uncomfortable truth that browser-based tracking is slowly circling the drain of digital obsolescence. Ad blockers are winning. Privacy regulations are multiplying like rabbits. Important conversions happen offline.
Which brings us to the solution that everyone’s talking about but remarkably few people have actually implemented properly: server-side tracking.
The concept is elegant enough: instead of relying on fragile JavaScript in someone’s browser to tell Facebook or Google that a conversion happened, your server — the authoritative source that actually processed the transaction — does the telling. No ad blockers to dodge. No cookie restrictions to navigate. Just one server having a straightforward conversation with another server about the commercial transaction that definitely, absolutely occurred.
Simple, right?
Well. Not exactly.
There are two critical components to a server-side tracking implementation that doesn’t simply replicate your existing problems in a new and more expensive format:
First, your conversions need to come from the actual source of truth — your payment processor, e-commerce platform, CRM, or whatever system definitively knows that money changed hands (or leads were generated, or subscriptions were activated — see What conversions events are there). This is the entire point. If you’re still involving the browser in this process, you’ve merely moved the deck chairs around on the Titanic while the iceberg of iOS 18 approaches.
Second, you need a way to tell each platform — Meta, Google, TikTok, your analytics tools, that spreadsheet your CEO inexplicably cares about—whose conversion this was. And here’s where it gets properly fiddly: each platform speaks its own peculiar dialect of identifier. Facebook wants an fbp cookie value and an fbc click ID. Google Ads wants a gclid. Google Analytics 4 wants a Client ID.
Without these platform-specific identifiers, you’re essentially calling up Meta and saying, “Hello, someone bought something!” To which Meta reasonably responds, “Lovely. But who? Which ad campaign do I attribute this to? Which audience should I optimize? Why are you like this?"
Before we proceed, let’s address a popular misconception that’s caused more confusion than a flat-pack furniture manual.
There exists something called “server-side tagging,” typically implemented via a server-side Google Tag Manager container. The pitch is seductive: install this container, fire events to it from your website, and—presto—they’re magically forwarded to all your platforms server-side! Easy-peasy! No JavaScript bloat from multitude of trackers! Privacy-friendly! Your tracking problems solved with one neat trick!
Except it doesn’t actually work like that.
A server-side GTM container configured this way is merely a proxy. It receives events from the browser and dutifully forwards them along to their destinations. Which means you’re still fundamentally dependent on the browser successfully sending those events in the first place. If someone has an ad blocker, or Privacy Badger, or has simply disabled JavaScript because they’re the sort of person who reads terms and conditions, your “server-side” setup still misses the conversion entirely.
More critically, it doesn’t have access to the complete attribution history that ad platforms need. When Facebook receives a server-side conversion event, it wants to know not just that a purchase happened, but the entire chain of clicks, impressions, and cookie values that led to it — ultimately, the original click identifier it can associate with its user and their clicks. A browser-to-proxy-to-platform setup can’t provide this with the reliability that actual server-to-server integration can.
Even if you fire an event to the container server-to-server, for example, from a CRM, it won’t help: the container has no knowledge of the past customer journey. It doesn’t know which ad clicks this CRM lead you’ve sent to it made. It can only forward what it received.
This doesn’t mean server-side GTM is useless — it has legitimate applications for reducing client-side JavaScript and improving page performance. And sometimes it’s useful for regulatory compliance. But it’s not the same thing as true server-side conversion tracking, and conflating the two is like confusing a bicycle with a motorcycle because they both have two wheels.
Over the next sections, we’ll explore the Conversions APIs offered by the major platforms: Meta’s CAPI (Conversions API), Google’s various server-side options, TikTok’s Events API, and others. Each has its own quirks, authentication methods, and ways of making you question your career choices.
We’ll cover:
By the end, you’ll have a working understanding of how to implement server-side tracking that actually deserves the name — not just shuffling events around through different pipes, but fundamentally changing where conversion data originates and how it flows to your marketing platforms.
Fair warning: this involves actual planning. It doesn’t matter whether you’re building a bespoke integration or using a no-code customer data platform like Able CDP. We’ll take understanding of what conversions exist that we discussed in the Track chapter and we’ll get them to ad platforms. If you’re ready to build something that actually works reliably in our post-cookie dystopia, then let’s crack on.