SKAdNetwork (SKAN): What iOS Attribution Can And Cannot Tell You

The short version

SKAdNetwork — usually SKAN — is Apple's privacy-preserving attribution framework for iOS app installs. Rather than the advertiser observing a user across an ad and an app, Apple observes the chain and reports the outcome.

What arrives is an aggregated, delayed, deliberately coarse record of an install and some early behavior. It is not a user, and it cannot be joined to one.

How it works

An ad is shown or clicked, carrying a signed campaign identifier.
The user installs and opens the app.
The app records a limited value describing what the user did.
Apple sends a postback to the ad network, and optionally the advertiser, after a delay.

Apple has revised the framework across versions, changing the number of postbacks, the granularity of values, and how campaign identifiers are structured. Confirm current behavior against Apple's documentation and your MMP rather than against older write-ups — this is the part that dates fastest.

The four constraints that actually matter

Delay. Postbacks arrive after a timer, not in real time. Same-day optimization on SKAN data is not possible in the way it is elsewhere.

Coarseness. The value describing user behavior is small and has to be designed in advance. You decide what you most need to know; everything else is not measured.

Privacy thresholds. When too few installs occur in a breakdown, detail is withheld entirely. Small campaigns receive postbacks with the interesting parts removed.

No user-level join. You cannot connect a SKAN install to a specific user later. Long-window LTV analysis at user level is unavailable through this path.

Why your numbers disagree

SKAN counts, platform-reported counts, and MMP counts will not match. This is expected, not a fault — they use different attribution rules, different windows, and different thresholds for withholding data.

The useful discipline is to pick one source as authoritative for each decision and track the size of the gap over time. Teams that try to reconcile the numbers into agreement spend the effort and lose the signal, since the gap itself indicates how much of your reported performance is claimed rather than observed.

Designing the conversion value

This is the one part you control, and it deserves deliberate design.

Choose the earliest event that predicts value, not the most important event. An event firing after the measurement window is invisible regardless of how much it matters.
Prefer fewer, well-separated states over many states you cannot act on.
Decide the mapping before launching. Changing it mid-flight makes periods non-comparable.

Where to see it in Playad

When Adjust is connected, Dashboards includes a SKAN summary view. Adjust supplies attribution, cohort, and SKAN data; Airbridge supplies attribution, retention, and cohort data. Without an MMP connected, this view has no data source.

Common mistakes

Expecting SKAN, platform, and MMP numbers to reconcile.
Designing a conversion value around an event that happens after the measurement window.
Running campaigns too small to clear privacy thresholds, then reading the gaps as poor performance.
Applying same-day optimization habits to delayed data.
Relying on write-ups from an earlier framework version.

Practical rule

Treat SKAN as a coarse, delayed, aggregate signal, and design your conversion value for the earliest event that predicts value. Then judge iOS performance on the trend within SKAN rather than on agreement with other sources.

Sources

Apple's developer documentation is the authoritative reference for current SKAdNetwork behavior, which changes by version.
Your MMP's documentation governs how postbacks are processed and presented.