SKAdNetwork in 2026: How to Read iOS Results Without Fooling Yourself

01What SKAdNetwork is, and why it still runs your iOS reporting

Every founder we onboard asks some version of the same question in week one: why do our iOS numbers look so much worse than Android? The honest answer is usually that iOS is not performing worse, it is being reported differently. SKAdNetwork, or SKAN, is Apple’s privacy-preserving install attribution framework, and on most app accounts we manage it now carries the majority of the paid iOS signal.

The shift began when App Tracking Transparency arrived with iOS 14.5 in April 2021. Apps must ask permission before tracking users across other companies’ apps and sites, which limits access to the IDFA. Plenty of users say no. For those users, the old device-level attribution path is closed, and Apple’s frameworks report what happened instead: which ad network and campaign drove an install, plus a small, carefully limited signal about what the user did afterwards.

That is the part people miss. SKAN is not a broken version of the old system. It is a different instrument with a different job. It will never tell you that a specific user from a specific ad bought a yearly plan. It will tell you, in aggregate and with a delay, whether a campaign is bringing in users who behave like payers. Used that way, it is genuinely useful.

Where SKAN sits next to your other data

We treat iOS measurement as three layers that sit side by side. Consented users can still be attributed at the device level through your mobile measurement partner. Everyone else flows through SKAN, and more recently through AdAttributionKit, Apple’s newer framework introduced in 2024 that works alongside it. Then your own product analytics records what users do inside the app, regardless of where they came from. If you have not yet chosen or set up an MMP, start with our mobile measurement partner guide, because SKAN data is far easier to work with once it arrives through one.

02How SKAdNetwork works, step by step

The mechanics sound technical, but the flow is simple once you see it laid out. Here is what happens between an ad impression and a number landing in your dashboard.

1. The ad is shown. An ad network registered with Apple serves an ad for your app inside another app or on its own platform, and signs that impression so Apple can verify it later.
2. The user installs and opens your app. Your app, usually through your MMP’s SDK, registers with the framework on first launch so the install can be credited.
3. Your app updates the conversion value. As the user does things you care about, such as finishing onboarding, starting a trial or making a purchase, the app updates a conversion value that encodes that behaviour.
4. Timers run and the window closes. The device waits until the measurement window ends, then adds a random delay so the postback cannot be tied to a specific moment of activity.
5. A postback is sent. The device sends an attribution postback to the ad network, and copies can go to you or your MMP. It names the campaign identifiers and carries the conversion value, when privacy thresholds allow it.
6. Your MMP decodes it. Your MMP translates the raw value back into the events you defined and shows it next to spend.

Two consequences follow directly. First, data is late by design, so judging an iOS campaign on yesterday’s numbers is a mistake. Second, the conversion value only carries what you encoded into it. If you encoded the wrong thing, you will make confident decisions on the wrong signal for months.

03Designing your SKAdNetwork conversion value schema

If you only change one thing after reading this, change your schema. The conversion value schema is the mapping between user behaviour and the values your app sends. Most apps we audit are running whatever default the MMP suggested on day one, and that default rarely fits their monetisation model.

Start from what predicts revenue

The question is not “what events do we have?” but “what early behaviour separates a user who pays from one who does not?” On a subscription fitness app we managed, the strongest early predictor was not trial start. It was completing a second workout within the first two days. Trial starters who never did a second workout cancelled at a far higher rate in our cohorts. Once the schema gave weight to that second workout, iOS campaigns that looked equal suddenly separated into clear winners and losers.

This is where good product analytics earns its keep. We use cohort analysis in tools like Mixpanel, Amplitude or Firebase to find the early actions that correlate with Day-30 retention and revenue, then encode those. Our Mixpanel product analytics setup work usually starts with exactly this question, because a schema built without it is a guess.

Three schema styles and when they fit

Whatever style you choose, write the schema down in a one-page document the whole team can read: which value means what, why, and which business number it is meant to predict. We revisit that page whenever pricing, onboarding or paywall placement changes, because the meaning of early behaviour changes with them.

04SKAN 4 postbacks, windows and coarse values

Earlier versions of SKAdNetwork gave you a single postback based on very early activity. SKAN 4 changed that. It introduced up to three postbacks over different time windows, so you can see a first read on early behaviour and later reads on what users did after the first few days. It also introduced coarse conversion values alongside the fine values, which matters more than it sounds.

Fine values, coarse values and why both exist

Fine values carry more detail and are what you design most of your schema around. Coarse values are broad buckets that can be sent when privacy thresholds would otherwise block the detailed number, and they are what later postbacks rely on. In practice, this means you need two schemas, not one: a detailed fine-value map for the first window and a simple coarse map that still says something useful about value later on.

For exact window lengths and current limits, check Apple’s documentation and your MMP’s notes, because both get updated. What does not change is the principle: plan the coarse buckets around low, middle and high value users, so even the least detailed postback separates good campaigns from weak ones.

A schema that only works when every postback arrives in full detail is a schema designed for a world that no longer exists.

05Crowd anonymity: why campaign structure decides your data

Crowd anonymity tiers control how much detail a SKAdNetwork postback carries. The idea is simple: the fewer installs a campaign and its identifiers represent, the less detail Apple will release, so no small group of users can be singled out. Small campaigns get thinner postbacks, sometimes with no conversion value at all.

This turns campaign structure into a measurement decision. An iOS account split into twenty small ad sets, each targeting a slightly different audience, will often return less useful data than the same budget in three or four consolidated campaigns. On a meditation app we took over, consolidating iOS campaigns on Meta from a dozen ad sets to three sharply reduced the share of postbacks that came back without a value. The spend did not change. The visibility did.

• Consolidate on iOS. Fewer campaigns with more volume each clear privacy thresholds more often. Run audience experiments on Android, where the referrer gives you detail.
• Avoid tiny geo splits. Splitting a modest budget across many markets on iOS starves each campaign of volume. Group markets with similar behaviour.
• Keep identifiers meaningful. Networks map campaign identifiers to your campaigns. Do not waste them on micro tests you cannot read anyway.
• Let campaigns run long enough. Turning campaigns on and off every few days keeps them below the volume that earns detailed postbacks, and slows learning for the platform too.

Each network handles SKAN a little differently. Our Meta app campaign management and TikTok ads teams build iOS structures with these thresholds in mind from the first day, rather than restructuring after a month of blank postbacks.

06SKAdNetwork vs AdAttributionKit: what changes for you

Apple introduced AdAttributionKit in 2024 as a newer framework that works alongside SKAN. For most app marketers, the day-to-day question is not which one is better, it is whether your stack is ready for both. In practice, that means three checks.

• Your MMP supports both. AppsFlyer, Adjust, Branch and Singular all publish guidance on Apple’s frameworks. Ask your account manager how they combine the two in reporting and whether your schema carries across.
• Your networks support both. Ask each paid partner how they receive and report Apple’s postbacks today, and what changes on their side.
• Your reports label the source. A dashboard that silently blends sources makes it impossible to compare periods honestly.

The underlying discipline is the same for both frameworks: a thoughtful value schema, sensible campaign structure and patience with delayed data. If those are in place, a framework change is an administrative task rather than a reporting crisis.

07Working with MMPs and ad networks on SKAN

SKAdNetwork involves at least three parties: Apple, the ad network and whoever decodes the postbacks for you. Things go wrong at the hand-offs. We have seen accounts where the MMP schema was updated but the network was still optimising against the old meaning of each value, so the algorithm was chasing the wrong users for weeks.

A simple change protocol

1. Write the new schema and the reason for the change on one page.
2. Update the MMP configuration and record the exact date and time.
3. Confirm with each network that their optimisation reads the new mapping, especially if you use value-based bidding.
4. Mark the change on every dashboard and avoid comparing results across the switch for at least one full set of postback windows.
5. Review results after the windows close, not the morning after.

Google App campaigns, Meta, TikTok and Snapchat all support SKAN-based optimisation in their own ways, and their in-platform numbers will never perfectly match your MMP. That is normal. What matters is that the direction agrees. Our app install campaign work across Google Ads and Snapchat ads uses the MMP as the referee, with each platform’s own view as a second opinion.

08Reading SKAdNetwork data alongside other signals

The biggest mindset shift on iOS is accepting that no single report is the truth. We build iOS decisions from a stack of signals, each with a known weakness, and we look for agreement between them.

A practical routine we use: SKAN and MMP data steer campaign-level calls weekly, product cohorts check that users from paid iOS behave like users from Android, and a blended view of iOS revenue against iOS spend keeps everyone honest each month. For the modelling side, our attribution modelling service builds the bridge between these views, and we report them together in a Looker Studio dashboard so nobody has to reconcile five exports by hand.

One more source of truth is your existing users. Retargeting lapsed iOS users is harder to measure than acquisition, but the same principles apply. If you run app retargeting, keep it in separate campaigns so it does not muddy acquisition postbacks.

09Common SKAdNetwork mistakes we fix in audits

When we take over an iOS account, these are the problems we find most often, in rough order of how much money they cost.

1. Running the default schema. The MMP template was never designed for your app. It encodes generic events that do not predict your revenue.
2. Judging iOS on day-one numbers. Postbacks arrive late by design. Cutting campaigns before the windows close kills good campaigns early.
3. Too many small campaigns. Fragmented structures fall below privacy thresholds and return postbacks with no value.
4. Changing the schema without telling anyone. Networks keep optimising against the old meaning and historical comparisons break.
5. Ignoring coarse values. Teams design a beautiful fine-value schema and leave later postbacks with buckets that say nothing.
6. Expecting iOS and Android to match. The two platforms are measured differently. Compare each against its own history first.

None of these need a bigger budget to fix. They need a clear owner, a written schema and the discipline to wait for data. If you want a second pair of eyes, our app marketing team reviews SKAN setups as part of every onboarding, and you can see the wider range of support on our full services page or start from the youremergingads.com homepage.