iOS 14 and the Meta pixel: what actually broke (and what to do now)

When Apple shipped App Tracking Transparency (ATT) with iOS 14.5, Meta's advertising machine took a visible hit. Reported conversions dropped, audiences shrank, and return on ad spend looked worse overnight. Years later, plenty of PrestaShop merchants are still running the same pixel-only setup that ATT quietly broke — and still wondering why Meta under-reports their sales.

The short version: the browser-based pixel lost the signal it relied on, and the fix is to send conversions from your server instead. But to fix it confidently, it helps to understand exactly what changed and why the old approach can never fully recover on its own. Here is what happened in detail.

What App Tracking Transparency actually did

ATT forced apps to ask permission before tracking users across other companies' apps and websites. The famous “Ask App Not to Track” prompt meant a large majority of users opted out — by most accounts, the overwhelming majority. For Meta, that cut off a stream of cross-app signal it used to attribute conversions and build audiences.

Crucially, ATT did not only affect in-app behaviour. It was part of a broader move by Apple to limit cross-site tracking in Safari and iOS as well, compounding the cookie restrictions already imposed by Intelligent Tracking Prevention.

The combined effect was that Meta could no longer reliably follow a person from seeing an ad to completing a purchase on your store. The conversions still happened; Meta just lost the thread connecting them to the ads that caused them.

Why the pixel started missing sales

The Meta pixel is client-side JavaScript. It depends on browser cookies — chiefly _fbp (a first-party browser identifier Meta sets) and _fbc (which stores the click ID from the fbclid parameter in the ad URL) — to tie a shopper back to the ad they clicked.

When those cookies are blocked, shortened, or never set, the pixel still fires but cannot match the conversion to a click. The sale happened; Meta just cannot prove it came from Meta.

Layer on the ad-blockers that cancel the pixel request entirely — often 30% or more of an audience — and you get the under-reporting merchants describe: real revenue in the bank, far less of it credited in Ads Manager. The worst part is that the loss is biased toward exactly the privacy-conscious, iOS-heavy audiences that many stores most want to reach.

The Conversions API restores the signal

Meta's answer is the Conversions API (CAPI) — a server-to-server channel that sends conversion events directly from your backend to Meta, bypassing the browser entirely. Because it runs server-side, it is immune to ad-blockers, closed tabs, and most cookie restrictions.

With Meta CAPI in place, a purchase recorded by PrestaShop is sent to Meta with whatever match signals are available — hashed email, hashed phone, and a server-reconstructed _fbc built from the fbclid in the landing URL when the browser cookie is missing.

That _fbc reconstruction is a small detail with outsized impact: it recovers attribution that Apple's cookie restrictions would otherwise destroy, by capturing the click identifier at the moment of the landing rather than relying on a cookie that may never survive to checkout.

Deduplication: pixel and CAPI without double counting

You do not throw the pixel away. The strongest setup runs the pixel and CAPI together: the pixel captures rich browser behaviour and on-site context, while CAPI guarantees the conversion itself is recorded. The risk is obvious — if both report the same sale, Meta could count it twice and inflate your results.

The solution is event deduplication. Both the pixel and the server send the same event_id for a given action, and Meta collapses them into one event, preferring whichever arrived with better data. Done right, you get the coverage of server-side with the richness of client-side and no inflation.

Getting the event_id identical across both channels is the part that trips up most do-it-yourself setups, because it has to be deterministic and generated the same way in the browser and on the server. Our how it works page shows how this is wired on PrestaShop.

What this means for audiences and bidding

Restoring conversion signal is not only about cleaner reports. Meta's delivery and optimisation systems learn from the conversions you send back. When the pixel was silently dropping a third or more of your sales, Meta was optimising against a distorted picture — underbidding on audiences that were quietly converting and misjudging which creatives worked.

Feeding Meta complete, server-side conversion data with strong match signals lets its optimisation see the true value of each click and audience. Many merchants find that retargeting and lookalike audiences perform noticeably better once CAPI is sending reliable data, simply because the inputs are no longer broken.

Better signal in means better delivery out — the same principle that applies across every modern ad platform. It is worth restating because it reframes CAPI from a compliance chore into a growth lever: the merchants who treat conversion data as a first-class asset consistently get more out of the same ad budget than those who let the pixel quietly decay.

What PrestaShop merchants should do now

Start by accepting that a pixel-only setup is leaving conversions — and therefore ad performance — on the table. Then layer CAPI on top, sharing one event_id per event for clean deduplication, and make sure first-party data such as email and phone is normalised and SHA-256 hashed before it leaves your server.

PrestaSignal handles all of this through a self-hosted sGTM container, so the pixel and CAPI stay in sync without you touching code on the confirmation page. The CAPI access token stays server-side and never reaches the browser, and PII is hashed before transmission.

If Meta keeps under-reporting your sales, book a teardown and we will measure the gap on your store and show you exactly what CAPI would recover.