Table of Contents
SKAdNetwork conversion values are small, privacy-limited signals an iOS app encodes after first launch. They describe selected behavior without returning the user’s identity. The schema determines what the returned code means, but its availability and the receiving network’s support also matter. This guide explains fine and coarse values under SKAN 4, the observation windows and how to evaluate a schema against mature app outcomes.
SKAdNetwork (SKAN) is Apple’s privacy-preserving install-attribution framework. Devices send delayed postbacks that can be aggregated for campaign reporting. The conversion value is an app-defined engagement signal within that postback; it can be limited or absent. Other attribution fields and separate, appropriately collected product data are also relevant to measurement decisions.
What are SKAdNetwork conversion values?
A SKAdNetwork conversion value is an app-defined code for observed behavior. A fine conversion value is an integer from 0 to 63, giving 64 states. A coarse conversion value has three states: low, medium or high. Fine detail can be returned only in the first eligible higher-tier postback. Coarse detail can be returned in the first postback at a lower tier, and in eligible later postbacks. One postback never contains both value types, and value detail can be missing.
Under SKAdNetwork, the code compresses selected app behavior into a limited signal. It is not an entire user history or the only input an advertising platform can use. Document the meaning of each state, verify that the receiving platform interprets it correctly and separate raw observed postbacks from any modeled reporting.
Apple defines the three coarse states in its SKAdNetwork.CoarseConversionValue reference. The schema is an important implementation decision alongside SDK support, attribution setup and campaign economics. A well-defined code is useful only when it is updated, returned and interpreted as intended.
How do conversion values work under SKAN 4?
SKAN 4 supports three fixed conversion-observation windows extending to 35 days after first launch, with up to three winning postbacks. Multiple postbacks depend on the required framework integration and privacy tier. The window determines when app behavior can update the value; the postback is delivered later.
The windows span days 0 to 2, 3 to 7 and 8 to 35 after first launch. Apple’s multiple-window documentation sets out their conditions. Fine detail is available only in the first eligible higher-tier postback; later postbacks can carry coarse detail. Delivery follows a random delay of 24 to 48 hours for the first postback and 24 to 144 hours for later postbacks, after the window ends or an early lock. Observing an event in the first 48 hours does not mean its postback arrives within those hours.
Crowd anonymity determines which postback details can be returned. Apple uses four tiers and considers the publisher app or domain, advertised app, country and hierarchical source identifier. At Tier 0, the first postback still contains a two-digit source identifier, but no conversion value; later postbacks are not sent. Higher tiers can return more detail. There is no published campaign-volume number that guarantees a fine value. Test consolidation against actual reporting and business outcomes rather than treating it as a requirement for every account.
The lockWindow parameter in Apple’s updatePostbackConversionValue API finalizes the current window early. The system then prepares its postback, applies the random delivery delay and ignores further updates in that same window. Locking can bring reporting forward, but it cannot extend a window or guarantee a richer value.
The Admiral Media Signal Encoding Ladder
Design a schema around a business decision. The Admiral Media Signal Encoding Ladder starts with the outcome the app needs, then checks what can be observed, encoded and validated within Apple’s windows. This keeps implementation choices tied to the app’s economics.
- Anchor on the value you actually monetize. Define the outcome the app needs: a paid subscription, deposit, qualified lead or purchase. Choose an observable early event only where cohort evidence supports its relationship to that outcome. A trial or registration is not automatically revenue.
- Map what is observable inside the first 48 hours. Because the fine value lives only in postback one, list the events a real user can plausibly complete in days 0 to 2: onboarding milestones, a trial start, a tutorial completion, an add-to-cart. The ceiling on early signal is whatever happens in that window, so the product funnel, not the marketer, sets the limit.
- Choose an encoding model: revenue buckets, event milestones, or a predicted-value proxy. Fit the mapping to the events available in the window and the app’s business model. Validate it against comparable cohorts; choosing a model alone does not establish that it will improve scale.
- Define coarse values for eligible first and later windows. Give low, medium and high explicit meanings for each observation period. Coarse values are not just a low-volume fallback: later postbacks use them even at higher tiers. Preserve missing values separately from an observed zero.
- Set the lock to the decision in each fixed window. An early lock stops further updates in that window and can bring its postback forward. It cannot keep the fine-value window open for a week. If useful events occur after day 2, plan the eligible later coarse mappings and reconcile them with mature cohorts.
- Validate the schema against incrementality, then iterate. A conversion value schema can look healthy in-platform while measuring the wrong thing. Admiral Media pressure-tests schemas against incrementality and cohort outcomes, then revises the mapping, because the first schema is a hypothesis, not a finished system.
Start from event definitions and the intended decision, then verify the SDK behavior and postback decoding. A schema that is easy to configure is not necessarily predictive of revenue, so treat the first mapping as a hypothesis and evaluate it after the relevant cohort matures.
Fine or coarse: which conversion value should you optimize for?
Design fine and coarse mappings together. Apple’s privacy tier and observation window determine which one can be returned; later eligible postbacks use coarse values. Separately, confirm which values the chosen ad network can use for reporting or bidding. A value being available from Apple does not establish platform support.
| Dimension | Fine value (0 to 63) | Coarse value (low / medium / high) |
|---|---|---|
| Granularity | 64 states, enough for revenue bands or detailed funnels | 3 states, broad tiers only |
| When it is returned | Postback 1 only, at eligible higher privacy tiers | Eligible lower-tier postback 1 and eligible postbacks 2 and 3 |
| Privacy dependency | Fine detail requires an eligible first-postback tier | Coarse detail is also tier-limited; Tier 0 has no conversion value |
| Best use | Detailed early behavior observable in the first window | Broad value tiers in the first or later observation windows |
| Main risk | No fine detail in later windows or privacy-limited postbacks | Limited resolution; network reporting and bidding support can differ |
Fine and coarse mappings serve different reporting conditions. Define both where the integration supports them, but retain missing detail as missing. Google Ads’ current schema guidance says its modeling and optimization use fine values, while Google Analytics can configure coarse mappings. Check that distinction for the network and SDK in use before expecting later-window coarse values to improve bidding.
How do you design a conversion value schema that actually optimizes?
You design a schema by choosing an encoding model that matches how your app makes money, then mapping it so the highest values mark the users worth paying most to acquire. There are three workable models, and the right one depends on the app economy.
Revenue bucketing assigns ranges of the 0 to 63 scale to bands of early revenue. It suits apps where users spend real money in the first days, such as ecommerce or games with early in-app purchases. The strength is a direct line from conversion value to cash. The weakness is that apps where paid conversion occurs later see little day-zero revenue to bucket.
Event milestone encoding assigns values to an ordered sequence of funnel steps: registration, onboarding complete, trial start, paywall view, subscription. It suits subscription and lead-generation apps where the path to revenue is a chain of predictive actions rather than an immediate purchase. The Clark case study is instructive here. Working with Clark, the Admiral Media team found that optimizing toward carefully chosen mid-funnel events, rather than only the obvious lower-funnel goal, lifted performance, because users explore an app before committing. That same logic governs a good milestone schema: the values that predict revenue are often upstream of revenue itself.
Predicted-value proxy encoding compresses an estimate of longer-term value into the available states. It requires enough reliable historical cohort data to validate that prediction. Compare forecast and realized outcomes at the same cohort age; a model can be more complex without being more accurate.
A web step can add separately measured funnel events, such as a registration or purchase. It does not remove SKAN requirements for attributable app installs, nor does server-side collection bypass consent or privacy rules. Use the web and app measurements for their actual outcomes and avoid presenting a web conversion as a fully attributed app install.
What do Admiral Media’s campaigns reveal about measuring under signal loss?
The case studies below illustrate campaign decisions made under measurement constraints. Their reported outcomes do not isolate a SKAN conversion-value schema as the cause. Assess event definitions, campaign structure and independent outcome evidence separately before applying a case result to another app.
When App Tracking Transparency reshaped attribution, the immediate effect on live accounts was a flood of conversions with unidentified sources. In Admiral Media’s work with TIER, the mobility brand, the team adjusted strategy and reallocated budget so the account still understood where value came from, then scaled user acquisition: TIER reached a 297% increase in new customers, expanded into two new channels beyond its original platform, and scaled its acquisition budget fivefold in under three months. The client specifically credited Admiral Media’s support on tracking and incrementality, but the case does not identify a controlled conversion-value schema test.
The Clark engagement shows the same principle applied to event strategy. By treating which events to optimize toward as a deliberate choice rather than a default, the Admiral Media team improved upper, middle, and lower funnel performance at once. Comparing month three to month one, Clark saw cost per lead fall by 50%, cost per install drop by 29%, conversion rate rise by 41%, and installs grow by 18%. These are reported engagement outcomes from event optimization and testing. They do not establish that a particular SKAN mapping caused the gains.
Miles Mobility illustrates a web-to-app acquisition strategy, not a general way to bypass Apple’s attribution requirements. By moving acquisition through a web-to-app structure on Google with a mobile measurement partner for attribution, the Admiral Media team helped Miles Mobility reach 260% more conversions at a 25% lower cost per acquisition. The result concerns that reported campaign setup. A web event, an app install and an attributed in-app conversion remain different outcomes; the case is not proof of unrestricted iOS user-level tracking.
For further reading, see Admiral Media’s AdAttributionKit measurement playbook, incrementality testing guide and post-ATT app retargeting framework. Use postbacks to understand attributed outcomes and independent testing to investigate lift. Neither the case examples nor a valid postback alone proves that a schema caused additional revenue.
Apple’s direction of travel reinforces the point. AdAttributionKit, documented in Apple’s developer reference, builds on SKAN and interoperates with it, while adding eligible re-engagement and alternative app marketplace support. Reuse the business definitions where appropriate, but verify each framework’s SDK, API, network and OS requirements rather than assuming an unchanged implementation. Managing more than 500 million euros in ad spend across 150-plus mobile brands, the Admiral Media team has had to make these decisions at scale rather than in theory.
Frequently Asked Questions
What is a SKAdNetwork conversion value in simple terms?
A conversion value is an app-defined code for behavior observed in a SKAN conversion window. Fine values range from 0 to 63; coarse values are low, medium or high. A postback may return one type or no value detail, depending on the window, privacy tier and app updates. Other attribution fields and separate product reporting still matter.
What is the difference between fine and coarse conversion values?
Fine values offer 64 states and are limited to the first eligible higher-tier postback. Coarse values offer three states and can appear in an eligible lower-tier first postback and eligible later postbacks, even at higher tiers. Apple never returns both value types in one postback. A privacy-limited or missing value is not evidence of zero revenue.
How many conversion windows does SKAdNetwork 4 have?
SKAN 4 has three fixed conversion-observation windows: days 0 to 2, 3 to 7 and 8 to 35 after first launch. Eligible winning attributions can produce up to three postbacks. Fine detail is available only in the first eligible higher-tier postback. Delivery occurs after the window ends or an early lock plus a random delay, so the first 48 hours of observation are not a promise of receipt within 48 hours.
What is crowd anonymity in SKAdNetwork?
Crowd anonymity controls the postback data tier. Apple considers several crowd dimensions, including publisher, advertised app, country and hierarchical source identifier. At Tier 0 the first postback retains a two-digit source identifier but no conversion value; later postbacks are not sent. Higher tiers can return more detail. Consolidation is a testable trade-off, not a guarantee of a fine value.
How do you choose a conversion value schema for a subscription app?
Start from the subscription funnel and what can be observed in each window. A trial or onboarding event may be a useful proxy where cohort evidence links it to later payment or retention. If paid conversion occurs in a later eligible window, plan the coarse mapping for that period. Compare the proxy with actual mature subscription outcomes; do not assume that all subscription revenue falls outside the full 35-day observation period.
Does AdAttributionKit replace SKAdNetwork conversion values?
AAK builds on SKAN and interoperates with it; there is no universal replacement deadline in Apple’s interoperability documentation. Both use fine and coarse conversion values. Business definitions can inform both schemas, but the implementation must match the network, SDK and supported OS versions. AAK’s re-engagement capability also needs its own eligible integration.
Can you measure iOS campaigns without relying on conversion values?
Some outcomes can be measured separately through consented product analytics, web-funnel events or incrementality tests. These methods answer different questions from a SKAN attributed install. A web step or server-side event does not remove Apple’s tracking and attribution requirements. Combine the evidence for the decision at hand, keeping measured web outcomes, app installs and incremental lift distinct.
