Conversion tracking used to be simple. A pixel fired on a confirmation page, the ad platform recorded the event, and the numbers in the dashboard matched what actually happened. That version of tracking has been falling apart since 2017, when Apple’s WebKit team introduced Intelligent Tracking Prevention in Safari. ITP blocked third-party cookies by default and capped the lifespan of first-party cookies set through JavaScript to seven days. Every major browser has since followed with similar restrictions. The result is that client-side tracking pixels now miss a growing share of conversions, and the gap between what happened and what got recorded widens each year.
This matters for anyone choosing an advert platform to run campaigns on, because a platform’s conversion tracking capabilities determine how accurately the advertiser can measure return on spend. If the tracking setup undercounts conversions by 20 or 30 percent, every decision made from that data is distorted. Campaigns that are actually profitable look marginal. Placements that convert get cut. Budget shifts away from what works toward what happens to report more completely.
The Client-Side Tracking Problem
Browser-based tracking pixels are JavaScript tags that fire when a user loads a specific page. They depend on the browser cooperating: accepting cookies, executing the script, and sending the data back to the ad platform’s servers. Three things have eroded that cooperation.
First, ad blockers. Depending on the audience, anywhere from 15 to 40 percent of users run software that blocks tracking scripts outright. Technical audiences skew higher.
Second, Apple’s App Tracking Transparency framework. Introduced with iOS 14.5 in April 2021, ATT requires apps to ask users for permission before tracking activity across other apps and websites. Now-defunct Flurry Analytics, which tracked data across more than one million mobile apps, reported at the time that the worldwide opt-in rate among apps displaying the prompt settled at roughly 25 percent. Three out of four iOS users said no. That removes the identifier (IDFA) that connected ad clicks to in-app conversions for the majority of Apple’s mobile audience.
Third, cookie expiration. Even when a pixel fires successfully, the cookie it sets may not last long enough to connect the click to a conversion that happens days later. Safari caps JavaScript-set cookies at seven days. A user who clicks an ad on Monday and converts the following Tuesday may not be attributed.
What Server-Side Tracking Changes
Server-side conversion tracking sends data from the advertiser’s server directly to the ad platform, bypassing the browser entirely. No JavaScript needs to execute. No cookie needs to survive. The conversion event is recorded on the backend and transmitted through an API.
Google’s server-side implementation of this is Enhanced Conversions for Leads (via the Google Ads API), which accepts hashed first-party data (email addresses, phone numbers, physical addresses) and matches it against Google’s user records to attribute conversions that the pixel missed. The setup is not trivial. It requires accepting Google’s customer data terms, configuring either the Google tag or the Google Ads API, and sending properly hashed user identifiers with each conversion event.
The technical bar is higher than just dropping a pixel into a page template. It requires backend development work, or at minimum a tag management platform that supports server-side containers. The tradeoff is a more complete conversion count. For advertisers spending enough that a 20 to 30 percent undercount changes budget decisions, that tradeoff is worth it.
What the Ad Tech Stack Needs to Support
The ad platform needs to accept server-side conversion data, either through a dedicated API or a postback URL. TrafficJunky, for example, provides conversion tracking documentation that covers both pixel-based and server-to-server postback methods, so advertisers can choose based on their technical setup.
The advertiser’s site or app needs to collect first-party identifiers at the point of conversion. An email address entered during checkout or account creation is the most common. Without it, server-side tracking has nothing to match against.
A tag management or server-side container needs to sit between the two, hashing the data before transmission and routing events to the correct endpoints. Google Tag Manager’s server-side option handles this for Google’s ecosystem, but campaigns running across multiple platforms need a solution that sends data to each one.
Finally, the advertiser needs a way to compare what the ad platform reports against what the backend actually recorded. Discrepancies between platform-reported conversions and internal records are normal. Large discrepancies mean the tracking is broken somewhere in the chain. Without a regular reconciliation process, the undercount goes unnoticed and the data stays wrong.
The shift from client-side pixels to server-side tracking is not optional for advertisers who need accurate measurement. The browsers and operating systems have made that decision already. The question is whether the rest of the ad tech stack has caught up.
Amanda Lancaster is a PR manager who works with 1resumewritingservice. She is also known as a content creator. Amanda has been providing resume writing services since 2014.
