If you've been running ads on Meta or Google for a couple of years, you've probably noticed something odd: the number of purchases you see in your own store doesn't match the number of purchases the ad platform reports to you. Almost always the platform's side is missing information, never has extra. This isn't a one-off glitch, it's a trend that's been accelerating for years, and it has a name: tracking blocking.
Safari (the browser on iPhone and Mac) has blocked much third-party cookie tracking by default for a while now. Plenty of Chrome and Firefox users install privacy extensions or simply reject cookies in the consent banner. And mobile apps, especially since Apple introduced its tracking permission system, require explicit consent that a large share of people deny without a second thought. The result is that the traditional pixel, that little snippet of code installed on your site that tells Meta or Google whenever someone buys, sees less and less.
What the Conversions API actually is
The Conversions API (CAPI on Meta, or "enhanced conversions" in Google's variants) is an alternative and complementary route to the pixel: instead of the user's browser telling Meta what happened, it's your own server (your website's or online store's) that sends that information directly, server to server, bypassing the browser and without depending on it allowing cookies. It's harder to block because it doesn't live on the ground where blockers operate.
The simplest way to picture it: the pixel is like a witness watching the sale from outside the shop, and more and more curtains keep blocking its view. The Conversions API is like the shop assistant themselves (your server, which knows for certain the sale happened because it processed it) calling directly to report it. Nobody can block their view because they're not watching from outside.
Why this matters for the money you spend on ads
When the ad system sees fewer conversions than actually happen, two things go wrong. The first is that it underrates your campaigns' real performance: if you actually generate 100 sales a month but the platform only "sees" 70, your reported cost per sale looks higher than it really is, and you might end up cutting budget from something that's working better than it appears. The second, more important in the medium term, is that the optimisation algorithm (the one deciding who to show the ad to) learns from less and worse data, so it optimises worse: it looks for people similar to those 70 conversions it did see, not the real 100, and that bias carries forward.
In tests we've run with ecommerce clients, turning on the Conversions API alongside the pixel (not replacing it, but as a complement, which is how Meta recommends using it) has recovered between 15% and 35% of conversions that previously went unseen, depending heavily on the type of audience (more people on iPhone tends to mean a bigger improvement). That extra data isn't just a nicer number in the report: it directly improves how the algorithm decides to spend your budget.
How it's implemented in practice
For businesses with stores on platforms like Shopify, WooCommerce or PrestaShop, implementation is usually reasonably straightforward: official integrations or plugins exist that connect your store to Meta's Conversions API or Google Ads' enhanced conversions without touching code by hand. For custom-built sites (as is often the case for businesses with in-house development in PHP or other languages), it requires a developer to implement event sending from the server, which is a one-off configuration job, not ongoing maintenance.
One important nuance: you need to avoid duplicating conversions when turning on both routes (pixel and server API) without coordinating them. Meta and Google have deduplication systems using a unique event identifier that must be sent consistently from both sides; skip that step and you risk counting each sale twice, which skews the metrics in the opposite direction (everything looks better than it actually is).
The other side: what data gets sent and what to watch out for
The Conversions API can send customer personal data (email, phone, name) in encrypted (hashed) form so the platform can recognise that person without the data travelling in plain text. This requires having the consent piece properly sorted: your site must clearly inform users what data is collected and why, and sending should only be activated once the user has given consent through the cookie banner, in line with GDPR. It isn't optional, it's a legal requirement, and platforms can suspend accounts that don't respect it.
Cases where the improvement is especially noticeable
The impact is bigger in sectors with a longer buying cycle (where the user visits several times before buying and is more likely to reject cookies at some point), in businesses with a lot of traffic from iPhone and Safari, and in any case where checkout happens outside the main domain (external payment gateways, for example), a scenario where the traditional pixel loses the trail very easily.
A case with numbers: the gap that appeared when comparing both systems
An online sportswear store had noticed for a while that the number of purchases it saw in its own management system didn't match the number Meta reported in its ads dashboard, with a gap of between 20% and 30% depending on the month. Before turning on the Conversions API, they ran the exercise of comparing, over one week, every purchase logged in their system against what showed up in Meta, and found that almost all the purchases "invisible" to the pixel came from iPhone users on Safari, exactly the pattern you'd expect given that browser's third-party cookie blocking.
After implementing the Conversions API alongside the existing pixel, with deduplication correctly configured, the gap between real purchases and those reported by Meta shrank to under 8% over the following two months. The most valuable side effect wasn't just a more accurate report, it was that the cost per purchase Meta reported dropped noticeably (without real spend having changed), because the system was now splitting that same spend across a number of conversions much closer to the real figure, which also led the algorithm to start optimising better from that fuller data.
What to check if you turn on the Conversions API and see no improvement
If, after implementation, the gap between real and reported conversions doesn't improve, there are three common points worth checking. The first is deduplication: if the event identifier isn't sent identically from the pixel and the server, Meta may fail to recognise it as the same event, and in the worst case may end up duplicating instead of complementing. The second is the quality of the data sent: if the customer's email or phone isn't captured consistently during checkout, the API has less to match the user with. The third is the time window between the browser event and the server event: if there's too much delay between the two (for example, because of a slow order confirmation process), Meta may process them as independent events instead of complementary ones.
What happens to customer privacy in all of this
It's reasonable for a business owner to wonder whether all this means handling personal data more aggressively. The correct answer, when properly implemented, is no: the data sent (email, phone) is transformed through a cryptographic function called hashing before it leaves your server, so that neither Meta nor Google ever receives the data in plain text, only an encrypted version that can only be matched against an identical hash generated from the same original data. It's the same principle secure password systems use: a match can be verified without ever storing or transmitting the actual data.
This doesn't exempt you from the rest of GDPR's obligations: the website must clearly inform users what's collected and why in its privacy policy, and sending this data must depend on user consent through the cookie banner, just as with the traditional pixel. The technical difference is in how the data travels, not in whether prior user consent is needed, which remains mandatory in both cases.
Why this technical investment pays off even for small businesses
This kind of technical improvement can seem reserved for businesses with in-house development teams, but the relationship between implementation effort and benefit obtained is usually especially favourable precisely for small businesses with a tight advertising budget: when every euro of budget counts, recovering between 15% and 35% of conversion data that was previously being lost has a proportionally bigger impact than on an account with a budget so large it can already absorb some inefficiency without noticing much.
Simplified step-by-step of a typical implementation
To give a concrete idea of the process, here's how an implementation usually unfolds on a store using a standard platform like Shopify or WooCommerce. First, the official Conversions API integration is switched on from Meta's events panel, which on most of these platforms already comes with a guided setup wizard. Second, the unique event identifier is configured, checking in Meta's own panel that pixel and server conversions are being properly deduplicated (Meta shows a match quality indicator that helps verify this). Third, over one or two weeks, the comparison between conversions logged in the store's management system and those Meta reports is reviewed, adjusting any significant discrepancy before considering the implementation complete.
For businesses with custom development, the process is mechanically similar but requires a developer to manually implement event sending from the server at the exact moment of each conversion (purchase, sign-up, contact), using the technical documentation Meta and Google Ads make available to any developer. Implementation time in these cases usually ranges from a few hours for a store on a standard platform to several days for a complex build with multiple distinct conversion points.
Frequently asked questions
Do I need to remove the pixel if I turn on the Conversions API?
No, quite the opposite: it's recommended to keep both active at the same time. They complement each other and, with deduplication properly set up, each event gets counted only once, taking the data from whichever channel captures it first.
Does this fully solve the problem or just mitigate it?
It mitigates it noticeably, but doesn't eliminate it 100%. No system recovers 100% of the conversions lost to tracking blocking; what it achieves is closing much of that gap and giving the algorithm considerably more data to work with.
Is implementing the Conversions API expensive?
It depends on the platform. On stores with official plugins (Shopify, WooCommerce) it's usually a matter of a few hours of setup. On custom builds, the cost depends on the site's complexity, but it's usually a one-off investment, not a recurring expense.
Does this affect Google Ads too, or is it just a Meta thing?
It affects both. Google has its own equivalent system (enhanced conversion import, with hashed customer data) pursuing the same goal for the same reason: browser cookie blocking keeps increasing.
Can I do it myself without a developer?
On platforms with official integration (Shopify has its own, ready to enable in a few clicks, for example), yes. On a custom-built site, you'll almost always need whoever maintains the server-side code to step in.
What if a customer rejects cookies? Does the API ignore that and send data anyway?
It shouldn't. A properly configured system respects the user's decision: if they reject cookies or tracking, neither the pixel nor the Conversions API should send their data. The API solves the technical problem of unintentional blocking (browsers filtering out third-party cookies), it doesn't give you a free pass to bypass consent a user has explicitly denied.