Guide SKAdNetwork 4.0 : Comment fonctionnent les trois fenêtres de postback

Comment fonctionne l'attribution multi-fenêtre de SKAdNetwork 4.0 ? SKAdNetwork 4.0 divise la mesure des conversions en trois fenêtres séquentielles couvrant les jours 0 à 2, 3 à 7 et 8 à 35 après le premier lancement de l'application. Apple attribue un niveau de données de postback à chaque téléchargement d'application, ce qui détermine si les postbacks éligibles exposent des données d'attribution détaillées (fines), grossières ou réduites.

SKAdNetwork 4.0 est le framework d'attribution publicitaire mobile d'Apple préservant la confidentialité, qui permet de mesurer les campagnes sur iOS en toute sécurité. Il introduit trois fenêtres de conversion séquentielles s'étendant jusqu'à 35 jours après le premier lancement, des identifiants de source hiérarchiques, des valeurs de conversion grossières et des mécanismes de verrouillage de fenêtre pour évaluer la valeur vie client à mi-parcours sans collecter d'identifiants d'appareils persistants.

En un coup d'œil : Chronologies clés des postbacks et règles de divulgation

• Fenêtre 1 (Jours 0 à 2 après le premier lancement) : Peut divulguer des valeurs détaillées (0 à 63) ou grossières (low, medium, high) ; s'envoie après un délai supplémentaire aléatoire de 24 à 48 heures.
• Fenêtre 2 (Jours 3 à 7 après le premier lancement) : Peut divulguer un coarse-conversion-value lorsqu'il est fourni et autorisé par le niveau de données de postback ; sinon, ce champ est absent. S'envoie après un délai supplémentaire aléatoire de 24 à 144 heures.
• Fenêtre 3 (Jours 8 à 35 après le premier lancement) : Peut divulguer un coarse-conversion-value lorsqu'il est fourni et autorisé par le niveau de données de postback ; sinon, ce champ est absent. S'envoie après un délai supplémentaire aléatoire de 24 à 144 heures.
• Contrainte de données du Niveau 0 : Les téléchargements relevant du Niveau 0 reçoivent un unique postback contenant un ID de source à 2 chiffres et aucune valeur de conversion ; les deuxième et troisième postbacks sont omis.
• Exigence de postbacks multiples : Pour être éligible à plusieurs postbacks gagnants, la publicité doit être signée à l'aide de SKAdNetwork 4 ou d'une version ultérieure, et l'application annoncée doit mettre à jour les valeurs de conversion pendant les fenêtres de conversion applicables.

Qu'est-ce que SKAdNetwork 4.0 et comment fonctionne l'attribution multi-fenêtre

L'évolution structurelle des contraintes à minuteur unique vers le suivi du cycle de vie multi-fenêtre

Les versions initiales de StoreKit Ad Network d'Apple (SKAdNetwork 2.0 et 3.0) fonctionnaient avec un unique minuteur glissant de 24 heures. Sous SKAdNetwork 3 et les versions antérieures, des mises à jour valides et croissantes de la valeur de conversion pouvaient prolonger la période de conversion glissante en redémarrant le minuteur de 24 heures. Une fois les 24 heures écoulées sans mise à jour, la fenêtre se fermait et Apple envoyait un postback unique après un délai aléatoire.

Cette architecture à minuteur unique créait des frictions opérationnelles :

• Horizons d'observation restreints : Les annonceurs ne pouvaient mesurer que l'engagement précoce se produisant pendant les premiers jours suivant l'installation.
• Retards de reporting : Des mises à jour de conversion qualifiantes répétées pouvaient prolonger la période de mesure effective et retarder le postback final, ralentissant ainsi les algorithmes d'enchères publicitaires automatisés.
• Visibilité à long terme limitée : SKAdNetwork 3 ne disposait pas de fenêtres de conversion ultérieures dédiées à une mesure structurée du 7e au 30e jour.

SKAdNetwork 4.0 restructure ce modèle en établissant trois fenêtres de mesure fixes et séquentielles ancrées sur le premier lancement de l'application par l'utilisateur.

Dissociation des minuteurs d'attribution et des sessions utilisateur actives

Dans SKAdNetwork 4.0, les fenêtres de conversion progressent en fonction d'une durée calendaire fixe plutôt que de l'activité continue de l'utilisateur. Lorsqu'une application est ouverte pour la première fois à la suite d'une impression publicitaire attribuée, le système d'exploitation lance la Fenêtre 1.

Que l'utilisateur ouvre l'application une ou cinquante fois au cours des premières 48 heures, la Fenêtre 1 se ferme à la marque des 48 heures (sauf clôture anticipée explicite via le verrouillage de fenêtre). Le système passe ensuite automatiquement à la Fenêtre 2 (du 3e au 7e jour), puis à la Fenêtre 3 (du 8e au 35e jour). Cette dissociation garantit des intervalles d'envoi de postbacks structurés pour les pipelines de données en aval.

La chaîne de signature cryptographique à deux volets

SKAdNetwork maintient l'intégrité des données à l'aide de la cryptographie à clé publique à travers deux phases distinctes :

• Volet Impression publicitaire (Réseau ad vers Apple): Lorsqu'un réseau publicitaire diffuse une impression, il signe la charge utile publicitaire à l'aide de sa clé privée. Lors de l'installation et du lancement de l'application, le système d'exploitation valide cette signature par rapport à la clé publique du réseau publicitaire enregistrée auprès d'Apple pour vérifier l'éligibilité à l'attribution.
• Volet Validation d'installation (Apple vers Réseau ad/Développeur): Lorsqu'une fenêtre de conversion se ferme, Apple signe la charge utile du postback de validation d'installation. Le réseau publicitaire récepteur et le point de terminaison du développeur vérifient cette signature à l'aide de la clé publique d'Apple pour valider l'authenticité et l'intégrité du postback.

Voir aussi : SKAdNetwork ──> Modèle d'attribution mobile

La mécanique des trois fenêtres de postback et des chronologies de mesure

Fenêtre 1 : Capturer l'engagement précoce et les signaux de conversion de haute précision

• Intervalle de mesure : Du 0e au 2e jour (les 48 premières heures suivant le premier lancement).
• Divulgation de données disponible : Valeur de conversion détaillée (entier de 6 bits de 0 à 63) ou valeur grossière (low, medium, high), déterminée par le niveau de données de postback attribué.
• Délai de postback aléatoire : 24 à 48 heures après la fermeture ou le verrouillage de la fenêtre.
• Objectif analytique : Mesurer la fin de l'onboarding immédiat, les étapes clés du didacticiel, la conversion d'achat initiale et le risque d'attrition précoce.

Fenêtre 2 : Évaluer la rétention précoce des utilisateurs et les jalons à mi-parcours

• Intervalle de mesure : Du 3e au 7e jour après le premier lancement (de la 48e à la 168e heure).
• Divulgation de données disponible : Peut divulguer un coarse-conversion-value (low, medium, high) lorsqu'il est fourni et autorisé par le niveau de données de postback ; sinon, ce champ est absent. Les valeurs détaillées (0 à 63) ne sont pas prises en charge dans la Fenêtre 2.
• Délai de postback aléatoire : 24 à 144 heures (1 à 6 jours) après la fermeture ou le verrouillage de la fenêtre.
• Objectif analytique : Évaluer la rétention du 3e au 7e jour, les boucles d'engagement sur plusieurs jours, les essais d'abonnement initiaux et le comportement d'achat répété.

Fenêtre 3 : Mesurer la rétention à long terme et la valeur vie client cumulative

• Intervalle de mesure : Du 8e au 35e jour après le premier lancement (de la 168e à la 840e heure).
• Divulgation de données disponible : Peut divulguer un coarse-conversion-value (low, medium, high) lorsqu'il est fourni et autorisé par le niveau de données de postback ; sinon, ce champ est absent.
• Délai de postback aléatoire : 24 à 144 heures (1 à 6 jours) après la fermeture ou le verrouillage de la fenêtre.
• Objectif analytique : Capturer les repères de rétention du 1er mois, les conversions d'essai en abonnement payant et les jalons de monétisation à long terme.

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

Mécanique des délais aléatoires : Fenêtre 1 par rapport aux Fenêtres 2 et 3

Pour empêcher les heuristiques d'attaque temporelle où un observateur corrèle la milliseconde exacte d'une transaction in-app avec la réception d'un postback d'attribution, Apple applique des délais de transmission aléatoires :

• Minuteur de la Fenêtre 1 : Si la Fenêtre 1 se ferme naturellement sans verrouillage anticipé, le premier postback est envoyé après un délai supplémentaire aléatoire de 24 à 48 heures.
• Minuteurs des Fenêtres 2 et 3 : Apple étend la fenêtre de délai aléatoire de 24 à 144 heures (jusqu'à 6 jours complets) pour tenir compte de la durée prolongée des périodes de mesure.

Comment les niveaux de données de postback contrôlent la divulgation

La matrice officielle des niveaux de données de postback

Apple attribue un niveau de données de postback (du Niveau 0 au Niveau 3) aux téléchargements d'applications en fonction de la cohorte associée à l'application ou au domaine source, à l'application annoncée, au pays d'installation et à l'identifiant de source hiérarchique. Apple ne publie pas de seuils universels de nombre d'installations pour les Niveaux 0 à 3.

Comment fonctionnent les identifiants de source hiérarchiques

Structure et granularité de l'identifiant de source

SKAdNetwork 4.0 remplace l'ancien ID de campagne à 2 chiffres par un entier hiérarchique à 4 chiffres appelé l'identifiant de source :

Les réseaux publicitaires et les développeurs définissent la signification de l'identifiant de source hiérarchique en fonction des exigences de reporting internes :

• Deux chiffres inférieurs ($d_2 d_1$) : Constituent la partie minimale de deux chiffres de l'identifiant de source hiérarchique qui peut être divulguée. Les réseaux publicitaires peuvent utiliser cette partie pour le regroupement de campagnes larges, mais Apple ne prescrit pas de signification commerciale fixe.
• Chiffres d'ordre supérieur ($d_4 d_3$) : Peuvent encoder des dimensions internes telles que l'emplacement publicitaire, l'ID de création ou la cible géographique. Apple n'attribue pas de sémantique commerciale fixe aux chiffres individuels.

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.

La consolidation des campagnes peut augmenter la cohorte associée à des identifiants de source particuliers, mais Apple ne publie pas de seuils d'installation universels et la consolidation ne garantit pas un niveau de données de postback spécifique.

Valeurs de conversion détaillées (fines) versus grossières

Valeurs de conversion détaillées (fines)

Les valeurs de conversion détaillées fonctionnent comme des nombres binaires à 6 bits représentant des entiers de 0 à 63 ($2^6 = 64$ valeurs distinctes). Disponibles strictement dans la Fenêtre 1 sous les niveaux de données de postback Niveau 2 ou Niveau 3, les valeurs fines permettent aux développeurs d'encoder des plages de revenus granulaires, des étapes de tunnel de conversion ou des combinaisons d'événements au niveau du bit.

Valeurs de conversion grossières

Les valeurs de conversion grossières offrent une alternative à granularité inférieure lorsque le niveau de données de postback applicable ne permet pas une divulgation détaillée et servent de format de valeur de conversion pour les deuxième et troisième postbacks. Apple n'attribue aucune sémantique commerciale prédéfinie à low, medium ou high ; les exemples ci-dessous sont des mappages définis par l'application à titre indicatif :

• low : Mappage illustratif pour un engagement de base (par ex., première ouverture d'application ou inscription).
• medium : Mappage illustratif pour un engagement intermédiaire (par ex., tutoriel complété ou session active sur plusieurs jours).
• high : Mappage illustratif pour des jalons de conversion à haute valeur (par ex., achat in-app ou activation d'essai).

Pour la conception de schémas de conversion spécifiques à votre implémentation, consultez la documentation sur le mappage des conversions SKAN.

Mappage de l'index de séquence de postbacks

Dans les postbacks SKAdNetwork 4, le champ postback-sequence-index identifie la fenêtre de conversion correspondante :

Apple spécifie qu'un postback de validation d'installation peut contenir soit un conversion-value (détaillé), soit un coarse-conversion-value (grossier), mais jamais les deux simultanément.

Les charges utiles suivantes sont des exemples illustratifs de SKAdNetwork 4. Les champs de postback réels varient selon la séquence de postbacks, le niveau de données de postback, le type d'annonce et les conditions de divulgation de la confidentialité. Les valeurs d'exemple attribution-signature sont des espaces réservés et ne sont pas valides cryptographiquement.

L'Exemple 1 ci-dessous illustre une charge utile de postback détaillé pour la Fenêtre 1, et l'Exemple 2 illustre une charge utile de postback grossier pour la Fenêtre 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...=="
}

Compromis liés au verrouillage anticipé d'une fenêtre de conversion

Accélération de la mesure avec le paramètre lockWindow

Par défaut, chaque fenêtre de mesure reste ouverte pendant toute sa durée calendaire (48 heures pour la Fenêtre 1, 5 jours pour la Fenêtre 2, 28 jours pour la Fenêtre 3). Lorsque lockWindow est réglé sur true, la mise à jour devient la dernière mise à jour de la valeur de conversion pour la fenêtre active. Le système prépare le postback et ignore les mises à jour supplémentaires de la valeur de conversion pour le reste de cette fenêtre.

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

Considérations opérationnelles lors de l'appel des verrouillages de fenêtre

• Envoi de postback accéléré : Lorsqu'une conversion est finalisée de manière anticipée, le délai de postback commence dès que la conversion verrouillée est finalisée, au lieu d'attendre l'écoulement complet de la fenêtre calendaire.
• Indépendance des fenêtres : Le verrouillage de la fenêtre en cours ne déplace pas le début de la fenêtre suivante. La fenêtre de conversion suivante commence toujours à sa limite temporelle prédéfinie (par ex., la Fenêtre 2 commence le 3e jour, quel que soit le moment où la Fenêtre 1 a été verrouillée).
• Blocage des événements ultérieurs : Une fois que lockWindow: true est exécuté, le système d'exploitation ignore tous les appels de mise à jour de la valeur de conversion ultérieurs pendant le reste de cette fenêtre spécifique.

Le code Swift ci-dessous montre comment mettre à jour des valeurs de conversion fines et grossières et invoquer des verrouillages de fenêtre à l'aide de 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)
    }
}

Interopérabilité entre SKAdNetwork 4.0 et AdAttributionKit

La relation entre SKAdNetwork et Apple AdAttributionKit

Apple a introduit AdAttributionKit en tant que framework d'attribution étendu pour iOS 17.4 et les versions ultérieures. AdAttributionKit et SKAdNetwork peuvent coexister, mais ils restent des API d'attribution distinctes :

• Appels d'API spécifiques au framework : Les applications doivent appeler l'API de mise à jour de conversion qui correspond au framework utilisé par le réseau publicitaire. Si un réseau publicitaire diffuse des annonces via AdAttributionKit, l'application invoque les méthodes de conversion d'AdAttributionKit ; si elle utilise SKAdNetwork, elle appelle les API StoreKit.
• Sélection du gagnant inter-framework : Lorsque les deux frameworks enregistrent des impressions qualifiées pour une seule installation, le système d'exploitation les évalue ensemble et sélectionne une impression gagnante unique pour l'attribution.
• Comportement de transition (bridge) : Apple fournit un comportement de pontage de la valeur de conversion pour certains appels de mise à jour SKAdNetwork afin de garantir la compatibilité entre les couches de mesure.

SKAdNetwork 4 reste important pour l'exploitation des intégrations d'attribution de l'App Store existantes, tandis qu'Apple oriente les nouvelles implémentations publicitaires d'applications vers AdAttributionKit et documente l'interopérabilité entre les deux frameworks.

Matrice comparative : Ancien modèle SKAN 3.0 versus modèle multi-fenêtre SKAN 4.0

Résumé et cadre de décision

SKAdNetwork 4.0 étend la visibilité de l'attribution à 35 jours à compter du premier lancement de l'application, introduit des valeurs de conversion grossières pour offrir une mesure à granularité inférieure lorsque la divulgation détaillée n'est pas disponible, et permet aux développeurs de verrouiller les fenêtres de mesure afin de réduire la latence des postbacks lorsqu'une fenêtre de conversion est finalisée de manière anticipée. Une mise en œuvre réussie nécessite un mappage minutieux des schémas de conversion dans les trois fenêtres et l'alignement des appels de mise à jour côté client sur des jalons commerciaux réels.

Le routage de liens profonds au niveau de l'application peut fonctionner parallèlement aux frameworks d'attribution d'Apple préservant la confidentialité en tant que couche de mesure et d'onboarding distincte. Pour des workflows d'attribution et de routage de liens profonds spécifiques à votre implémentation, consultez la documentation d'OpoInstall.

Documents associés

• Concepts : Attribution multi-fenêtre, Niveaux de données de postback, Identifiants de source hiérarchiques, Verrouillage de fenêtre, Valeurs grossières

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

• Standards : Spécification JSON IETF RFC 8259

• API : API StoreKit updatePostbackConversionValue, Postbacks de validation d'installation SKAdNetwork

Documentation officielle

• Documentation du développeur Apple sur SKAdNetwork

• Documentation du développeur Apple sur AdAttributionKit

• Documentation du développeur Apple sur la réception de postbacks dans plusieurs fenêtres de conversion

• Documentation du développeur Apple sur l'identification des paramètres dans les postbacks de validation d'installation

• Documentation du développeur Apple sur la mise à jour des valeurs de conversion des postbacks

• Comprendre l'interopérabilité entre AdAttributionKit et SKAdNetwork