A client was told that server side tracking would restore their conversion data to pre-privacy-update levels. They spent about 14,000 dollars implementing it and recovered a meaningful but far smaller share of what they had been promised.
The implementation was competent. The promise was nonsense. Server side tracking is genuinely valuable and it does not do what most vendors imply it does, and the gap between those two facts is where a lot of money gets wasted.
Here is the version I give clients before they decide.
What actually happens today
Right now, when someone lands on your site, their browser loads a container that loads eight or twelve separate vendor scripts. Each script independently collects data and sends it directly from the visitor's browser to that vendor's servers.
Everything about that arrangement is fragile. Ad blockers block the requests. Browsers restrict the storage those scripts rely on. Network conditions drop requests. The scripts compete for the main thread and slow the page. And you have no visibility into or control over what each vendor collects.
What server side changes
You add one intermediary. The browser sends data to a collection endpoint on a domain you control. That endpoint runs a container on your own server infrastructure, and that container distributes the data to the vendors.
Four consequences follow.
The browser makes one request instead of twelve. Less JavaScript on the device, fewer connections, better interaction responsiveness. This is a real and underrated benefit, and it plugs directly into the performance work in Core Web Vitals in practice.
Requests go to your own domain, which is far less likely to be blocked than a request to a known ad tech hostname.
You control the payload. You can decide exactly what each vendor receives, strip fields, hash identifiers, and enforce consent server side rather than trusting each vendor's own tooling.
Cookies can be set server side, which on some browsers extends their usable lifetime meaningfully compared to a cookie written by JavaScript.
What it does not do
It does not restore cross site tracking. If the ecosystem no longer allows following someone from a publisher to your site, moving your collection to a server changes nothing about that.
It does not fix consent. If a user declines, you must not track them, and doing so server side because it is harder to detect is a compliance problem and an ethical one. Server side gives you better enforcement of consent, not an exemption from it.
It does not make your attribution correct. It improves input quality into a system that is still fundamentally estimating. The realistic expectations are in marketing attribution after cookies.
It does not eliminate client side code entirely. Something still has to run in the browser to observe the interaction and send it onward.
The realistic recovery
The honest range from what I have seen and what practitioners report: somewhere in the region of 10 to 30 percent more observed conversions, heavily dependent on your audience's blocker usage, browser mix, and how bad your prior setup was.
A B2B audience of technical buyers on privacy focused browsers sits at the high end. A general consumer audience on default mobile browsers sits at the low end.
If a vendor quotes you a specific recovery percentage before looking at your traffic composition, that number is marketing.
The costs nobody mentions in the pitch
Infrastructure. You are running a server that receives every event. At low volume this is cheap. At high volume it is not, and it scales with traffic, not revenue. Budget for it as an ongoing line item.
A person who understands it. This is the real cost. Server side containers fail silently. A misconfigured transformation can drop a conversion type for six weeks and nothing in the interface will look wrong. You need someone who checks, or you have traded a visible problem for an invisible one.
Migration risk. The window where both systems run in parallel and disagree is confusing and requires patience. Budget three to six weeks of parallel running before you cut over.
Testing overhead. Every new campaign type, every new conversion event, now involves a step that used to be automatic.
Who should actually do this
Do it if you spend meaningfully on paid media where conversion data quality directly changes bidding, if your audience skews technical or privacy conscious, if you operate under strict privacy requirements and need control over the payload, or if third party scripts are demonstrably hurting your page performance.
Do not do it if your paid spend is small, if nobody on your team or your agency can maintain it, or if your current tracking is broken for ordinary reasons. Fix the ordinary reasons first, because I have audited plenty of accounts where the conversion tracking problem was a missing tag on the thank you page, not a privacy restriction.
The order I implement in
Fix the existing setup first. Verify every conversion fires, on every path, on mobile. Standardize your campaign tagging with a UTM builder so you have consistent inputs. Most of the perceived data problem is resolved here at a fraction of the cost.
Define the events that matter. Not everything. The four to eight events that represent real business outcomes. Server side implementations bloat when teams port over every legacy tag, most of which nobody has looked at in two years.
Set up the endpoint on your own subdomain. Same site as your main domain, not a vendor hostname. This is the part that determines whether the blocking benefit materializes.
Run parallel for a month. Compare event counts daily. Expect discrepancies and investigate them, because that investigation is where you learn what your data actually contains.
Cut over, then monitor deliberately. Set an alert on daily event volume by type. Silent failure is the primary risk of this architecture and a volume alert catches nearly all of it.
The privacy framing that matters
There is a version of this conversation that treats server side tagging as a way to keep tracking people who asked not to be tracked. I want to be direct: that is a bad idea legally, and it is a worse idea strategically.
The durable advantage is not squeezing more out of third party data. It is building first party relationships where people give you information because they get something for it. That is the argument in first party data strategy, and it is the reason I push clients toward email lists and owned audiences rather than more elaborate tracking.
Server side infrastructure is a legitimate tool for collecting the data you are entitled to, cleanly and efficiently. It is not a workaround, and any consultant selling it as one is handing you a liability with a monthly hosting bill attached.
Audit before you architect
If server side tracking is on your roadmap, do this first: spend one afternoon verifying that your current conversion tracking works on every path, on a real mobile device, with a real test conversion, for every event you care about.
In my experience roughly half of the teams considering a server side migration discover something broken in that afternoon that explains most of their data gap. Fixing it costs nothing. Then, if the gap remains and your paid spend justifies it, build the server side layer knowing exactly what problem it is solving. That sequence has saved more than one client a five figure project they did not need.