Asignación de valores de conversión de SKAdNetwork: Automatización de esquemas SKAN dinámicos

¿Cómo asigna un MMP los esquemas de SKAdNetwork de forma automática? Un Partner de Medición Móvil (MMP) o backend de atribución automatiza la asignación de esquemas de SKAdNetwork traduciendo los eventos in-app y los niveles de ingresos en esquemas de configuración JSON dinámicos y versionados dentro de una consola centralizada. El SDK móvil recupera esta configuración al iniciarse y evalúa las reglas de conversión de manera local en tiempo de ejecución, lo que permite que los cambios admitidos en dichas reglas surtan efecto sin necesidad de publicar una nueva versión binaria de la aplicación.

Un esquema de valores de conversión de SKAdNetwork es un conjunto de reglas a nivel de proveedor o de aplicación que asigna los comportamientos de los usuarios en la aplicación —como transacciones de ingresos, hitos de incorporación o interacción con funciones— a los valores detallados de 6 bits de Apple (de 0 a 63) y a los valores generales de 3 niveles (low, medium, high). Las arquitecturas de asignación dinámica distribuyen archivos de configuración versionados desde un backend en la nube hasta el SDK del cliente, eliminando la necesidad de programar de forma rígida la lógica de conversión dentro de los binarios compilados de la aplicación para iOS.

La arquitectura de la asignación automatizada de valores de conversión de SKAdNetwork

Delimitación de la capa de plataforma de Apple y la capa de esquemas del proveedor

Para diseñar un motor de valores de conversión robusto, los equipos de ingeniería deben separar las reglas nativas del marco de Apple de las abstracciones de esquemas del proveedor:

• Capa de plataforma de Apple: Rige las primitivas principales del sistema operativo, incluidas las tres ventanas de conversión secuenciales (Día 0–2, Día 3–7, Día 8–35 tras el primer lanzamiento), los valores detallados de 6 bits (0–63), los valores generales (low, medium, high), los niveles de datos de los postbacks y la API SKAdNetwork.updatePostbackConversionValue.
• Capa de esquemas del proveedor: Abarca las reglas de negocio definidas por la aplicación, tales como la categorización de ingresos, las progresiones en el embudo de incorporación, la asignación de indicadores mediante lógica de bits, la sincronización remota en formato JSON y la evaluación de reglas en el lado del cliente.

┌────────────────────────────────────────┐
│                           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]         │
└────────────────────────────────────────┘

Los inconvenientes de la lógica de conversión codificada rígidamente

Programar la lógica de conversión de forma estática directamente dentro del objetivo de la aplicación para iOS genera limitaciones operativas considerables:

• Dependencia de la revisión del App Store: Cualquier modificación en los umbrales de ingresos, la ponderación de eventos o los activadores de bloqueo de ventana requiere un ciclo completo de lanzamiento de binarios.
• Fragmentación de versiones: Múltiples versiones históricas de la aplicación en producción transmiten semánticas de conversión contradictorias, lo que corrompe los modelos de informes posteriores.
• Inflexibilidad en la optimización: Los equipos de crecimiento no pueden ajustar las estrategias de conversión entre campañas enfocadas en la interacción y campañas enfocadas en la monetización en respuesta al rendimiento de marketing en tiempo real.

El flujo de entrega de configuración dinámica

Las arquitecturas de asignación automatizada desacoplan la lógica de conversión del binario compilado mediante un canal de múltiples etapas:

1. Configuración en la consola: Los especialistas en marketing y analistas configuran las ponderaciones de eventos, los niveles de moneda y las reglas de bloqueo de ventana en un panel centralizado.
2. Versionado y fijación de esquemas: El backend publica una carga útil de configuración JSON versionada. Para evitar desvíos semánticos durante el ciclo de vida de conversión de 35 días del usuario, una implementación sólida del proveedor fija la configuración activa del esquema establecida durante la ventana de conversión inicial, asegurando que las reglas exactas de mapeo permanezcan disponibles incluso tras reiniciar la aplicación.
3. Ingesta y almacenamiento en caché del cliente: El SDK móvil descarga el esquema activo al inicializar la aplicación y almacena en caché tanto la carga útil de configuración como los metadatos de versión en el almacenamiento local persistente.
4. Evaluación local de reglas: Cuando ocurren eventos in-app, el SDK los evalúa frente al conjunto de reglas almacenado en caché de manera local, sin añadir una solicitud síncrona de configuración remota a la ruta de ejecución de eventos.

Véase también: SKAdNetwork ──> Arquitectura de atribución móvil

Diseño de esquemas dinámicos de valores de conversión en las ventanas de SKAN 4.0

Particionamiento de esquemas en múltiples ventanas

SKAdNetwork 4.0 estructura la medición de conversiones a través de tres ventanas secuenciales vinculadas al primer lanzamiento de la aplicación:

• Ventana 1 (Día 0–2): Las primeras 48 horas posteriores al primer lanzamiento.
• Ventana 2 (Día 3–7): Desde la hora 48 hasta la 168 posterior al primer lanzamiento.
• Ventana 3 (Día 8–35): Desde la hora 168 hasta la 840 posterior al primer lanzamiento.

Un motor de esquemas dinámicos divide las reglas entre estas ventanas y ejecuta los cálculos de valor adecuados en función del tiempo transcurrido desde el inicio inicial de la aplicación.

Ventana 1 (Día 0–2): Estructuración de valores detallados y generales

La Ventana 1 es la única ventana de conversión apta para revelar valores de conversión detallados. La configuración para la Ventana 1 define dos asignaciones concurrentes:

• Asignación detallada (0–63): Reglas de alta resolución que capturan los niveles iniciales de monetización, los hitos de incorporación o las puntuaciones de participación compuestas.
• Asignación general (low, medium, high): Estados alternativos de menor granularidad que se revelan cuando el nivel de datos del postback asignado no permite informes detallados.

Ventanas 2 (Día 3–7) y 3 (Día 8–35): Seguimiento del ciclo de vida general

Los segundo y tercer postbacks no exponen valores de conversión detallados; para los niveles de datos elegibles, solo revelan valores generales.

Los esquemas para las Ventanas 2 y 3 se centran en la retención a largo plazo y en los hitos de monetización:

• Asignación general de la Ventana 2: Evalúa la retención en el embudo medio (p. ej., low = Activo del Día 3 al 7; medium = 3 sesiones completadas; high = Compra repetida o prueba convertida).
• Asignación general de la Ventana 3: Evalúa la retención a largo plazo y las renovaciones de suscripciones (p. ej., low = Retenido del Día 8 al 35; medium = Hito de nivel alcanzado; high = Suscriptor de pago activo).

Los desarrolladores que configuran esquemas de conversión pueden consultar la documentación de asignación de conversiones de SKAN para obtener directrices técnicas sobre las estructuras de reglas para múltiples ventanas.

Modelos de codificación definidos por el proveedor: segmentación de ingresos, embudos y lógica de bits

Estos modelos de codificación representan patrones de diseño a nivel de proveedor y de aplicación, más que tipos de esquemas dictados por Apple.

Esquemas basados en ingresos

Los esquemas de ingresos distribuyen los valores detallados disponibles entre los montos de compra acumulados:

• Segmentación lineal: Divide un rango de ingresos en intervalos iguales (p. ej., 64 segmentos de incrementos de $1.50 hasta $96.00). Ideal para aplicaciones con tamaños de transacción predecibles.
• Segmentación logarítmica: Asigna segmentos granulares a compras de bajo coste mientras amplía los rangos de los segmentos para transacciones de alto valor (p. ej., los valores del 1 al 20 cubren de $0.99 a $19.99; los valores del 21 al 50 cubren de $20.00 a $100.00; los valores del 51 al 63 cubren de $100.00 a $1000.00+).
• Segmentación basada en percentiles: Mapea las distribuciones históricas de compra de los usuarios en segmentos de cohortes basados en curvas de monetización empíricas.

Esquemas de progresión en el embudo y direccionalidad de valores

En SKAdNetwork 3 y versiones anteriores, Apple exigía que los valores de conversión aumentaran de forma monótona. En SKAdNetwork 4.0, Apple eliminó esta restricción, permitiendo que los valores de conversión en la Ventana 1 aumenten o disminuyan a lo largo de llamadas posteriores a la API.

Sin embargo, muchos esquemas de atribución imponen intencionadamente una progresión monótona como convención de diseño a nivel de proveedor para garantizar que los valores más altos representen resultados comerciales progresivamente más sólidos:

• Valor 0: Aplicación instalada y abierta.
• Valor 10: Registro completado.
• Valor 20: Tutorial de incorporación finalizado.
• Valor 30: Método de pago añadido.
• Valor 45: Artículo añadido al carrito.
• Valor 63: Pago inicial completado.

Esquemas categóricos basados en bits

Los esquemas basados en bits tratan el número entero de 6 bits ($2^6 = 64$) como seis indicadores booleanos independientes ($b_5 b_4 b_3 b_2 b_1 b_0$):

La carga útil JSON versionada a continuación ilustra un documento de configuración dinámica para múltiples ventanas:

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

Configuración dinámica del SDK: Ingesta y evaluación de configuraciones remotas en tiempo de ejecución

Mecánicos de evaluación de reglas en el lado del cliente

Los SDK de atribución evalúan las reglas de conversión de manera local dentro del entorno de ejecución de la aplicación:

• Sin obtención síncrona de configuración remota en la ruta de eventos: Las acciones in-app activan evaluaciones locales en memoria frente a un conjunto de reglas activo, invocando de inmediato las API de StoreKit sin bloquear la ejecución de la aplicación.
• Minimización de datos: Para la ruta de actualización de conversiones de SKAdNetwork que se muestra aquí, las entradas de eventos sin procesar se pueden evaluar localmente y solo es necesario pasar a StoreKit los valores de conversión resultantes. Esto no describe por sí mismo ni limita otros flujos de datos analíticos implementados por un SDK.

Gestión del estado sin conexión y persistencia local

Cuando una aplicación se inicia sin conexión o en condiciones de red degradadas:

1. El SDK inicializa la marca de tiempo del primer lanzamiento de forma independiente en la persistencia local.
2. El SDK carga el esquema de configuración fijado desde el almacenamiento local persistente, verificando que la carga útil almacenada en caché coincida con la versión del esquema fijado.
3. Si ocurren eventos in-app mientras no hay conexión, el SDK los evalúa frente al conjunto de reglas almacenado en caché y llama inmediatamente a la API de actualización de StoreKit.
4. La preparación y entrega de postbacks siguen gestionadas por el sistema y son asíncronas; la aplicación no necesita enviar los postbacks por sí misma.

La implementación en Swift que se muestra a continuación demuestra un motor de evaluación de esquemas para múltiples ventanas que calcula valores detallados y generales, gestiona los estados de bloqueo específicos de cada ventana, persiste las configuraciones de esquemas fijadas y confirma las actualizaciones de estado únicamente tras una ejecución exitosa 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)")
                }
            }
        }
    }
}

Automatización de la ejecución de lockWindow para acelerar la preparación de postbacks

Mecánica operativa del parámetro lockWindow

Cuando una aplicación llama a updatePostbackConversionValue(_:coarseValue:lockWindow:) con lockWindow: true, la actualización se convierte en la última actualización del valor de conversión para la ventana activa. El sistema operativo prepara el postback de inmediato e ignora las actualizaciones adicionales del valor de conversión durante el resto de esa ventana.

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

Ventajas e inconvenientes estratégicos del bloqueo automatizado de ventanas

• Envío acelerado de postbacks: Finalizar una conversión de forma anticipada permite que el retraso aleatorio del postback de Apple comience de inmediato, entregando los datos de conversión a las redes publicitarias con mayor rapidez.
• Independencia de ventanas: Bloquear la ventana actual no adelanta el inicio de la siguiente ventana; la Ventana 2 sigue comenzando el Día 3 independientemente de cuándo se haya bloqueado la Ventana 1.
• Truncamiento de la observación: Una vez que la ventana está bloqueada, el sistema ignora las llamadas posteriores para actualizar el valor de conversión durante el resto de dicha ventana de conversión. Los eventos in-app pueden seguir ocurriendo, pero ya no pueden alterar el estado de conversión de SKAdNetwork de esa ventana.

Coordinación de los esquemas SKAN con AdAttributionKit

La evolución de la pila de atribución de Apple

Apple recomienda ahora AdAttributionKit para campañas publicitarias de aplicaciones tanto en el App Store como en mercados de aplicaciones alternativos. SKAdNetwork sigue siendo relevante para las integraciones existentes y la interoperabilidad, por lo que los motores de mapeo dinámico deben mantener su capa de reglas de negocio separada de las API de conversión específicas del marco:

• Dimensiones de valor compartidas: Ambos marcos evalúan valores detallados de 6 bits (de 0 a 63) y valores generales de 3 niveles (low, medium, high).
• Capas de API distintas: SKAdNetwork utiliza SKAdNetwork.updatePostbackConversionValue, mientras que AdAttributionKit utiliza Postback.updateConversionValue.
• Comportamiento de puente: Si una integración admite ambos marcos, Apple recomienda llamar a las API de actualización de conversión de ambos, teniendo en cuenta el comportamiento documentado de puente entre SKAdNetwork y AdAttributionKit.

Matriz de decisión comparativa: Lógica de cliente codificada estáticamente frente a configuración dinámica

Resumen y marco de decisión

La automatización de la asignación de valores de conversión de SKAdNetwork desacopla la experimentación de crecimiento de los ciclos de lanzamiento de binarios móviles. Al distribuir esquemas dinámicos desde un panel de atribución centralizado y evaluarlos localmente dentro del SDK, los equipos de ingeniería pueden ajustar con precisión los segmentos de ingresos, optimizar los hitos del embudo y configurar bloqueos automáticos de ventanas, permitiendo que los cambios compatibles en las reglas de conversión surtan efecto sin necesidad de volver a enviar binarios de la aplicación a App Store Connect.

El enrutamiento de enlaces profundos (deep links) a nivel de aplicación puede operar junto con los marcos de atribución que preservan la privacidad de Apple como una capa independiente de medición e incorporación. Plataformas como OpoInstall proporcionan infraestructura para el enrutamiento contextual de origen y el enlace profundo diferido (deferred deep linking), lo que permite a los equipos preservar la intención del usuario a través de los embudos de conversión de web a aplicación.

Para obtener más información sobre cómo configurar canales de atribución y enlaces profundos que cumplan con la privacidad, consulte la documentación de OpoInstall.

Materiales relacionados

• Conceptos: Esquemas de valores de conversión, asignación de esquemas dinámicos, segmentación de ingresos, bloqueo de ventanas, monotonicidad

• Tecnologías: Apple SKAdNetwork, Apple AdAttributionKit, marco StoreKit, SDK móvil de OpoInstall

• Estándares: Especificación JSON IETF RFC 8259

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

Documentación oficial

• Documentación de desarrolladores de Apple sobre la actualización de valores de conversión de postbacks

• Documentación de desarrolladores de Apple sobre SKAdNetwork

• Documentación de desarrolladores de Apple sobre AdAttributionKit

• Documentación de desarrolladores de Apple sobre la recepción de postbacks en múltiples ventanas de conversión

• Comprensión de la interoperabilidad entre AdAttributionKit y SKAdNetwork