iOS Privacy Killed My Tracking — How Do I Fix It With Server-Side and CAPI?

A browser pixel works by running code in the customer's browser that reports what they did back to the ad platform. That mechanism depends on the browser cooperating, and increasingly it does not. Privacy features, tracking prevention and ad blockers each remove a share of those reports.

The result is that a growing proportion of real purchases never get reported. Your sales did not fall; the reporting of them did, and the two are easy to confuse when you are looking at a dashboard rather than at your bank account.

This has a second and more expensive effect that most businesses do not connect. Ad platforms optimise by learning which people convert, and if a share of conversions never reaches them, they are learning from incomplete data. Your campaigns get worse, not just your reports, and the cost shows up as a rising cost per purchase that no setting explains.

The gap is not small and it varies by audience and device mix. If your reported conversions are consistently below the orders in your back office, you are seeing this, and the difference between those two numbers is the size of the problem.

Instead of relying on the customer's browser to report a purchase, your store's own server sends the event directly to the ad platform. The order happened on your system, your system knows it happened, and it tells Meta or TikTok or Google directly rather than hoping a browser script survived.

This is what Meta calls the Conversions API, and the other platforms have equivalents. The principle is the same across all of them: move the reporting from the customer's device to your infrastructure, where privacy features and ad blockers cannot interfere.

The recovery is meaningful rather than total. You will not get back every lost conversion, but you will recover a substantial share, and for a Kuwait store spending seriously on ads that recovery is worth more than the setup cost by a wide margin.

The second benefit is data quality. Server-side events can carry more reliable matching information, which improves the platform's ability to attribute a conversion to the right person and therefore to optimise properly. Better data going in produces better targeting coming out.

On a platform with native integrations this is largely a configuration task rather than a development one. You connect your ad accounts through the platform's official channel and server-side events are handled for you, which removes most of the ways this goes wrong on a custom build.

On a custom-built store it is a development project. Your server needs to send correctly formatted events with the right parameters to each platform's endpoint, handle authentication, and deduplicate against any browser events still firing. This is real work and it needs someone who has done it before.

Deduplication is the part that most commonly goes wrong. If both the browser pixel and the server send the same purchase, and they are not correctly matched by a shared event ID, the platform counts it twice. Your reported performance doubles, you scale spend against inflated numbers, and you lose money at a rate your dashboard actively conceals.

So run both, correctly deduplicated, rather than replacing one with the other. Browser events still capture things the server does not see, and the combination with proper deduplication is more complete than either alone.

Place a real order through your own store and watch it arrive. The platform testing tools show incoming events and their source, so you should see the purchase arriving from the server and, if browser tracking is also active, see the two correctly matched rather than counted separately.

Then compare your reported conversions against your actual orders for a full month. The two will never match exactly, but the gap should narrow noticeably after server-side tracking is live. If it does not, something is not configured correctly and the setup has cost you money without returning anything.

Watch for the opposite problem too. If reported conversions suddenly exceed your actual order count, you have a deduplication failure, and this is more dangerous than under-reporting because it causes you to increase spend on a false signal.

And check the event quality score or match quality indicator the platforms provide. This tells you how well the information you are sending allows the platform to identify the person, and improving it is usually a matter of sending more of the fields the platform accepts rather than a technical rebuild.

If you are spending meaningfully on paid advertising, yes, and the case gets stronger the more you spend. The recovery applies to every campaign you run, and the improvement in optimisation compounds over time as the platform learns from better data.

If you spend very little on ads and most of your business comes from organic social and word of mouth, this is a lower priority than fixing your product pages, your reply speed or your average order value. Server-side tracking improves the efficiency of paid acquisition and does nothing for a business that is not doing much of it.

The cost depends entirely on your platform. On a store with native integrations it is a configuration step and effectively free. On a custom build it is a development project with an ongoing maintenance element, and that cost needs to be weighed against your actual ad spend.

And the alternative to consider first is whether your basic tracking is even working. A meaningful share of Kuwait accounts we look at have a broken or duplicated standard pixel, and fixing that costs nothing and recovers more than server-side tracking would have added on top of a broken foundation. You can start a free Shopify trial and get server-side conversion tracking as a supported integration rather than a development project.