Your iOS campaign can drive real installs and revenue while the dashboard still arrives late, omits conversion detail, and refuses to identify a single user. That is not necessarily a broken SDK. It is how SKAdNetwork—usually shortened to SKAN—protects privacy while attributing paid app installs.
The harder question in 2026 is not only “what is SKAdNetwork?” Apple now directs developers toward AdAttributionKit, a newer framework built on SKAN’s foundations. App teams need to understand the data they receive today, avoid reading delayed aggregates like device-level analytics, and plan a migration without interrupting campaign measurement.
What is SKAdNetwork?
SKAdNetwork is Apple’s privacy-preserving framework for attributing app installs to advertising campaigns without exposing a user-level advertising identifier. Apple determines the winning ad interaction on the device, waits through a measurement window, and sends a cryptographically signed postback containing limited campaign and conversion data.
SKAN is part of StoreKit. It measures eligible paid app advertising across registered ad networks; it is not a general analytics system. Apple says apps can call SKAdNetwork APIs regardless of the user’s App Tracking Transparency status, and those APIs do not require access to the IDFA (Apple’s SKAdNetwork documentation).
That distinction explains both the framework’s value and its limits:
- It gives advertisers a deterministic, Apple-signed attribution signal without sharing a device identity.
- It reports campaign outcomes after deliberate delays rather than in real time.
- It can describe post-install quality through encoded conversion values, but not an individual event stream.
- It covers eligible ad-driven installs; it does not label organic installs or explain every owned-channel journey.
SKAN therefore answers “did a qualifying ad contribute to this install, and what aggregate quality signal followed?” It does not answer “which named user clicked, installed, purchased, and returned?”
How SKAdNetwork works from impression to postback
Four participants make the flow work: the ad network, the publisher or source app showing the ad, the advertised app, and Apple’s App Store and device services.
- The ad network signs an eligible ad. Registered networks use an Apple-issued network ID and cryptographic keys. The signed impression includes details such as the advertised app and a hierarchical source identifier.
- A source app or eligible web placement presents the ad. An app that displays ads includes its partners’ lowercase, case-sensitive IDs under
SKAdNetworkItemsinInfo.plist(Apple’s property-list reference). - The person clicks or views the ad, then installs and launches the advertised app. Apple documents a 30-day install window after a click or eligible web ad, a 24-hour window after a view, and up to 60 days from installation to first launch and conversion registration (Apple’s attribution time-window guide).
- The advertised app updates a conversion value. The value encodes the post-install outcome the advertiser chose to measure. Updating it also registers the app launch for attribution.
- Apple selects the winning eligible impression. Click-through impressions take priority over view-through impressions; recency then determines the winner within each group.
- The device sends delayed postbacks. Apple sends the winning postback to the attributed ad network. From iOS 15 onward, the advertised app’s developer can also opt in to receive a copy at a configured HTTPS endpoint.
The ad network normally forwards its postback to the advertiser or mobile measurement partner (MMP). An MMP can verify, aggregate, decode, and enrich those records with campaign metadata. It cannot restore an IDFA, remove Apple’s delay, or reveal fields Apple withheld for crowd anonymity.
What arrives in a postback?
The exact payload depends on the SKAN version and privacy tier. Common fields identify the ad network, advertised app, postback sequence, source identifier, winning status, redownload status, and either a fine or coarse conversion value when Apple permits it.
The signature matters. It lets a receiver confirm that Apple produced the attribution record and that the payload has not been altered. A unique transaction or postback identifier also helps a receiver reject replayed duplicates. Apple describes these safeguards as part of its fraud protections, but a signed postback does not prove that every impression or tap before the install was high quality (Apple’s ad-attribution overview).
SKAdNetwork 4 postbacks and measurement windows
SKAN 4, available from iOS 16.1 for ads signed with version 4, replaced the older single-window view with three fixed conversion windows. A winning attribution can produce up to three postbacks.
| Postback | Conversion window after first launch | Possible value | Random delay after close or lock |
|---|---|---|---|
| 1 | Days 0–2 | Fine or coarse | 24–48 hours |
| 2 | Days 3–7 | Coarse only | 24–144 hours |
| 3 | Days 8–35 | Coarse only | 24–144 hours |
These are not three user-level events. They are three aggregate opportunities to summarize value over progressively later parts of the customer lifecycle. Apple may send only the first postback when the install falls into the lowest data tier, and nonwinning attributions receive only one limited postback.
The app can lock a conversion before its window ends. Locking tells SKAN that measurement for that window is complete, so Apple can schedule the postback without waiting for the window to close. The tradeoff is finality: subsequent updates in that window are ignored. Apple retains the random delivery delay even after a lock (Apple’s multiple-postback documentation).
Use a lock only when the speed gained is worth the future signal lost. A subscription app might lock after a trial starts if that is its decisive early event. A game that needs two days to distinguish retained players from one-session installs may be better served by leaving the first window open.
SKAdNetwork conversion values: fine, coarse, and useful
A conversion value is a compact code for post-install quality. It is not an event name sent directly by the device.
The first SKAN 4 postback can contain a fine conversion value from 0 to 63. Those 64 states can represent mutually exclusive milestones, revenue buckets, combinations of behaviors, or a scoring ladder. The second and third postbacks can contain only a coarse value—low, medium, or high—and the first postback may fall back to coarse when its privacy tier does not allow fine data.
Good mapping starts with a decision, not with 64 empty slots. Ask what the acquisition team will change when a signal rises or falls.
- A commerce app could map fine values to registration, product view, cart, purchase, and early revenue bands.
- A subscription app could encode onboarding completion, trial start, paid conversion, and an early value range.
- A game could combine tutorial completion, session depth, level progression, and revenue buckets.
- Later coarse windows could group users by weak, promising, and strong retention or monetization outcomes.
Avoid schemas that are technically dense but operationally unreadable. If finance, growth, and engineering interpret value 37 differently, the extra granularity is false precision. Keep a versioned mapping table, record when it changes, and align the same definitions across the app, MMP, ad networks, and warehouse.
Crowd anonymity changes the answer you receive
Apple assigns each download a postback data tier based on the size of a similar conversion crowd. Larger crowds can unlock more digits of the source identifier, fine conversion data, publisher information, and—at the highest qualifying level—country data. Smaller crowds return fewer fields.
This is why a conversion value can be null even when the app called the update API correctly. It is also why splitting a modest budget across too many campaigns, geographies, and source-ID combinations can reduce usable detail: each segment may build too little volume to qualify for richer data.
Do not “fix” nulls by inventing user-level matches. Monitor the null rate by network, campaign structure, app version, and postback sequence. Then consolidate fragmentation where the experiment does not justify the privacy and learning cost.
How to implement SKAdNetwork without losing the plot
The framework spans app code, campaign configuration, a receiving server, and analysis. Treat it as a measurement system, not a single SDK switch.
1. Confirm which role your app plays
A publisher app that shows ads must include its ad-network partners in SKAdNetworkItems and present eligible signed impressions. An advertised app that is promoted updates conversion values and may configure a postback-copy endpoint. Many apps do both, but the responsibilities are different.
Do not paste a stale identifier list into every release. Reconcile the list with the networks and mediation partners actually serving ads, preserve lowercase identifiers, and add release QA that checks the built Info.plist rather than only the source file.
2. Choose one conversion-value owner
Let either your app logic or one measurement SDK own conversion updates. Two SDKs competing to set values can produce a schema that no dashboard can decode reliably. The current AppsFlyer SKAN guide, for example, explicitly warns customers not to integrate another SDK that also sets conversion values.
Document the owner, API version, mapping version, lock rules, and fallback coarse values. Test upgrades as measurement changes, not merely dependency changes.
3. Receive and retain raw postbacks
Starting with iOS 15, an advertised app can add NSAdvertisingAttributionReportEndpoint to Info.plist. Apple derives a well-known HTTPS path from that domain and can send the developer a copy of the winning postback (Apple’s advertised-app configuration).
Store the original payload before transformation. Verify the signature, deduplicate identifiers, preserve arrival time, and log parsing failures. Keep decoded business fields beside—not instead of—the source payload, so a mapping error can be corrected later.
4. Test delays, missing fields, and version fallbacks
Your happy path is not enough. Exercise fine, coarse, and absent conversion values; each postback sequence; redownloads; locked and unlocked windows; duplicate delivery; an invalid signature; an unknown mapping version; and devices or networks that fall back to an earlier SKAN version.
Apple’s production timers make iterative QA slow, so use Apple’s supported testing tools and developer settings where available. Keep production and development receiver URLs separate, as Apple recommends in its AdAttributionKit testing walkthrough.
5. Reconcile datasets by definition and time basis
SKAN install counts will not equal product analytics, App Store totals, ATT-consented attribution, or an ad platform’s modeled report. The systems use different eligibility rules, windows, date fields, privacy logic, and late-arriving data.
Build a comparison table for each source: what constitutes an install, which date anchors the row, whether redownloads are included, how organic traffic is handled, and when a day is considered complete. Freeze reporting cohorts long enough for the last expected postback delay before judging performance.
Deeplinkly gives app teams one place to manage mobile attribution alongside deep and deferred links, campaign analytics, and raw exports. That combination is useful when the operating problem is broader than SKAN—such as keeping campaign context across an install or comparing privacy-safe iOS results with other channels—but the SKAN dataset must still be interpreted within Apple’s aggregation rules.
What SKAdNetwork cannot measure by itself
Knowing the boundary prevents expensive dashboard arguments.
No user-level journey. A postback cannot be joined to a named person or device. Conversion values summarize behavior; they do not expose the underlying event log.
No real-time optimization signal. Even the first postback arrives after a measurement period or lock plus a randomized delay. Intraday decisions need leading indicators from other permitted data, not a fictional “live SKAN” feed.
No complete organic or owned-channel attribution. SKAN is designed around eligible ads from registered networks. Email, QR codes, referrals, and untagged discovery need their own privacy-compliant measurement and linking plan.
No automatic deferred deep linking. Attribution and routing are related but separate jobs. A campaign may need a deferred deep link to carry an intended destination through installation; a SKAN conversion value does not contain or restore that routing context.
No universal lifetime-value answer. The three windows reach day 35, but the later two expose only coarse values and may not arrive. Long-term LTV still requires cohort models built from permitted first-party behavior and carefully defined aggregate acquisition signals.
SKAdNetwork vs. AdAttributionKit: what to do now
AdAttributionKit is Apple’s newer privacy-preserving attribution framework for the App Store and alternative app marketplaces. It builds on SKAN concepts—signed impressions and postbacks, conversion windows, fine and coarse values, source identifiers, and crowd anonymity—while adding capabilities such as re-engagement attribution.
Apple also designed the frameworks to interoperate. The official interoperability guide says an app can update both frameworks, network identifiers with .skadnetwork and .adattributionkit suffixes are compatible across them, and eligible impressions from both frameworks compete in one attribution decision (Apple’s interoperability documentation).
AdAttributionKit is not merely a speculative “SKAN 5.” Apple’s 2025 updates added overlapping re-engagement conversion windows, configurable attribution rules, geography in sufficiently anonymous postbacks, and improved developer testing. In that same session, Apple told developers using SKAdNetwork that it was a good time to migrate (WWDC25: What’s new in AdAttributionKit).
Use a staged migration:
- Inventory dependencies. Record which networks, SDKs, MMP features, conversion APIs, dashboards, and receiver parsers rely on SKAN-specific fields.
- Ask partners for an adoption matrix. “Supports AdAttributionKit” should specify impression formats, install and re-engagement support, conversion updates, postback forwarding, reporting, and minimum OS or SDK versions.
- Preserve comparable mappings. Keep business meanings stable while changing APIs so a framework migration does not masquerade as a performance change.
- Run interoperable coverage where required. When partners use both frameworks, follow Apple’s guidance on calling both update APIs and accept that only one eligible impression wins.
- Version the receiver. Parse SKAN and AdAttributionKit payloads explicitly, retain raw records, and test missing or newly introduced fields.
- Move reporting in cohorts. Compare complete, maturity-matched periods before retiring the old path.
The practical decision is not “turn SKAN off today.” It is “stop designing new measurement as though SKAN is the final Apple interface.” Maintain the path your active networks require, but put new engineering around AdAttributionKit-compatible schemas, receivers, and tests.
Frequently asked questions
Does SKAdNetwork require ATT consent?
No. Apple says apps can call SKAdNetwork APIs regardless of tracking authorization status. SKAN does not provide access to the IDFA or permit user-level tracking; ATT remains a separate framework governing tracking and access to the advertising identifier.
How many SKAdNetwork postbacks are there?
SKAN 4 can send up to three postbacks for a winning attribution, covering days 0–2, 3–7, and 8–35 after first launch. Privacy tier, winning status, SKAN version, app implementation, and network support can result in fewer postbacks.
What is a SKAdNetwork conversion value?
A conversion value is an advertiser-defined code that summarizes post-install quality. SKAN 4 supports a fine value from 0 to 63 in the first postback and coarse low, medium, or high values when less granularity is allowed or in later postbacks.
Why are SKAdNetwork conversion values null?
Apple may omit a conversion value when the crowd-anonymity tier does not allow it. Nulls can also reflect implementation, partner, schema, or version problems, so diagnose them by app version, network, campaign structure, postback sequence, and raw payload rather than assuming one cause.
Is AdAttributionKit replacing SKAdNetwork?
AdAttributionKit is Apple’s forward path for privacy-preserving app attribution, and Apple encourages SKAN users to migrate. SKAdNetwork and AdAttributionKit remain interoperable, so migration should follow actual ad-network and measurement-partner support instead of an abrupt shutdown.
Do I still need an MMP with SKAdNetwork?
Not strictly. A team can implement Apple’s APIs, receive postbacks, maintain mappings, and integrate each network itself. An MMP becomes useful when the team wants one place to collect and verify postbacks, decode conversion values, join permitted campaign metadata, manage partner integrations, and reconcile SKAN with other measurement sources.
Build for privacy-safe measurement, not perfect-looking rows
SKAdNetwork works when teams accept its contract: Apple decides the winning eligible ad, the app encodes a limited outcome, crowd anonymity controls detail, and randomized postbacks arrive later. Reliable analysis comes from disciplined schemas, raw-payload retention, explicit dataset definitions, and patience—not attempts to recreate a prohibited device graph.
For an existing SKAN program, audit conversion ownership, postback collection, null rates, and campaign fragmentation before changing the schema. For new work, make AdAttributionKit readiness a requirement and keep interoperability until your partner matrix supports the move. If you need to connect those privacy-safe paid signals with deep linking and broader campaign measurement, evaluate an app attribution platform against that complete workflow rather than choosing on a SKAN dashboard alone.