Ограничения SKAdNetwork: что должны знать маркетологи iOS

SKAdNetwork limitations are the single biggest reason iOS user acquisition feels like guesswork. Apple's SKAdNetwork (often shortened to SKAN) tells an ad network that an install happened and roughly how valuable it was — and almost nothing else. There is no device identifier, no user-level record, no clean funnel from impression to purchase. You get a signed, delayed, deliberately blurred summary, and you have to build a media-buying strategy on top of it.

Think of it as the final score of a basketball game with no play-by-play. You know the result. You do not know who passed, who scored, or in what order. That gap between "the number moved" and "here is why" is where budget quietly leaks.

What follows is what SKAdNetwork does and does not give you — every version number, conversion window and postback delay taken from Apple's own developer documentation — plus the workarounds that hold up in a real media plan.

What SKAdNetwork actually measures

SKAdNetwork is Apple's install-validation API, and three parties take part. Ad networks register with Apple, get an ad network identifier and cryptographically sign their ads. Source apps or Safari web pages display those signed ads. Advertised apps update a conversion value as people engage after install. Apple signs the resulting postback and the device sends it to the ad network — and, since iOS 15, a copy to the advertised app's developer if they opt in by declaring an endpoint in their Info.plist.

Crucially, none of this requires App Tracking Transparency consent. Apple states plainly that apps do not need to call ATT before using SKAdNetwork APIs and can call them regardless of tracking authorization status. That is the trade: no consent prompt, but no user-level data either.

The conversion value itself is tiny. The fine conversion value is an unsigned 6-bit integer — a value from 0 to 63, so 64 possible states in total. Since SKAdNetwork 4 there is also a coarse conversion value with exactly three constants: low, medium and high. Apple assigns no meaning to any of them. Your entire post-install measurement schema — day-one retention, purchase bands, tutorial completion, subscription starts — has to be encoded into those 64 slots or three buckets. That single constraint drives most of the practical SKAdNetwork limitations marketers run into.

The SKAdNetwork limitations that change how you buy media

Here are the constraints that matter operationally, rather than the ones that only matter to your engineering team.

• No user-level data. Postbacks carry no device or user identifier. You cannot rebuild a funnel, retarget from ad data, or reconcile a specific install with a specific impression.
• A 64-value budget for everything. Revenue, retention and engagement all compete for the same six bits in the first window.
• Fine values die after window one. Apple's documentation is explicit: after the first conversion window, the system ignores the fine value. The second and third postbacks carry only a coarse low/medium/high signal.
• Delay is structural, not a bug. Postbacks are held back deliberately so timing itself cannot be used to identify a user.
• Data can be stripped entirely. If the crowd around your campaign is too small, Apple removes the conversion value, the source app ID and digits of the source identifier before the postback is sent.
• One postback per ad network. Each ad network receives one install-validation postback, winning or non-winning — never both.
• View-through impressions expire fast. StoreKit records a maximum of 15 view-through impressions per source app and discards the oldest beyond that; each expires after 24 hours.
• Attribution is winner-take-all. Only one impression wins. There is no fractional or multi-touch credit inside SKAdNetwork.

The practical effect: you can measure a channel, but you cannot audit it. Modelling gaps where you would normally have raw rows is now part of the job, and simple back-of-envelope maths — blended CPI, payback, window-over-window movement — carries more weight than it used to. A quick pass through a break-even calculator before you set a target CPI is worth more than a dashboard you cannot verify.

Conversion windows and postback timing: the real clock

SKAdNetwork 4 introduced three conversion windows, measured from the user's first launch of the app. These are the numbers straight from Apple's documentation, and they are the ones to plan around.

Conversion window	Days after first launch	Random send delay	Data in the postback
First	Days 0–2	24–48 hours	Fine conversion value (0–63) plus coarse value, subject to data tier
Second	Days 3–7	24–144 hours	Coarse value only, two-digit source identifier
Third	Days 8–35	24–144 hours	Coarse value only, two-digit source identifier

By default the system waits for the window to close, then adds the random delay before sending. That means a third-window postback can legitimately land more than 40 days after the install. You can pull the first two forward using the lockWindow parameter on updatePostbackConversionValue: set it to true and Apple prepares the postback immediately, ignores any further updates in that window, then sends after the same random delay.

Two details people get wrong. First, locking does not remove the delay — it only removes the wait for the window to close. Second, the earliest possible first postback is unchanged between version 3 and version 4: 24–48 hours after the app finalises its conversion value. In version 3 the value finalised when a rolling 24-hour timer expired and the device then sent the postback after a random 0–24 hours; in version 4 you lock the value and the device sends after a random 24–48 hours. Same total.

The attribution windows in front of all of that are separate and also fixed. A StoreKit-rendered ad gives the user 30 days to install. A view-through ad gives 24 hours. An attributable web ad tapped in Safari gives 30 days. Once installed, the user has 60 days to launch, and the device has 60 days from install to send the first conversion value update. When you are mapping day 2, day 7 and day 35 boundaries onto an actual reporting calendar, a date calculator removes a surprising amount of spreadsheet error, and a business days calculator helps if your reporting cadence skips weekends.

Crowd anonymity tiers: why your postback arrives half-empty

The least understood of the SKAdNetwork limitations is the postback data tier. Apple assigns each app download a tier from 0 to 3 based on crowd size — specifically the crowd associated with the app or domain showing the ad, the advertised app, the install country, and the hierarchical source identifier the ad network supplied. The bigger the crowd, the more data survives.

Tier	First postback contains	Second and third postbacks
Tier 3	Source identifier (2, 3 or 4 digits), fine conversion value, source app ID or source domain, and country code if that country's crowd is also Tier 3	Coarse value plus two-digit source identifier
Tier 2	Source identifier (2, 3 or 4 digits) and fine conversion value	Coarse value plus two-digit source identifier
Tier 1	Two-digit source identifier and a coarse value only	Coarse value plus two-digit source identifier
Tier 0	Two-digit source identifier only — no conversion value at all	None sent

Read that bottom row carefully. A Tier 0 campaign gets one postback with a two-digit campaign bucket and nothing else. No conversion value, no publisher, no second or third window. Non-winning postbacks are also limited to the first window and never include a conversion value or source app ID.

This is why granular campaign structures backfire on iOS. Apple computes the tier for the two-, three- and four-digit versions of your source identifier and selects the one with the highest tier, preferring the most digits when tiers are equal — but if the best available tier is 1 or 0, it falls back to two digits regardless. Slicing a modest budget across hundreds of narrow campaigns pushes every slice into a smaller crowd and strips your own reporting. Fewer, larger campaigns genuinely return more data.

What each SKAdNetwork version added

Version behaviour is set by the version the ad network signs with, not by the device alone, so knowing what each release introduced tells you what your partners can actually deliver.

Version	Available from	What it added
1.0	iOS 11.3	The original install-validation postback. No version number in the postback itself.
2.0	iOS 14	Conversion values from the advertised app; postback gains version number, conversion value, source app ID and redownload flag.
2.1	iOS 14	Postbacks signed with Apple's NIST P-256 public key.
2.2	iOS 14.5	View-through ads via SKAdImpression, plus the fidelity-type parameter (0 for view-through, 1 for StoreKit-rendered).
3.0	iOS 14.6	The did-win parameter, and non-winning postbacks to up to five other ad networks.
4.0	iOS 16.1	Three conversion windows and up to three postbacks, coarse conversion values, hierarchical source identifiers, and attributable web ads in Safari.

The campaign-cap change people cite is real and worth stating precisely. In versions 1 through 3 the campaign identifier had to be an integer between 1 and 100. SKAdNetwork 4 replaced it with a four-digit hierarchical source identifier, expanding the addressable space to 10,000 values — but the winning postback only reveals two, three or four of those digits depending on your data tier. The ceiling went up; the visibility did not automatically follow.

One more nuance on eligibility: an advertised app must be built with the iOS 16.1 SDK or later to register three conversions. Built against an earlier SDK, it registers one conversion and produces one winning postback, no matter what the ad network signed.

AdAttributionKit and where SKAdNetwork is heading

Apple's SKAdNetwork documentation now opens with a direct instruction: use AdAttributionKit for app ad campaigns on the App Store and alternative marketplaces. AdAttributionKit, introduced for iOS 17.4, builds on SKAdNetwork's functionality and extends it to alternative app marketplaces, which SKAdNetwork does not cover.

SKAdNetwork has not been switched off, and the two frameworks interoperate rather than compete. Apple documents the specifics: .adattributionkit and .skadnetwork ad network IDs are compatible across both, so you do not need separate identifiers. If an app has impressions from both frameworks, the system sorts them together and only one wins — click-through always outranks view-through, then impressions are ordered by timestamp, with a maximum of six impressions considered per conversion. And when an app calls the SKAdNetwork conversion-value methods, SKAdNetwork bridges the call into AdAttributionKit automatically.

Practically, that means you should not treat AdAttributionKit as a fix for SKAdNetwork limitations. It is the same privacy architecture — delayed, aggregated, crowd-thresholded postbacks — extended to more distribution surfaces. Plan for both, and expect the underlying constraints to persist.

The role of Mobile Measurement Partners (MMPs)

This is where partners earn their place. A mobile measurement partner (MMP) specialises in helping developers and advertisers extract the most value from Apple's deliberately limited reports.

SKAdNetwork alone feels like completing a puzzle with half the pieces missing. A good MMP fills in more of the picture: it normalises postbacks across networks, decodes your conversion-value schema consistently, models the gap left by null and Tier 0 postbacks, and reconciles SKAN numbers against your own revenue. It cannot manufacture data Apple withheld — nobody can — but it stops you comparing incompatible numbers from six networks and calling the result a report. Still, run the arithmetic yourself rather than trusting a blended dashboard figure: a ROI calculator for paid social returns and a CPC calculator for bid-side maths will flag implausible numbers faster than any interface.

Why these SKAdNetwork limitations really matter

Consider the practical implications of SKAdNetwork limitations. Say you have just launched a mobile game and spent heavily on user acquisition. You want to know:

• Which creative convinced people to download?
• Did those users spend money in the app?
• Are they still playing on day seven, or did they uninstall on day one?

SKAdNetwork answers none of those directly. The first is capped by your source-identifier digits and data tier. The second must be squeezed into 64 fine values, then flattened to low/medium/high after day two. The third arrives in a postback that may be more than a month old. Industry surveys since App Tracking Transparency have consistently reported that many advertisers find iOS return on ad spend harder to measure and that some cut iOS budgets in response; the direction of travel is well established, even though specific percentages vary by source and year.

How to work around SKAdNetwork limitations

You cannot change Apple's system. You can change how you buy against it. Work through these in order.

1. Design the conversion-value schema first. Decide what those 64 fine values represent before you spend anything. Revenue bands, a retention flag and an engagement tier all competing for the same six bits is the most common self-inflicted wound.
2. Consolidate campaign structure. Fewer, larger campaigns raise your crowd size and therefore your data tier. Granularity you cannot see is granularity you do not have.
3. Decide deliberately whether to lock windows. Locking window one gets you data faster; not locking gives the full two days of signal. Pick per campaign type, not globally.
4. Treat null and Tier 0 postbacks as data. A rising share of value-free postbacks usually means your structure has fragmented, not that performance collapsed.
5. Test creative on volume, not attribution. Creative comparison survives limited data better than anything else, provided you give each variant enough installs to clear the crowd threshold.
6. Blend SKAN with first-party signals. Reconcile postbacks against your own in-app revenue and engagement metrics; the two together beat either alone.
7. Model the gap, then validate it. Predictive and media-mix models are reasonable responses to missing data, but re-check them against actual revenue every cycle, and compare periods with a percentage increase calculator rather than eyeballing chart shapes.

None of this removes the constraints. All of it keeps campaigns efficient inside them.

SKAN dashboards and "SKAN apps"

"SKAN app" usually means a dashboard that makes SKAdNetwork data legible — pulling postbacks from several ad networks into one place so campaigns can be compared side by side, with the better ones normalising conversion-value schemas so networks stop reporting apples against oranges. What none of them can do is surface data Apple never sent. A dashboard cannot recover a stripped conversion value or invent a publisher ID. They work around SKAdNetwork limitations; they do not eliminate them. If you are handling raw postbacks yourself, they arrive as signed JSON, so a JSON formatter is handy for inspecting individual payloads and a JSON to CSV converter for pulling a batch into a spreadsheet for analysis.

The balance between privacy and performance

It is worth asking why these SKAdNetwork limitations exist at all. Apple built the framework so advertisers could measure results without following people from tap to tap across apps. The delays, the crowd thresholds and the six-bit conversion value are each a specific mechanism for making individual users unidentifiable in aggregate reporting; the frustration marketers feel is the design working as intended. Advertisers need enough signal to keep investing and users deserve not to be tracked by default, and SKAdNetwork 4's multiple windows and AdAttributionKit's expansion to alternative marketplaces are both attempts to widen the signal without reopening user-level tracking. Expect future changes to follow the same shape.

Frequently asked questions

How long does a SKAdNetwork postback take to arrive?

The first postback is sent 24–48 hours after the first conversion window closes or after you lock the value. The second and third postbacks are sent 24–144 hours after their windows close. Because the second window ends on day 7 and the third on day 35, a third-window postback can arrive more than 40 days after install.

Why is my conversion value missing from the postback?

Almost always the postback data tier. At Tier 1 you get a coarse value instead of the fine value; at Tier 0 you get no conversion value at all and no second or third postback. Small crowds — niche apps, small install countries, over-segmented campaigns — are the usual cause.

Does SKAdNetwork require App Tracking Transparency consent?

No. Apple states that apps do not need to use App Tracking Transparency before calling SKAdNetwork APIs and can call them regardless of tracking authorization status. That is precisely why the data is so limited.

What is the difference between fine and coarse conversion values?

The fine value is a 6-bit integer from 0 to 63 and is only available in the first postback. The coarse value has three states — low, medium and high — and is what you receive in the second and third windows, and in lower data tiers. Apple assigns no meaning to either; you define what they represent.

Does AdAttributionKit replace SKAdNetwork?

Apple now directs developers to AdAttributionKit for App Store and alternative marketplace campaigns, and it builds on SKAdNetwork's functionality. The two interoperate: ad network IDs are compatible across both, impressions from both are sorted together with only one winner, and SKAdNetwork conversion updates are bridged into AdAttributionKit. SKAdNetwork remains documented and supported.

How many campaigns can I run under SKAdNetwork 4?

The identifier space expanded from a campaign ID between 1 and 100 to a four-digit hierarchical source identifier, so up to 10,000 values. But winning postbacks only reveal two, three or four digits depending on your crowd anonymity tier, so running 10,000 distinguishable campaigns is not realistic for most advertisers.

Final thoughts

SKAdNetwork limitations are not a temporary inconvenience waiting on a patch. They are the architecture, and AdAttributionKit carries the same principles forward to more distribution surfaces, so teams waiting for full-fidelity iOS attribution to return will keep making decisions late.

The teams that do well design the conversion-value schema deliberately, keep campaign structures wide enough to clear crowd thresholds, treat postback delay as a planning input rather than a complaint, and hold their models honest against first-party revenue. Mobile marketing measurement changed permanently. It did not end — and the advertisers who adapt their strategy to the constraints still win.