SKAdNetwork And SKAN 4 Explained For UA Teams

When a user sees or taps an ad and later installs the app, the device — not the ad network or the advertiser — records the attribution. After the app updates its conversion value to reflect what the user did, and after a delay that includes a random component, the device sends a postback to the winning ad network (and optionally a copy to the advertiser). The postback contains the campaign identifier, the conversion value and some context, but no user or device identifier.

SKAN 4 introduced several changes that matter for UA:

• Three postback windows instead of one: roughly days 0–2, 3–7 and 8–35 after install. You get a signal about early behavior and later behavior from the same user.
• Fine and coarse conversion values: the first postback can carry a fine value (0–63, six bits) when privacy thresholds are met; later postbacks carry a coarse value (low, medium, high).
• Crowd anonymity tiers: the amount of data in a postback depends on install volume for that campaign and source. Small campaigns receive less detail.
• Hierarchical source identifier: the old 2-digit campaign ID became a 4-digit source identifier, with only the lower digits revealed at low volume.
• Lock window: apps can lock a conversion value early to receive the postback sooner, trading completeness for speed.
• Web-to-app attribution: SKAN extended to ads shown in Safari web pages.

Apple protects privacy by withholding detail when too few installs share the same campaign and publisher. In practice this means fragmented campaigns get worse data. If you split budget across many small campaigns, sources and creatives, many postbacks will arrive with only coarse values or null values and truncated source IDs.

The practical rule: consolidate. Use fewer campaigns with more volume each, and let the DSP handle granular optimization inside them. Design your source-identifier hierarchy so the most important dimension (for example geo or creative concept) sits in the digits revealed first.

The conversion-value schema is the mapping from user behavior to the 64 fine values and three coarse values. It is the single most important SKAN decision, because it determines what your bidder can learn from iOS. Most MMPs provide a schema builder; the thinking is yours.

• Decide the business question: revenue (ROAS), engagement (retention proxies) or funnel depth (registration, KYC, purchase).
• Use the first window for early, predictive signals — tutorial completion, first purchase, revenue buckets, sessions.
• Use coarse values in windows two and three for later value: low/medium/high revenue or retained vs churned.
• Size revenue buckets on your real distribution so most users do not fall into the same bucket.
• Keep it stable — changing the schema mid-flight breaks comparability and resets learning.

The following is an illustrative example only, to show the structure rather than recommended thresholds for your app:

• Fine values 0–7: engagement only — install, tutorial complete, level 5, level 10, combined with session counts.
• Fine values 8–63: revenue buckets for users who purchased in the first window, combined with an engagement flag.
• Window 2 coarse: low = no activity after day 3; medium = active, no purchase; high = purchase in days 3–7.
• Window 3 coarse: low = churned; medium = active; high = cumulative revenue above a chosen threshold.

SKAN postbacks are delayed by design. The first postback arrives after the first window closes plus a random delay; later postbacks arrive later still. That means iOS optimization runs on older data than Android. Do not judge an iOS campaign on day-one dashboards, and keep bid changes measured — chasing noise in partial data is a common mistake.

Use the lock window deliberately. If your key early event usually happens in the first hours, locking the value early shortens the delay. If valuable events happen on day two, locking too early throws them away.

Postbacks go to the ad network that won the attribution. A DSP receives and decodes them, joins them to its own campaign and source structure, and uses conversion values as optimization signal. Combined with consented device-level data where ATT opt-in exists, and with modeled or aggregated signals from your MMP, this gives the bidder enough to price iOS impressions on predicted value.

In Adora X, we review your schema before launch, map source identifiers to the dimensions that matter, and report SKAN results alongside MMP aggregates so your team sees one consistent picture.

SKAN does not exist in isolation. A share of iOS users do grant tracking permission through the App Tracking Transparency prompt, and for those users device-level attribution through your MMP still works. Most MMPs therefore present two views of iOS performance: deterministic results for consented users and SKAN results for everyone attributed through Apple's framework, often with a modeled or blended view that tries to combine the two without double counting.

For UA teams the practical consequence is that no single iOS number is perfect. Agree internally which view is used for which decision — for example, SKAN for channel-level budget allocation and consented data for creative and placement diagnostics — and keep that convention stable so trends remain comparable over time.

Because SKAN reports revenue only through the buckets you designed, ROAS on iOS is an estimate. The usual approach assigns each conversion value a representative revenue amount — often the midpoint of the bucket or a value calibrated from consented users — and sums those amounts per campaign. Later coarse postbacks are used to adjust early estimates as cohorts mature.

Calibrate regularly. If your revenue distribution shifts — a new monetization feature, a pricing change, a seasonal event — bucket midpoints drift away from reality. Comparing SKAN-estimated revenue with actual revenue from consented users, or with total iOS revenue in your own analytics, shows when the mapping needs updating.

• Too many small campaigns, so most postbacks fall below privacy thresholds and arrive without detail.
• Revenue buckets copied from another app rather than sized on your own purchase distribution.
• Using all 64 fine values for engagement and leaving no room for revenue signal.
• Locking conversion values too early and discarding valuable day-two behavior.
• Changing the schema frequently, which makes week-over-week comparisons meaningless.
• Reading iOS results on the same day-one cadence as Android.

• SKAN 4 support enabled in your app and MMP SDK versions.
• Conversion-value schema designed, tested and documented.
• Source-identifier hierarchy agreed with your DSP and networks.
• Campaign structure consolidated to meet privacy thresholds.
• Reporting expectations set: delayed data, coarse values, and how ROAS will be estimated.