iOS 14.5+ broke pixel-only tracking. Here's how to rebuild remarketing accuracy with the Conversion API alongside the pixel.
Most Meta remarketing accounts are quietly broken. Not in a way that produces an error in the dashboard — in a way that produces a slow erosion of match rates, audience sizes, and campaign performance. The cause is the same one that has been compounding since April 2021: pixel-only tracking no longer captures most of the conversion data on the open web.
The fix is not subtle. You need to send the same events twice — once from the browser via the pixel, once from the server via the Conversion API — with a deduplication key that lets Meta reconcile them. Done correctly, you recover 15 to 40 percent of the events the pixel alone is missing, your custom audiences refill, and your ROAS reporting stops drifting away from your actual revenue.
The Apple ATT framework gave iOS users a system-level prompt to deny app-to-app tracking. Most chose to deny. The downstream effect on web tracking was less obvious but more consequential: Safari started aggressively trimming third-party cookies, the lifetime of first-party cookies set by JavaScript dropped to 7 days, and ad blockers got better at noticing the pixel firing. Even users who say yes to tracking now generate weaker, shorter-lived signals.
You can see this in two places. First, the volume of pixel-attributed conversions drops while your back-end revenue stays flat or grows — the classic sign that you're under-counting. Second, your retargeting audience sizes shrink month over month even though your traffic is stable, because you're losing the ability to identify returning users.
The Conversion API (CAPI) is Meta's server-to-server endpoint. Instead of relying on a JavaScript pixel to phone home from the browser, your server sends event data directly to Meta. The server knows more than the browser: it sees every checkout, every signup, every paid event — including the ones the pixel missed because of an ad blocker, a Safari ITP block, or a network failure.
The point is not to replace the pixel. The point is to send both and let Meta deduplicate. The pixel captures the browser-side context (which ad clicked, which page viewed, fbclid, fbp cookie). The CAPI captures the server-side ground truth (the order actually happened, here's the email hash, here's the order value). When Meta sees the same event from both sources with a matching event_id, it counts it once — but it now has confidence in the conversion plus all the rich matching parameters.
The two viable paths are direct integration and a tag-management container. Direct integration means your e-commerce platform or backend posts events to the Meta Graph API endpoint whenever a relevant action happens. Shopify, WooCommerce, and most modern commerce platforms have native CAPI integrations that take an hour to configure. A tag manager container — typically GTM server-side — is more flexible and the right choice for non-commerce setups (lead gen, SaaS signups, multi-step funnels).
Whichever path, the non-negotiables are: send an event_id on both pixel and server events so Meta can deduplicate; hash user data (email, phone, name) with SHA-256 before sending; pass fbp and fbc cookies from the browser through to the server so Meta can stitch sessions; and verify in Events Manager that your match quality score climbs above 7 within two weeks.
The first metric to check is Event Match Quality (EMQ) inside Events Manager. A pixel-only setup typically scores 4 to 6. After CAPI with proper user data hashing, you should see 7 to 9. Below 7 means you're not sending enough identifying parameters — add phone, first name, and last name to the hash payload.
The second is deduplication rate. Meta reports the percentage of events that arrived from both sources and were merged. If your dedup rate is under 60 percent, your event_id is not matching between the pixel and server calls. The most common cause is a timing mismatch — the pixel fires immediately on page load but the server event sends 30 seconds later with a different event_id. Generate the event_id server-side and pass it to the browser before the pixel fires.
The third is your custom audience sizes over the following 60 days. Audiences built on website visitors should grow back to where they were before iOS 14.5 within a quarter. If they don't, your CAPI is firing but not sending enough user data for Meta to match.
CAPI is not a workaround for consent. If a user has declined cookies, you should not be sending their data to Meta from the server either — the legal status is identical. Most properly built CAPI integrations gate server events on the same consent signal as the pixel.
It is also not a replacement for first-party measurement. The point of CAPI is to keep Meta's optimization model accurate so it can find more buyers. Your internal attribution still needs to come from your own analytics layer.
Most accounts we audit have one of two problems: the pixel alone, or the pixel plus a CAPI that's silently sending duplicate events without proper deduplication. The fix is the same either way: get the event_id right, hash the user data properly, and watch the EMQ score climb. Two weeks of clean implementation gets you back to where you were before ATT. The work is mostly engineering, not strategy.
Most Meta remarketing accounts are quietly broken. Not in a way that produces an error in the dashboard — in a way that produces a slow erosion of match rates, audience sizes, and campaign performance. The cause is the same one that has been compounding since April 2021: pixel-only tracking no longer captures most of the conversion data on the open web.
The fix is not subtle. You need to send the same events twice — once from the browser via the pixel, once from the server via the Conversion API — with a deduplication key that lets Meta reconcile them. Done correctly, you recover 15 to 40 percent of the events the pixel alone is missing, your custom audiences refill, and your ROAS reporting stops drifting away from your actual revenue.
The Apple ATT framework gave iOS users a system-level prompt to deny app-to-app tracking. Most chose to deny. The downstream effect on web tracking was less obvious but more consequential: Safari started aggressively trimming third-party cookies, the lifetime of first-party cookies set by JavaScript dropped to 7 days, and ad blockers got better at noticing the pixel firing. Even users who say yes to tracking now generate weaker, shorter-lived signals.
You can see this in two places. First, the volume of pixel-attributed conversions drops while your back-end revenue stays flat or grows — the classic sign that you're under-counting. Second, your retargeting audience sizes shrink month over month even though your traffic is stable, because you're losing the ability to identify returning users.
The Conversion API (CAPI) is Meta's server-to-server endpoint. Instead of relying on a JavaScript pixel to phone home from the browser, your server sends event data directly to Meta. The server knows more than the browser: it sees every checkout, every signup, every paid event — including the ones the pixel missed because of an ad blocker, a Safari ITP block, or a network failure.
The point is not to replace the pixel. The point is to send both and let Meta deduplicate. The pixel captures the browser-side context (which ad clicked, which page viewed, fbclid, fbp cookie). The CAPI captures the server-side ground truth (the order actually happened, here's the email hash, here's the order value). When Meta sees the same event from both sources with a matching event_id, it counts it once — but it now has confidence in the conversion plus all the rich matching parameters.
The two viable paths are direct integration and a tag-management container. Direct integration means your e-commerce platform or backend posts events to the Meta Graph API endpoint whenever a relevant action happens. Shopify, WooCommerce, and most modern commerce platforms have native CAPI integrations that take an hour to configure. A tag manager container — typically GTM server-side — is more flexible and the right choice for non-commerce setups (lead gen, SaaS signups, multi-step funnels).
Whichever path, the non-negotiables are: send an event_id on both pixel and server events so Meta can deduplicate; hash user data (email, phone, name) with SHA-256 before sending; pass fbp and fbc cookies from the browser through to the server so Meta can stitch sessions; and verify in Events Manager that your match quality score climbs above 7 within two weeks.
The first metric to check is Event Match Quality (EMQ) inside Events Manager. A pixel-only setup typically scores 4 to 6. After CAPI with proper user data hashing, you should see 7 to 9. Below 7 means you're not sending enough identifying parameters — add phone, first name, and last name to the hash payload.
The second is deduplication rate. Meta reports the percentage of events that arrived from both sources and were merged. If your dedup rate is under 60 percent, your event_id is not matching between the pixel and server calls. The most common cause is a timing mismatch — the pixel fires immediately on page load but the server event sends 30 seconds later with a different event_id. Generate the event_id server-side and pass it to the browser before the pixel fires.
The third is your custom audience sizes over the following 60 days. Audiences built on website visitors should grow back to where they were before iOS 14.5 within a quarter. If they don't, your CAPI is firing but not sending enough user data for Meta to match.
CAPI is not a workaround for consent. If a user has declined cookies, you should not be sending their data to Meta from the server either — the legal status is identical. Most properly built CAPI integrations gate server events on the same consent signal as the pixel.
It is also not a replacement for first-party measurement. The point of CAPI is to keep Meta's optimization model accurate so it can find more buyers. Your internal attribution still needs to come from your own analytics layer.
Most accounts we audit have one of two problems: the pixel alone, or the pixel plus a CAPI that's silently sending duplicate events without proper deduplication. The fix is the same either way: get the event_id right, hash the user data properly, and watch the EMQ score climb. Two weeks of clean implementation gets you back to where you were before ATT. The work is mostly engineering, not strategy.
Schedule a strategy call. We'll look at your marketing and outline clear next steps within 30 minutes.
Schedule Your Strategy Call →