iOS 14.5 attribution: what ATT broke, and how to recover tracking without violating it

When Apple shipped iOS 14.5 in April 2021 with App Tracking Transparency (ATT), Meta lost the ability to track 60-80% of iOS users across apps. For Shopify and DTC stores running Meta Ads, this showed up as a sudden 30-40% drop in reported conversions — even though actual sales were unchanged.

Five years later, most stores are still under-measuring iOS conversions and over-spending on Meta to compensate. The fix isn't bypassing ATT; it's recovering the signal Apple actually still allows.

What ATT actually broke

ATT didn't disable tracking. It changed the default consent state and added a prompt. The prompt — "Allow [App] to track your activity across other companies' apps and websites?" — gets a "Yes" rate of around 25% across most e-commerce app traffic. The other 75% deny tracking.

For users who deny:

• Meta's pixel-based attribution doesn't function (no IDFA available).
• The conversion is still made on your site; you still ship the order and bank the revenue.
• The conversion is invisible in Meta Ads Manager. The ad that drove it gets zero credit.

The net effect: Meta sees fewer conversions than actually happened, so the algorithm can't optimize as effectively, and your reported ROAS looks worse than the actual ROAS by 30-40%.

What's still allowed under ATT

Three signals are still available without violating ATT:

1. First-party events — events on your own domain, sent server-side from your backend to Meta's Conversions API (CAPI). These don't require ATT consent because they're not "cross-app tracking" in Apple's sense. 2. Modeled conversions — Meta's machine learning fills in conversions for ATT-denied users based on patterns in consented users. Less accurate, but better than zero. 3. Aggregated Event Measurement (AEM) — Apple's own protocol that returns aggregated, time-delayed conversion data for ATT-denied users. Up to 8 events per domain, prioritized.

Stores that wire up all three recover 80-90% of the pre-iOS-14 signal. Stores that wire up none stay at 60-70% of true conversion volume in Meta's reporting.

The CAPI setup that actually moves the needle

The biggest lift is sending complete CAPI events with proper identity matching:

• em** (hashed email) on every purchase event.
• ph** (hashed phone) when available.
• fbc** (Facebook click ID) from the URL parameter fbclid, captured at landing and persisted in a first-party cookie.
• fbp** (Facebook browser ID) from the _fbp cookie.
• client_ip_address and client_user_agent** from the request.
• event_id** matching the corresponding pixel event for deduplication.

Stores that send only em see CAPI match rates of 40-60%. Stores that send all six identifiers see match rates of 85-95%. That's the difference between Meta knowing the conversion happened versus modeling it.

The deduplication trap

The most common implementation bug we see at Omesta: stores send both pixel events and CAPI events without proper deduplication, and Meta counts both. Reported conversions inflate. Reported ROAS looks great. Real ROAS hasn't changed.

The fix is correct event_id matching between the pixel event and the CAPI event. Same event_id, same event, Meta counts once. Different event_id or missing field, Meta counts both, and your numbers lie.

Omesta's leak scan catches this. We compare your pixel event volume to your CAPI event volume and flag any window where the difference doesn't match the expected ATT-denial rate. If your CAPI events look suspiciously low, you're losing iOS attribution. If they look suspiciously high, you're double-counting.

AEM priority ordering

Apple's Aggregated Event Measurement caps you at 8 prioritized events per domain. Most stores leave Meta's default priority in place — which puts page views and add-to-carts in the top 8 and pushes purchase priority lower than it should be.

The correct priority for a typical Shopify store:

1. Purchase 2. Subscribe (if you have subscriptions) 3. Initiate Checkout 4. Add to Cart 5. Add Payment Info 6. View Content 7. Search 8. Page View

The point: in AEM, only the highest-priority event per visitor gets reported. If a visitor sees an ad, adds to cart, and purchases, you want the Purchase event reported, not the Add to Cart.

Modeled conversions: useful, not trustworthy

Meta fills in unreported iOS conversions with a machine-learning model that estimates "how many conversions probably happened for users we couldn't measure." This shows up in Ads Manager as part of your reported number.

These are useful for trend-spotting but unreliable for individual-campaign optimization. The model can be off by 20-30% for any given campaign in any given week. Don't tune budgets based on modeled-only data; tune based on CAPI-matched data and use modeled as directional confirmation.

The recovery checklist

To recover your iOS attribution:

1. Wire up CAPI server-side with all six identity fields. 2. Set event_id for every event and dedupe properly. 3. Re-order AEM priorities to put Purchase first. 4. Verify CAPI match rate in Events Manager > Data Sources > Settings > Diagnostics. Target: 80%+. 5. Compare pixel + CAPI volume to actual orders weekly. Any persistent gap is a leak.

Omesta's attribution-holes detection scans for each of these and gives you the specific fix per leak. Most stores find 1-3 attribution leaks costing $400-$1,800/month in misallocated ad spend.

The bigger point

Stores that have given up on iOS attribution are leaving money in two places: under-attributing real conversions, and over-spending on Meta because the algorithm can't optimize against signal it doesn't see. Recovering even 70% of the pre-iOS-14 signal usually moves true ROAS 0.4-0.8x.

See the leak scan or browse all leak patterns.