SKAdNetwork (SKAN) Explained: The 2026 iOS Attribution Reality

SKAdNetwork (SKAN) is Apple's privacy-preserving attribution API for iOS app installs and in-app events. It is the only attribution mechanism that works when a user has not granted App Tracking Transparency (ATT) consent — which, in 2026, is the majority of iOS users. The problem is not that SKAN exists. The problem is that most mobile marketing teams are still running SKAN 2 conversion value schemas when Apple shipped SKAN 4 in late 2022 with hierarchical source IDs, multiple postback windows, and coarse + fine conversion value support. The ROAS gap between "what your MMP reports" and "what your bank account sees" on iOS is largely a SKAN misconfiguration problem.

TL;DR: SKAdNetwork is Apple's privacy-preserving iOS attribution API. SKAN 4 (available since iOS 16.1) delivers up to three postback windows, hierarchical 2-bit + 6-bit source IDs, and crowd anonymity thresholds per window. Most teams are still on SKAN 2 schemas. Migrating to SKAN 4 and mapping conversion values to revenue buckets or key events is the single highest-leverage iOS measurement fix available in 2026 — and AdLibrary's competitor creative longevity signals fill the blind spots SKAN still can't eliminate.

What SKAdNetwork actually is

SKAdNetwork is a framework Apple introduced in iOS 14.5 (April 2021) as part of the App Tracking Transparency rollout. When a user does not grant ATT permission — and roughly 70-75% of iOS users globally have not, per industry consensus — the IDFA is unavailable. Standard last-click attribution, which depends on matching a device identifier between the ad network and the advertiser's SDK, simply does not work.

SKAN is Apple's substitute. Instead of user-level tracking, it works like this:

1. An ad network registers the install campaign with Apple.
2. After install, the advertiser's app calls SKAdNetwork.updateConversionValue() to set a 6-bit integer (values 0-63) representing the user's in-app behavior within the measurement window.
3. Apple validates the attribution and delivers a signed postback directly to the ad network — bypassing the advertiser entirely — with a delay designed to prevent fingerprinting.
4. The ad network maps the postback data back to the advertiser's reporting dashboard.

Notice what is absent: user ID, device ID, timestamp of conversion, individual event data. SKAN is aggregate-level attribution by design. You learn that a campaign drove a certain volume of conversions in a certain conversion value bucket. You do not learn which user converted.

This is not a bug. It is the trade Apple made explicit in its SKAdNetwork documentation: privacy-preserving measurement is the explicit goal. The question for advertisers is not "how do I get around SKAN?" but "how do I configure SKAN to tell me the most useful thing it can within these constraints?"

For background on the broader iOS 14 measurement shift, the Meta Ads performance dip post-iOS 14 explainer covers the reporting collapse that happened when the IDFA disappeared overnight. For context on what accurate iOS ROAS should look like once SKAN is correctly configured, the ROAS explainer covers the full calculation framework.

SKAN versions compared: 2.0 / 3.0 / 4.0

The version delta matters enormously for measurement granularity. Here is what each version delivers.

The most important SKAN 4 additions for performance marketers are the three postback windows and the hierarchical source ID. With SKAN 2, you had one shot: whatever conversion value you lock within the first ~24-48 hours post-install is all you learn. With SKAN 4, window 1 captures early intent signals (first purchase, tutorial completion), window 2 captures retention signals (D3–D7 engagement, second purchase), and window 3 captures longer-horizon signals (subscription conversion, D14 LTV milestone).

The hierarchical source ID lets ad networks report up to a 4-digit number at the campaign level — enough to encode network + campaign + creative dimensions in a single field. AppsFlyer's SKAN 4 guide walks through how to map source ID digits to creative parameters.

If your iOS campaign reporting today shows a single conversion value bucket and a single postback delay, you are running SKAN 2 or 3 semantics on an SKAN 4-capable device. The upgrade is a schema decision, not a code change — but it requires deliberate configuration in your MMP and your ad network.

How conversion value schemas work

The conversion value is a 6-bit integer (0–63 in fine mode) that your app encodes with updateConversionValue() or updatePostbackConversionValue() (SKAN 4). It is the only behavioral signal Apple will carry through the SKAN postback. Choosing the right mapping — revenue bucket, event-based, or hybrid — is the core SKAN configuration decision.

Conversion value schema patterns

The default schema mistake is assigning conversion values to app events in alphabetical or chronological order without asking: which event or revenue milestone happens within the measurement window AND predicts downstream LTV?

For a subscription app with a 7-day free trial, the purchase event arrives on day 7 — outside SKAN 2's 24-48h window. The correct schema encodes trial start, profile completion, and content engagement as early events that predict eventual subscription. For a shopping app, the first add-to-cart or first purchase may arrive inside the window and directly predicts LTV.

AppsFlyer's SKAN conversion value recommendation engine and Adjust's conversion value manager both offer schema configuration interfaces, but neither can tell you which early events actually predict LTV in your app. That calibration requires a cohort analysis against your own historical install data. For SKAN campaigns showing high coarse-value rates and diminishing returns, the audience saturation estimator helps diagnose whether the issue is a measurement configuration problem or a genuine reach-frequency ceiling.

Postback mechanics and the crowd anonymity problem

SKAN postbacks are not delivered in real time. Apple deliberately delays them to prevent cross-referencing with other signals that might re-identify a user. The delay structure is one of the most misunderstood aspects of SKAN in practice.

SKAN 4 postback timing

Window 1 closes 2 days after install. Apple then waits an additional random 24-48 hours before sending the postback. This means window 1 postbacks arrive roughly 3-4 days after install. Window 2 closes on day 7; postback arrives ~7-9 days post-install. Window 3 closes on day 35; postback arrives ~35-37 days post-install.

The crowd anonymity threshold is Apple's privacy guardrail. If a campaign does not drive enough installs to meet an undisclosed volume threshold within a window, Apple will return a coarse conversion value (low / medium / high) instead of the fine 6-bit value — or return no conversion value at all. This threshold is per-window, per-campaign, per-ad network. Apple has not published the exact number, but Singular's SKAN analytics research places it at roughly 25-50 installs per combination in practice.

The downstream implication: SKAN is structurally biased toward high-volume campaigns. A test creative with 30 installs may return coarse or null conversion values in all three windows, while the same creative at 300 installs returns fine values. This is not noise in your measurement — it is a designed privacy property. The attribution tracking explainer covers how this interacts with CAPI signal quality on the Meta side.

Practical implications:

• Do not interpret null conversion values as zero LTV. They may be below-threshold conversions.
• Aggregate test results across longer time windows before pausing SKAN-attributed campaigns.
• Use the learning phase calculator to estimate how many installs you need before SKAN returns statistically stable fine values.
• On low-volume campaigns, lean on the coarse value (low/medium/high) to make directional calls, not the fine value.

MMP configuration: what AppsFlyer, Adjust, Branch, and Singular actually do

A Mobile Measurement Partner (MMP) sits between your app, your ad networks, and Apple's SKAN API. In practice, the MMP's SKAN configuration determines what you actually see in your dashboard — and the defaults across platforms are not equivalent.

AppsFlyer runs SKAN via its Conversion Studio, which maps conversion value ranges to revenue or event milestones in a visual UI. AppsFlyer's SKAN measurement hub is one of the more mature configuration tools in the space and supports SKAN 4 multi-window schemas. Its predictive modeling layer — "SKAN + Predict" — fills measurement gaps on low-volume campaigns using probabilistic projection.

Adjust provides a conversion value manager that lets you set fine and coarse value mappings per window. Adjust's SKAdNetwork measurement documentation is explicit about crowd anonymity implications and supports SKAN 4 hierarchical source IDs. One Adjust-specific consideration: their "SKAdNetwork Signature" product acts as an additional validation layer to reduce spoofed postbacks from ad fraud — relevant because SKAN postbacks are signed by Apple but can be replayed by fraudulent networks.

Branch approaches SKAN as a universal attribution bridge. Their SKAN integration guide is built around their cross-platform people-based measurement model, which attempts to attribute installs across both SKAN and non-SKAN surfaces (consented users) and present a unified view. Branch is particularly strong for apps that drive installs from both web and app surfaces simultaneously.

Singular is notable for publishing the most detailed public SKAN analytics research. Their SKAN benchmarks report provides crowd anonymity threshold estimates, postback timing distributions, and conversion value coverage rates across the industry — essential reading before configuring your own schema. Singular's BI connectors also make SKAN data easier to route to a warehouse for LTV cohort analysis.

Meta's SKAN integration deserves separate attention. Meta delivers SKAN postbacks through Apple's system for ATT-non-consented users, while running its own Aggregated Event Measurement (AEM) layer on top for web conversion matching. Meta's SKAdNetwork for advertisers documentation explains how Meta's view-through and click-through attribution windows map onto SKAN postback windows. The short version: Meta recommends a 1-day click / 1-day view window for SKAN-attributed installs, which aligns with window 1's 0-2 day coverage.

Regardless of which MMP you use, the configuration sequence is the same: (1) define your conversion value schema tied to in-window events or revenue buckets, (2) implement updatePostbackConversionValue() calls in your app, (3) register your MMP's postback endpoint with Apple, (4) validate postback receipt and match rates in your MMP's SKAN dashboard before scaling.

Step 0: AdLibrary fills the SKAN attribution gap

Here is the honest limitation of SKAN that no MMP will put in its pitch deck: even a perfectly configured SKAN 4 schema with three windows and hierarchical source IDs still only tells you what happened inside the postback windows. It tells you nothing about whether your creative is working before you spend money on a campaign.

SKAN tells you postback counts and conversion value distributions — after the install, after the window closes, after a 24-48h delay. By the time you know a creative is failing on iOS, you have already paid for the installs.

AdLibrary inverts this. The moat is longevity.

An iOS app advertiser that has been running the same creative — same hook, same format, same offer — continuously for 60+ days across multiple geographies is not doing it out of stubbornness. They are doing it because the creative is profitable. The market already voted with their media budget. That vote is visible in the ad timeline analysis on AdLibrary today, before you spend a dollar.

The practical workflow:

1. Build a watchlist of iOS-focused competitors. Use unified ad search to filter for app install ad formats (square + portrait video, App Store CTA overlays). Save the top advertisers in your category to a saved-ads cohort.

2. Read longevity as a proxy for SKAN profitability. Any creative that has been running continuously for 30+ days has survived at least one postback window cycle. If it survived 60+ days, it has survived all three SKAN 4 windows and the advertiser chose to keep scaling it. That is not a coincidence.

3. Pattern-match before you test. Pull the ad timeline view on the highest-longevity creatives in your watchlist. What do the hooks share? What offer structure appears repeatedly? What visual treatment survives longest? These patterns are SKAN-validated by the market — not by your test budget.

4. Enter SKAN-aware creative testing. Use AdLibrary's competitive patterns to build your test variants, then configure your SKAN 4 schema to catch the early events (tutorial completion, first purchase, first content engagement) that predict whether the variant will survive window 2 and window 3.

The SKAN attribution gap — postback delays, crowd anonymity thresholds, coarse values on low-volume tests — is real. AdLibrary's competitor creative longevity proxy does not eliminate it. It changes the question from "why did my SKAN test fail?" to "which creative patterns are already winning at scale on iOS, and how do I iterate from there?"

This is the same logic that makes saved-ads cohorts the starting point in the post-iOS 14 attribution rebuild playbook. SKAN tells you what happened. AdLibrary tells you what is already working.

ATT opt-in rates and what they mean for SKAN coverage

SKAN does not exist in isolation. It runs alongside probabilistic attribution for ATT-consented users. The ratio between these two determines how much of your iOS measurement actually runs through SKAN — and therefore how much your conversion value schema matters.

Industry consensus in 2026 puts iOS ATT opt-in rates at approximately 25-30% globally, with meaningful variation by vertical. Gaming apps tend to see lower opt-in rates (20-25%) because gamers associate tracking with intrusive advertising. Utility and finance apps see higher rates (35-45%) because users perceive a clearer value exchange. The Adjust Mobile App Trends report publishes vertical-level ATT benchmarks annually.

The implication: on a typical iOS user base, roughly 70-75% of your attribution runs through SKAN. The other 25-30% runs through MMP-side deterministic matching on consented IDFAs. Your SKAN schema therefore governs the measurement quality for the majority of your iOS installs.

A second implication: ATT consent prompt placement and framing affects your opt-in rate. Apps that show a custom permission ask before the system ATT dialog — explaining what tracking enables for the user — consistently see 5-15 percentage point higher opt-in rates. Higher opt-in = more deterministic attribution = less dependency on SKAN postback quality. This is not an attribution-window setting or a schema decision; it is a product UX decision with direct ROAS measurement consequences.

The relationship between SKAN and the attribution window settings you configure on Meta, Google, or TikTok is additive, not competitive. Platform attribution windows apply to consented-IDFA users. SKAN postbacks cover the non-consented majority. Both need to be correct for your iOS reporting to be coherent.

How to configure SKAN 4 correctly: step-by-step

This section is the operational guide. No theory — just the configuration sequence that moves you from SKAN 2 default schemas to a working SKAN 4 setup.

Step 1: Audit your current SKAN version

Log into your MMP dashboard and pull the SKAN postback report. If you see a single postback per install (not three postback windows), you are on SKAN 2 or SKAN 3 semantics. If your source ID is a 2-digit campaign number only, you are not using hierarchical source IDs.

Step 2: Define your measurement window events

For each of the three SKAN 4 windows, identify the in-app event that:

• Happens within the window's closing time (window 1: D0-D2, window 2: D3-D7, window 3: D8-D35)
• Predicts downstream LTV with the highest correlation in your historical data
• Has sufficient volume to clear the crowd anonymity threshold

For a shopping app, this might be: W1 = first add-to-cart, W2 = first purchase, W3 = second purchase or subscription upgrade. For a gaming app: W1 = tutorial complete + level 5, W2 = level 20 or first IAP, W3 = D30 retention or second IAP.

Step 3: Map conversion values to revenue tiers

For fine conversion values (0-63), divide your expected LTV range into 6-bit buckets. A common approach: 0 = no event, 1-20 = low LTV tier, 21-40 = mid LTV tier, 41-63 = high LTV tier, with sub-buckets for event stages within each tier. The EMQ Scorer can help verify whether your signal mapping produces valid conversion value distributions.

Step 4: Implement SDK calls

Replace SKAdNetwork.updateConversionValue() with SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:) (SKAN 4 API). The lockWindow parameter forces Apple to send the window 1 postback immediately rather than waiting for the timer to expire — useful for installs where you have high-confidence early conversion data.

Step 5: Register postback endpoints

SKAN 4 allows up to 3 postback copies: the ad network's endpoint plus two developer-controlled endpoints. Register your MMP's endpoint as developer endpoint 1. Use endpoint 2 for your own data warehouse if you want raw postback data outside the MMP.

Step 6: Validate and iterate

After deploying, pull the SKAN postback report daily for the first two weeks. Check: postback receipt rate (should be >90% for high-volume campaigns), fine vs coarse value distribution (if >60% coarse, your campaigns may be below crowd anonymity thresholds), and window coverage (are you receiving W1, W2, and W3 postbacks, or only W1?).

For ongoing creative testing using these attribution signals, the ad creative testing use case covers the resolution criteria and measurement cycle. To build the creative hypotheses you are testing, the competitor ad research workflow shows how to move from ad library observation to a SKAN-ready brief.

SKAN ROAS: why platform-reported numbers are structurally wrong

The postback delay is not the only SKAN reporting distortion. There are three structural reasons why iOS ROAS reported by platforms through SKAN systematically misrepresents actual campaign performance.

1. The modeled conversion problem. When a campaign falls below the crowd anonymity threshold, Apple returns a coarse or null conversion value. Platforms fill this gap with modeled conversions — statistical estimates of what the postback probably would have shown. Meta, Google, and TikTok all do this. None of them publish the exact methodology. Modeled conversions can represent 30-60% of reported SKAN installs on mid-tier campaigns. This is not fraud — it is designed-in privacy preservation — but it means your SKAN ROAS on low-volume campaigns is partially a projection.

2. The postback window mismatch. Your campaign optimization window (typically 7 days on Meta, 30 days on Google) may not align with your SKAN measurement windows. If you optimize on a 7-day conversion window but your most predictive events happen in SKAN window 3 (D8-D35), the platform is optimizing against stale, window-1-only signal.

3. The attribution window double-counting on consented users. For the 25-30% of iOS users who granted ATT consent, both SKAN and deterministic MMP attribution fire. MMPs and platforms handle this deduplication differently. If your MMP defaults to SKAN-primary attribution, consented-user installs may be attributed twice — once to SKAN and once to the deterministic path — if deduplication logic is not correctly configured.

The corrective stack is the same triangulation approach that applies to web attribution: platform SKAN reporting for directional campaign optimization, MMP-side LTV cohorts for budget allocation, and marketing mix modeling or incrementality testing for ground-truth ROAS validation. The marketing efficiency ratio — total revenue divided by total ad spend — is the final sanity check that SKAN-reported ROAS cannot substitute for on its own.

For the full picture on how iOS attribution gaps interact with Meta's Aggregated Event Measurement and CAPI, the Facebook ads attribution tracking guide covers the deterministic + modeled + SKAN stack in one place.

SKAN-aware creative strategy

SKAN's postback delay and crowd anonymity thresholds change how you should design and test creatives for iOS. Three concrete adjustments.

1. Front-load the qualifying event. If your SKAN window 1 schema captures "first purchase," every creative decision should be evaluated on whether it accelerates time-to-first-purchase. A creative hook that drives curiosity but slows purchase intent (informational unboxing, feature tour) will produce worse window 1 conversion values than a hook that leads with the offer or the outcome. For app install campaigns on Meta, this means testing offer-first vs curiosity-first hooks against SKAN window 1 postback distributions, not just install volume.

2. Run creative tests at sufficient volume. The crowd anonymity threshold means that creative tests with fewer than ~25-50 installs per variant will return coarse or null conversion values. This is a minimum viable scale problem. If your daily budget produces fewer than 25 installs per creative variant, SKAN will not give you fine conversion value signal. Use the learning phase calculator to determine the budget needed to clear the threshold within your measurement window.

3. Use competitor longevity as pre-test validation. Before running a SKAN test at budget, validate your creative concept against competitor ad longevity signals in AdLibrary. A creative hook that is running at scale across multiple iOS-focused advertisers in your category for 60+ days is a SKAN-validated pattern. Test against it, not instead of it. Use the saved-ads watchlist to track which iOS-targeted creatives survive month-over-month in your vertical — these are your benchmark.

SKAN and ad fraud: the validation gap

SKAN postbacks are signed by Apple using a cryptographic signature, which prevents basic replay attacks. However, the SKAN architecture creates a new fraud vector: install fraud at the ad network level.

Here is how it works. A fraudulent ad network registers fake installs with Apple via the SKAN API. Apple signs the postback because the install event was technically valid from its perspective. The ad network delivers the signed postback to the advertiser. The MMP verifies the Apple signature — and marks the install as valid — without any way to verify whether the install reflected a real user.

Adjust's SKAdNetwork fraud research documents this vector and explains how server-side validation of SKAN postback timing and source ID patterns can flag anomalies. The behavioral signal: fraudulent SKAN campaigns tend to show unusually uniform conversion value distributions (all installs returning value 0, or all returning the same bucket), unusually fast postback timing, and source IDs that do not match any registered campaign.

The practical implication: SKAN is not fraud-proof. For high-spend iOS campaigns, configure your MMP's SKAN postback validation rules, set minimum install thresholds per source ID before crediting performance, and cross-reference SKAN-reported installs against app store first-open events in your own analytics. Any significant discrepancy between SKAN postback count and app-store first-open count is a fraud signal.

For ongoing competitive intelligence that identifies which iOS creatives are being scaled by advertisers in your category — a signal that correlates with SKAN profitability — the competitor ad monitoring automation covers the full watchlist-to-alert workflow.

Frequently asked questions

What is the difference between SKAdNetwork and ATT?

ATT (App Tracking Transparency) is Apple's permission framework. It asks users whether they consent to being tracked across apps and websites for advertising purposes. SKAdNetwork (SKAN) is Apple's attribution API that works regardless of ATT status — it is the mechanism that replaces IDFA-based tracking for ATT-non-consented users. SKAN and ATT are complementary: ATT determines whether you get deterministic user-level attribution; SKAN provides aggregate-level attribution when you do not. See Apple's developer documentation on ATT and SKAdNetwork for the technical separation.

How many postback windows does SKAN 4 have?

SKAN 4 delivers three postback windows: window 1 covers D0-D2 post-install, window 2 covers D3-D7, and window 3 covers D8-D35. Each window has its own conversion value (fine 0-63 if above crowd anonymity threshold, coarse low/medium/high if below) and its own postback delay (approximately 24-48 hours after the window closes). SKAN 2 and SKAN 3 delivered only a single postback window with no extended measurement.

What is a good SKAN conversion value schema?

There is no universal answer — the right schema depends on which in-app events within each measurement window best predict downstream LTV for your specific app and user cohort. The principle: identify the event in window 1 (D0-D2) that has the highest correlation with 30-day LTV in your historical data, encode revenue tiers or event milestones into the 6-bit fine value range (0-63), and configure SKAN 4's coarse values (low/medium/high) as fallback for below-threshold campaigns. Singular's SKAN schema examples provide category-specific starting points.

Why are my SKAN conversion values mostly null or coarse?

Null or coarse conversion values on SKAN postbacks mean one of three things: (1) your campaign volume is below Apple's crowd anonymity threshold for fine value reporting — roughly 25-50 installs per campaign combination; (2) your app's updatePostbackConversionValue() calls are not firing correctly within the measurement window; or (3) the events you are mapping to conversion values are not occurring within the window's close time. Run a conversion value audit in your MMP dashboard: check event fire rates within window timers and compare install volume against learning phase thresholds.

How does SKAN interact with Meta's Aggregated Event Measurement?

Meta's Aggregated Event Measurement (AEM) is its own privacy-preserving attribution layer that applies to web conversion events from iOS browsers. SKAN applies to app install and in-app events. For app advertisers, both systems run simultaneously: SKAN covers ATT-non-consented iOS users installing via app-to-app (e.g., a Meta ad leading to an App Store install), while AEM covers web-to-app or web-to-web conversion flows. Meta's SKAdNetwork for advertisers documentation explains how Meta reconciles SKAN postbacks with AEM signals in its reporting. The short version: they are additive, not substitutes, and both require correct configuration to produce coherent iOS ROAS numbers.

For the full measurement stack that triangulates SKAN with MMM and incrementality testing, the death of attribution post is the canonical read on why no single signal — including a correctly configured SKAN 4 — is sufficient for iOS budget allocation decisions.