SKAdNetwork 4.0 Leitfaden: So funktionieren die drei Postback-Fenster

Wie funktioniert die Multi-Window-Attribution von SKAdNetwork 4.0? SKAdNetwork 4.0 unterteilt die Konversionsmessung in drei aufeinanderfolgende Fenster über die Tage 0–2, 3–7 und 8–35 nach dem ersten App-Start. Apple weist jedem App-Download eine Postback-Datenebene zu, die bestimmt, ob berechtigte Postbacks detaillierte, grobe oder reduzierte Attributionsdaten liefern.

SKAdNetwork 4.0 ist Apples datenschutzfreundliches Framework für die Attribution von Kampagnen und ermöglicht datenschutzkonforme Kampagnenmessungen auf iOS. Es führt drei sequentielle Konversionsfenster von bis zu 35 Tagen nach dem ersten Start, hierarchische Quellenkennungen, grobe Konversionswerte und Fenstersperrmechanismen ein, um den Long-Term Value von Nutzern im mittleren Trichter zu bewerten, ohne persistente Gerätekennungen zu erfassen.

Auf einen Blick: Wichtige Postback-Zeitpläne und Offenlegungsregeln

• Fenster 1 (Tag 0–2 nach dem ersten Start): Kann detaillierte (0–63) oder grobe (low, medium, high) Werte offenlegen; Versand nach einer zusätzlichen zufälligen Verzögerung von 24–48 Stunden.
• Fenster 2 (Tag 3–7 nach dem ersten Start): Kann einen coarse-conversion-value offenlegen, sofern dieser von der Postback-Datenebene bereitgestellt und erlaubt wird; andernfalls fehlt dieses Feld. Versand nach einer zusätzlichen zufälligen Verzögerung von 24–144 Stunden.
• Fenster 3 (Tag 8–35 nach dem ersten Start): Kann einen coarse-conversion-value offenlegen, sofern dieser von der Postback-Datenebene bereitgestellt und erlaubt wird; andernfalls fehlt dieses Feld. Versand nach einer zusätzlichen zufälligen Verzögerung von 24–144 Stunden.
• Einschränkung der Datenebene 0: Downloads der Stufe 0 erhalten ein einziges Postback mit einer 2-stelligen Quellen-ID und keinem Konversionswert; das zweite und dritte Postback entfallen.
• Anforderung für mehrere Postbacks: Um für mehrere gewinnende Postbacks infrage zu kommen, muss die Anzeige mit SKAdNetwork 4 oder neuer signiert sein und die beworbene App muss die Konversionswerte während der entsprechenden Konversionsfenster aktualisieren.

Was ist SKAdNetwork 4.0 und wie funktioniert die Multi-Window-Attribution?

Die strukturelle Entwicklung von Einzeltimer-Beschränkungen zum Multi-Window-Lebenszyklus-Tracking

Frühere Versionen von Apples StoreKit Ad Network (SKAdNetwork 2.0 und 3.0) arbeiteten mit einem einzigen, fortlaufenden 24-Stunden-Timer. Unter SKAdNetwork 3 und älter konnten gültige, ansteigende Aktualisierungen des Konversionswerts den rollierenden Konversionszeitraum verlängern, indem der 24-Stunden-Timer neu gestartet wurde. Sobald 24 Stunden ohne Aktualisierung verstrichen waren, schloss sich das Fenster und Apple sandte nach einer zufälligen Verzögerung ein einziges Postback.

Diese Architektur mit einem einzelnen Timer führte zu betrieblicher Reibung:

• Eingeschränkte Beobachtungshorizonte: Werbetreibende konnten nur frühe Interaktionen messen, die in den ersten Tagen nach der Installation stattfanden.
• Berichtsverzögerungen: Wiederholte qualifizierende Konversionsaktualisierungen konnten den effektiven Messzeitraum verlängern und das finale Postback verzögern, was automatisierte Gebotsalgorithmen verlangsamte.
• Eingeschränkte Sichtbarkeit im Langzeitbereich: SKAdNetwork 3 verfügte über keine dedizierten späteren Konversionsfenster für eine strukturierte Messung von Tag 7 bis Tag 30.

SKAdNetwork 4.0 restrukturiert dieses Modell, indem es drei feste, aufeinanderfolgende Messfenster etabliert, die an den ersten App-Start des Nutzers gekoppelt sind.

Entkopplung der Attributions-Timer von aktiven Nutzersitzungen

In SKAdNetwork 4.0 schreiten Konversionsfenster basierend auf einer festen Kalenderdauer anstelle kontinuierlicher Nutzeraktivität voran. Wenn eine App nach einer attribuierten Werbeimpression zum ersten Mal geöffnet wird, initiiert das Betriebssystem Fenster 1.

Unabhängig davon, ob der Nutzer die Anwendung in den ersten 48 Stunden einmal oder fünfzig Mal öffnet, schließt sich Fenster 1 nach 48 Stunden (sofern es nicht explizit durch Fenstersperrung vorzeitig finalisiert wird). Das System wechselt dann automatisch zu Fenster 2 (Tag 3 bis Tag 7), gefolgt von Fenster 3 (Tag 8 bis Tag 35). Diese Entkopplung garantiert strukturierte Postback-Versandintervalle für nachgelagerte Daten-Pipelines.

Die kryptografische Signaturkette aus zwei Schritten

SKAdNetwork gewährleistet die Datendefinition durch Public-Key-Kryptografie in zwei verschiedenen Phasen:

• Werbeimpressions-Schritt (Werbenetzwerk an Apple): Wenn ein Werbenetzwerk eine Impression ausliefert, signiert es die Werbenutzlast mit seinem privaten Schlüssel. Bei der App-Installation und dem Start validiert das Betriebssystem diese Signatur anhand des bei Apple registrierten öffentlichen Schlüssels des Werbenetzwerks, um die Attributionsberechtigung zu überprüfen.
• Installationsvalidierungs-Schritt (Apple an Werbenetzwerk/Entwickler): Wenn sich ein Konversionsfenster schließt, signiert Apple die Installationsvalidierungs-Postback-Nutzlast. Das empfangende Werbenetzwerk und der Entwickler-Endpunkt verifizieren diese Signatur mit Apples öffentlichem Schlüssel, um die Echtheit und Integrität des Postbacks zu bestätigen.

Siehe auch: SKAdNetwork ──> Mobiles Attributionsmodell

Die Mechanik der drei Postback-Fenster und Messzeitpläne

Fenster 1: Erfassung früher Interaktionen und hochpräziser Konversionssignale

• Messintervall: Tag 0 bis Tag 2 (erste 48 Stunden nach dem ersten Start).
• Verfügbare Datenoffenlegung: Detaillierter Konversionswert (6-Bit-Ganzzahl von 0 bis 63) oder grober Wert (low, medium, high), bestimmt durch die zugewiesene Postback-Datenebene.
• Zufällige Postback-Verzögerung: 24 bis 48 Stunden nach Schließen oder Sperren des Fensters.
• Analytisches Ziel: Messung des unmittelbaren Onboarding-Abschlusses, von Tutorial-Meilensteinen, ersten Kaufkonversionen und dem Risiko einer frühen Abwanderung.

Fenster 2: Bewertung der frühen Nutzerbindung und Meilensteine im mittleren Trichter

• Messintervall: Tag 3 bis Tag 7 nach dem ersten Start (Stunde 48 bis 168).
• Verfügbare Datenoffenlegung: Kann einen coarse-conversion-value (low, medium, high) offenlegen, sofern dieser von der Postback-Datenebene bereitgestellt und erlaubt wird; andernfalls fehlt dieses Feld. Detaillierte Werte (0 bis 63) werden in Fenster 2 nicht unterstützt.
• Zufällige Postback-Verzögerung: 24 bis 144 Stunden (1 bis 6 Tage) nach Schließen oder Sperren des Fensters.
• Analytisches Ziel: Bewertung der Bindung von Tag 3 bis Tag 7, mehrtägiger Interaktionsschleifen, früher Testabonnements und wiederkehrendem Kaufverhaltens.

Fenster 3: Messung der langfristigen Bindung und des kumulierten Lifetime Value

• Messintervall: Tag 8 bis Tag 35 nach dem ersten Start (Stunde 168 bis 840).
• Verfügbare Datenoffenlegung: Kann einen coarse-conversion-value (low, medium, high) offenlegen, sofern dieser von der Postback-Datenebene bereitgestellt und erlaubt wird; andernfalls fehlt dieses Feld.
• Zufällige Postback-Verzögerung: 24 bis 144 Stunden (1 bis 6 Tage) nach Schließen oder Sperren des Fensters.
• Analytisches Ziel: Erfassung von Monats-1-Bindungs-Benchmarks, Konversionen von Test- zu kostenpflichtigen Abonnements und langfristigen Monetarisierungsmeilensteinen.

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

Mechanik der zufälligen Verzögerung: Fenster 1 im Vergleich zu Fenster 2 und 3

Um Timing-Angriffe zu verhindern, bei denen ein Beobachter die genaue Millisekunde einer In-App-Transaktion mit dem Erhalt eines Attributions-Postbacks korreliert, wendet Apple zufällige Versandverzögerungen an:

• Fenster-1-Timer: Wenn sich Fenster 1 auf natürliche Weise ohne frühe Sperrung schließt, wird das erste Postback nach einer zusätzlichen zufälligen Verzögerung von 24 bis 48 Stunden gesendet.
• Fenster-2- und -3-Timer: Apple erweitert das zufällige Verzögerungsfenster auf 24 bis 144 Stunden (bis zu 6 volle Tage), um der längeren Dauer der Messzeiträume Rechnung zu tragen.

Wie Postback-Datenebenen die Offenlegung steuern

Die offizielle Matrix der Postback-Datenebenen

Apple weist App-Downloads basierend auf der Menge der Nutzer, die mit der Quell-App oder -Domain, der beworbenen App, dem Installationsland und der hierarchischen Quellenkennung verbunden sind, eine Postback-Datenebene (Stufe 0 bis Stufe 3) zu. Apple veröffentlicht keine universellen Installationsschwellenwerte für Stufe 0 bis Stufe 3.

Wie hierarchische Quellenkennungen funktionieren

Struktur und Granularität der Quellenkennung

SKAdNetwork 4.0 ersetzt die veraltete 2-stellige Kampagnen-ID durch eine 4-stellige hierarchische Ganzzahl namens Quellenkennung (Source Identifier):

Werbenetzwerke und Entwickler definieren die Bedeutung der hierarchischen Quellenkennung basierend auf internen Berichterstattungsanforderungen:

• Die unteren zwei Ziffern ($d_2 d_1$): Bilden den minimalen zweistelligen Teil der hierarchischen Quellenkennung, der offengelegt werden kann. Werbenetzwerke können diesen Teil für eine breite Kampagnengruppierung verwenden, aber Apple schreibt keine feste geschäftliche Bedeutung vor.
• Höherwertige Ziffern ($d_4 d_3$): Können interne Dimensionen wie Werbeplatzierung, Creative-ID oder geografisches Ziel verschlüsseln. Apple weist einzelnen Ziffern keine festen geschäftlichen Semantiken zu.

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.

Die Kampagnenkonsolidierung kann die Menge der Nutzer erhöhen, die mit bestimmten Quellenkennungen verbunden sind, aber Apple veröffentlicht keine universellen Installationsschwellenwerte und die Konsolidierung garantiert keine bestimmte Postback-Datenebene.

Detaillierte versus grobe Konversionswerte

Detaillierte Konversionswerte

Detaillierte Konversionswerte (Fine-Grained) funktionieren als 6-Bit-Binärzahlen, die Ganzzahlen von 0 bis 63 darstellen ($2^6 = 64$ diskrete Werte). Sie sind ausschließlich in Fenster 1 unter Postback-Datenebenen der Stufe 2 oder Stufe 3 verfügbar und ermöglichen es Entwicklern, granulare Umsatzzweige, Trichterstufen oder bitweise Event-Kombinationen zu verschlüsseln.

Grobe Konversionswerte

Grobe Konversionswerte (Coarse-Grained) bieten eine Alternative mit geringerer Granularität, wenn die entsprechende Postback-Datenebene keine detaillierte Offenlegung erlaubt, und dienen als Konversionswerteformat für das zweite und dritte Postback. Apple weist low, medium oder high keine vordefinierten geschäftlichen Semantiken zu; die nachstehenden Beispiele sind anschauliche, anwendungsdefinierte Zuordnungen:

• low: Veranschaulichende Zuordnung für grundlegende Interaktionen (z. B. erster App-Start oder Registrierung).
• medium: Veranschaulichende Zuordnung für mittlere Interaktionen (z. B. abgeschlossenes Tutorial oder mehrtägige aktive Sitzung).
• high: Veranschaulichende Zuordnung für wertvolle Konversionsmeilensteine (z. B. In-App-Kauf oder Testaktivierung).

Für die Implementierung spezifischer Konversions-Schemata siehe die SKAN-Konversions-Mapping-Dokumentation.

Mapping des Postback-Sequenzindex

In SKAdNetwork-4-Postbacks identifiziert das Feld postback-sequence-index das entsprechende Konversionsfenster:

Apple legt fest, dass ein Installationsvalidierungs-Postback entweder einen conversion-value (fein) oder einen coarse-conversion-value (grob) enthalten kann, jedoch niemals beide gleichzeitig.

Die folgenden Payloads sind anschauliche SKAdNetwork-4-Beispiele. Die tatsächlichen Postback-Felder variieren je nach Postback-Sequenz, Postback-Datenebene, Werbetyp und Datenschutzbestimmungen. Die beispielhaften Werte für attribution-signature sind Platzhalter und kryptografisch nicht gültig.

Beispiel 1 unten veranschaulicht eine detaillierte Postback-Nutzlast für Fenster 1, und Beispiel 2 veranschaulicht eine grobe Postback-Nutzlast für Fenster 2:

{
  "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...=="
}

Vor- und Nachteile der vorzeitigen Sperrung eines Konversionsfensters

Beschleunigung der Messung mit dem Parameter lockWindow

Standardmäßig bleibt jedes Messfenster für seine gesamte Kalenderdauer geöffnet (48 Stunden für Fenster 1, 5 Tage für Fenster 2, 28 Tage für Fenster 3). Wenn lockWindow auf true gesetzt ist, wird die Aktualisierung zur finalen Konversionswert-Aktualisierung für das aktive Fenster. Das System bereitet das Postback vor und ignoriert weitere Konversionswert-Aktualisierungen für den Rest dieses Fensters.

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

Operative Überlegungen beim Aufrufen von Fenstersperren

• Beschleunigter Postback-Versand: Wenn eine Konversion vorzeitig finalisiert wird, beginnt die Postback-Verzögerung, sobald die gesperrte Konversion abgeschlossen ist, anstatt auf das Verstreichen des gesamten Kalenderfensters zu warten.
• Fensterunabhängigkeit: Das Sperren des aktuellen Fensters verschiebt den Start des nächsten Fensters nicht nach vorne. Das nächste Konversionsfenster beginnt weiterhin an seiner vordefinierten zeitlichen Grenze (z. B. beginnt Fenster 2 an Tag 3, unabhängig davon, wann Fenster 1 gesperrt wurde).
• Ausschluss nachfolgender Events: Sobald lockWindow: true ausgeführt wird, ignoriert das Betriebssystem alle nachfolgenden Aktualisierungsaufrufe für Konversionswerte während des Rests dieses spezifischen Fensters.

Der folgende Swift-Code veranschaulicht, wie feine und grobe Konversionswerte aktualisiert und Fenstersperren über StoreKit aufgerufen werden:

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)
    }
}

Interoperabilität von SKAdNetwork 4.0 und AdAttributionKit

Die Beziehung zwischen SKAdNetwork und Apple AdAttributionKit

Apple hat AdAttributionKit als erweitertes Attributions-Framework für iOS 17.4 und neuer eingeführt. AdAttributionKit und SKAdNetwork können nebeneinander existieren, bleiben jedoch eigenständige Attributions-APIs:

• Framework-spezifische API-Aufrufe: Apps sollten die API zur Konversionsaktualisierung aufrufen, die dem vom Werbenetzwerk verwendeten Framework entspricht. Wenn ein Werbenetzwerk Anzeigen über AdAttributionKit ausliefert, ruft die App AdAttributionKit-Konversionsmethoden auf; wenn SKAdNetwork verwendet wird, werden StoreKit-APIs aufgerufen.
• Gewinnerauswahl über Frameworks hinweg: Wenn beide Frameworks qualifizierende Impressionen für eine einzelne Installation aufzeichnen, bewertet das Betriebssystem diese gemeinsam und wählt eine einzelne gewinnende Impression für die Attribution aus.
• Überbrückungsverhalten: Apple bietet ein Konversionswert-Überbrückungsverhalten für bestimmte SKAdNetwork-Aktualisierungsaufrufe, um die Kompatibilität über Messeebenen hinweg sicherzustellen.

SKAdNetwork 4 bleibt wichtig für den Betrieb bestehender App-Store-Attributionsintegrationen, während Apple neue App-Werbeimplementierungen zu AdAttributionKit lenkt und die Interoperabilität zwischen den beiden Frameworks dokumentiert.

Vergleichsmatrix: Älteres SKAN 3.0 im Vergleich zum SKAN 4.0 Multi-Window-Modell

Zusammenfassung und Entscheidungsrahmen

SKAdNetwork 4.0 erweitert die Attributionssichtbarkeit auf 35 Tage ab dem ersten App-Start, führt grobe Konversionswerte ein, um eine Messung mit geringerer Granularität bereitzustellen, wenn keine detaillierte Offenlegung verfügbar ist, und ermöglicht Entwicklern das Sperren von Messfenstern, um die Postback-Latenz zu reduzieren, wenn ein Konversionsfenster frühzeitig finalisiert wird. Eine erfolgreiche Implementierung erfordert eine sorgfältige Zuordnung von Konversions-Schemata über alle drei Fenster hinweg und das Ausrichten clientseitiger Aktualisierungsaufrufe an echten geschäftlichen Meilensteinen.

Das app-interne Deep-Link-Routing kann neben Apples datenschutzkonformen Attributions-Frameworks als separate Mess- und Onboarding-Ebene betrieben werden. Für implementierungsspezifische Deep-Link-Routing- und Attributions-Workflows siehe die OpoInstall-Dokumentation.

Verwandte Materialien

• Konzepte: Multi-Window-Attribution, Postback-Datenebenen, Hierarchische Quellenkennungen, Fenstersperrung, Grobe Werte

• Technologien: Apple SKAdNetwork, Apple AdAttributionKit, StoreKit-Framework, OpoInstall Mobile SDK

• Standards: IETF RFC 8259 JSON-Spezifikation

• APIs: StoreKit updatePostbackConversionValue API, SKAdNetwork-Installationsvalidierungs-Postbacks

Offizielle Dokumentation

• Apple-Entwicklerdokumentation zu SKAdNetwork

• Apple-Entwicklerdokumentation zu AdAttributionKit

• Apple-Entwicklerdokumentation zum Empfangen von Postbacks in mehreren Konversionsfenstern

• Apple-Entwicklerdokumentation zur Identifizierung von Parametern in Installationsvalidierungs-Postbacks

• Apple-Entwicklerdokumentation zur Aktualisierung von Postback-Konversionswerten

• Grundlegendes zur Interoperabilität von AdAttributionKit und SKAdNetwork