SKAdNetwork Conversion Values Requirements in 2026
Set a clear SKAdNetwork conversion values schema across windows, coarse outcomes, and reporting so iOS campaign results stay useful.
SKAdNetwork conversion values tell an ad network what a new user did after installing an iOS app, without attaching that activity to a person or device. This guide covers the SKAdNetwork conversion value requirements that matter for an iOS app using version 4: eligibility, three conversion windows, fine and coarse values, and a schema that a team can actually operate.
Apple’s rules shape the postback. The app team’s job is to turn product behavior into a small, stable set of signals that answer a budget question. Did a campaign bring users who reached the right early milestone, started a trial, or made a purchase?
Check the SKAdNetwork 4 requirements before designing values
Apple says a version 4 postback requires a version 4 ad signature. For ads shown inside an app, the source app must use the iOS 16.1 SDK or later. The advertised app must be App Store-signed and run on iOS 16.1 or later. Apple also documents Safari 16.1 or later for web ads.
Those conditions sit outside the conversion schema, but they decide whether the schema can produce the expected postback. Confirm the network’s signing setup first. Then confirm the advertised app is built and distributed for the required platform level. A values map cannot repair an ineligible impression.
Apple’s SKAdNetwork 4 release notes are the source of record for these conditions. The broader SKAdNetwork documentation also explains that the system uses privacy thresholds to decide how much postback detail it can include.
Plan SKAdNetwork conversion values around decisions
SKAdNetwork 4 allows an advertised app built with the iOS 16.1 SDK or later to register up to three conversions for the winning ad impression. That means an app can update conversion values in three separate conversion windows and receive up to three winning postbacks.
Do not start with every event in the analytics plan. Start with the decision each window should support. A puzzle game might use the earliest window to separate a bounced install from a player who finished onboarding. A later window can distinguish engaged players from people who attempted or completed a purchase. A subscription app might use the same structure for account creation, trial start, and paid conversion.
The windows are not three copies of the same report. Each one should add information that becomes available later. If the first window captures tutorial completion well, repeating that event in every later window wastes part of the schema.
| Sample app | Window purpose | Decision it supports | Signals used |
|---|---|---|---|
| Puzzle game | Early quality | Keep or cut creative tests | onboarding, first level |
| Puzzle game | Engagement | Compare campaign quality | several sessions, progression |
| Puzzle game | Monetization | Forecast payback | purchase attempt, purchase |
This is a sample planning table made for this article. It does not imply that every game should use the same milestones. A casual game, a strategy game, and a subscription utility can all need different evidence of value.
Build a SKAdNetwork conversion value schema that can be explained
A version 4 update can include a fine-grained conversion value and a coarse conversion value. Apple describes the fine value as an integer from 0 to 63. Coarse values give three broader outcomes: low, medium, and high. The system’s privacy tier affects the detail available in a postback, so the coarse map should still be useful when the full fine value is not present.
A practical approach is to make the fine value more detailed inside each business outcome. The sample below gives a fictional puzzle game a clear ladder. It is a sample schema, not an Apple-defined template.
| Fine value range | Sample behavior | Coarse value | Why it matters |
|---|---|---|---|
| 0 to 15 | Installed, then left before the first level | low | Separates weak early quality from meaningful play |
| 16 to 39 | Finished onboarding or returned for another session | medium | Shows early engagement that may justify more spend |
| 40 to 55 | Reached later content or attempted a purchase | high | Flags users with stronger value signals |
| 56 to 63 | Completed a purchase | high | Keeps confirmed revenue at the top of the map |
The ranges cover all 64 fine values, from 0 through 63. That is deliberate. No event should leave a user in an undefined state. The first row also has a meaning. A zero-like outcome is still a measurement result, not missing data.
Keep the map small enough to audit. If a UA manager cannot explain what a value band represents, it will be hard to trust a campaign comparison later. A map with a few meaningful groups beats a dense list of event combinations that no one can reconcile.
Update conversion values with a single owner and a change log
The app can call Apple’s conversion-value update methods as behavior occurs. Apple also allows a window to be locked, which can cause the postback to arrive sooner. Locking is a reporting tradeoff: it may speed up the result, but it stops the app from collecting later behavior in that window.
Set ownership before release. Product should define the behavior that signals value. Engineering should implement the update rules and verify the release build. UA should state the decision the result will drive. Analytics should preserve the schema version next to each campaign report.
Version the map whenever its meaning changes. Suppose a team moves a first-purchase event from one fine-value band to another. Comparing the old and new value without a version marker can make a campaign look better or worse for no real performance reason. Keep the previous map, its release date, and its event definitions available to the people reading cohort ROAS.
For a separate Android measurement path, see how to set up Google Play Install Referrer for mobile attribution. It uses a different mechanism, so avoid forcing one platform’s fields into the other’s reporting model.
Read the postbacks as cohort signals, not user records
SKAdNetwork reporting is designed around privacy-preserving postbacks. It is not a person-level event stream. Use it to compare groups of installs by campaign, source identifier detail, country where available, and conversion outcome. Then compare that picture with direct revenue and retention reporting where the app has a valid basis to collect it.
For example, a campaign with more high coarse outcomes in the first window may deserve another budget test. That does not prove lifetime profitability by itself. It creates a hypothesis that later postbacks, purchase records, and cohort revenue can test.
A cohort table should always state the schema version and the observation window. That prevents a value of 42 from being treated as a universal metric when it only has meaning inside one app’s map. The same discipline helps when reading a cohort ROAS worked example: the denominator, observation day, and revenue definition must stay visible.
For a technical overview and the category’s other guides, visit SKAdNetwork and Privacy.
SKAdNetwork conversion value checklist
- Confirm that the network signs version 4 ads and that the required source and advertised app conditions are met.
- Give each of the three conversion windows a distinct decision to support.
- Map every possible outcome to a defined fine value from 0 through 63.
- Make low, medium, and high coarse values useful on their own.
- Test the update rules in the release build, including events that should not raise a value.
- Record the schema version with campaign and cohort reporting.
- Review whether locking a window helps the decision enough to justify giving up later signals.
Clear conversion values do not make every postback equally detailed. They do make the detail received easier to act on. That is the standard to use when approving a map for production.
