Why Meta Conversions Dropped After iOS 14 (AEM, Domain Verification, 8-Event Limit)

"Ever since the iOS 14 update, our Meta (Facebook) ad conversions have visibly dropped." This is still one of the most common complaints in ad operations. You changed nothing about your ad setup or your pixel implementation — yet the conversion count in Events Manager and in your campaigns fell. Almost always, the cause is a misunderstanding of ATT (App Tracking Transparency), introduced in iOS 14.5, and the AEM (Aggregated Event Measurement) mechanism Meta introduced to cope with it.

Do any of these sound familiar?

• Meta conversions clearly dropped around the time iOS 14.5 became widely adopted
• Meta's conversion count is lower than your GA4 or backend numbers
• Events Manager shows a notice or warning that you can configure only up to 8 events
• Some conversions are reported as "modeled" (estimated)
• Conversions show up in reports with a significant delay after they happen

This guide explains how iOS 14 causes Meta conversions to drop or go missing, the relationship between ATT, AEM, the 8-event limit, and domain verification, how to verify — in your real production environment — exactly how you're being tracked right now, and how to mitigate with CAPI.

First principle: the iOS 14 change is a structural spec change, not a malfunction

The biggest reason this goes wrong is treating the conversion drop as a malfunction — "the pixel broke" or "we botched the implementation." In reality, most of the decline since iOS 14.5 stems from a structural spec change made for privacy. It isn't the kind of thing where fixing something restores the old numbers.

Mistake this, and you fall into the swamp of endlessly tweaking settings while "the numbers never come back." So let's walk through what actually changed, in order.

ATT (App Tracking Transparency): more opt-outs

From iOS 14.5, Apple introduced ATT (App Tracking Transparency). Before an app can track a user across other apps and sites, it must show a permission dialog: "Allow this app to track you?"

The key point: many users tap "Ask App Not to Track." When a user who came to your site from inside the Facebook/Instagram app has declined tracking, Meta can no longer tie that user's behavior together the way it used to.

As a result, Meta can no longer assume the precise, person-level measurement it relied on before. To compensate, Meta introduced AEM, covered next.

ATT opt-in rates: how much signal is actually lost

How large is the gap? Industry benchmarks give a concrete picture. As of mid-2025, the global ATT opt-in rate sits around 25–35 % — meaning roughly 65–75 % of iOS users decline tracking. Rates vary by app category (sports apps see opt-in as high as 50 %; many utility and social apps remain under 20 %), but the aggregate effect is the same: Meta loses person-level signal for the majority of iOS traffic.

For advertisers whose audience skews heavily toward iOS — common in Japan, where iPhone market share exceeds 60 % — the signal loss is proportionally larger, and the share of conversions that become modeled or unmeasured grows accordingly. This is why the same pixel setup can produce very different undercount levels for different advertisers: the gap is driven by your audience's iOS share and opt-in behavior, not by a universal percentage.

AEM (Aggregated Event Measurement): 8 prioritized events per domain

AEM (Aggregated Event Measurement) is Meta's mechanism for measuring the web conversions of users who declined tracking via ATT — not at the individual level, but in an aggregated form. It's designed to fit within Apple's privacy framework.

In practice, the rule with the biggest impact is this one.

Main AEM constraint	What it means
Event cap	You can configure only up to 8 events per domain
Prioritization	You must assign a priority order to those 8 events
One conversion, one event	For tracking-declined users, only the single highest-priority event is measured per action
Lower-priority events	Events outside the 8, or with low priority, are not measured / not reported

In other words, conversion events you used to measure freely, in any number, now have to compete for priority within a cap of 8. If an e-commerce site was measuring page views, add-to-cart, purchase, and various micro-conversions all at once, the ones that don't fit in 8 — or rank low — will be dropped for tracking-declined users.

Common pitfall: setting your important purchase event (Purchase) to a low priority. Because AEM measures only the single highest-priority event per action, if purchase is low-priority, an earlier micro-event can win out and the all-important purchase goes unreported.

2025 update: Meta removed the manual 8-event limit

In June 2025 Meta made a significant change: the manual AEM configuration panel in Events Manager was retired. Advertisers no longer need to choose, rank, or manually prioritize 8 events. Meta's system now automatically aggregates all eligible standard and custom events behind the scenes.

What this means in practice:

• The "Aggregated Event Measurement" configuration tab in Events Manager is gone
• There is no manual event cap — all eligible events are processed automatically
• You no longer need to worry about a low-priority event displacing a high-priority one
• AEM itself still operates under the hood for ATT-declined users, but the advertiser-facing configuration step has been eliminated

However, the underlying privacy constraint has not changed. For users who declined ATT, measurement is still aggregated and delayed, and modeled conversions still fill the gap. What changed is that Meta now handles event selection automatically rather than requiring advertisers to manage it. If you previously spent time optimizing your 8-event priority list, that work is no longer needed — but implementing CAPI and verifying pixel-CAPI deduplication remain just as important.

Domain verification: without it, you can't even configure measurement

As a prerequisite for setting event priorities in AEM, Meta began requiring domain verification — the process by which an advertiser proves to Meta that "this domain is mine."

• Without domain verification, your permission to configure and edit the 8 events is unstable
• When multiple businesses or ad accounts use the same domain, it also determines who holds control over event configuration

If you find that "I tried to set the 8 events but I can't touch them / nothing takes effect," the underlying cause is often that domain verification simply isn't complete. It's the first thing to confirm as a precondition for implementation.

How the numbers "change": delay, modeling, shorter windows

Measurement after iOS 14 doesn't just "drop." The nature of the numbers themselves changes as follows. Without understanding this, you can't read the reports correctly.

• Reporting delay: Conversions from tracking-declined users may be reported in aggregate with up to roughly 72 hours of delay via AEM. "Today's numbers look low" is sometimes just because aggregation is still in progress.
• Modeled (estimated) conversions mixed in: Meta statistically estimates and fills in what can't be measured at the individual level. Your reported conversions include estimates, not direct measurements. This is by design, not a malfunction.
• Shorter attribution window: Since iOS 14, the default attribution window was shortened (with 7-day click becoming a standard baseline, for example), so results that previously counted under a longer window appear to have decreased.

Common pitfall: judging "it dropped" by comparing against old reports. Because the default attribution window changed, talking about increases or decreases while not comparing under the same conditions leads you to the wrong cause. Align the window settings before comparing.

Why conversions drop even though the pixel "fires"

In DevTools you can see the pixel request (facebook.com/tr) going out just fine. Yet Meta's conversion count falls — this is the most confusing pattern after iOS 14. The reason: firing from the browser (a request is sent) and the complete conversion Meta measures and reports become decoupled by ATT and AEM.

For tracking-declined users, even if the pixel fires:

• It can't be tied at the individual level, so it goes to AEM's aggregate measurement, where reporting is delayed and restricted
• If it's outside the priority order of the 8 events, that event isn't reported
• The gap is filled by modeling (estimation), so it's no longer an actual count

So even if you confirm "facebook.com/tr is firing in Network," if that's the path of a tracking-declined user, it is not necessarily reported as a complete, ad-usable conversion. Checking only whether the pixel fires will never reveal post-iOS-14 losses.

For diagnosing "not tracking" issues in general, see the separate guide on diagnosing why Meta conversions aren't tracking.

Mitigation: backfill the server side with CAPI

The standard countermeasure for post-iOS-14 losses is CAPI (the Conversions API). Rather than relying on the browser pixel alone, it sends conversions to Meta directly from your server, making it less affected by browser-side limits (ad blockers, tracking prevention, some signal loss).

• Run the browser pixel and CAPI together, sharing the same event name and event_id so Meta deduplicates them
• Send information you reliably hold on the server side to raise your event match quality

That said, CAPI isn't "install it and you're done." It's essential to verify that deduplication and the payload are configured correctly. See verifying that the Meta Conversions API (CAPI) works for the detailed checks.

Beyond conversion counting: impact on targeting and optimization

The conversion drop is the most visible symptom, but iOS 14's effects go further — into how Meta targets and optimizes ads in the first place.

• Retargeting audiences shrink. When a user declines ATT, Meta cannot match their website behavior back into a Custom Audience. Since the majority of iOS users opt out, retargeting pools built from website visitors (e.g., "visited product page but didn't purchase") can lose 50 % or more of their iOS segment.
• Lookalike audience quality degrades. Lookalikes depend on Meta identifying patterns among your seed audience members. With less cross-app signal, lookalike models built from website-event seeds (add-to-cart, purchase) become less precise, and cost per acquisition (CPA) tends to rise.
• Optimization algorithms receive less feedback. Meta's delivery algorithm learns from conversion signals. Fewer observed conversions mean the algorithm needs more budget and time to exit the learning phase, and campaign performance can become more volatile.

The practical takeaway: after iOS 14 it is not enough to fix measurement alone. Advertisers who also shift to first-party audience strategies — uploading CRM lists, using in-app engagement audiences, and leaning on first-party data for conversion tracking — tend to recover targeting effectiveness faster than those who rely solely on pixel-based audiences.

Note that the same "numbers drop due to privacy measures" problem occurs on Google's side through a different mechanism called Consent Mode. For a side-by-side comparison, see why Consent Mode makes your conversions drop.

How to verify "how am I being tracked right now" in production

Method 1: Check domain verification and the AEM 8-event setup

In Events Manager, confirm the foundation first.

1. Is domain verification complete in Business Settings?
2. On the "Aggregated Event Measurement" screen, are 8 events registered with the priority order you intended?
3. Is your most important conversion (usually Purchase or Lead) placed at the top of the priority list?

What it tells you: whether the prerequisites for measurement (verification) and the priorities are set up correctly at all.

Method 2: Watch the pixel fire in DevTools Network

1. Open the target production page (especially the purchase-complete / thank-you page) and open the "Network" tab
2. Filter for facebook.com/tr
3. Take the action and check whether the request fires and whether id (pixel ID) and ev (event name) are correct

What it tells you: that the event fires from the browser (stage ②). What it doesn't: how Meta handles it as aggregate measurement on the path of an ATT-declined user (stage ③).

Method 3: Check test events and the attribution window in Events Manager

• Do your target events arrive in real time in Test Events?
• Is the report's attribution window set to the same conditions as the past data you want to compare against?
• How much of the conversions are labeled "modeled" / "estimated"?

What it tells you: the reality of receipt, and the nature of the numbers (actual vs. estimated, and whether windows are aligned).

What checking on your own machine can't tell you

The methods above are useful, but testing once on your own machine has two blind spots specific to post-iOS-14 measurement:

1. Your environment isn't your production users' environment. The device or browser you test on has usually allowed tracking, or is a desktop unaffected by ATT. But the ones pulling your Meta numbers down are the users who declined ATT on iOS. Judging "it's firing, so it's fine" from your own environment misses the entire loss.
2. Anything involving an ad click is hard to reproduce. To properly see "how a person who came via a Facebook ad and then declined ATT is treated on Meta's side," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.

Post-iOS-14 losses happen on the path of "the production user who declined," not "the you who allowed." The fact that it looks fine when you allow is exactly what breeds complacency.

A checklist to verify with confidence

• Is domain verification complete?
• Are the 8 AEM events registered with the priority order you intended?
• Is your most important conversion at the top of the priority list?
• Does facebook.com/tr fire in DevTools, with the correct pixel ID and event name?
• Have you aligned the report's attribution window with what you're comparing against?
• Are you reading the numbers knowing they include "modeled" (estimated) conversions?
• Are you accounting for the reporting delay (up to ~72 hours) before misreading a low same-day number?
• Have you implemented CAPI as a countermeasure and verified deduplication (event_id)?
• Have you checked under real production visitor conditions (including ATT-declined), not just one pattern on your machine?

Frequently asked questions

Q. How much do Meta conversions drop after iOS 14? A. It varies. The size depends on the share of your traffic that declines ATT on iOS, your AEM 8-event setup, and the change in the attribution window. The important point is that this is a structural change driven by privacy specs, not a malfunction. You can mitigate losses with setup optimization and CAPI, but rather than aiming to restore the exact pre-iOS-14 numbers, the right posture is to re-measure under the new assumptions.

Q. What exactly is the "8-event limit"? A. In AEM you can configure only up to 8 conversion events per domain, each with a priority. For tracking-declined users, only the single highest-priority event is measured per action. The more events a site was measuring, the more it's affected by events outside the cap or at low priority being dropped.

Q. What happens if I don't verify my domain? A. Configuring and editing the 8 AEM events becomes unstable, and the prerequisites for measurement aren't in place. When multiple accounts use the same domain, it also leaves "who controls the configuration" undecided. It's the first thing to do before you start implementation.

Q. What is a "modeled conversion"? Is it a malfunction? A. No. It's a conversion Meta statistically estimates and fills in for what can't be measured at the individual level, such as users who declined tracking via ATT. It isn't a direct measurement, so the number behaves differently, but it's working as designed.

Q. Will CAPI bring my numbers back to the original? A. Not "fully back," but server-side sending — less affected by browser-side limits — mitigates losses and raises event match quality. It does require that deduplication and the payload be configured correctly. See the CAPI verification guide for details.

Q. Is this the same as the Google Ads "Consent Mode drop" problem? A. The broad theme — "numbers drop due to privacy measures" — is similar, but the mechanisms differ. Meta is ATT + AEM; Google is Consent Mode. The comparison is laid out in the Consent Mode article.

Conclusion: re-measure under "new assumptions," not as a "malfunction"

The problem of Meta conversions dropping after iOS 14 can't be diagnosed by watching whether the pixel fires. What matters is verifying — on the assumption of the structural changes of ATT, the AEM 8-event limit, domain verification, reporting delay, and modeling — how your real production users (especially those who declined ATT) are actually being measured. For the full picture of Meta tracking, see the sibling Meta conversion tracking complete guide.

ConversionOK runs your live page in an independent, isolated browser and intercepts the pixel events and parameters actually sent, then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your measurement.