Guía de SKAdNetwork 4.0: Cómo funcionan las tres ventanas de postback

¿Cómo funciona la atribución multiventana de SKAdNetwork 4.0? SKAdNetwork 4.0 divide la medición de conversiones en tres ventanas secuenciales que abarcan los días 0–2, 3–7 y 8–35 posteriores al primer inicio de la aplicación. Apple asigna un nivel de datos de postback a cada descarga de app, lo cual determina si los postbacks elegibles exponen datos de atribución detallados, aproximados o reducidos.

SKAdNetwork 4.0 es el marco de atribución publicitaria móvil de Apple diseñado para preservar la privacidad, permitiendo medir campañas de forma segura en iOS. Introduce tres ventanas de conversión secuenciales que se extienden hasta 35 días después del primer inicio, identificadores de origen jerárquicos, valores de conversión aproximados y mecanismos de bloqueo de ventanas para evaluar el valor del tiempo de vida del usuario a mitad del embudo sin recopilar identidades de dispositivos persistentes.

De un vistazo: Cronologías clave de postback y reglas de divulgación

• Ventana 1 (Días 0–2 posteriores al primer inicio): Puede divulgar valores detallados (0–63) o aproximados (low, medium, high); se envía tras un retraso aleatorio adicional de 24 a 48 horas.
• Ventana 2 (Días 3–7 posteriores al primer inicio): Puede divulgar un coarse-conversion-value cuando se proporcione y el nivel de datos de postback lo permita; de lo contrario, dicho campo estará ausente. Se envía tras un retraso aleatorio adicional de 24 a 144 horas.
• Ventana 3 (Días 8–35 posteriores al primer inicio): Puede divulgar un coarse-conversion-value cuando se proporcione y el nivel de datos de postback lo permita; de lo contrario, dicho campo estará ausente. Se envía tras un retraso aleatorio adicional de 24 a 144 horas.
• Restricción de Datos del Nivel 0: Las descargas que recaen en el Nivel 0 reciben un único postback que contiene un ID de origen de 2 dígitos y ningún valor de conversión; el segundo y tercer postback se omiten.
• Requisito de Múltiples Postbacks: Para ser elegible para múltiples postbacks ganadores, el anuncio debe estar firmado utilizando SKAdNetwork 4 o posterior, y la app anunciada debe actualizar los valores de conversión durante las ventanas de conversión aplicables.

Qué es SKAdNetwork 4.0 y cómo opera la atribución multiventana

La evolución estructural desde las restricciones de temporizador único hasta el seguimiento del ciclo de vida multiventana

Las primeras versiones de StoreKit Ad Network de Apple (SKAdNetwork 2.0 y 3.0) operaban bajo un único temporizador continuo de 24 horas. En SKAdNetwork 3 y versiones anteriores, las actualizaciones válidas y crecientes del valor de conversión podían extender el período de conversión continuo reiniciando el temporizador de 24 horas. Una vez transcurridas 24 horas sin actualizaciones, la ventana se cerraba y Apple enviaba un único postback tras un retraso aleatorio.

Esta arquitectura de temporizador único generaba fricción operativa:

• Horizontes de Observación Restringidos: Los anunciantes solo podían medir el compromiso temprano que ocurría durante los primeros días posteriores a la instalación.
• Retrasos en los Informes: Las actualizaciones de conversión recurrentes y cualificadas podían extender el período de medición efectivo y retrasar el postback final, ralentizando los algoritmos automatizados de puja publicitaria.
• Visibilidad Limitada a Largo Plazo: SKAdNetwork 3 no contaba con ventanas de conversión posteriores dedicadas para una medición estructurada entre el día 7 y el día 30.

SKAdNetwork 4.0 reestructura este modelo al establecer tres ventanas de medición fijas y secuenciales ancladas al primer inicio de la app por parte del usuario.

Desacoplamiento de los temporizadores de atribución y las sesiones de usuario activas

En SKAdNetwork 4.0, las ventanas de conversión avanzan en función de una duración fija de calendario en lugar de la actividad continua del usuario. Cuando una app se abre por primera vez tras una impresión publicitaria atribuida, el sistema operativo inicia la Ventana 1.

Independientemente de si el usuario abre la aplicación una vez o cincuenta veces durante las primeras 48 horas, la Ventana 1 se cierra al marcar las 48 horas (a menos que se finalice explícitamente antes mediante el bloqueo de ventanas). A continuación, el sistema avanza automáticamente a la Ventana 2 (del día 3 al día 7) y posteriormente a la Ventana 3 (del día 8 al día 35). Este desacoplamiento garantiza intervalos estructurados para el envío de postbacks destinados a las canalizaciones de datos posteriores.

La cadena de firma criptográfica de dos fases

SKAdNetwork mantiene la integridad de los datos mediante criptografía de clave pública a través de dos fases diferenciadas:

• Fase de Impresión Publicitaria (de la Red Publicitaria a Apple): Cuando una red publicitaria sirve una impresión, firma la carga útil del anuncio con su clave privada. Tras la instalación y el inicio de la app, el sistema operativo valida esta firma frente a la clave pública de la red publicitaria registrada en Apple para verificar la elegibilidad de atribución.
• Fase de Validación de Instalación (de Apple a la Red Publicitaria/Desarrollador): Cuando una ventana de conversión se cierra, Apple firma la carga útil del postback de validación de instalación. La red publicitaria receptora y el punto de acceso del desarrollador verifican esta firma utilizando la clave pública de Apple para comprobar la autenticidad e integridad del postback.

Véase también: SKAdNetwork ──> Modelo de Atribución Móvil

La mecánica de las tres ventanas de postback y los cronogramas de medición

Ventana 1: Captura de la participación temprana y señales de conversión de alta precisión

• Intervalo de Medición: Del día 0 al día 2 (primeras 48 horas tras el primer inicio).
• Divulgación de Datos Disponible: Valor de conversión detallado (entero de 6 bits de 0 a 63) o valor aproximado (low, medium, high), determinado por el nivel de datos de postback asignado.
• Retraso de Postback Aleatorio: De 24 a 48 horas después de que la ventana se cierre o se bloquee.
• Objetivo Analítico: Medir la finalización inmediata del proceso de incorporación, los hitos del tutorial, la conversión de compra inicial y el riesgo temprano de abandono.

Ventana 2: Evaluación de la retención temprana de usuarios e hitos a mitad del embudo

• Intervalo de Medición: Del día 3 al día 7 tras el primer inicio (horas 48 a 168).
• Divulgación de Datos Disponible: Puede divulgar un coarse-conversion-value (low, medium, high) cuando se proporcione y el nivel de datos de postback lo permita; de lo contrario, dicho campo estará ausente. Los valores detallados (de 0 a 63) no son compatibles en la Ventana 2.
• Retraso de Postback Aleatorio: De 24 a 144 horas (de 1 a 6 días) después de que la ventana se cierre o se bloquee.
• Objetivo Analítico: Evaluar la retención entre el día 3 y el día 7, los ciclos de interacción de múltiples días, las pruebas de suscripción iniciales y el comportamiento de recompra.

Ventana 3: Medición de la retención a largo plazo y el valor del tiempo de vida acumulado

• Intervalo de Medición: Del día 8 al día 35 tras el primer inicio (horas 168 a 840).
• Divulgación de Datos Disponible: Puede divulgar un coarse-conversion-value (low, medium, high) cuando se proporcione y el nivel de datos de postback lo permita; de lo contrario, dicho campo estará ausente.
• Retraso de Postback Aleatorio: De 24 a 144 horas (de 1 a 6 días) después de que la ventana se cierre o se bloquee.
• Objetivo Analítico: Capturar los puntos de referencia de retención del primer mes, las conversiones de prueba a suscripción de pago y los hitos de monetización a largo plazo.

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

Mecánica de los retrasos aleatorios: Ventana 1 frente a las Ventanas 2 y 3

Para evitar heurísticas de ataques de tiempo en las que un observador correlaciona el milisegundo exacto de una transacción dentro de la app con la recepción de un postback de atribución, Apple aplica retrasos de envío aleatorios:

• Temporizador de la Ventana 1: Si la Ventana 1 se cierra de forma natural sin un bloqueo temprano, el primer postback se envía tras un retraso aleatorio adicional de 24 a 48 horas.
• Temporizadores de las Ventanas 2 y 3: Apple amplía la ventana de retraso aleatorio de 24 a 144 horas (hasta 6 días completos) para tener en cuenta la mayor duración de los períodos de medición.

Cómo los niveles de datos de postback controlan la divulgación

La matriz oficial de niveles de datos de postback

Apple asigna un nivel de datos de postback (del Nivel 0 al Nivel 3) a las descargas de aplicaciones en función del conjunto de usuarios asociado con la app o dominio de origen, la app anunciada, el país de instalación y el identificador de origen jerárquico. Apple no publica umbrales universales de recuento de instalaciones para los Niveles 0 al 3.

Cómo funcionan los identificadores de origen jerárquicos

Estructura y granularidad del identificador de origen

SKAdNetwork 4.0 sustituye el ID de campaña clásico de 2 dígitos por un entero jerárquico de 4 dígitos denominado Identificador de Origen:

Las redes publicitarias y los desarrolladores definen el significado del identificador de origen jerárquico en función de sus requisitos de informes internos:

• Dos dígitos inferiores ($d_2 d_1$): Constituyen la porción mínima de dos dígitos del identificador de origen jerárquico que puede divulgarse. Las redes publicitarias pueden usar esta parte para la agrupación amplia de campañas, pero Apple no prescribe un significado comercial fijo.
• Dígitos de orden superior ($d_4 d_3$): Pueden codificar dimensiones internas como la ubicación del anuncio, el ID del elemento creativo o el objetivo geográfico. Apple no asigna semántica comercial fija a los dígitos individuales.

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 consolidación de campañas puede incrementar el conjunto de usuarios asociado a determinados identificadores de origen, pero Apple no publica umbrales universales de instalaciones y dicha consolidación no garantiza un nivel de datos de postback específico.

Valores de conversión detallados frente a aproximados

Valores de conversión detallados (Fine-Grained)

Los valores de conversión detallados operan como números binarios de 6 bits que representan enteros del 0 al 63 ($2^6 = 64$ valores discretos). Disponibles exclusivamente en la Ventana 1 bajo los niveles de datos de postback Nivel 2 o Nivel 3, los valores detallados permiten a los desarrolladores codificar rangos de ingresos granulares, etapas del embudo o combinaciones de eventos a nivel de bits.

Valores de conversión aproximados (Coarse-Grained)

Los valores de conversión aproximados ofrecen una alternativa de menor granularidad cuando el nivel de datos de postback aplicable no permite la divulgación detallada, y actúan como el formato de valor de conversión para el segundo y tercer postback. Apple no asigna ninguna semántica comercial predefinida a low, medium o high; los siguientes ejemplos son asignaciones ilustrativas definidas por la aplicación:

• low: Mapeo ilustrativo para participación básica (p. ej., apertura inicial de la app o registro).
• medium: Mapeo ilustrativo para participación intermedia (p. ej., tutorial completado o sesión activa de varios días).
• high: Mapeo ilustrativo para hitos de conversión de alto valor (p. ej., compra dentro de la app o activación de prueba).

Para el diseño de esquemas de conversión específicos de su implementación, consulte la documentación de mapeo de conversión de SKAN.

Mapeo del índice de secuencia de postback

En los postbacks de SKAdNetwork 4, el campo postback-sequence-index identifica la ventana de conversión correspondiente:

Apple especifica que un postback de validación de instalación puede contener un conversion-value (detallado) o un coarse-conversion-value (aproximado), pero nunca ambos simultáneamente.

Las siguientes cargas útiles son ejemplos ilustrativos de SKAdNetwork 4. Los campos reales de los postbacks varían según la secuencia del postback, el nivel de datos del postback, el tipo de anuncio y las condiciones de divulgación de privacidad. Los valores de muestra de attribution-signature son marcadores de posición y no son válidos criptográficamente.

El Ejemplo 1 a continuación ilustra una carga útil de postback detallado para la Ventana 1, y el Ejemplo 2 ilustra una carga útil de postback aproximado para la Ventana 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...=="
}

Ventajas y desventajas de bloquear una ventana de conversión de forma anticipada

Aceleración de la medición con el parámetro lockWindow

De forma predeterminada, cada ventana de medición permanece abierta durante toda su duración de calendario (48 horas para la Ventana 1, 5 días para la Ventana 2, 28 días para la Ventana 3). Cuando lockWindow se establece en true, la actualización se convierte en la actualización final del valor de conversión para la ventana activa. El sistema prepara el postback e ignora las actualizaciones adicionales del valor de conversión durante el resto de dicha 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 Value Locked / Postback Prepared] ──► Delay (24-48h) ──► Postback 1 Sent Sooner

Consideraciones operativas al invocar el bloqueo de ventanas

• Envío acelerado de postbacks: Cuando una conversión se finaliza de forma anticipada, el retraso del postback comienza tan pronto como se consolida dicha conversión bloqueada, en lugar de esperar a que transcurra la ventana de calendario completa.
• Independencia de las ventanas: El bloqueo de la ventana actual no adelanta el inicio de la siguiente ventana. La siguiente ventana de conversión sigue comenzando en su límite temporal predefinido (p. ej., la Ventana 2 comienza el día 3 independientemente de cuándo se haya bloqueado la Ventana 1).
• Exclusión de eventos posteriores: Una vez que se ejecuta lockWindow: true, el sistema operativo ignora todas las llamadas de actualización del valor de conversión subsiguientes durante el resto de esa ventana específica.

El código en Swift a continuación demuestra cómo actualizar los valores de conversión detallados y aproximados e invocar el bloqueo de ventanas utilizando 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)
    }
}

Interoperabilidad entre SKAdNetwork 4.0 y AdAttributionKit

La relación entre SKAdNetwork y Apple AdAttributionKit

Apple introdujo AdAttributionKit como un marco de atribución ampliado para iOS 17.4 y versiones posteriores. AdAttributionKit y SKAdNetwork pueden coexistir, pero siguen siendo API de atribución distintas:

• Invocaciones de API específicas del marco: Las aplicaciones deben llamar a la API de actualización de conversiones que corresponda al marco utilizado por la red publicitaria. Si una red publicitaria sirve anuncios a través de AdAttributionKit, la app invoca los métodos de conversión de AdAttributionKit; si utiliza SKAdNetwork, llama a las API de StoreKit.
• Selección del ganador entre marcos: Cuando ambos marcos registran impresiones cualificadas para una sola instalación, el sistema operativo las evalúa conjuntamente y selecciona una única impresión ganadora para la atribución.
• Comportamiento de puente: Apple proporciona un comportamiento de puente de valores de conversión para ciertas llamadas de actualización de SKAdNetwork con el fin de garantizar la compatibilidad entre capas de medición.

SKAdNetwork 4 sigue siendo importante para operar las integraciones de atribución existentes en el App Store, mientras que Apple orienta las nuevas implementaciones publicitarias de aplicaciones hacia AdAttributionKit y documenta la interoperabilidad entre ambos marcos.

Matriz comparativa: SKAN 3.0 clásico frente al modelo multiventana de SKAN 4.0

Resumen y marco de decisiones

SKAdNetwork 4.0 amplía la visibilidad de atribución a 35 días desde el primer inicio de la app, introduce valores de conversión aproximados para ofrecer mediciones de menor granularidad cuando la divulgación detallada no está disponible, y permite a los desarrolladores bloquear las ventanas de medición para reducir la latencia de los postbacks cuando una ventana de conversión se finaliza de forma anticipada. Una implementación exitosa requiere un mapeo cuidadoso del esquema de conversión en las tres ventanas y alinear las llamadas de actualización del lado del cliente con los hitos comerciales genuinos.

El enrutamiento de enlaces profundos a nivel de aplicación puede operar junto con los marcos de atribución respetuosos con la privacidad de Apple como una capa de medición e incorporación independiente. Para conocer los flujos de trabajo de atribución y enrutamiento de enlaces profundos específicos de su implementación, consulte la documentación de OpoInstall.

Materiales relacionados

• Conceptos: Atribución Multiventana, Niveles de Datos de Postback, Identificadores de Origen Jerárquicos, Bloqueo de Ventanas, Valores Aproximados

• Tecnologías: Apple SKAdNetwork, Apple AdAttributionKit, Marco de StoreKit, SDK Móvil de OpoInstall

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

• API: API updatePostbackConversionValue de StoreKit, Postbacks de validación de instalación de SKAdNetwork

Documentación oficial

• Documentación para desarrolladores de Apple sobre SKAdNetwork

• Documentación para desarrolladores de Apple sobre AdAttributionKit

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

• Documentación para desarrolladores de Apple sobre la identificación de parámetros en postbacks de validación de instalación

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

• Comprender la interoperabilidad entre AdAttributionKit y SKAdNetwork