With Google's latest wave of AI ad products rolling out, one thing is now certain: the future of ad delivery will lean more and more on the black-box algorithms of the ad giants, and the levers advertisers can manually pull will keep shrinking.
In the past, you could still pull ahead of competitors through audience targeting, placement splits, bidding strategy, and interest-set testing. But what actually determines the quality of an ad system's learning today isn't how skillfully you configure the backend. It's whether you can feed the system enough clean, accurate conversion signal.
Much like the broader AI race, the tech giants now care less about algorithmic breakthroughs than about infrastructure: power supply, chip capacity, and the like. As digital advertisers, we should be paying the same attention to the competition over data infrastructure.
It started back in 2017, when Apple introduced ITP (Intelligent Tracking Prevention) and effectively kicked off the post-cookie era. Every major browser and OS has since followed suit, tightening user privacy protections one release at a time. Third-party cookies, cross-site tracking, and front-end JavaScript tracking are all far less stable than they used to be. And that's before you factor in that roughly 30% to 35% of internet users worldwide run an ad blocker on at least one device. Relying on front-end tracking alone simply isn't reliable anymore, yet most websites still deploy tracking through nothing more than a Pixel and front-end GTM (Google Tag Manager).
This is the root reason ad conversion costs keep climbing. It's not that platform algorithms are getting worse. It's that the signal you're feeding the ad system was already full of holes to begin with.
How client-side tracking works
The traditional way of embedding a Facebook Pixel, Google Ads Tag, or any other third-party tracking snippet is, at its core, client-side tracking.
Put simply, you drop a piece of JavaScript into the page and let the user's browser do the tracking work.
The whole process breaks down into roughly three steps:
- Load: When a user lands on the site, the browser downloads and runs the third-party tracking script.
- Identify: The script reads or writes a cookie to figure out who this user is and where they came from.
- Send: The script fires a request from the browser, passing events like page views, clicks, add-to-cart, and purchases to Meta, Google, or other ad platforms.
This approach used to work well. It's simple, cheap, and marketers can handle most of the setup themselves in GTM.
But as you can probably tell from the description above, the whole logic rests entirely on the user's browser.
If the browser blocks cookie writes, the user has an ad blocker installed, or the script simply fails to fire during page load, tracking data can go missing and create a gap.
That's one of the reasons ad performance has gotten harder to pull off over the past decade. With fewer signals to identify consumers, the algorithm has to work through increasingly convoluted user patterns to sniff out prospects. It sometimes even seems to conjure up a rosy "happiness dashboard" of inflated results, while the actual revenue you're pulling in from ads never quite matches what the backend reports.
As a side note, I know plenty of people aren't fans of Safari and install other browsers on their phones instead. But on iOS, every in-app browser runs on the same WebKit engine as Safari, so whether you open a link inside Facebook, LINE, or any other social app, you're still subject to Apple's ITP policy.
Another road to Mordor
So is there really no way to get accurate user data to advertisers without being at the mercy of browser policy?
There is, my friend. There is.
Frodo couldn't just stroll through the front gate of Mordor, but there was still an old, winding path that led straight to Mount Doom. The tracking world has its own version of that path: Server-to-Server Tracking, or S2S for short, something most affiliate systems, DSPs, and CPA offers have been quietly relying on for years.
The core idea behind S2S isn't complicated:
Don't leave the browser in charge of reporting your most important conversion data. Have the website's own server send the conversion result straight to the tracking platform instead.
Take the S2S postback commonly used in affiliate marketing as an example. The flow looks roughly like this:
A click generates a unique ID: When a user clicks an affiliate's unique link, the affiliate platform generates a globally unique click ID (for example,
?click_id=abc123xyzappended to the URL).The advertiser's server records it: Once the user lands on the advertiser's site, the advertiser's system stores that click ID, whether in a database, a session, a first-party cookie, or tied to the user's account or order data.
The server fires a postback when conversion happens: When the user completes a signup, places an order, makes a payment, or triggers any other designated conversion event, the advertiser's server sends an HTTP request directly to the tracking platform's postback URL, carrying the click ID and order value back to the affiliate platform to log the conversion.
I know all of this might be a bit much for marketers without a technical background, so let me put it more simply.
Traditional pixel tracking works something like this:
The user does something on your site, and their browser makes the phone call to notify the ad platform.
S2S tracking, on the other hand, works more like this:
Once the user actually completes a conversion, your own backend makes the call to notify the ad platform directly.
So the value of S2S isn't some mysterious black magic. It simply moves the reporting of your most important conversions from a front end that's easily disrupted to a back end that's far more stable.
That's also why affiliate systems adopted S2S postbacks so early on: the numbers directly determine how much commission gets paid out to affiliate partners, so both sides care a great deal about data accuracy.
Let's get one thing straight: S2S, CAPI, and GTM Server-Side are not the same thing
Before going further, there's an important distinction to make.
A lot of people lump Server-Side Tracking, S2S postback, Meta CAPI, Google Enhanced Conversions, and GTM Server-Side together as if they were one thing.
They're all related to "sending data from the server side," sure, but they're not identical.
Here's a simple way to think about the difference:
| Type | Main Purpose | Common Use Case |
|---|---|---|
| S2S Postback | Reports the final conversion using a click ID | Affiliate, DSP, CPA offers |
| Conversions API / Enhanced Conversions | Sends events to ad platforms from the website's backend | Meta, Google, TikTok ad optimization |
| GTM Server-Side | Sets up a server-side relay to collect, clean, and distribute events | Multi-platform tracking, data governance, event dedup |
This article focuses on the fundamentals of S2S tracking. The finer implementation details, like GTM Server-Side, cloud architecture, data cleaning, event deduplication, and hybrid tracking, are topics for a more advanced follow-up.
The downside of S2S tracking
If S2S tracking is this simple and effective, does it really have no downsides?
Of course it does. A pure postback is extremely precise, but it has one fatal weakness: it can only capture a single final conversion outcome, like a purchase or a signup. If a visitor never registers or never places an order, the system won't even have a record that they visited your site at all.
That creates two problems.
First, it's hard to analyze the funnel in between.
You know who ultimately bought, but not where everyone else dropped off.
Second, it's hard to do remarketing.
Most remarketing audiences still depend on front-end events, browsing behavior, engagement data, or signals the ad platform can actually identify.
So S2S isn't a silver bullet.
It's great for reinforcing your most critical conversion reporting, but that doesn't mean you can shut off front-end tracking altogether.
The mature approach: moving toward hybrid tracking
The idea behind hybrid tracking is this:
The front end collects signals like browser environment, page interactions, and user behavior; the back end reports more stable, more trustworthy conversion data.
In short, it's a division of labor between front end and back end.
The front end still pulls its weight, since it can see what users do on the page: page views, button clicks, add-to-cart, time on page, form interactions, and so on.
The back end pulls its weight too, since it can confirm what actually happened in business terms: payment completed, order placed, account created, first deposit made.
But hybrid tracking brings a new problem of its own:
The same event can end up being sent twice, once from the front end and once from the back end.
Take a purchase event: if the front-end pixel fires once and the back-end CAPI fires again, and the platform fails to recognize they're the same event, you end up with double counting.
That's where you need deduplication, a mechanism for removing duplicate events.
In practice, that means giving the same event a shared event ID whether it's sent from the front end or the back end, so the ad platform knows:
These two records describe the same thing. Don't count it twice.
This is actually where server-side tracking most often goes wrong.
It's not enough to just "send the data out."
You also have to make sure nothing is duplicated, nothing is dropped, every field is formatted correctly, and every ad platform can actually parse it the way you intend.
This is exactly why I think marketers need to understand the basics of tracking architecture. You need to grasp how the whole system works and where the pitfalls lie. Otherwise you can pour in a huge amount of time, effort, and even money, only to end up worse off than before.
Evaluating an S2S build
Moving your tracking architecture from purely front-end to server-side isn't as simple as installing another plugin or adding one more tag in GTM. It's an infrastructure-level engineering project. Before you commit to a full rollout, there are a few things worth evaluating.
Data accuracy
This is the main reason to adopt S2S in the first place. A properly built system can theoretically recover 15% to 30% of your order data. But without a solid deduplication mechanism, you risk badly polluting the data the ad platform receives, which in turn hurts the algorithm's machine learning. Test the whole thing thoroughly before you ever push it live.
Site load speed
This one is more of a happy side effect. Ad tracking is rarely the only front-end JavaScript on a page: plenty of SaaS tools, like live-chat widgets or EDM systems, also load client-side. Moving that traffic to the server instead takes real weight off the front end, which can improve Core Web Vitals and load speed. Your SEO score and user experience may end up a bit better too.
Team communication overhead
This is probably the piece most companies underestimate.
Unlike a traditional deployment, where marketers can handle almost everything themselves in GTM, S2S fundamentally reshapes the site's entire data transmission structure. That means spending real time explaining requirements and workflows to backend developers who don't usually deal with marketing requests. Marketers need to understand how the whole system works if they're going to bridge that gap with the technical team correctly.
Build and maintenance cost
Server-side tracking isn't free.
Even if you use GTM Server-Side, you'll likely still need to pay for cloud hosting: Google Cloud, Cloud Run, App Engine, or a third-party server-side GTM hosting service.
These are recurring costs you almost certainly didn't have before.
Conclusion: this isn't just an IT problem, it's a decision about building a future-ready data architecture
In a post-cookie era where privacy comes first, server-side tracking does have a real barrier to entry, namely build cost and hosting overhead. But what it buys back is your most valuable asset: real data and accurate ad attribution. Lay this "underground line" before your competitors do, and your ad machine learning will simply outlearn theirs. That will be the deepest moat on the digital marketing battlefield going forward.
It demands deep cross-team collaboration: marketers have to define which funnel stages actually matter, media buyers need to understand how attribution logic is shifting, and engineers have to guarantee the rigor and fail-safes of the data pipeline. Only once all three groups share a common technical language can this kind of data architecture, precise and privacy-safe at the same time, actually deliver its full commercial value.