What is SKAdNetwork (SKAN)?
Also known as: SKAN, Apple SKAdNetwork
What is SKAdNetwork?
SKAdNetwork is Apple's privacy-preserving attribution framework for iOS ad campaigns. It returns aggregated install and post-install conversion signals without exposing the IDFA or any user-level identifier. Apple itself signs each postback. Per the Apple Developer SKAdNetwork documentation, SKAN is the only sanctioned attribution path for users who deny App Tracking Transparency.
The framework moves attribution from the device to Apple. The ad network registers the click. The App Store records the install. Apple sends a signed postback to the network and (optionally) to the advertiser. No identifier ever crosses the boundary.
This is the trade. Privacy intact. Granularity gone.
SKAN vs traditional attribution
Traditional MMP attribution and SKAN solve the same problem with opposite trust models. The table below maps the differences advertisers run into in week one.
| Dimension | Traditional MMP attribution | SKAdNetwork |
|---|---|---|
| Identifier | IDFA or fingerprint | None |
| Granularity | User-level | Aggregated by campaign |
| Latency | Real time | 24 to 144 hours |
| Conversion windows | Configurable, up to 30+ days | Three fixed postback windows |
| Re-attribution | Supported | Not supported in SKAN 4.0 |
| Cohort minimums | None | Privacy threshold drops small cohorts |
| Trust authority | The MMP and ad network | Apple |
The shift matters because every legacy iOS playbook (long attribution windows, per-user multi-touch attribution, real-time creative testing) breaks under SKAN. The reporting model has to be rebuilt around campaign-level math.
SKAN 4.0 changes
SKAN 4.0 shipped with iOS 16.1 in October 2022. It addressed the three biggest complaints about earlier versions: one-shot postbacks, opaque conversion values, and the absence of Web-to-App.
Multiple postbacks
SKAN 4.0 sends up to three postbacks per install. Postback 1 fires within 0 to 2 days of install. Postback 2 fires 3 to 7 days post-install. Postback 3 fires 8 to 35 days post-install. Each captures a different stage of user behavior. Day-1 retention. Day-7 monetization. Day-30 LTV signals. Per the AppsFlyer SKAN 4.0 guide, this is the single largest unlock for retention-focused advertisers.
Hierarchical conversion values
Earlier SKAN versions returned a 6-bit conversion value (0 to 63) on a single postback. SKAN 4.0 splits the signal in two. A coarse value (low, medium, high) survives even when the privacy threshold strips fine-grain data. A fine value (0 to 63) returns only when the cohort is large enough. Coarse-grain data is the safety net for small campaigns.
Web-to-App attribution
For the first time, SKAN 4.0 attributes installs that started from a Safari ad click rather than an in-app ad. The advertiser registers an eligible domain and Apple validates the click chain. This closes the iOS gap for performance teams running search ads, display, or affiliate traffic to App Store install pages.
Conversion value mapping (the hard part)
Conversion value mapping is where most SKAN implementations fail. The advertiser has 64 possible fine values per postback window. Each value must encode every business signal that matters: install, signup, trial, first purchase, revenue tier, retention day. Bit allocation is a one-shot decision per app version.
The standard pattern uses a bitmask. Bits 0 to 2 encode revenue buckets. Bits 3 to 4 encode key events (signup, trial, purchase). Bit 5 encodes retention. The encoding gets locked into the app build. Change it later and historical SKAN data becomes uncomparable.
Three rules from teams that got it right:
- Pick the events that drive bidding, not the ones that look pretty in a dashboard. Most apps need install, first-purchase, and Day-7 retention. Skip the rest.
- Use revenue buckets, not exact dollar amounts. SKAN truncates anyway. Encode $0, $0-5, $5-20, $20-50, $50+ as five values, not five thousand.
- Reserve at least one bit for experimentation. A spare bit lets you measure a new event without shipping a new app version.
The mapping also has to align with the network's bidder. Meta, TikTok, and Apple Search Ads each ingest the conversion value differently. Test in a sandbox before going live.
SKAN reporting limitations
SKAN reporting fails in three predictable places. The fixes are operational, not technical.
Privacy threshold
Apple drops the source app ID and the fine conversion value when a cohort is below an undisclosed threshold. Industry estimates put the floor around 25 installs per campaign per day. Below that, the postback returns a null source app and a coarse-only value. Per Singular's SKAN benchmarks, roughly 30 to 50 percent of small-campaign postbacks land in the null-cohort bucket.
Postback delays
Postback 1 lands 24 to 48 hours after install. Postback 2 lands up to a week later. Postback 3 lands up to 35 days post-install. A campaign launched Monday morning has near-zero attributable data until Wednesday and no Day-7 read until the following Monday. Bid pacing has to absorb the lag.
Null cohort
A "null cohort" install is one where Apple stripped both the source app and the fine value. The advertiser knows an install happened, on which campaign, but cannot tell which sub-publisher delivered it or what the user did post-install. Null cohorts are unavoidable on small spend. The fix is to consolidate budget into fewer, larger campaigns so cohorts clear the privacy floor.
Real-world example with numbers
A mobile gaming studio runs a $30,000 weekly iOS install campaign on Meta. Pre-ATT, the MMP reported 4,200 installs per week with a $7.14 CPI and a Day-7 ROAS of 18 percent.
After ATT (around 75 percent opt-out per Apple's published rates), the MMP attributes only 1,050 installs from on-device tracking. The other 3,150 installs are SKAN-only.
Postback 1 returns 2,890 SKAN installs across 14 campaign IDs. Coarse value: low for 60 percent, medium for 30 percent, high for 10 percent. The studio's conversion value mapping decodes "high" as a Day-1 purchase. That tags 289 installs as buyers.
Postback 2 (Day 3-7) returns the fine conversion value for 11 of the 14 campaigns. The other 3 fall into the null cohort because spend was under $200 per campaign. The studio consolidates those three into one campaign the next week. Cohort size doubles. Null-cohort rate drops to under 5 percent.
Total recovered signal: 2,890 SKAN + 1,050 MMP = 3,940 attributed installs against the 4,200 actual. 94 percent recovery, hybrid pipeline.
SKAN + CAPI + on-device modeling pipeline
No single signal solves iOS attribution in 2026. The working pattern combines three pipes.
SKAN handles the in-app install signal. The network's iOS install-optimizer bidder trains directly on SKAN postbacks. Skip SKAN and the bidder runs blind.
CAPI handles web events that lead to App Store visits. A user who reads a blog post, clicks a Meta ad, and then installs the app a week later gets attributed via server-side CAPI on the web side and SKAN on the app side. The two get stitched together by the MMP via the post-ATT consented audience.
On-device modeling fills the remaining gap. Meta's Aggregated Event Measurement and Google's modeled conversions estimate the conversions that neither SKAN nor CAPI saw. Modeled volume is approximate but it keeps the bidder learning. Per AppsFlyer's 2024 hybrid-setup data, advertisers running all three signals recover meaningfully more of the pre-ATT signal volume than those running SKAN alone.
The pipeline order matters. Install conversion tracking starts with SKAN. Web layer adds CAPI. Modeled layer fills gaps. The MMP deduplicates. The bidder optimizes against the merged signal, not any single source.
That is iOS attribution after privacy. Three signals, one merged view, no IDFA in sight.
Related terms
Frequently asked questions
What is SKAdNetwork in simple terms?
SKAdNetwork is the only Apple-approved way to attribute iOS ad conversions after App Tracking Transparency. It tells advertisers an install happened and shares a small numeric conversion value, with no user-level identifier. The signal comes from Apple, not the ad network. It is delayed, aggregated, and capped to protect privacy.
How is SKAN different from the IDFA?
The IDFA was a per-device identifier any app could read. SKAN never exposes the device ID. It returns a postback signed by Apple with a campaign ID, a conversion value, and a coarse source app ID. The advertiser sees an aggregated count of installs per campaign, not who installed.
What changed in SKAN 4.0?
SKAN 4.0 introduced three postbacks per conversion (not one), hierarchical conversion values with coarse and fine grain, source identifier expanded from 2 to 4 digits, Web-to-App attribution, and a hierarchical source app field. It launched with iOS 16.1 in late 2022. Adoption is now standard across major MMPs.
Why does SKAN data look so different from MMP data?
Three reasons. SKAN postbacks arrive 24 to 144 hours after the install, not in real time. The privacy threshold drops the source app ID and conversion value when a cohort is too small. And SKAN counts unique installs only, while MMPs count re-engagement, re-installs, and cross-device. Expect 20 to 50 percent variance.
Do you still need SKAN if you have CAPI and on-device modeling?
Yes. SKAN is the only Apple-sanctioned iOS install signal. CAPI sends server-side web events. On-device modeling estimates lost conversions. Run all three. SKAN trains the network's iOS bidder. CAPI fills the web gap. Modeling fills the rest. Per AppsFlyer's 2024 SKAN benchmarks, hybrid setups recover the most of the pre-ATT signal volume.