Why ‘did attribution fail?’ is the wrong question to ask about null SKAN postbacks

16 min read | Updated March 2026

SKAdNetwork (SKAN) is Apple's privacy-preserving attribution framework that replaced deterministic, user-level mobile measurement on iOS. Since its enforcement alongside App Tracking Transparency (ATT) in 2021, SKAN has become the single most important measurement layer for any iOS advertiser, yet most marketers still misunderstand its mechanics.

In our experience working across app portfolios of varying scale, the gap between 'understanding SKAN conceptually' and 'extracting actionable signal from SKAN' determines whether an iOS campaign is profitable or flying blind.

What is SKAdNetwork (SKAN) and why does it exist?

SKAdNetwork is Apple’s on-device attribution API that measures ad-driven app installs without sharing user-level identifiers. It exists because Apple’s App Tracking Transparency framework drastically reduced IDFA availability. According to privacy-first attribution frameworks for mobile apps, ATT opt-in rates have remained low across the industry, with gaming apps seeing particularly poor consent, eliminating the deterministic measurement that powered mobile UA for a decade.

Before SKAN, attribution worked by matching a device-level identifier (IDFA) across the ad click and the app install. With ATT, that signal largely disappeared.

SKAN fills the gap by having Apple itself act as a trusted intermediary: the App Store validates that an install came from a specific ad, then sends an aggregated, time-delayed postback to the ad network. Critically, SKAN operates at the campaign level, not the user level.

You never learn which specific user converted, only that a certain number of installs and post-install signals came from a given campaign ID.

As discussed in this SKAdNetwork guide for UA marketers, the system caps you at 100 campaign IDs per ad network, which forces a fundamental rethinking of campaign structure compared to the pre-ATT era of unlimited granularity.

• SKAN attributes installs without exposing any user-level data to advertisers or ad networks
• Apple acts as the trusted attribution authority, validating installs server-side
• Postbacks are delayed and aggregated, preventing re-identification of individual users
• The framework caps campaigns at 100 per ad network, requiring strategic campaign consolidation

How is SKAN different from traditional MMP attribution?

Traditional MMP attribution (via AppsFlyer, Adjust, Kochava, etc.) matched user-level ad interactions to installs using the IDFA. This gave you exact cost-per-user, exact LTV curves, and exact ROAS by creative. SKAN gives you none of that.

Instead, you get campaign-level install counts and encoded post-install quality signals (conversion values), delayed by 24-48+ hours. According to Singular's SKAN benchmarks report, SKAN consistently underreports install volumes by 15-30% compared to MMP probabilistic models, which means you need to triangulate across multiple data sources.

For a deep dive on how post-ATT attribution measurement works across frameworks, see our privacy-first attribution and measurement guide.

How do SKAN postbacks work step by step?

When a user taps an ad and installs an app, Apple's App Store registers the attribution.

After a timer window expires (minimum 24 hours for the first postback in SKAN 4.0, per Apple's SKAdNetwork documentation), Apple sends a cryptographically signed postback to the ad network containing the campaign ID, conversion value, and coarse/fine granularity level. No user identifiers are included.

The flow has five distinct steps. First, the ad network calls Apple's API to register an ad impression or click. Second, the user installs and opens the app. Third, the app calls updatePostbackConversionValue() to register post-install events (like registration, purchase, or level completion).

Fourth, Apple's timer runs for a set window. Fifth, Apple sends the postback to the ad network (and optionally a copy to the advertiser).

As outlined in the SKAN playbook with Piyush Mishra, some advertisers strategically extend their effective measurement window to 48-72 hours by carefully timing their conversion value updates.

The timer resets each time the conversion value is updated to a higher value during the first postback window, which gives you a mechanism to capture more signal, but at the cost of delaying the postback further.

What triggers the SKAN timer to reset?

The timer for the first postback resets every time updatePostbackConversionValue() is called with a value higher than the current one. This is critical for schema design.

If a user installs, registers (conversion value = 10), and then makes a purchase (conversion value = 40) within the window, the timer resets at each update. The postback won't fire until 24 hours after the last update.

According to Apple's official SKAdNetwork documentation, the initial timer for SKAN 4.0's first postback is between 24-48 hours, with randomized noise added to prevent timing-based re-identification.

What are SKAN conversion values and how should you set them up?

Conversion values are a 6-bit integer (0-63) that encode post-install user quality signals into a single number sent back in the SKAN postback. You get 64 possible values, and how you map in-app events to those 64 slots is the single highest-leverage decision in your SKAN measurement setup.

Think of the 64 conversion values as 64 buckets. You need to design a schema that maps meaningful combinations of events and revenue thresholds to these buckets.

The compound synthetic conversion value approach combines multiple event signals (e.g., did the user register AND reach level 5 AND spend $1.99?) into a single value.

At RocketShip HQ, we typically recommend schemas that blend revenue buckets with engagement milestones, because for most apps, revenue alone in the first 24-72 hours captures too little signal.

According to AppsFlyer's SKAN performance index, apps that use engagement-based conversion value schemas see higher postback fill rates than those relying on revenue-only mapping, which aligns with our experience across gaming and subscription app clients where engagement proxies (like tutorial completion or day-1 session count) alongside revenue produce materially more usable postbacks.

• 6-bit fine-grained values give you integers 0 through 63 (64 total)
• Each value must be higher than the previous to trigger a timer reset
• Revenue-only schemas waste most values on thresholds users won't hit in 24 hours
• Compound schemas blending engagement + revenue maximize signal extraction

What is a compound synthetic conversion value schema?

Need help scaling your mobile app growth? Talk to RocketShip HQ about how we apply these strategies for apps spending $50K+/month on UA.

A compound schema uses bit manipulation to pack multiple binary signals into the 6-bit conversion value. For example, bit 1 = completed registration, bit 2 = reached level 3, bit 3 = made any purchase, bits 4-6 = revenue bucket.

This yields far more information per postback than a linear revenue mapping. As recommended in this SKAN guide for marketers, assigning non-monetary values to engagement events like registration and level progression serves as a reliable proxy for user quality when purchase data is too sparse in early windows.

What changed in SKAN 4.0 and Apple's Ad Attribution Kit?

SKAN 4.0 introduced three postback windows (instead of one), coarse conversion values (low/medium/high), hierarchical source identifiers (2-digit and 4-digit campaign IDs), and crowd anonymity tiers that gate data granularity based on install volume. Apple's Ad Attribution Kit (AAK) subsequently rebranded SKAN with minimal practical changes to the underlying mechanics.

The three postback windows operate on different timelines: 0-2 days, 3-7 days, and 8-35 days post-install. Only the first postback can include fine-grained (6-bit) conversion values, and only when crowd anonymity thresholds are met. The second and third postbacks are limited to coarse values (low/medium/high).

According to data cited in the AAK guide episode, Meta's SKAN 4.0 adoption rate sat at roughly 5%, which means the vast majority of advertisers are still operating on SKAN 3.0 mechanics in practice.

This low adoption rate means multi-postback data remains sparse for most advertisers as of early 2026.

How do crowd anonymity tiers affect the data you actually receive?

Crowd anonymity tiers are Apple's volume-gating mechanism that determines whether you get fine-grained conversion values, coarse values, or nothing at all. They are the single biggest reason SKAN data quality varies wildly between high-spend and low-spend campaigns.

Apple defines multiple anonymity tiers (tier 0 through tier 3). At tier 0 (very few installs), you receive almost no data: no conversion value, no source app ID. At tier 1, you get coarse conversion values. At tier 2, you get fine-grained values.

At tier 3, you get fine-grained values plus the full 4-digit source identifier. According to Apple's developer documentation, the exact thresholds are not published and may change.

Industry patterns suggest that campaigns with higher daily install volumes consistently receive more granular postback data, with a meaningful threshold effect that directly informs the campaign consolidation strategy driving most SKAN optimization work. This directly informs the campaign consolidation strategy that drives most of our SKAN optimization work at RocketShip HQ.

• Tier 0: no conversion value, no source app ID returned
• Tier 1: coarse values (low/medium/high) only
• Tier 2: fine-grained 6-bit conversion values
• Tier 3: fine-grained values plus full 4-digit hierarchical source identifier

How should you structure SKAN campaigns to maximize data quality?

Consolidate campaigns aggressively. The 100-campaign-per-network limit combined with crowd anonymity thresholds means that fragmenting spend across many campaigns is the fastest way to lose SKAN signal. At RocketShip HQ, we have seen consistently that consolidating campaigns on a single ad network pushes more campaigns above crowd anonymity tier 2, significantly increasing the proportion of postbacks with usable fine-grained conversion values.

Campaign consolidation is the foundational best practice. Every additional campaign splits your install volume, pushing more campaigns below crowd anonymity thresholds. This directly reduces the percentage of postbacks with usable conversion values.

According to AppsFlyer's SKAN benchmark data, campaigns that exceed crowd anonymity tier 2 return fine-grained values on the majority of first postbacks, while campaigns below that threshold frequently get null or coarse values. Beyond consolidation, you need to align your audience targeting strategy with SKAN's constraints.

On Meta, this means using broad targeting and letting the algorithm optimize against your conversion value schema, since the old playbook of running dozens of lookalike segments is incompatible with SKAN's aggregation requirements.

• Aim for fewer than 15 active campaigns per ad network to preserve crowd anonymity thresholds
• Use Meta’s AEM and Conversions API setup to align with SKAN postback priorities and recover signal from the 70-75% of iOS users who don’t opt into tracking
• Test conversion value schemas quarterly as your user behavior evolves
• Monitor null postback rates: if a significant share of postbacks return null, you likely need to consolidate further

How do you triangulate SKAN data with other measurement sources?

SKAN should never be your only measurement layer. Successful iOS advertisers triangulate SKAN postback data with MMP modeled attribution, Apple Search Ads data (which operates outside SKAN via Apple Search Ads’ own attribution API), and layered measurement approaches that recover previously unattributed spend to build a complete picture.

As discussed in the SKAN playbook with Piyush Mishra, the smartest growth teams build a measurement stack, not a measurement point. According to Singular’s SKAN benchmarks, SKAN underreports install volumes by 15-30% versus MMP probabilistic models. That gap needs to be accounted for through calibration.

At RocketShip HQ, we recommend establishing a 'source of truth hierarchy': use SKAN as the privacy-compliant campaign-level optimization signal, layer MMP modeled data for cross-network spend allocation, and run incrementality tests quarterly to validate that the directional signals from both SKAN and MMP models reflect genuine lift.

See our guide on privacy-first attribution and measurement for the full framework.

• Use SKAN for campaign-level optimization signals within each ad network
• Use MMP modeled data (AppsFlyer SSOT, Adjust, etc.) for cross-network budget allocation
• Run incrementality tests quarterly to validate that SKAN-driven optimizations produce genuine lift
• Cross-reference SKAN postback volumes against App Store Connect download data to calibrate underreporting

What are the biggest mistakes marketers make with SKAdNetwork?

The three most costly SKAN mistakes are: over-fragmenting campaigns (killing crowd anonymity), using revenue-only conversion value schemas (wasting the majority of your 64 values on thresholds most users never reach in 24 hours), and treating SKAN as a direct replacement for user-level attribution instead of a complementary signal layer.

According to AppsFlyer's SKAN performance data, a substantial share of iOS campaigns operate below crowd anonymity tier 2, meaning they receive only coarse or null conversion values. This is almost always caused by running too many campaigns. The second mistake, revenue-only schemas, is equally prevalent.

According to data.ai research, median day-1 payer rates for mobile games sit below 3%, which means a revenue-only schema yields a non-null conversion value for under 3% of your installs. Blending engagement milestones into your schema captures signal from the other 97%.

The third mistake is organizational: teams that try to replicate pre-ATT reporting granularity from SKAN alone will always be disappointed. SKAN is one input into a multi-source measurement framework.

• Campaign fragmentation: running 30+ campaigns per network when fewer than 15 would preserve data quality
• Revenue-only schemas: ignoring engagement signals that cover the vast majority of users
• Expecting user-level data: SKAN is campaign-level by design, and trying to reverse-engineer user paths defeats its purpose
• Ignoring null rates: not monitoring the percentage of postbacks returning null conversion values

How does SKAN handle ad fraud and invalid installs?

SKAN includes built-in fraud resistance through cryptographic signing of postbacks by Apple, which makes it significantly harder to spoof installs compared to traditional attribution. According to AppsFlyer's mobile ad fraud report, iOS fraud rates have declined substantially in the post-ATT era, partly because SKAN's architecture makes device-farm and click-injection fraud less effective.

Each SKAN postback is cryptographically signed by Apple, meaning ad networks and advertisers can verify that the postback genuinely originated from Apple's servers and wasn't fabricated. This is a fundamental improvement over the pre-ATT world where attribution was based on click-to-install matching that could be gamed.

However, SKAN is not immune to all fraud vectors. SDK spoofing (where a malicious SDK simulates conversion value updates inside a legitimate app) remains a theoretical risk, and the delayed, aggregated nature of SKAN postbacks makes real-time fraud detection impossible.

For a deeper analysis of current fraud benchmarks and protection strategies, see our summary of the AppsFlyer fraud report.

How does SKAN interact with retargeting campaigns?

SKAN is designed exclusively for measuring new app installs and does not support retargeting or re-engagement attribution. If you run retargeting campaigns on iOS, SKAN will not attribute conversions from users who already have your app installed.

This is a significant limitation for apps with large existing user bases. Pre-ATT, retargeting lapsed users cost 30-50% less than acquiring new users, making it a core UA lever especially for e-commerce and travel apps.

According to AppsFlyer's app retargeting report, retargeting conversion rates on iOS declined meaningfully post-ATT compared to pre-ATT baselines, partly because of measurement gaps. Without SKAN coverage, retargeting measurement relies entirely on MMP probabilistic models (which have their own accuracy limitations) or deep link click-through data.

The practical implication is that retargeting on iOS requires a different measurement stack than new user acquisition, and teams that attempt to evaluate both through the same SKAN lens will misattribute spend.

SKAdNetwork is not a temporary inconvenience: it is the permanent foundation of iOS measurement. The advertisers who win on iOS are the ones who master conversion value schema design, campaign consolidation, and multi-source triangulation.

If you're struggling with null postback rates, low data fidelity, or SKAN data that doesn't match your MMP numbers, RocketShip HQ can help.

Start by auditing your current campaign count per network, reviewing your conversion value schema against actual day-1 user behavior, and establishing a calibration process between SKAN and your MMP modeled data.

Frequently Asked Questions

Can I use SKAN with Apple Search Ads or does it have its own attribution?

Apple Search Ads operates its own attribution system separate from SKAN, providing deterministic, tap-level data through the Apple Ads Attribution API. According to Apple’s documentation, Apple Search Ads attribution returns the keyword, ad group, and campaign that drove the install without relying on SKAN postbacks. For advertisers running both Meta and Apple Search Ads together, this makes Apple Search Ads the only major iOS channel with user-level attribution still available for consented users.

This makes Apple Search Ads the only major iOS channel with user-level attribution still available for consented users.

Does SKAN work for web-to-app campaigns?

SKAN does not natively support web-to-app attribution flows. According to Apple’s SKAdNetwork documentation, SKAN requires the ad to be rendered via a participating ad network’s SDK or through Safari’s Private Click Measurement. If your funnel sends users from a mobile web landing page to the App Store, web-to-app attribution and CPA impact but that install will not receive a SKAN postback unless the referring ad network has properly registered the initial impression or click through Apple’s API.

If your funnel sends users from a mobile web landing page to the App Store, that install will not receive a SKAN postback unless the referring ad network has properly registered the initial impression or click through Apple's API.

How long do I have to wait for SKAN data before making optimization decisions?

You should wait a minimum of 72-96 hours after campaign launch before making SKAN-informed optimization decisions. According to Apple's documentation, the first postback has a 24-48 hour delay with additional randomized noise, meaning postbacks for installs on day 1 may not arrive until day 3 or 4.

In our experience, teams benefit from allowing sufficient time to accumulate meaningful SKAN conversion value data before making budget reallocation decisions.

What happens to SKAN postbacks if a user uninstalls the app before the timer expires?

Apple still sends the SKAN postback even if the user uninstalls the app before the timer window closes. According to Apple's developer documentation, the postback reflects whatever conversion value was last registered before the uninstall.

If the user installed and immediately uninstalled without triggering any conversion value update, the postback will contain a null conversion value, which is one reason null rates can be misleadingly high for campaigns with poor early user experience.

Are there tools that help automate SKAN conversion value schema management?

Yes, all major MMPs including AppsFlyer's Conversion Studio, Adjust, and Singular offer built-in SKAN conversion value management tools. These platforms let you define conversion value mappings, decode incoming postbacks, and visualize SKAN performance alongside modeled attribution data.

According to AppsFlyer's SKAN documentation, their Conversion Studio supports both single-mapping and advanced compound schema configurations, and it handles the decode logic server-side so you don't need to build your own postback parser.

Will Apple eventually replace SKAN with something better?

Apple's trajectory suggests iterative improvement rather than wholesale replacement. The rebranding of SKAN to Ad Attribution Kit (AAK) in 2024, as covered in our AAK guide episode, introduced no fundamental architectural changes.

According to Apple's WWDC 2024 sessions, the AAK roadmap focuses on improving crowd anonymity tier thresholds and potentially adding support for re-engagement attribution in future versions.

However, Apple has given no indication of returning to user-level attribution, so building your measurement infrastructure around privacy-preserving, aggregated signals remains the correct long-term bet.

Looking to scale your mobile app growth with performance creative that delivers results? Talk to RocketShip HQ to learn how our frameworks can work for your app.

Not ready yet? Get strategies and tips from the leading edge of mobile growth in a generative AI world: subscribe to our newsletter.

Related Reading

• Privacy-first attribution and measurement for mobile apps (comprehensive guide)
• AppsFlyer App Retargeting Report: Benchmarks and Post-ATT Strategies (2026)
• AppsFlyer Mobile Ad Fraud Report: Fraud Rates and Protection Benchmarks (2026)
• How to Use Lookalike Audiences for Mobile App UA on Meta
• Privacy-first attribution and measurement for mobile apps