If you buy installs on iOS, the numbers in your ad platforms are estimates, and some of them are bad estimates. That is not a bug you can file. It is how iOS attribution has worked since Apple’s App Tracking Transparency prompt arrived, and the teams that do well on iOS are the ones that stopped treating Ads Manager as the truth and built a measurement setup that can be trusted instead.
This is what that setup looks like, in the order we build it.
Page Contents
Why iOS attribution broke in the first place
Before 2021, every install carried a device identifier, so an ad network could match the person who tapped the ad to the person who opened the app. Apple’s ATT prompt made that identifier opt-in, and most people declined. Without it, the old match is impossible.
What Apple offered instead is SKAdNetwork, or SKAN: a privacy-preserving system in which Apple itself confirms that an install came from an ad, and sends the ad network a postback with a small amount of information about what the user did afterwards. That information is a single number, the conversion value, that your app sets and Apple relays. Nothing about the individual user is attached. The postback is delayed, and if too few installs come from a given campaign, Apple withholds parts of it to protect anonymity.
Apple has since renamed and extended the framework as AdAttributionKit. The mechanics that matter to a marketer are the same: you get a delayed, aggregated, coarse signal, and the quality of that signal is almost entirely determined by what you chose to encode in it. The full mechanics, postback by postback, are in our SKAN 4.0 Handbook on the playbooks page; the version differences are in SKAN 3 vs SKAN 4 and AdAttributionKit vs SKAN.
Why this matters more than it looks
It would be tempting to file SKAN under reporting. It is not a reporting problem. It is an optimisation problem.
Meta, Google and TikTok do not optimise toward your business. They optimise toward whatever signal you send back to them. If the only thing your setup passes back is “install”, the platform will find you installs, and it will be very good at it, and a large share of them will be people who open the app once. If you pass back “retained on day one” or “started a trial”, the platform can learn what those people look like and find more of them.
So the chain is: an event fires in your app, your MMP records it, the conversion value encodes it, Apple relays it, the network learns from it. A break at any link means you are paying for a delivery system that is optimising toward the wrong thing, and the ad platform will report success the whole time.
That is why a measurement audit belongs in week one of any iOS programme, before spend scales. Money spent while the signal is wrong is money spent teaching the platform the wrong lesson.
Three sources of iOS truth, and which one to trust
Once you accept that the ad platforms cannot see iOS conversions directly, the question is what each of them is looking at instead. There are three sources, and they are not equal.
Meta’s Aggregated Event Measurement. Meta’s own framework for iOS. It takes the limited signal it receives and statistically models the conversions it cannot observe. Useful for delivery, because it is what Meta optimises on, but it is a model, and its output moves with the model’s assumptions as much as with your results.
Google’s Firebase. Google’s App Campaigns lean on Firebase rather than SKAN for their iOS conversion reporting. It is another independent source of data, and again a partly modelled one, with its own attribution logic that does not match Meta’s or Apple’s.
Apple’s own data. SKAN postbacks and App Store Connect are Apple’s primary record: Apple saw the install, Apple saw the purchase, Apple relayed the signal. No modelling on top. It is coarse, delayed and aggregated, but it is the cleanest of the three because it is the only one not estimating.
The practical rule: optimise on what each platform can see, because that is what its delivery system learns from, but judge on Apple’s numbers, cross-checked against your MMP. When Meta’s AEM and Apple’s count disagree, Apple is right about what happened and Meta is right about what Meta thinks happened.
The five ways it usually goes wrong
These are the failures we find most often when we audit an account. Most accounts have at least two.
1. The conversion value encodes an event that cannot happen in the window. SKAN’s first postback covers roughly the first two days after install. A schema that only encodes a paid subscription, for a product with a seven-day free trial, will encode almost nothing, because the purchase happens after the window closes. One subscription client we worked with had exactly this: the schema mapped paying subscribers only, so the platforms were learning from near-silence. Reworking it to capture trial starts, which do happen inside the window, gave the platforms something to optimise toward.
2. The events never reach the MMP. A schema is only as good as the events feeding it. On one two-app publisher we reviewed, the first app’s SKAN reports showed revenue buckets populating as designed, while the second app’s postbacks were arriving but decoding almost entirely as “no events”, with revenue null. Same publisher, same MMP, same schema template. The second app simply was not sending session and revenue events to the MMP, so there was nothing to encode. Fix the tagging before touching the schema.
3. Most of the range is unused. The fine conversion value has 64 possible values, 0 to 63. A surprising number of schemas use 16 of them. That throws away resolution you will want later, when you are trying to tell a $0.50 day-two user from a $4 one.
4. Platform-reported numbers are treated as truth. Meta models iOS conversions it cannot see. On one client, comparing Meta’s reported iOS purchases against Apple’s own App Store Connect count of purchases from users who arrived via Facebook and Instagram, Meta’s capture rate over 31 weeks ranged from 26% to 112%. Some weeks it saw a quarter of the real purchases; some weeks it reported more than existed. The install counts matched Apple’s closely the whole time. The reported CPA was unreliable in both directions, and nothing in the dashboard said so.
5. Nobody reconciles. The MMP number, Apple’s number and each platform’s number will never match exactly. The question is whether anyone is checking how far apart they are, and whether the gap is stable. A gap that widens is the earliest warning you get that something in the chain has broken.
How to fix it, in order
Week one: audit everything. The SKAN schema, the mapping from it to the MMP and from the MMP to Meta and Google, Events Manager, and then the numbers themselves: Meta against App Store Connect, Meta against Google Play, the MMP against both stores. This is unglamorous and it is the whole foundation. We set out the checklist step by step in what a mobile measurement audit looks like.
Choose the event the platforms should chase. It has to be predictive of value, and it has to happen inside the postback window. For most subscription apps that is a trial start or a day-one return, not a paid conversion. For most games it is early retention or early revenue. The algorithms mostly learn from day-one behaviour and, to a lesser extent, day seven; they cannot learn from month-three retention, however much you care about it.
Design the schema around how the product makes money. Two apps from the same publisher can need different models:
- Revenue-led. If early revenue is meaningful, encode combined revenue (in-app purchase plus ad revenue) across the full 0 to 63 range, with bucket edges dense where most users sit and a cap around where the real distribution ends. Coarse values map to low, medium and high revenue bands.
- Engagement-led with light revenue. If early revenue is sparse, encode engagement as
the primary signal and revenue as secondary. A workable formula is
value = engagement bucket x 8 + revenue bucket, with eight engagement levels (first launch, two sessions, three sessions, day-one retained, and so on) and eight revenue levels. Coarse values then map to retention milestones rather than dollars.
Pass the same event to every network. Once the MMP knows what a retained user is, that is the number that goes back to Meta, Google and TikTok, and it is what they optimise on. Consistency across networks matters more than any single network’s setup.
Reconcile weekly. MMP against Apple, MMP against each network. Log the gaps. A stable gap is a known bias you can plan around. A moving gap is a broken link, and weekly is often enough to catch it before a month of spend has gone into it.
Judge creative on the MMP or on Apple, not on Ads Manager. This is the part that changes decisions. If you cut and scale creatives on a platform-reported iOS CPA that swings between a quarter and a hundred percent of reality, you will cut winners and scale losers. We set out what to read instead in how to analyze ad creative performance.
Past roughly $200,000 a month, add media mix modelling. Apple Search Ads uses its own attribution API, Meta and TikTok use SKAN, Google’s App Campaigns lean on Firebase. They cannot be added up. At scale, an MMM is how you reconcile them into one read on what each channel is actually contributing. Below that spend, there is not enough variation for a model to learn from, and weekly reconciliation does the job. How to build one is in our MMM playbook for post-ATT iOS performance.
What this looks like in practice
The first week of an iOS engagement is a measurement week, not a creative week. Events are mapped, the schema is written against the product’s monetisation model, postbacks are validated, and the reconciliation sheet is set up. Only then does spend go on, because from that point the platforms are learning from a signal that means something.
It is also the reason serious agencies ask for a minimum engagement length. A single month buys you the audit and the setup and almost none of the learning. Two months is the shortest period that tells you anything, and the measurement week is why. More on how engagements are priced and scoped in how much a user acquisition agency costs.
This post is part of our guide to how to choose a mobile UA agency.
Frequently asked questions
How do you fix mobile attribution on iOS? Audit every event, SDK and postback first. Choose a conversion event that predicts value and happens inside SKAN’s postback window, such as a trial start or day-one return. Design the conversion value schema around how the product makes money, using the full 0 to 63 range. Pass the same event to every network, reconcile MMP, Apple and platform numbers weekly, and judge creative on the MMP or Apple, not on platform-reported CPA.
What is SKAN and why does it matter? SKAdNetwork is Apple’s privacy-preserving attribution: Apple confirms an install came from an ad and relays a single coarse conversion value, delayed and aggregated, with no user-level data. It matters because Meta, Google and TikTok optimise toward whatever signal comes back. A weak or wrong conversion value means the platforms are optimising toward the wrong users.
Why does Meta’s iOS CPA not match my real numbers? Because Meta models conversions it cannot observe. On one account, Meta’s capture of real iOS purchases, checked against App Store Connect, ranged from 26% to 112% week to week. The install counts matched; the purchase counts did not. Treat platform-reported iOS CPA as an estimate with wide error bars.
What should the SKAN conversion value encode? An event that predicts value and happens inside the first postback window. Revenue buckets if early revenue is meaningful; engagement milestones with a light revenue component if it is not. Use all 64 values, not 16.
Do I need the Meta SDK as well as an MMP? It is not essential, but it helps. The MMP is the source of record; the platform SDK gives the platform a richer signal to learn from and usually improves delivery.
When do I need media mix modelling? Once spend is large enough that the channels’ incompatible attribution methods (Apple’s own API, SKAN, Firebase) are hiding real trade-offs, which in practice is around $200,000 a month and up. Below that, weekly reconciliation is enough.
