SKAN 4 postback windows: Apple’s current conversion windows and lock behaviour
Apple SKAdNetwork 4 conversion windows—days 0–2, 3–7 and 8–35—plus lock-window delays from current StoreKit documentation.
Apple’s current StoreKit documentation for SKAdNetwork 4 defines three conversion windows that can yield up to three winning postbacks, with optional lockWindow behaviour that finalises a value early. Measurement leads should map conversion schemas to these Apple values rather than MMP paraphrases. SKAdNetwork 4 generally requires iOS 16.1+ participants as stated in the version 4 release notes; the window lengths themselves are specified on the multiple-conversion-windows article.
What the documentation currently requires
Receiving postbacks in multiple conversion windows (Apple Developer Documentation; markdown read from the source 19 September 2026) states:
- The conversion window begins when the user first launches the app.
- First window: days 0 to 2.
- Second window: days 3 to 7.
- Third window: days 8 to 35.
- Apps may update conversion values in all three windows.
- Eligibility for multiple postbacks: ad network signs with SKAdNetwork 4 or later; advertised app calls
updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:)orupdatePostbackConversionValue(_:coarseValue:completionHandler:)in each window. - Without a lock, the system prepares the postback when the window ends, then sends after a random delay: 24–48 hours for the first postback; 24–144 hours for the second and third.
- With lockWindow enabled, the system prepares immediately on lock, ignores further updates in that window, and applies the same delay bands after the lock.
- Fine
conversion-valueis relevant to the first postback (tier-dependent); second and third postbacks use coarse values (low/medium/high) when provided. Tier 0 receives only the first postback.
SKAdNetwork 4 release notes state version “4.0” signing, and that advertised apps built with iOS 16.1 SDK or later can register up to three conversions; earlier SDKs only one.
What is recommendation, not Apple law
How a studio packs revenue or tutorial events into fine/coarse values is a schema design choice. Crowding all value into day 0–2 is common industry practice but is not mandated by Apple on these pages.
Who should act, and how
- Align MMP/SKAN schemas to windows 0–2 / 3–7 / 8–35 from first launch.
- Decide explicitly whether to lock early for faster postbacks versus waiting for end-of-window.
- Reserve fine values for window 1; plan coarse-only utility for windows 2–3.
- Confirm network signatures and app SDK meet SKAN 4 / iOS 16.1 conditions before expecting three postbacks.
Applicability table
| Provider / field | Dates | Applies to | Documented change / value | Owner | Next check |
|---|---|---|---|---|---|
| Apple SKAdNetwork 4 | Version docs current at retrieve 19 Sep 2026 | iOS install measurement | Three conversion windows; up to three winning postbacks | Measurement lead | Re-read on StoreKit doc update |
| Window 1 | Documented as days 0–2 | Same | Fine value eligible (tier-dependent); delay 24–48h | Measurement + MMP | Map early events |
| Window 2 | Days 3–7 | Same | Coarse value; delay 24–144h | Measurement + MMP | Map mid-week events |
| Window 3 | Days 8–35 | Same | Coarse value; delay 24–144h | Measurement + MMP | Map day-8+ events |
| lockWindow | Documented API behaviour | Same | Finalises early; ignores further updates in window | App eng | Review lock policy |
| SKAN 4 participant conditions | Per release notes | Networks + advertised apps | Sign 4.0; iOS 16.1+ as documented | UA + eng | Audit SDK versions |
Download the applicability table.
Limits of this record
Based on Apple StoreKit documentation only. No MMP UI was inspected. Crowd-anonymity tiers affect which fields appear; this record does not predict tier outcomes for a title.
