Server-side tracking, explained without the jargon

For years, conversion tracking worked one way: a JavaScript pixel fired in the visitor's browser when they completed a purchase, and told the ad platform. Simple and, for a while, reliable.

Three things broke it. Ad blockers now block tracking scripts for a substantial share of users. Safari's Intelligent Tracking Prevention caps client-side cookie lifetime to seven days, and in some cases 24 hours. And Apple's App Tracking Transparency prompt meant most iOS users declined cross-app tracking outright.

The result is that browser pixels typically capture 60–80% of actual conversions. Platforms fill the gap with modelled estimates, which is why reported numbers can look stable while the underlying signal degrades.

Instead of relying on the visitor's browser to report the conversion, your own server does it. When an order completes, your backend makes an API call directly to Meta, Google, or TikTok saying: this conversion happened, here is the hashed customer information, here is the value.

Ad blockers can't block it, because it isn't happening in the browser. ITP doesn't apply, because there's no third-party cookie involved. iOS privacy settings don't apply, because there's no cross-app tracking occurring.

The customer data you send — email, phone, name — is hashed before transmission, so the platform receives an irreversible fingerprint it can match against its own hashed records rather than raw personal data.

Most implementations run browser and server tracking simultaneously, which is correct — but it creates an obvious risk of counting every conversion twice.

The fix is an event_id: a unique identifier generated per conversion and sent identically from both the browser pixel and the server call. When the platform receives two events with the same event_id, it keeps one.

This is the most common implementation failure we find in audits. Teams implement CAPI, see conversions jump 40%, and celebrate — when in fact they've started double-counting and their reported CPA is now fiction in the other direction. Always verify deduplication in the platform's event diagnostics before trusting any number.

There are three routes, with different tradeoffs.

The largest gains from this work usually come not from recovering lost events but from changing which event you send.

Most accounts optimize toward the easiest event to fire — a form submission, an add-to-cart, an application start. Platforms are extremely good at finding people who do those things, which is exactly the problem when those actions don't correlate with revenue.

Server-side tracking makes it practical to send the event that actually matters, including ones that happen days later. A fintech client switched from application starts to funded accounts and found three campaigns consuming 34% of budget were producing funded accounts at four times target cost — invisible for eighteen months under the previous setup.

Check the platform's event match quality score — Meta reports this directly, and above 6.0 is healthy. Low scores usually mean you're sending too few customer parameters.

Compare platform-reported conversions against your actual order count over a fixed window. They won't match exactly and shouldn't, but the gap should be explicable and stable rather than drifting.

Watch for duplication in the platform's event diagnostics for at least two weeks after launch. Deduplication failures often appear intermittently rather than constantly, so a single clean day proves nothing.