Mappage des valeurs de conversion SKAdNetwork : Automatiser les schémas SKAN dynamiques

Comment un MMP mappe-t-il automatiquement les schémas SKAdNetwork ? Un partenaire de mesure mobile (MMP) ou un backend d'attribution automatise le mappage des schémas SKAdNetwork en traduisant les événements in-app et les paliers de revenus en schémas de configuration JSON dynamiques et versionnés sur une console centralisée. Le SDK mobile récupère cette configuration au lancement et évalue les règles de conversion localement à l'exécution, permettant aux modifications de règles de conversion prises en charge d'être appliquées sans nécessiter une nouvelle publication de binaire d'application.

Un schéma de valeur de conversion SKAdNetwork est un ensemble de règles au niveau du fournisseur ou de l'application qui associe les comportements des utilisateurs in-app — tels que les transactions de revenus, les étapes d'intégration ou l'engagement avec les fonctionnalités — aux valeurs fines à 6 bits d'Apple (0 à 63) et aux valeurs grossières à 3 paliers (low, medium, high). Les architectures de mappage dynamique distribuent des fichiers de configuration versionnés d'un backend cloud vers le SDK client, éliminant ainsi le besoin d'intégrer en dur la logique de conversion dans les binaires d'applications iOS compilés.

L'architecture du mappage automatisé des valeurs de conversion SKAdNetwork

Délimitation de la couche plateforme Apple et de la couche schéma fournisseur

Pour concevoir un moteur de valeur de conversion robuste, les équipes d'ingénierie doivent séparer les règles du framework natif d'Apple des abstractions de schémas au niveau du fournisseur :

• Couche plateforme Apple : Régit les primitives principales du système d'exploitation, notamment les trois fenêtres de conversion séquentielles (Jour 0-2, Jour 3-7, Jour 8-35 après le premier lancement), les valeurs fines à 6 bits (0-63), les valeurs grossières (low, medium, high), les niveaux de données de postback et l'API SKAdNetwork.updatePostbackConversionValue.
• Couche schéma fournisseur : Englobe les règles métier définies par l'application, telles que le regroupement par tranches de revenus, les progressions dans l'entonnoir d'intégration, l'allocation de drapeaux au niveau binaire, la synchronisation JSON à distance et l'évaluation des règles côté client.

┌────────────────────────────────────────┐
│                           Vendor Schema Layer                                  │
│  [MMP / Analytics Console] ──► [Publishes Versioned JSON Configuration]     │
│                                              │                                │
│  [Client Mobile SDK]       ──► [Evaluates In-App Events Locally in Memory]  │
└──────────────────────────────────────┬─┘
                                       │ (Calculates Fine, Coarse, & Lock)
                                       ▼
┌────────────────────────────────────────┐
│                           Apple Platform Layer                                 │
│  [StoreKit Framework]      ──► [SKAdNetwork.updatePostbackConversionValue]  │
│  [Operating System]        ──► [Manages Conversion Windows & Timers]        │
│  [System]                  ──► [Prepares and Sends Signed Postback]         │
└────────────────────────────────────────┘

Les pièges de la logique de conversion codée en dur

Coder en dur la logique de conversion directement dans une cible d'application iOS crée des limitations opérationnelles importantes :

• Dépendance aux révisions de l'App Store : Toute modification des seuils de revenus, des pondérations d'événements ou des déclencheurs de verrouillage de fenêtre nécessite un cycle de publication de binaire complet.
• Fragmentation des versions : De multiples versions historiques d'applications en production transmettent des sémantiques de conversion contradictoires, corrompant les modèles de reporting en aval.
• Manque de flexibilité d'optimisation : Les équipes de croissance ne peuvent pas ajuster les stratégies de conversion entre les campagnes axées sur l'engagement et celles axées sur la monétisation en fonction des performances marketing en temps réel.

Le pipeline de diffusion de configuration dynamique

Les architectures de mappage automatisé découplent la logique de conversion du binaire compilé via un pipeline à plusieurs étapes :

1. Configuration de la console : Les spécialistes du marketing et les analystes configurent les pondérations des événements, les niveaux de devise et les règles de verrouillage de fenêtre sur un tableau de bord centralisé.
2. Versionnement et épinglage des schémas : Le backend publie une charge utile de configuration JSON versionnée. Pour éviter la dérive sémantique pendant le cycle de vie de conversion de 35 jours de l'utilisateur, une implémentation robuste du fournisseur épingle la configuration de schéma active établie lors de la fenêtre de conversion initiale, garantissant que les règles de mappage exactes restent disponibles même après les redémarrages de l'application.
3. Ingestion et mise en cache côté client : Le SDK mobile télécharge le schéma actif lors de l'initialisation de l'application et met en cache à la fois la charge utile de configuration et les métadonnées de version dans le stockage persistant local.
4. Évaluation des règles locales : Lorsque des événements in-app se produisent, le SDK les évalue par rapport à l'ensemble de règles mis en cache localement, sans ajouter de requête de configuration distante synchrone au chemin d'exécution des événements.

Voir aussi : SKAdNetwork ──> Architecture d'attribution mobile

Conception de schémas de valeurs de conversion dynamiques à travers les fenêtres SKAN 4.0

Partitionnement de schéma multi-fenêtre

SKAdNetwork 4.0 structure la mesure des conversions sur trois fenêtres séquentielles ancrées au premier lancement de l'application :

• Fenêtre 1 (Jour 0-2) : Les 48 premières heures suivant le premier lancement.
• Fenêtre 2 (Jour 3-7) : De la 48e à la 168e heure suivant le premier lancement.
• Fenêtre 3 (Jour 8-35) : De la 168e à la 840e heure suivant le premier lancement.

Un moteur de schéma dynamique partitionne les règles entre ces fenêtres, exécutant les calculs de valeur appropriés en fonction du temps écoulé depuis le lancement initial de l'application.

Fenêtre 1 (Jour 0-2) : Structuration des valeurs fines et grossières

La fenêtre 1 est la seule fenêtre de conversion éligible pour divulguer des valeurs de conversion fines. La configuration de la fenêtre 1 définit deux mappages simultanés :

• Mappage fin (0-63) : Règles haute résolution capturant les niveaux de monétisation initiaux, les étapes d'intégration ou les scores d'engagement composites.
• Mappage grossier (low, medium, high) : États de repli à granularité inférieure divulgués lorsque le niveau de données de postback attribué ne permet pas un reporting fin.

Fenêtres 2 (Jour 3-7) et 3 (Jour 8-35) : Suivi du cycle de vie grossier

Les deuxième et troisième postbacks n'exposent pas de valeurs de conversion fines ; pour les niveaux de données éligibles, ils ne divulguent que des valeurs grossières.

Les schémas pour les fenêtres 2 et 3 se concentrent sur la fidélisation à long terme et les jalons de monétisation :

• Mappage grossier de la fenêtre 2 : Évalue la rétention à moyen terme (par exemple, low = Actif du Jour 3 au 7 ; medium = 3 sessions complétées ; high = Achat répété ou essai converti).
• Mappage grossier de la fenêtre 3 : Évalue la rétention à longue traîne et les renouvellements d'abonnements (par exemple, low = Retenu du Jour 8 au 35 ; medium = Étape de niveau atteinte ; high = Abonné payant actif).

Les développeurs configurant des schémas de conversion peuvent consulter la documentation sur le mappage de conversion SKAN pour obtenir des directives techniques sur les structures de règles multi-fenêtres.

Modèles d'encodage définis par le fournisseur : Regroupement de revenus, entonnoirs et logique binaire

Ces modèles d'encodage représentent des modèles de conception au niveau du fournisseur et de l'application plutôt que des types de schémas prescrits par Apple.

Schémas basés sur les revenus

Les schémas de revenus allouent les valeurs fines disponibles sur les montants d'achat cumulés :

• Regroupement linéaire : Divise une plage de revenus en intervalles égaux (par exemple, 64 seaux d'incréments de 1,50 $ jusqu'à 96,00 $). Idéal pour les applications dont la taille des transactions est prévisible.
• Regroupement logarithmique : Alloue des compartiments granulaires aux achats à faible coût tout en élargissant les plages de compartiments pour les transactions de grande valeur (par exemple, les valeurs 1 à 20 couvrent 0,99 $ à 19,99 $ ; les valeurs 21 à 50 couvrent 20,00 $ à 100,00 $ ; les valeurs 51 à 63 couvrent 100,00 $ à 1000,00 $+).
• Regroupement basé sur les centiles : Mappe les distributions historiques des achats des utilisateurs dans des segments de cohorte basés sur des courbes de monétisation empiriques.

Schémas de progression dans l'entonnoir et directionalité des valeurs

Dans SKAdNetwork 3 et les versions antérieures, Apple exigeait que les valeurs de conversion augmentent de manière monotone. Dans SKAdNetwork 4.0, Apple a supprimé cette restriction, permettant aux valeurs de conversion de la fenêtre 1 d'augmenter ou de diminuer lors des appels d'API ultérieurs.

Cependant, de nombreux schémas d'attribution appliquent intentionnellement une progression monotone en tant que convention de conception au niveau du fournisseur pour s'assurer que les valeurs plus élevées représentent des résultats commerciaux progressivement plus solides :

• Valeur 0 : Application installée et ouverte.
• Valeur 10 : Inscription complétée.
• Valeur 20 : Tutoriel d'intégration terminé.
• Valeur 30 : Méthode de paiement ajoutée.
• Valeur 45 : Article ajouté au panier.
• Valeur 63 : Paiement initial complété.

Schémas catégoriels binaires

Les schémas binaires traitent l'entier à 6 bits ($2^6 = 64$) comme six indicateurs booléens indépendants ($b_5 b_4 b_3 b_2 b_1 b_0$) :

La charge utile JSON versionnée ci-dessous illustre un document de configuration dynamique multi-fenêtre :

{
  "schema_version": "4.0.1",
  "app_id": "1234567890",
  "currency": "USD",
  "windows": {
    "window_1": {
      "mode": "hybrid_revenue_and_funnel",
      "fine_mapping": [
        { "event": "app_open", "min_revenue_cents": 0, "fine_value": 0, "lock": false },
        { "event": "registration_complete", "min_revenue_cents": 0, "fine_value": 10, "lock": false },
        { "event": "tutorial_complete", "min_revenue_cents": 0, "fine_value": 20, "lock": false },
        { "event": "purchase", "min_revenue_cents": 99, "fine_value": 30, "lock": false },
        { "event": "purchase", "min_revenue_cents": 999, "fine_value": 45, "lock": false },
        { "event": "purchase", "min_revenue_cents": 4999, "fine_value": 63, "lock": true }
      ],
      "coarse_mapping": {
        "low": { "events": ["app_open", "registration_complete"] },
        "medium": { "events": ["tutorial_complete"] },
        "high": { "events": ["purchase"] }
      }
    },
    "window_2": {
      "mode": "coarse_retention_and_monetization",
      "coarse_mapping": {
        "low": { "events": ["app_open"], "lock": false },
        "medium": { "events": ["session_milestone"], "lock": false },
        "high": { "events": ["repeat_purchase"], "lock": true }
      }
    },
    "window_3": {
      "mode": "coarse_long_tail_ltv",
      "coarse_mapping": {
        "low": { "events": ["app_open"], "lock": false },
        "medium": { "events": ["level_milestone"], "lock": false },
        "high": { "events": ["subscription_active"], "lock": true }
      }
    }
  }
}

Configuration dynamique du SDK : Ingestion et évaluation des configurations distantes à l'exécution

Mécanismes d'évaluation des règles côté client

Les SDK d'attribution évaluent les règles de conversion localement dans le runtime de l'application :

• Pas de récupération synchrone de configuration distante sur le chemin des événements : Les actions in-app déclenchent des évaluations locales en mémoire par rapport à un ensemble de règles actif, invoquant immédiatement les API StoreKit sans bloquer l'exécution de l'application.
• Minimisation des données: Pour le chemin de mise à jour de conversion SKAdNetwork illustré ici, les entrées d'événements brutes peuvent être évaluées localement et seules les valeurs de conversion résultantes doivent être transmises à StoreKit. Cela ne décrit ni ne limite en soi les autres flux de données analytiques mis en œuvre par un SDK.

Gestion de l'état hors ligne et persistance locale

Lorsqu'une application se lance hors ligne ou dans des conditions réseau dégradées :

1. Le SDK initialise l'ancre d'horodatage du premier lancement de manière indépendante dans la persistance locale.
2. Le SDK charge le schéma de configuration épinglé à partir du stockage local persistant, en vérifiant que la charge utile mise en cache correspond à la version du schéma épinglé.
3. Si des événements in-app se produisent hors ligne, le SDK les évalue par rapport à l'ensemble de règles mis en cache et appelle immédiatement l'API de mise à jour StoreKit.
4. La préparation et la livraison des postbacks restent gérées par le système et asynchrones ; l'application n'a pas besoin d'envoyer elle-même les postbacks.

L'implémentation Swift ci-dessous démontre un moteur d'évaluation de schéma multi-fenêtre qui calcule les valeurs fines et grossières, gère les états de verrouillage spécifiques aux fenêtres, conserve les configurations de schéma épinglées et valide les mises à jour d'état uniquement après une exécution réussie de StoreKit :

import Foundation
import StoreKit

// MARK: - Schema Configuration Models

struct SKANSchemaConfig: Codable {
    let schemaVersion: String
    let appId: String
    let currency: String
    let windows: SchemaWindows

    enum CodingKeys: String, CodingKey {
        case schemaVersion = "schema_version"
        case appId = "app_id"
        case currency, windows
    }
}

struct SchemaWindows: Codable {
    let window1: Window1Config
    let window2: WindowCoarseConfig
    let window3: WindowCoarseConfig

    enum CodingKeys: String, CodingKey {
        case window1 = "window_1"
        case window2 = "window_2"
        case window3 = "window_3"
    }
}

struct Window1Config: Codable {
    let mode: String
    let fineMapping: [FineRule]
    let coarseMapping: CoarseRuleGroup

    enum CodingKeys: String, CodingKey {
        case mode
        case fineMapping = "fine_mapping"
        case coarseMapping = "coarse_mapping"
    }
}

struct FineRule: Codable {
    let event: String
    let minRevenueCents: Int
    let fineValue: Int
    let lock: Bool

    enum CodingKeys: String, CodingKey {
        case event
        case minRevenueCents = "min_revenue_cents"
        case fineValue = "fine_value"
        case lock
    }
}

struct WindowCoarseConfig: Codable {
    let mode: String
    let coarseMapping: [String: CoarseRule]

    enum CodingKeys: String, CodingKey {
        case mode
        case coarseMapping = "coarse_mapping"
    }
}

struct CoarseRuleGroup: Codable {
    let low: CoarseRule
    let medium: CoarseRule
    let high: CoarseRule
}

struct CoarseRule: Codable {
    let events: [String]?
    let lock: Bool?
}

// MARK: - Multi-Window SKAN 4.0 Schema Engine

final class SKANSchemaEngine {

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

    private var activeSchema: SKANSchemaConfig?
    private var firstLaunchDate: Date?
    private var lockedWindows = Set<Int>()
    private var lastRecordedFineValue: Int = 0
    private var pinnedSchemaVersion: String?

    /// Initializes the first-launch timestamp anchor independently of remote configuration fetches
    func initializeLifecycleAnchor() {
        let defaults = UserDefaults.standard
        if let storedLaunch = defaults.object(forKey: "skan_first_launch_date") as? Date {
            self.firstLaunchDate = storedLaunch
        } else {
            let now = Date()
            self.firstLaunchDate = now
            defaults.set(now, forKey: "skan_first_launch_date")
        }

        let lockedArray = defaults.array(forKey: "skan_locked_windows") as? [Int] ?? []
        self.lockedWindows = Set(lockedArray)
        self.lastRecordedFineValue = defaults.integer(forKey: "skan_last_fine_value")
        self.pinnedSchemaVersion = defaults.string(forKey: "skan_pinned_schema_version")

        // Restore previously cached schema payload if it matches the pinned version
        if let pinnedVersion = self.pinnedSchemaVersion,
           let cachedData = defaults.data(forKey: "skan_cached_schema_payload"),
           let cachedSchema = try? JSONDecoder().decode(SKANSchemaConfig.self, from: cachedData),
           cachedSchema.schemaVersion == pinnedVersion {
            self.activeSchema = cachedSchema
        }
    }

    /// Loads active schema, persisting the pinned payload to maintain consistency across the 35-day lifecycle
    func configure(schema: SKANSchemaConfig) {
        let defaults = UserDefaults.standard
        if let pinned = pinnedSchemaVersion {
            // If already pinned, accept only schemas matching the pinned version
            if pinned == schema.schemaVersion {
                self.activeSchema = schema
                if let data = try? JSONEncoder().encode(schema) {
                    defaults.set(data, forKey: "skan_cached_schema_payload")
                }
            }
        } else {
            // Pin the initial schema version for this lifecycle
            self.activeSchema = schema
            self.pinnedSchemaVersion = schema.schemaVersion
            defaults.set(schema.schemaVersion, forKey: "skan_pinned_schema_version")
            if let data = try? JSONEncoder().encode(schema) {
                defaults.set(data, forKey: "skan_cached_schema_payload")
            }
        }
    }

    /// Determines the active conversion window based on elapsed time from first launch
    private var currentWindowIndex: Int {
        guard let firstLaunch = firstLaunchDate else { return 0 }
        let elapsedHours = Date().timeIntervalSince(firstLaunch) / 3600.0

        switch elapsedHours {
        case 0.0..<48.0:
            return 1
        case 48.0..<168.0:
            return 2
        case 168.0...840.0:
            return 3
        default:
            return 0 // Window closed (>35 days)
        }
    }

    /// Evaluates an in-app event against the active schema for the current window
    func trackEvent(name: String, revenueCents: Int = 0) {
        guard #available(iOS 16.1, *),
              let schema = activeSchema else { return }

        let window = currentWindowIndex
        guard window >= 1 && window <= 3, !lockedWindows.contains(window) else { return }

        var targetFineValue: Int?
        var targetCoarseValue: SKAdNetwork.CoarseConversionValue?
        var shouldLock = false
        var matchedRule = false

        if window == 1 {
            // Window 1: Evaluate fine-grained rules with highest-threshold precedence
            let matchingFineRules = schema.windows.window1.fineMapping
                .filter { $0.event == name && revenueCents >= $0.minRevenueCents }
                .sorted { $0.minRevenueCents < $1.minRevenueCents }

            if let highestRule = matchingFineRules.last {
                targetFineValue = highestRule.fineValue
                if highestRule.lock { shouldLock = true }
                matchedRule = true
            }

            // Window 1: Evaluate coarse-grained rules explicitly
            if schema.windows.window1.coarseMapping.high.events?.contains(name) == true {
                targetCoarseValue = .high
                matchedRule = true
            } else if schema.windows.window1.coarseMapping.medium.events?.contains(name) == true {
                targetCoarseValue = .medium
                matchedRule = true
            } else if schema.windows.window1.coarseMapping.low.events?.contains(name) == true {
                targetCoarseValue = .low
                matchedRule = true
            }
        } else {
            // Windows 2 & 3: Evaluate coarse rules only
            let coarseConfig = (window == 2) ? schema.windows.window2 : schema.windows.window3
            
            if let highRule = coarseConfig.coarseMapping["high"], highRule.events?.contains(name) == true {
                targetCoarseValue = .high
                if highRule.lock == true { shouldLock = true }
                matchedRule = true
            } else if let medRule = coarseConfig.coarseMapping["medium"], medRule.events?.contains(name) == true {
                targetCoarseValue = .medium
                if medRule.lock == true { shouldLock = true }
                matchedRule = true
            } else if let lowRule = coarseConfig.coarseMapping["low"], lowRule.events?.contains(name) == true {
                targetCoarseValue = .low
                if lowRule.lock == true { shouldLock = true }
                matchedRule = true
            }
        }

        // If no explicit rule matched for this event, do not trigger a StoreKit update
        guard matchedRule else { return }

        let fineToSubmit = targetFineValue ?? (window == 1 ? lastRecordedFineValue : 0)
        let clampedFine = max(0, min(63, fineToSubmit))
        let coarseToSubmit = targetCoarseValue ?? .low

        // Dispatch StoreKit conversion update
        // Note: StoreKit ignores the fineValue parameter after Window 1
        SKAdNetwork.updatePostbackConversionValue(
            clampedFine,
            coarseValue: coarseToSubmit,
            lockWindow: shouldLock
        ) { [weak self] error in
            guard let self = self else { return }
            if let error = error {
                print("StoreKit conversion update failed: \(error.localizedDescription)")
            } else {
                // Commit local state only after StoreKit successfully accepts the update
                DispatchQueue.main.async {
                    if window == 1 {
                        self.lastRecordedFineValue = clampedFine
                        UserDefaults.standard.set(clampedFine, forKey: "skan_last_fine_value")
                    }
                    if shouldLock {
                        self.lockedWindows.insert(window)
                        UserDefaults.standard.set(Array(self.lockedWindows), forKey: "skan_locked_windows")
                    }
                    print("SKAN 4.0 update succeeded: Window=\(window), Fine=\(clampedFine), Coarse=\(coarseToSubmit.rawValue), Locked=\(shouldLock)")
                }
            }
        }
    }
}

Automatisation de l'exécution de lockWindow pour accélérer la préparation des postbacks

Mécanismes opérationnels du paramètre lockWindow

Lorsqu'une application appelle updatePostbackConversionValue(_:coarseValue:lockWindow:) avec lockWindow: true, la mise à jour devient la dernière mise à jour de la valeur de conversion pour la fenêtre active. Le système d'exploitation prépare immédiatement le postback et ignore les mises à jour de valeurs de conversion supplémentaires 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 Locked / Postback Prepared] ──► Delay (24-48h) ──► Postback 1 Sent Sooner

Compromis stratégiques dans le verrouillage automatisé des fenêtres

• Envoi accéléré des postbacks: La finalisation anticipée d'une conversion permet au délai de postback randomisé d'Apple de commencer immédiatement, transmettant plus rapidement les données de conversion aux réseaux publicitaires.
• Indépendance des fenêtres: Le verrouillage de la fenêtre courante ne fait pas avancer le début de la fenêtre suivante ; la fenêtre 2 commence toujours au jour 3, indépendamment du moment où la fenêtre 1 a été verrouillée.
• Troncature de l'observation: Une fois la fenêtre verrouillée, le système ignore les appels de mise à jour de la valeur de conversion ultérieurs pour le reste de cette fenêtre de conversion. Les événements in-app peuvent continuer à se produire, mais ils ne peuvent plus modifier l'état de conversion SKAdNetwork de cette fenêtre.

Coordination des schémas SKAN avec AdAttributionKit

La pile d'attribution en évolution d'Apple

Apple recommande désormais AdAttributionKit pour les campagnes publicitaires d'applications sur l'App Store et les places de marché d'applications alternatives. SKAdNetwork reste pertinent pour les intégrations existantes et l'interopérabilité, de sorte que les moteurs de mappage dynamique doivent séparer leur couche de règles métier des API de conversion spécifiques au framework :

• Dimensions de valeur partagées : Les deux frameworks évaluent les valeurs fines à 6 bits (0 à 63) et les valeurs grossières à 3 paliers (low, medium, high).
• Couches d'API distinctes : SKAdNetwork utilise SKAdNetwork.updatePostbackConversionValue, tandis qu'AdAttributionKit utilise Postback.updateConversionValue.
• Comportement de transition : Si une intégration prend en charge les deux frameworks, Apple recommande d'appeler les API de mise à jour de conversion des deux frameworks, tout en tenant compte du comportement de transition documenté de SKAdNetwork vers AdAttributionKit.

Matrice de décision comparative : Logique client codée en dur par rapport à la configuration dynamique

Résumé et cadre de décision

L'automatisation du mappage des valeurs de conversion SKAdNetwork découple l'expérimentation de la croissance des cycles de publication de binaires mobiles. En distribuant des schémas dynamiques à partir d'un tableau de bord d'attribution centralisé et en les évaluant localement au sein du SDK, les équipes d'ingénierie peuvent affiner les tranches de revenus, optimiser les jalons de l'entonnoir et configurer des verrous de fenêtre automatisés, permettant aux modifications de règles de conversion prises en charge de prendre effet sans soumettre à nouveau les binaires de l'application à App Store Connect.

Le routage des liens profonds au niveau de l'application peut fonctionner aux côtés des frameworks d'attribution préservant la confidentialité d'Apple en tant que couche de mesure et d'intégration distincte. Des plateformes telles que OpoInstall fournissent une infrastructure pour le routage contextuel de première partie et le deep linking différé, permettant aux équipes de préserver l'intention de l'utilisateur à travers les tunnels de conversion web-vers-application.

Pour en savoir plus sur la configuration d'une attribution conforme à la confidentialité et des pipelines de deep linking, consultez la documentation d'OpoInstall.

Matériel connexe

• Concepts : Schémas de valeurs de conversion, Mappage de schéma dynamique, Regroupement de revenus, Verrouillage de fenêtre, Monotonie

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

• Standards : Spécification JSON IETF RFC 8259

• API : API StoreKit updatePostbackConversionValue, API AdAttributionKit Postback.updateConversionValue

Documentation officielle

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

• Documentation développeur Apple sur SKAdNetwork

• Documentation développeur Apple sur AdAttributionKit

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

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