Meta Aggregated Event Measurement (2027)

The problem is not AEM, it is the guides about AEM

Search this topic and you will hit three layers of sediment, all published as if they were current.

The oldest layer walks you through Events Manager step by step: open the Aggregated Event Measurement tab, choose your eight events, drag them into priority order, verify your domain first. Follow it today and you will look for a tab that is not there and conclude something is broken in your account.

The middle layer tells you the eight-event cap was lifted and the setup is now automatic. That is substantively true. But a large number of those pages date the change to 2025, sometimes to a specific month in 2025, and that is where the trail collapses. Every source we could find that carries a real, checkable date puts the announcement on 15 May 2023. We found none that dates it to 2025.

The third layer is the most damaging, because it sounds authoritative: pages announcing that Meta removed AEM. It did not. It removed the configuration requirements around AEM. The protocol is still defined in Meta's live developer documentation, and the Business Help Center article about it is still published.

So the value of this page is narrow and specific: getting the dates and the scope right, and being explicit about the parts that genuinely cannot be verified from outside a logged-in Meta session. If you only take one line away, take this one. The manual configuration burden is gone. The protocol is not. And the change is roughly three years old as of 2026, so anyone selling it to you as an update is re-stamping history.

What Aggregated Event Measurement actually is

Strip away the acronym and AEM is a workaround for a permission you cannot get.

Meta's own developer documentation defines it plainly: Aggregated Event Measurement is a way to measure app events from iOS 14.5+ users who have opted out of app tracking. That is the entire job. When a user declines the tracking prompt, the ordinary path for attributing a conversion back to an ad impression closes. AEM is the constrained path that stays open.

Branch's documentation, updated in April 2026, describes AEM in the broader terms most practitioners need: a privacy-preserving protocol allowing measurement of web and app events from iOS 14.5+ devices even when users have opted out of tracking, with near real-time reporting in minutes to hours, and up to 24 hours for full data propagation after configuration changes. Two things are worth pulling out of that description. First, it covers web as well as app events, which is why AEM appears in pixel conversations and not only in mobile-app conversations. Second, it is still being documented as actively supported in 2026 by a vendor whose customers would complain loudly if it were not.

The word doing the most work is "aggregated". AEM does not hand you an individual user's journey. It reports at a level where individuals are not identifiable. That constraint is the whole point, and it explains most of the behaviour that frustrates advertisers: the delays, the coarseness, the way numbers do not reconcile with a server-side count. AEM is not a broken version of the old attribution. It is a different, deliberately blunter instrument.

Why AEM exists at all: the ATT deadline

None of this originates with Meta. It originates with Apple, on a specific date.

Apple's own developer news announced that App Tracking Transparency became mandatory for all apps on 26 April 2021. From that date, apps had to use the ATT framework to request permission before tracking users or accessing the device's advertising identifier, the IDFA. Apple was unambiguous about the consequence of refusal: if permission is refused, the IDFA returns all zeros. Not degraded, not partial. Zeros.

That single design decision is the origin of everything downstream. An identifier that returns zeros cannot be joined against anything. Every advertising platform that had built measurement on the assumption of a stable device identifier had to invent a replacement or accept a hole in its reporting. Meta's replacement, on the events side, was AEM.

It is worth sitting with the date for a moment, because it reframes the whole topic. ATT is over five years old as of 2026. AEM is nearly as old. This is not an emerging disruption, it is settled infrastructure that a generation of advertisers has never worked without. The reason it still feels unsettled is that the guidance about it never stabilised, not that the technology keeps moving.

What actually changed on 15 May 2023

Here is the correction, laid out with its sourcing visible so you can check it rather than take it on trust.

Meta announced on 15 May 2023 that four things were no longer required. Adviso, publishing on 4 July 2023, reported the announcement and quoted Meta's documentation directly. DEPT, publishing independently on 31 May 2023, named the same 15 May 2023 date and described the same substance. Two independent publishers, same date, same content, both written within weeks of the event rather than years later.

The four confirmed changes:

1. Event prioritization is no longer necessary. The ranked list you were told to agonise over stopped mattering. Be precise about how far this goes, because the two sources part company here. DEPT reads it as the end of the cap itself: advertisers are no longer limited to tracking only eight events for iOS users. Adviso reads it more narrowly, as the end of the manual prioritization step, with a ceiling still implied by Apple's restrictions underneath. What both agree on, and what actually governs your setup, is that you no longer choose or rank eight events by hand. If your work depends on the harder claim that no ceiling exists at all, verify it against your own account rather than either write-up.
2. The Aggregated Event Measurement section was removed from Events Manager. The tab that every older tutorial tells you to open does not exist. That is the intended state, not a bug in your account.
3. Domain verification is no longer mandatory. It remains recommended. The compulsion tied to event configuration went away; the recommendation stayed.
4. Domain selection at ad creation is no longer required. You are no longer picking a conversion domain at the ad level for pixel tracking.

One further change was reported but appears in a single source rather than two, so treat it with more caution than the four above: that value sets are no longer required for Value Optimization. Verify that one against your own account if it affects your setup.

Notice what is not in that list. None of these four are "AEM was turned off". Every one of them is the removal of a manual step that a human used to perform in a Meta interface. Meta automated the configuration and deleted the controls. The measurement kept running.

Where "June 2025" came from

If the announcement was May 2023, why does so much of the internet say June 2025? We can trace most of it, and the answer is mundane: a copying error that acquired momentum.

Jon Loomer, who covers Meta ads mechanics closely, wrote these four changes up in an article titled "Meta Announces Big Changes to Website Conversion Campaigns". That article is dated 16 May 2023, the day after Meta's announcement. His companion posts covering the same changes, including one that walks through Meta's documentation line by line, carry May 2023 timestamps. He also noted at the time that the rollout was still in progress, which matters: advertisers did not watch the AEM tab vanish on announcement day, they watched it vanish from their own accounts over the following weeks. Loomer himself recorded the moment his tab finally disappeared in June 2023.

That is almost certainly where the stray "June" comes from. The announcement was May 2023; the visible disappearance, for many accounts, was June 2023. Somewhere in the retelling, "June 2023" became "June 2025", and pages that cite Loomer for a 2025 date are citing a source that is two years older than the date they attach to it.

We want to be precise about the limits of that account. We could not open jonloomer.com directly to read the article body (the site rejects automated requests), so the dating above rests on the article's own listed publication date and on the timestamps of his cross-posts covering the same four changes, not on a reading of the page. And we cannot prove a negative: it is possible Meta made some further, separate 2025 announcement we did not find. What we can say is bounded and checkable. The four changes described above are dated 15 May 2023 by two independent publishers who wrote them up within weeks, and every 2025-dated version of the story we examined describes those same four changes rather than any additional ones.

That last detail is the tell. A genuine second announcement would have new substance. These pages have identical substance and a different year.

Why the wrong date matters more than it looks

You might reasonably ask why a two-year dating error deserves this much attention. Two reasons, and the second is the important one.

The first is practical. If you believe the change happened in mid-2025, you will also believe that anything published before mid-2025 predates it, which means you will discard correct 2023 and 2024 material as stale and keep incorrect 2022 material as fresh. The error inverts your own filtering.

The second is diagnostic. A page that dates a 2023 announcement to 2025, while citing a 2023 source for it, did not check the source it is citing. That tells you something about everything else on the page. If the one checkable fact is wrong in a direction that flatters the page's recency, the unchecked facts around it deserve less benefit of the doubt.

This is the practical reading skill the topic demands, and it is worth stating without overreach. The 15 May 2023 date holds up because two publishers wrote it down within seven weeks of it happening, independently, and agreed. The 2025 date, everywhere we chased it, resolved to a source that says 2023. That is a claim about what we checked, not a claim about every page on the internet, and you should hold it that way. If you find a dated primary source that says 2025, it beats this page.

What is genuinely current: 2024 to 2026

If the headline change is history, where is the actual freshness on this topic? In the fact that AEM kept gaining capability after the configuration burden was lifted.

Meta began sending AEM reporting to mobile measurement partners (MMPs) in October 2024, as documented by Kochava. The effect is that iOS 14.5+ App Promotion campaigns using AEM for campaign attribution get near real-time reporting through their MMP rather than only inside Meta's own surfaces. That is a meaningful operational change for anyone running app campaigns through a third-party attribution stack, and it happened a year and a half after the change everyone writes about.

Vendor documentation, last updated 20 April 2026, still describes AEM as an actively supported protocol with near real-time reporting and up to 24 hours for full data propagation after configuration changes. Meta's developer documentation still carries the live definition. Meta's Business Help Center article "About Meta's Aggregated Event Measurement" is still published at that URL.

Meta's own framing, quoted in the 2023 coverage, anticipated exactly this. AEM "is designed to help keep people's data used to facilitate conversion reporting and ads optimization private. It will continue to evolve to help our advertisers support consumer privacy." That is a statement about an evolving product, not a deprecated one. And it has to be, because Apple's iOS 14 limitations remain in force. As long as ATT exists and users decline it, Meta needs something that measures those users without identifying them. Removing AEM would mean either abandoning that measurement or replacing it with something else that does the same job under a different name.

The one number you should be most sceptical of

Every AEM discussion eventually reaches for an ATT opt-in rate, and this is where the topic's data hygiene is at its worst. It is also where this page has to be careful, because the rule it is about to give you applies to its own headline number.

The current figure, quoted exactly as its publisher wrote it: AppsFlyer, in a press release dated 24 April 2025, reported that "globally, 50% of users now consent to tracking, a significant 10% increase since ATT's initial rollout." Regionally, France sat just under 51% and Germany at 47%.

Three things about that sentence deserve attention. First, AppsFlyer does not say whether the "10% increase" is a relative rise or a percentage-point one, and the two mean different things: 10 percentage points off a 50% level implies a 40% starting point, while a 10% relative rise implies about 45.5%. Anyone who reports this as "10 percentage points" has hardened a paraphrase into a statistic. Second, AppsFlyer does not publish the denominator. It says "users" and "opt-in rates" without defining the population, so the figure fails the very test the end of this section recommends. It is worth placing rather than discarding: AppsFlyer is the same source AdExchanger cited in 2021 for the prompt-level global average of roughly 37%, which makes 50% the plausible successor to the prompt-level metric rather than to the install-base one. That is an inference from source lineage, not something AppsFlyer states, and you should treat it as such.

Third, the number is not news. AppsFlyer had already published the identical "50% global, 10% increase" line for Q1 2024, in a release dated 26 April 2024, with more regional detail: UK 46%, US 44%, Germany 47%, France 53%, China 53%, Sweden 31%, Poland 39%. The 2025 stamp is fresher, but the number did not move between the two. If you cite 50% as evidence of a recent trend, you are reading movement into a flat line. Cite it as a stable level, not as a rise.

The deeper problem is methodological, and AdExchanger laid it out on 10 May 2021, two weeks after the prompt went live. At least three different metrics circulate under the same label. As measured then: the percentage of opted-in iOS users across all apps ranged from 4% to 13%; the percentage who select Allow when actually shown the prompt ranged from 1% to 60%, with a global average around 37%; the percentage of ad impressions containing an IDFA ranged from 15% to 30%. As the piece put it, these numbers cannot and should not be compared on an apples-to-apples basis, and yet they are.

Two separate lessons live in that paragraph, and they have different shelf lives. The durable one is that three incompatible methodologies circulate under one label, which is as true in 2026 as it was in 2021. The perishable one is the specific ranges, which are a May 2021 snapshot and should never be quoted as today's figures. AppsFlyer's own prompt-level metric moving from roughly 37% in 2021 to 50% by 2024 is the proof: quote a 2021 range as current and you are off by a third on the one metric we can actually track over time.

Those three metrics measure genuinely different things. Users who never see a prompt are in the denominator of the first and not the second. Impression-weighted IDFA presence is a different population again, skewed toward whichever apps serve the most ads. A page that quotes 12% and a page that quotes 50% can both be honest and both be right. The failure is in comparing them, and in planning against a number without knowing which of the three it is.

So the operating rule: before you use any ATT opt-in figure, ask what the denominator is and what year it was measured. If the source does not say, say so out loud when you quote it, or do not quote it.

What this means for how you work now

Strip the history out and the current-state instructions are short, which is itself the point.

Stop looking for the AEM tab. It was removed in May 2023. Its absence confirms your account is in the expected state. Any tutorial that tells you to open it is describing a Meta interface that has not existed for about three years, and everything else on that page inherits the same vintage.

Stop maintaining a priority list of eight events. There is nothing to maintain. If your team still has a documented process for ranking iOS events, it is describing a control that no longer exists.

Verify your domain anyway. The requirement was lifted, the recommendation was not. Meta still recommends it, both independent write-ups of the announcement say so, and the effort is trivial.

Expect delay and aggregation, and stop treating it as a defect. Vendor documentation records near real-time reporting in minutes to hours, and up to 24 hours for full data propagation after configuration changes. If you make a change and read the numbers an hour later, you are reading an incomplete picture by design. Give it a day before you draw a conclusion.

Do not expect AEM numbers to reconcile with a server-side count. They measure different populations under different constraints. A gap between them is the expected output of a privacy-preserving protocol, not evidence that one of them is broken.

Treat the performance claim as directional. Meta's internal study, relayed by Singular, reported roughly 9.5% more conversions for marketers using AEM without impacting cost per install or cost per action. That is Meta's own study about Meta's own product, arriving through a third party. It is plausible and it points the right way. It is not a planning input. If the difference matters to a real decision, measure it on your own account.

Symptoms that get blamed on AEM

A lot of iOS measurement confusion gets filed under "an AEM problem" when the cause is somewhere else entirely. This table maps the complaints to what the verified record actually supports.

The pattern across the whole table is the same. Most of what feels like an AEM malfunction is either a documented behaviour of a privacy-preserving protocol, or a stale guide describing an interface that was retired three years ago. Before you open a support ticket, check which of those two you are actually looking at.

There is one honest exception worth naming. If your events genuinely are not arriving at Meta at all, that is not an AEM question. AEM operates on events it receives; it does not generate them. A broken pixel, a misfiring SDK, or a server-side integration that stopped posting will produce silence that looks superficially like an attribution problem. Confirm the events are landing first, then reason about how they are being attributed. Getting that order backwards is how teams spend a week reading about a protocol when the fault was three layers below it.

The claims on this page that are not fully verified

Four things here are weaker than the rest, and you should know which.

Meta's Business Help Center article "About Meta's Aggregated Event Measurement" is login-gated. Its title was confirmed live in 2026, which is why this page can say the article still exists and therefore that AEM has not been retired as a named product. Its body text could not be read from outside an authenticated session, so no wording is attributed to it anywhere on this page, and you should not accept anyone else's paraphrase of it either. Open it from inside your own account.

The ~9.5% uplift figure is a Meta internal study relayed by a vendor. It is labelled directional throughout for that reason. Treat it as a claim about a product made by the company that sells the product.

The dating of the Loomer article to 16 May 2023 rests on the article's listed publication date and on the May 2023 timestamps of his cross-posts covering the same four changes. The site blocks automated requests, so we did not read the article body. If you can open it, check the date yourself; it is the load-bearing detail in that section.

The reading of AppsFlyer's 50% as a prompt-level metric is an inference from the fact that AppsFlyer was AdExchanger's source for the prompt-level figure in 2021. AppsFlyer does not state the denominator, and we are not able to.

The general definitions of SKAdNetwork and the Conversions API in the FAQ are offered as background context rather than as sourced claims, and are flagged as such there. Everything else on this page traces to either a primary source (Apple's developer news for the ATT date, Meta's developer documentation for the AEM definition) or to two independent publishers agreeing on the same dated fact (the 15 May 2023 announcement).

How to check any AEM guide in ninety seconds

Because Meta renames and relocates this surface regularly, and because a lot of published advice on this topic is a re-stamped copy of a re-stamped copy, the durable skill is auditing the guide rather than memorising the answer. Four questions.

Does it tell you to open an AEM tab in Events Manager? If yes, it describes a pre-May-2023 interface and everything on it is at least three years stale.

Does it name a source and a date for the change, and do they match? This is the highest-yield check on the topic. Several pages date the removal of the eight-event cap to 2025 while citing a source published in 2023. That is not a disagreement about facts, it is a page that did not open its own citation, and you can see it in ten seconds.

Does it say AEM was removed or discontinued? If yes, it confused the removal of the configuration requirements with the removal of the protocol. Meta's live developer documentation contradicts it.

Does every number carry a denominator and a date? If an opt-in rate appears without saying what it measures and when, it is unusable regardless of whether it happens to be correct.

Then do the thing no guide can do for you: open Events Manager and Meta's developer documentation, both of which you can reach in under a minute, and look at the live state. First-party observation beats second-hand summary every time on a surface that changes this often, this page included. What we can honestly offer is the dating, the scope, and an explicit map of where the evidence runs out.