SKAdNetwork 4.0 Guide: How the Three Postback Windows Work

How does SKAdNetwork 4.0 multi-window attribution work? SKAdNetwork 4.0 divides conversion measurement into three sequential windows spanning days 0–2, 3–7, and 8–35 after the app’s first launch. Apple assigns a postback data tier to each app download, which determines whether eligible postbacks expose fine-grained, coarse-grained, or reduced attribution data.

SKAdNetwork 4.0 is Apple’s privacy-preserving mobile advertising attribution framework that enables privacy-safe campaign measurement on iOS. It introduces three sequential conversion windows spanning up to 35 days after first launch, hierarchical source identifiers, coarse-grained conversion values, and window locking mechanics to evaluate mid-funnel user lifetime value without harvesting persistent device identities.

At a Glance: Key Postback Timelines and Disclosure Rules

• Window 1 (Day 0–2 After First Launch): May disclose fine-grained (0–63) or coarse-grained (low, medium, high) values; dispatches after an additional randomized 24–48 hour delay.
• Window 2 (Day 3–7 After First Launch): May disclose a coarse-conversion-value when provided and permitted by the postback data tier; otherwise that field is absent. Dispatches after an additional randomized 24–144 hour delay.
• Window 3 (Day 8–35 After First Launch): May disclose a coarse-conversion-value when provided and permitted by the postback data tier; otherwise that field is absent. Dispatches after an additional randomized 24–144 hour delay.
• Tier 0 Data Constraint: Downloads landing in Tier 0 receive a single postback containing a 2-digit source ID and no conversion value; second and third postbacks are omitted.
• Multiple-Postback Requirement: To be eligible for multiple winning postbacks, the ad must be signed using SKAdNetwork 4 or later, and the advertised app must update conversion values during the applicable conversion windows.

What Is SKAdNetwork 4.0 and How Does Multi-Window Attribution Operate

The Structural Evolution from Single-Timer Constraints to Multi-Window Lifecycle Tracking

Early versions of Apple’s StoreKit Ad Network (SKAdNetwork 2.0 and 3.0) operated under a single 24-hour rolling timer. Under SKAdNetwork 3 and earlier, valid increasing conversion-value updates could extend the rolling conversion period by restarting the 24-hour timer. Once 24 hours elapsed without an update, the window closed, and Apple dispatched a single postback following a randomized delay.

This single-timer architecture created operational friction:

• Restricted Observation Horizons: Advertisers could only measure early engagement occurring during the initial days post-install.
• Reporting Delays: Repeated qualifying conversion updates could extend the effective measurement period and delay the final postback, slowing automated ad bidding algorithms.
• Limited Long-Tail Visibility: SKAdNetwork 3 had no dedicated later conversion windows for structured Day-7-to-Day-30 measurement.

SKAdNetwork 4.0 restructures this model by establishing three fixed, sequential measurement windows anchored to the user’s first application launch.

Decoupling Attribution Timers from Active User Sessions

In SKAdNetwork 4.0, conversion windows advance based on fixed calendar duration rather than continuous user activity. When an app is opened for the first time following an attributed ad impression, the operating system initiates Window 1.

Whether the user opens the application once or fifty times during the first 48 hours, Window 1 closes at the 48-hour mark (unless explicitly finalized early via window locking). The system then automatically advances to Window 2 (Day 3 through Day 7), followed by Window 3 (Day 8 through Day 35). This decoupling guarantees structured postback dispatch intervals for downstream data pipelines.

The Two-Legged Cryptographic Signature Chain

SKAdNetwork maintains data integrity using public-key cryptography across two distinct phases:

• Ad Impression Leg (Ad Network to Apple): When an ad network serves an impression, it signs the ad payload using its private key. Upon app installation and launch, the operating system validates this signature against the ad network’s public key registered with Apple to verify attribution eligibility.
• Install-Validation Leg (Apple to Ad Network/Developer): When a conversion window closes, Apple signs the install-validation postback payload. The receiving ad network and developer endpoint verify this signature using Apple’s public key to verify the authenticity and integrity of the postback.

See Also: SKAdNetwork ──> Mobile Attribution Model

The Mechanics of the Three Postback Windows and Measurement Timelines

Window 1: Capturing Early Engagement and High-Precision Conversion Signals

• Measurement Interval: Day 0 to Day 2 (first 48 hours after first launch).
• Data Disclosure Available: Fine-grained conversion value (6-bit integer from 0 to 63) or coarse-grained value (low, medium, high), determined by the assigned postback data tier.
• Randomized Postback Delay: 24 to 48 hours after the window closes or locks.
• Analytical Objective: Measuring immediate onboarding completion, tutorial milestones, initial purchase conversion, and early churn risk.

Window 2: Evaluating Early User Retention and Mid-Funnel Milestones

• Measurement Interval: Day 3 to Day 7 after first launch (hours 48 through 168).
• Data Disclosure Available: May disclose a coarse-conversion-value (low, medium, high) when provided and permitted by the postback data tier; otherwise that field is absent. Fine-grained values (0 to 63) are not supported in Window 2.
• Randomized Postback Delay: 24 to 144 hours (1 to 6 days) after the window closes or locks.
• Analytical Objective: Assessing Day-3 to Day-7 retention, multi-day engagement loops, initial subscription trials, and repeat purchasing behavior.

Window 3: Measuring Long-Tail Retention and Cumulative Lifetime Value

• Measurement Interval: Day 8 to Day 35 after first launch (hours 168 through 840).
• Data Disclosure Available: May disclose a coarse-conversion-value (low, medium, high) when provided and permitted by the postback data tier; otherwise that field is absent.
• Randomized Postback Delay: 24 to 144 hours (1 to 6 days) after the window closes or locks.
• Analytical Objective: Capturing Month-1 retention benchmarks, trial-to-paid subscription conversions, and long-tail monetization milestones.

Ad Impression
      │
      ▼
App Install
      │
      ▼
First App Launch  ← conversion measurement t = 0
      │
      ├── Window 1: Day 0–2 after first launch
      │      Fine or coarse disclosure
      │      24–48h randomized delay after close/lock
      │
      ├── Window 2: Day 3–7 after first launch
      │      Coarse disclosure only (or absent)
      │      24–144h randomized delay after close/lock
      │
      └── Window 3: Day 8–35 after first launch
             Coarse disclosure only (or absent)
             24–144h randomized delay after close/lock

Randomized Delay Mechanics: Window 1 versus Windows 2 and 3

To prevent timing-attack heuristics where an observer correlates the exact millisecond of an in-app transaction with the receipt of an attribution postback, Apple applies randomized dispatch delays:

• Window 1 Timer: If Window 1 closes naturally without an early lock, the first postback is sent after an additional randomized 24-to-48-hour delay.
• Windows 2 and 3 Timers: Apple expands the randomized delay window to 24 through 144 hours (up to 6 full days) to account for the extended duration of the measurement periods.

How Postback Data Tiers Control Disclosure

The Official Postback Data Tier Matrix

Apple assigns a postback data tier (Tier 0 through Tier 3) to app downloads based on the crowd associated with the source app or domain, the advertised app, the country of install, and the hierarchical source identifier. Apple does not publish universal install-count thresholds for Tier 0 through Tier 3.

How Hierarchical Source Identifiers Work

Structure and Granularity of the Source Identifier

SKAdNetwork 4.0 replaces the legacy 2-digit Campaign ID with a 4-digit hierarchical integer called the Source Identifier:

Ad networks and developers define the meaning of the hierarchical source identifier based on internal reporting requirements:

• Lower Two Digits ($d_2 d_1$): Form the minimum two-digit portion of the hierarchical source identifier that may be disclosed. Ad networks may use this portion for broad campaign grouping, but Apple does not prescribe a fixed business meaning.
• Higher-Order Digits ($d_4 d_3$): May encode internal dimensions such as ad placement, creative ID, or geographic target. Apple does not assign fixed business semantics to individual digits.

Original Source Identifier: [ d4 ] [ d3 ] [ d2 ] [ d1 ]

Possible disclosed forms in first winning postback:
2-digit disclosure:          [ d2 ] [ d1 ]
3-digit disclosure:    [ d3 ][ d2 ] [ d1 ]
4-digit disclosure: [ d4 ][ d3 ][ d2 ] [ d1 ]

The exact number of digits disclosed depends on Apple's postback data tier.

Campaign consolidation may increase the crowd associated with particular source identifiers, but Apple does not publish universal install thresholds and consolidation does not guarantee a specific postback data tier.

Fine-Grained versus Coarse-Grained Conversion Values

Fine-Grained Conversion Values

Fine-grained conversion values operate as 6-bit binary numbers representing integers from 0 to 63 ($2^6 = 64$ discrete values). Available strictly in Window 1 under Tier 2 or Tier 3 postback data tiers, fine values allow developers to encode granular revenue ranges, funnel stages, or bitwise event combinations.

Coarse-Grained Conversion Values

Coarse-grained conversion values provide a lower-granularity alternative when the applicable postback data tier does not permit fine-grained disclosure and serve as the conversion-value format for the second and third postbacks. Apple assigns no predefined business semantics to low, medium, or high; the examples below are illustrative application-defined mappings:

• low: Illustrative mapping for baseline engagement (e.g., initial app open or registration).
• medium: Illustrative mapping for intermediate engagement (e.g., completed tutorial or multi-day active session).
• high: Illustrative mapping for high-value conversion milestones (e.g., in-app purchase or trial activation).

For implementation-specific conversion schema design, see the SKAN conversion mapping documentation.

Postback Sequence Index Mapping

In SKAdNetwork 4 postbacks, the postback-sequence-index field identifies the corresponding conversion window:

Apple specifies that an install-validation postback may contain either a conversion-value (fine) or a coarse-conversion-value (coarse), but never both simultaneously.

The following payloads are illustrative SKAdNetwork 4 examples. Actual postback fields vary by postback sequence, postback data tier, ad type, and privacy disclosure conditions. The sample attribution-signature values are placeholders and are not cryptographically valid.

Example 1 below illustrates a Window 1 fine-grained postback payload, and Example 2 illustrates a Window 2 coarse-grained postback payload:

{
  "version": "4.0",
  "ad-network-id": "example123.skadnetwork",
  "source-identifier": "4821",
  "app-id": 1234567890,
  "transaction-id": "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d",
  "postback-sequence-index": 0,
  "conversion-value": 47,
  "fidelity-type": 1,
  "did-win": true,
  "attribution-signature": "MEQCIFz8...SAMPLE_CRYPTOGRAPHIC_SIGNATURE...=="
}

{
  "version": "4.0",
  "ad-network-id": "example123.skadnetwork",
  "source-identifier": "48",
  "app-id": 1234567890,
  "transaction-id": "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d",
  "postback-sequence-index": 1,
  "coarse-conversion-value": "high",
  "fidelity-type": 1,
  "did-win": true,
  "attribution-signature": "MEQCIFz8...SAMPLE_CRYPTOGRAPHIC_SIGNATURE...=="
}

Trade-Offs of Locking a Conversion Window Early

Accelerating Measurement with the lockWindow Parameter

By default, each measurement window remains open for its full calendar duration (48 hours for Window 1, 5 days for Window 2, 28 days for Window 3). When lockWindow is true, the update becomes the final conversion-value update for the active window. The system prepares the postback and ignores additional conversion-value updates for the remainder of that window.

Default Window 1 (No Lock):
[First Launch] ─────────────── 48 Hours Open ───────────────► [Closes] ──► Delay (24-48h) ──► Postback 1

Locked Window 1 (Purchase at Hour 6):
[First Launch] ── 6h (Lock: true) ──► [Conversion Value Locked / Postback Prepared] ──► Delay (24-48h) ──► Postback 1 Sent Sooner

Operational Considerations When Invoking Window Locks

• Accelerated Postback Dispatch: When a conversion is finalized early, the postback delay begins as soon as the locked conversion is finalized, rather than waiting for the full calendar window to elapse.
• Window Independence: Locking the current window does not move the start of the next window forward. The next conversion window still begins at its predefined time boundary (e.g., Window 2 begins on Day 3 regardless of when Window 1 was locked).
• Subsequent Event Lockout: Once lockWindow: true is executed, the operating system ignores all subsequent conversion value update calls during the remainder of that specific window.

The Swift code below demonstrates how to update fine and coarse conversion values and invoke window locks using StoreKit:

import Foundation
import StoreKit

enum SKANError: Error {
    case invalidFineValue
    case unsupportedOSVersion
}

final class SKAN4Manager {

    static let shared = SKAN4Manager()
    private init() {}

    /// Updates conversion values and optionally locks the active SKAN 4.0 window
    /// - Parameters:
    ///   - fineValue: 6-bit integer (0 to 63) for Window 1. Note: In Windows 2 and 3, SKAdNetwork ignores the fineValue parameter.
    ///   - coarseValue: Coarse value string ("low", "medium", "high") for all windows
    ///   - shouldLock: Boolean flag to immediately finalize the active window
    func updateConversionState(
        fineValue: Int,
        coarseValue: SKAdNetwork.CoarseConversionValue,
        shouldLock: Bool,
        completion: ((Error?) -> Void)? = nil
    ) {
        guard #available(iOS 16.1, *) else {
            completion?(SKANError.unsupportedOSVersion)
            return
        }

        // Validate fine-grained value bounds (0 to 63)
        guard (0...63).contains(fineValue) else {
            completion?(SKANError.invalidFineValue)
            return
        }

        // Execute asynchronous SKAN 4.0 conversion update
        SKAdNetwork.updatePostbackConversionValue(
            fineValue,
            coarseValue: coarseValue,
            lockWindow: shouldLock
        ) { error in
            if let error = error {
                print("SKAN 4.0 update failed: \(error.localizedDescription)")
            } else {
                print("SKAN 4.0 update succeeded - Fine: \(fineValue), Coarse: \(coarseValue.rawValue), Locked: \(shouldLock)")
            }
            completion?(error)
        }
    }

    /// Illustrative revenue mapping workflow (Do not copy specific thresholds directly to production)
    /// Note: In production, determine the active conversion window and define window-specific coarse-value logic.
    func handleInAppPurchase(amountUSD: Double) {
        let fineVal: Int
        let coarseVal: SKAdNetwork.CoarseConversionValue
        let lock: Bool

        switch amountUSD {
        case 0.0..<5.0:
            fineVal = 10
            coarseVal = .low
            lock = false
        case 5.0..<25.0:
            fineVal = 25
            coarseVal = .medium
            lock = false
        case 25.0...:
            fineVal = 60
            coarseVal = .high
            // Lock window immediately to expedite postback preparation for high-value conversion
            lock = true
        default:
            fineVal = 0
            coarseVal = .low
            lock = false
        }

        updateConversionState(fineValue: fineVal, coarseValue: coarseVal, shouldLock: lock)
    }
}

SKAdNetwork 4.0 and AdAttributionKit Interoperability

The Relationship Between SKAdNetwork and Apple AdAttributionKit

Apple introduced AdAttributionKit as an expanded attribution framework for iOS 17.4 and later. AdAttributionKit and SKAdNetwork can coexist, but they remain distinct attribution APIs:

• Framework-Specific API Invocations: Apps should call the conversion-update API that corresponds to the framework used by the ad network. If an ad network serves ads via AdAttributionKit, the app invokes AdAttributionKit conversion methods; if using SKAdNetwork, it calls StoreKit APIs.
• Cross-Framework Winner Selection: When both frameworks record qualifying impressions for a single installation, the operating system evaluates them together and selects a single winning impression for attribution.
• Bridging Behavior: Apple provides conversion-value bridging behavior for certain SKAdNetwork update calls to ensure compatibility across measurement layers.

SKAdNetwork 4 remains important for operating existing App Store attribution integrations, while Apple directs new app advertising implementations toward AdAttributionKit and documents interoperability between the two frameworks.

Comparative Matrix: Legacy SKAN 3.0 versus SKAN 4.0 Multi-Window Model

Summary and Decision Framework

SKAdNetwork 4.0 extends attribution visibility to 35 days from first app launch, introduces coarse-grained conversion values to provide lower-granularity measurement when fine-grained disclosure is unavailable, and allows developers to lock measurement windows to reduce postback latency when a conversion window is finalized early. Successful implementation requires careful conversion schema mapping across all three windows and aligning client-side update calls with genuine business milestones.

Application-level deep-link routing can operate alongside Apple’s privacy-preserving attribution frameworks as a separate measurement and onboarding layer. For implementation-specific deep-link routing and attribution workflows, see the OpoInstall documentation.

Related Materials

• Concepts: Multi-Window Attribution, Postback Data Tiers, Hierarchical Source Identifiers, Window Locking, Coarse Values

• Technologies: Apple SKAdNetwork, Apple AdAttributionKit, StoreKit Framework, OpoInstall Mobile SDK

• Standards: IETF RFC 8259 JSON Specification

• APIs: StoreKit updatePostbackConversionValue API, SKAdNetwork install-validation postbacks

Official Documentation

• Apple Developer Documentation on SKAdNetwork

• Apple Developer Documentation on AdAttributionKit

• Apple Developer Documentation on Receiving Postbacks in Multiple Conversion Windows

• Apple Developer Documentation on Identifying Parameters in Install-Validation Postbacks

• Apple Developer Documentation on Updating Postback Conversion Values

• Understanding AdAttributionKit and SKAdNetwork Interoperability