Esquema de valores de conversión de SKAdNetwork 4.0: valores detallados, valores generales y ventanas de conversión

¿Cómo se configura un esquema de valores de conversión de SKAdNetwork 4.0? Un esquema de valores de conversión de SKAdNetwork 4.0 vincula eventos posteriores a la instalación o señales de ingresos con valores detallados de 0 a 63 y valores generales (low, medium, high). El nivel de datos de los postbacks de Apple determina qué representación del valor de conversión y qué otros campos de privacidad se muestran en un postback apto.

El IDFA (identificador para anunciantes) es el identificador restablecerle de Apple para la medición de publicidad en iOS. El marco de Transparencia en el Seguimiento de las Apps (ATT) de Apple modificó el acceso al IDFA, pasando de estar disponible por defecto a requerir la autorización del usuario, lo que impulsó la transición de la atribución móvil desde la coincidencia determinista entre aplicaciones hacia marcos de medición respetuosos con la privacidad.

Comprender las jerarquías de valores de conversión en SKAdNetwork 4.0

La evolución estructural: del modelo de postback único de SKAN 3.0 a la medición multiventana de SKAN 4.0

En SKAdNetwork 2.0 y 3.0, los anunciantes dependían de un único valor de conversión y de un temporizador continuo de 24 horas. En SKAN 3 y versiones anteriores, un valor de conversión más alto podía reiniciar dicho temporizador de 24 horas, lo que animaba a los desarrolladores a diseñar esquemas de valores de conversión con un incremento constante. Si un usuario completaba un evento de conversión dentro de la aplicación, el SDK del cliente integrado invocaba una API del sistema para actualizar un único número entero de 6 bits (del 0 al 63).

El modelo de postback único de SKAN ofrecía una visibilidad limitada de la interacción posterior a la instalación que ocurría después del periodo de conversión inicial, especialmente en aplicaciones móviles con embudos de conversión más largos, como plataformas de comercio electrónico por suscripción y juegos móviles de dificultad media.

SKAdNetwork 4.0 reestructuró este paradigma de medición al introducir una estructura multiventana de SKAdNetwork 4.0 compuesta por tres ventanas de tiempo diferenciadas, identificadores de origen ampliados que reemplazaron el modelo anterior de identificadores de campañas, y un sistema de valores de conversión de doble nivel formado por valores detallados y generales. SKAdNetwork 4 puede generar hasta tres postbacks para una atribución publicitaria ganadora. El segundo y el tercer postback solo están disponibles cuando se cumplen las condiciones de privacidad aplicables y las ventanas de conversión correspondientes generan información de conversión válida; el Nivel 0 solo recibe el primer postback.

Valores detallados: codificación de la interacción dentro de la app en enteros de 6 bits

Los valores de conversión detallados representan la métrica de medición tradicional de SKAN. Codificados como un número entero sin signo de 6 bits, estos valores admiten 64 estados numéricos discretos que van desde el 0 hasta el 63.

Dado que 6 bits ofrecen 64 valores potenciales, los desarrolladores diseñan una lógica de asignación para codificar hitos específicos de los usuarios o rangos de ingresos:

• Asignación secuencial del embudo: Asignación de valores de forma consecutiva según la profundidad del embudo (por ejemplo, 1 = Registro, 2 = Introducción, 3 = Nivel 5, 4 = Compra).

• Asignación por tramos de ingresos: Uso de los 64 estados detallados disponibles para representar un estado base y hasta 63 rangos de ingresos (por ejemplo, 1 = 0,01 $ – 0,99 $, 2 = 1,00 $ – 4,99 $, $\dots, 63 = 500,00 $+).

Los valores de conversión detallados se devuelven únicamente en el primer postback. El segundo y el tercer postback devuelven en su lugar valores de conversión generales.

Valores generales: clasificación del valor posterior a la instalación en niveles bajo, medio y alto

En la Ventana de conversión 1, Apple puede devolver el valor de conversión detallado o el general según el nivel de datos del postback aplicable. Las Ventanas de conversión 2 y 3 utilizan valores de conversión generales. Los valores detallados y generales se proporcionan conjuntamente cuando la app llama a la API de valores de conversión de SKAN 4; posteriormente, Apple determina qué representación, si la hay, se incluye en el primer postback en función del nivel de datos del postback. Los postbacks pueden contener valores de conversión detallados o generales, pero no ambos. Las etiquetas baja (low), media (medium) y alta (high) no tienen ningún significado comercial predefinido en SKAdNetwork; es la aplicación o la red publicitaria la que define qué representa cada nivel.

Un valor de conversión general consta de una propiedad de cadena que contiene uno de estos tres valores explícitos:

• low: Indica una interacción básica tras la instalación (por ejemplo, registro completado o sesión iniciada).

• medium: Indica un valor moderado tras la instalación (por ejemplo, alcanzar un hito intermedio en la app o un gasto de 1,00 $ – 19,99 $).

• high: Indica un valor elevado tras la instalación (por ejemplo, completar una suscripción de alto valor o un gasto de 20,00 $+).

En las Ventanas de conversión 2 y 3, el campo del valor de conversión no se utiliza para valores detallados; el sistema puede devolver el valor general proporcionado por el desarrollador cuando las condiciones de privacidad lo permitan.

Cómo funcionan los valores detallados y generales en las ventanas de conversión

Ventana de conversión 1 (días 0–2)

La Ventana de conversión 1 (días 0–2, aproximadamente las primeras 48 horas tras el primer lanzamiento de la app) abarca el periodo de medición inicial posterior a la instalación, durante el cual los desarrolladores pueden actualizar los valores de conversión detallados o generales antes de que el sistema cierre la ventana. En este intervalo, la aplicación móvil puede actualizar los valores de conversión varias veces a medida que el usuario completa eventos dentro de ella.

Dependiendo del nivel de datos del postback asignado por Apple, la Ventana de conversión 1 ofrece un valor detallado (de 0 a 63) o un valor general (low, medium, high). Si el nivel de datos del postback es el Nivel 0, el primer postback contiene únicamente el identificador de origen jerárquico de dos dígitos; el valor de conversión detallado o general se omite.

Ventanas de conversión 2 (de 3 a 7 días) y 3 (de 8 a 35 días)

Para proporcionar visibilidad sobre la retención de usuarios a medio y largo plazo, SKAdNetwork 4.0 introdujo dos ventanas de conversión adicionales:

• Ventana de conversión 2: Mide la interacción del usuario que se produce durante el periodo de medición de los días 3 a 7 posteriores a la instalación (una ventana de 5 días).

• Ventana de conversión 3: Mide la interacción del usuario que se produce durante el periodo de medición de los días 8 a 35 posteriores a la instalación (una ventana de 28 días).

A diferencia de la Ventana 1, las Ventanas de conversión 2 y 3 transmiten únicamente valores generales. Los valores detallados (de 0 a 63) no son compatibles en las ventanas 2 y 3. Los desarrolladores determinan el valor general notificado para cada ventana basándose en los eventos que ocurren durante ese periodo de medición.

Comprender los niveles de datos de los postbacks y el anonimato de la multitud

Apple determina el nivel de datos del postback para la descarga de la app basándose en el volumen de usuarios asociado a la aplicación o dominio de origen, la aplicación anunciada, el país donde se instaló la aplicación anunciada y el identificador de origen jerárquico proporcionado por la red publicitaria. Según el nivel, el primer postback puede exponer dos, tres o cuatro dígitos del identificador de origen jerárquico, mientras que el valor de conversión puede omitirse, devolverse como general o devolverse como detallado. De acuerdo con la documentación oficial del marco SKAdNetwork de Apple (StoreKit > SKAdNetwork), Apple no publica umbrales universales de volumen de instalaciones que los desarrolladores puedan utilizar para asociar campañas a niveles de datos fijos.

La siguiente tabla resume cómo se correlacionan las cargas útiles de datos de los postbacks con los niveles de privacidad en las distintas ventanas de conversión, según la documentación oficial del marco SKAdNetwork de Apple:

Utilizar la propiedad lockWindow para finalizar anticipadamente las ventanas de conversión

Establecer lockWindow: true bloquea el valor de conversión para la ventana actual. El sistema prepara de inmediato el postback correspondiente y omite las posteriores actualizaciones del valor de conversión en esa ventana. El postback sigue estando sujeto al retraso de entrega aleatorio establecido por Apple.

Por ejemplo, si un usuario completa una compra a las 6 horas de iniciarse la Ventana de conversión 1, la app puede configurar lockWindow: true. Esto cierra antes la ventana de medición y permite que comience el proceso de programación de postbacks de Apple, lo que puede hacer que el sistema prepare el postback con antelación, aunque se sigue aplicando el retraso de entrega aleatorio correspondiente.

Comparativa estructural de las ventanas de conversión 1, 2 y 3 de SKAdNetwork

Evaluación comparativa de los tiempos de los postbacks, tipos de valores y rangos de retraso en SKAN 4.0

La gestión de un esquema multiventana de SKAdNetwork requiere asignar los activadores de eventos en función de la duración de la ventana, la granularidad de los valores admitidos y los rangos de retraso de los postbacks.

La siguiente tabla contrasta las características técnicas de las Ventanas de conversión 1, 2 y 3:

Evaluación de la granularidad de los datos y las marcas temporales en las ventanas de conversión de SKAN

Si bien la Ventana de conversión 1 ofrece la mayor resolución de datos (valores detallados de 6 bits), las Ventanas 2 y 3 proporcionan señales esenciales de retención a largo plazo. Los analistas deben tener en cuenta los rangos de retraso de los postbacks al cruzar los datos de los postbacks de SKAN con los libros de transacciones internos.

Dado que Apple aplica un retraso aleatorio de 24 a 48 horas a los postbacks de la Ventana 1 y de hasta 144 horas para las Ventanas 2 y 3, los postbacks que llegan a los puntos finales de atribución no reflejan conversiones en tiempo real, sino periodos de interacción históricos completados días antes.

Los ingenieros que deseen configurar el registro del SDK en el lado del cliente y el análisis automatizado de los postbacks de SKAN pueden consultar la documentación de integración del SDK de atribución de OpoInstall para revisar la configuración de la estructura de la carga útil.

Cómo diseñar un esquema de valores de conversión de SKAdNetwork

Ejemplo de asignación de un esquema de conversión de SKAdNetwork 4.0

El diseño de un esquema de SKAdNetwork requiere relacionar los hitos dentro de la app y los tramos de compra con valores discretos, tanto detallados como generales.

La siguiente tabla ilustra un diseño estándar de esquema de valores de conversión para una aplicación móvil:

Marco de diseño de esquemas en producción: aplicaciones de juegos frente a aplicaciones de suscripción

Según la dinámica de monetización del producto, los equipos de ingeniería adaptan la configuración de los esquemas para priorizar la progresión rápida en el embudo o los niveles de ingresos a largo plazo:

• Aplicaciones de juegos (prioridad en los ingresos): Los valores del 0 al 10 reflejan el progreso inicial en el tutorial, mientras que del 11 al 63 representan los ingresos acumulados observados durante la Ventana 1. Los valores generales en las Ventanas 2 y 3 indican la frecuencia de compras repetidas (low = activo, medium = segunda compra, high = comprador VIP).

• Aplicaciones de suscripción (prioridad en las pruebas): Los valores del 0 al 5 corresponden al registro y la configuración del perfil, el valor 10 a la activación de la prueba gratuita y del 20 al 63 a la selección de planes de suscripción. Los valores generales en las Ventanas 2 y 3 indican la conversión de prueba a pago (low = sesión activa, medium = prueba convertida, high = suscripción renovada).

Cómo elegir entre valores de conversión basados en ingresos y basados en eventos

La elección entre modelos de esquemas basados en ingresos o en eventos requiere alinear la lógica del valor de conversión con la mecánica de monetización de la app:

• Modelos basados en ingresos (comercio electrónico y juegos): Son óptimos para aplicaciones en las que los eventos de compra se producen en las primeras 48 horas. Al codificar el gasto acumulado en tramos de ingresos progresivamente más amplios, las plataformas del lado de la demanda (DSP) reciben señales de ingresos útiles para el análisis de campañas. Si el esquema se basa en los ingresos acumulados, cada actualización de conversión debe reflejar el ingreso acumulado actual del usuario tras la instalación, y no solo el importe de la última transacción.

• Modelos de embudo basados en eventos (suscripciones): Ideales para aplicaciones con periodos de prueba o de consideración prolongados. Al asociar hitos secuenciales (por ejemplo, del registro a la activación de la prueba y a la suscripción), la medición de campañas evalúa a los usuarios en periodo de prueba con alta intención de compra antes de que expiren los días 0–2.

Diseño de tramos de ingresos: asignación de rangos de compras dentro de la app a valores de 0 a 63

Al analizar el retorno de la inversión publicitaria, la asignación de valores detallados de 6 bits a tramos de ingresos representa un diseño de esquema eficaz. La aplicación calcula los ingresos acumulados según su propia lógica de negocio y codifica el resultado en el valor de conversión. Los límites de los tramos que se muestran a continuación son ilustrativos y no constituyen una asignación completa de 64 tramos para producción. En un entorno de producción, dichos límites deben derivarse de la distribución de compradores de la app, la sensibilidad esperada del retorno y los objetivos de la campaña.

Un ejemplo de esquema de ingresos de 6 bits para una aplicación de comercio electrónico o de juegos se estructura de la siguiente manera:

• Value 0: Sin evento medido posterior a la instalación / base.

• Value 1: De 0,01 $ a 0,99 $ (microtransacción).

• Value 2: De 1,00 $ a 4,99 $.

• Value 3: De 5,00 $ a 9,99 $.

• dots\dotsdots

• Value 62: De 250,00 $ a 499,99 $.

• Value 63: 500,00 $ + (nivel de compradores de alto valor).

Cuando un usuario completa una compra dentro de la app, el SDK móvil calcula el gasto acumulado del usuario observado durante la Ventana 1, identifica el tramo numérico correspondiente e invoca updatePostbackConversionValue.

Diseño de embudos de interacción: asignación de hitos secuenciales

Para aplicaciones de suscripción o herramientas de utilidad donde las compras dentro de la app ocurren tarde en el ciclo de vida del usuario, asociar los valores detallados a hitos de interacción secuenciales proporciona señales tempranas sobre el rendimiento de la campaña.

Un esquema de hitos de interacción cartografía la profundidad de la progresión:

• Value 1: Registro de cuenta completado.

• Value 2: Tutorial de introducción finalizado.

• Value 3: Configuración de perfil y preferencias completada.

• Value 4: Prueba gratuita activada.

• Value 5: Primera compartición de contenido en la app.

• Value 10: Suscripción de pago iniciada.

SKAN 4.0 ofrece una gestión de los valores de conversión más flexible en comparación con versiones anteriores, aunque los anunciantes suelen seguir empleando estrategias de valores crecientes para garantizar la estabilidad en la optimización. La aplicación debe definir reglas de precedencia deterministas para que múltiples eventos que ocurran en la misma ventana se resuelvan en un único estado final, ya sea detallado o general.

[App Launch / Event] ──> [SDK Calls updatePostbackConversionValue]
                                    │
                                    ▼
         ┌──────────────────────────┴──────────────────────────┐
         ▼                                                     ▼
[Conversion Window 1 (0-2 Days)]               [Conversion Window 2 & 3]
 (Fine 0-63 or Coarse)                               (Coarse Only: Low/Med/High)
         │                                                     │
         └──────────────────────────┬──────────────────────────┘
                                    ▼
                [Apple Attribution System Delayed Postback]
                                    │
                                    ▼
               [Attribution / Analytics Backend]

Ejemplos ilustrativos de esquemas de SKAdNetwork 4.0 listos para producción

1. Esquema para juegos móviles (híbrido de ingresos y hitos)

Las aplicaciones de juegos utilizan un esquema híbrido en la Ventana 1, reservando los valores más bajos (0–10) para los hitos del tutorial y asignando los valores superiores (11–63) a los ingresos acumulados observados durante dicha ventana. En este esquema ilustrativo, la app asigna de forma independiente estos hitos a categorías generales.

• Value 1: Tutorial completado (asignación general low)

• Value 5: Nivel 10 alcanzado (asignación general medium)

• Value 15: Primera compra en la app (0,99 $ - 9,99 $)

• Value 40: Gasto medio (10,00 $ - 99,99 $) (asignación general high)

• Value 63: Comprador VIP (100,00 $+) (asignación general high)

2. Esquema para app de suscripción (enfocado en pruebas y renovaciones)

Las aplicaciones de suscripción asignan la Ventana 1 a la velocidad de conversión de las pruebas gratuitas, mientras utilizan los valores generales de las Ventanas 2 y 3 para realizar un seguimiento de las conversiones a largo plazo de prueba a pago y de los eventos de renovación.

• Ventana 1: Value 1 = Registro, Value 10 = Prueba iniciada (asignación general medium), Value 63 = Suscripción a plan anual (asignación general high)

• Ventana 2 (días 3-7): low = Sesión activa, medium = Prueba convertida, high = Plan anual retenido

• Ventana 3 (días 8-35): low = Reinteracción con la app, medium = Suscriptor de pago activo, high = Suscripción renovada

Gestión de esquemas de SKAdNetwork a escala

Para los equipos de crecimiento e ingeniería de datos que gestionan múltiples campañas en iOS, la administración centralizada de los valores de conversión permite reducir errores de implementación, automatizar la asignación de cargas útiles y mantener una visibilidad completa de los postbacks. Configurar flujos de trabajo seguros de atribución de instalaciones garantiza la integridad de los datos en los SDKs de los clientes y en las bases de datos de informes de backend.

Implementación de SKAdNetwork 4.0 con StoreKit

Actualizaciones programáticas de valores de conversión mediante StoreKit

Los postbacks de SKAdNetwork 4 están disponibles cuando se cumplen las condiciones de elegibilidad pertinentes de SKAdNetwork 4. Para recibir múltiples postbacks de SKAdNetwork 4, la app anunciada debe actualizar los valores de conversión durante las ventanas de conversión aplicables. Una actualización en la Ventana 1 no crea automáticamente los valores de conversión para la Ventana 2 o la Ventana 3. Para las aplicaciones que utilizan las API de SKAdNetwork 4, la app anunciada debe compilarse con el SDK de iOS 16.1 o posterior y ejecutarse en iOS 16.1 o posterior para invocar SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:completionHandler:) dentro de StoreKit. AdAttributionKit es un marco de atribución independiente de Apple y queda fuera del alcance de este ejemplo de implementación del valor de conversión de SKAdNetwork.

El método acepta tres parámetros principales:

1. fineValue: Un número entero de 0 a 63.

2. coarseValue: Una enumeración SKAdNetwork.CoarseConversionValue (.low, .medium, .high).

3. lockWindow: Un indicador booleano que señala si se debe finalizar anticipadamente la ventana.

Para la medición de múltiples postbacks en SKAdNetwork 4, la app debe continuar actualizando los valores de conversión durante las ventanas de conversión correspondientes; establecer un valor para la Ventana 1 no rellena automáticamente las Ventanas 2 y 3.

Los desarrolladores pueden consultar las especificaciones técnicas relativas a los esquemas de registro de eventos sin procesar y las estructuras de las cargas útiles de SKAN en la documentación oficial para desarrolladores.

El código y el esquema siguientes ilustran cómo los desarrolladores invocan la API de actualización de SKAN 4.0 en Swift y cómo los recopiladores de backend dan formato a la carga útil resultante del postback:

Nota: Los siguientes fragmentos de esquema y código son ejemplos conceptuales y no constituyen una especificación de la API de Apple u OpoInstall.

// Swift Example: Updating SKAdNetwork 4.0 Conversion Value on iOS 16.1+
import StoreKit

func updateSKANConversionValue(fineValue: Int, coarseValue: SKAdNetwork.CoarseConversionValue, shouldLock: Bool) {
    guard (0...63).contains(fineValue) else { return }
    if #available(iOS 16.1, *) {
        SKAdNetwork.updatePostbackConversionValue(fineValue, coarseValue: coarseValue, lockWindow: shouldLock) { error in
            if let error = error {
                print("SKAN Update Error: \(error.localizedDescription)")
            } else {
                print("SKAN Value Updated Successfully: Fine = \(fineValue), Coarse = \(coarseValue.rawValue), Locked = \(shouldLock)")
            }
        }
    } else {
        // Deprecated legacy API used for compatibility with older OS versions.
        SKAdNetwork.updateConversionValue(fineValue)
    }
}

{
  "example_only": true,
  "privacy_note": "Illustrative schema only",
  "measurement_model": "cumulative_revenue",
  "precedence": "highest_qualifying_value",
  "lock_policy": "lock_on_terminal_conversion",
  "event_type": "skan_conversion_value_mapping_config",
  "app_id": "com.example.iosapp",
  "skan_schema_version": "4.0",
  "window_1_config": {
    "fine_value_mappings": [
      { "value": 0, "event_name": "app_launch_or_baseline", "min_revenue_cents": 0 },
      { "value": 1, "event_name": "registration", "min_revenue_cents": 0 },
      { "value": 10, "event_name": "free_trial", "min_revenue_cents": 0 },
      { "value": 30, "event_name": "first_purchase", "min_revenue_cents": 100 },
      { "value": 63, "event_name": "whale_purchase", "min_revenue_cents": 50000 }
    ],
    "coarse_value_mappings": {
      "low": "app_launch_or_registration",
      "medium": "first_purchase_under_20",
      "high": "purchase_over_20"
    }
  },
  "window_2_config": {
    "coarse_value_mappings": {
      "low": "d3_d7_active_session",
      "medium": "d3_d7_repeat_purchase",
      "high": "d3_d7_subscription_renewed"
    }
  },
  "window_3_config": {
    "coarse_value_mappings": {
      "low": "d8_d35_active_session",
      "medium": "d8_d35_repeat_purchase",
      "high": "d8_d35_subscription_retained"
    }
  }
}

Mejores prácticas para los valores de conversión de SKAdNetwork

Alineación del diseño del esquema de conversión con los objetivos de la campaña

Diseñar un esquema de SKAdNetwork requiere seleccionar reglas de asignación que coincidan con los objetivos principales de tus campañas. Los equipos de compra de medios que buscan optimizar las conversiones de pruebas iniciales deben priorizar los hitos secuenciales del embudo en la Ventana de conversión 1. Por el contrario, los equipos de rendimiento que evalúan compras de alto valor deben implementar tramos de ingresos granulares.

Consolidación de campañas para superar los umbrales de anonimato de la multitud

Para evitar que los postbacks devuelvan valores null o recurran a alternativas generales, los equipos de crecimiento móvil gestionan la densidad de sus campañas:

• Reducir la fragmentación de campañas: Con el fin de disminuir la probabilidad de obtener niveles de datos de postbacks bajos, los equipos pueden evitar la fragmentación innecesaria de campañas y una segmentación excesivamente limitada. Sin embargo, Apple no publica un umbral universal de gasto o de instalaciones que garantice un nivel de datos de postback específico.

• Ampliar los parámetros de segmentación: Evita una segmentación geográfica o demográfica demasiado restrictiva que rompa los umbrales de anonimato de la multitud.

• Optimizar la estrategia de LockWindow: Los equipos generalmente deben considerar el uso de lockWindow: true únicamente cuando tengan la certeza de que no se espera ninguna otra señal de conversión valiosa en el tiempo restante de dicha ventana.

Lista de comprobación para el esquema de valores de conversión de SKAdNetwork 4.0

Para garantizar el cumplimiento total del seguimiento en SKAdNetwork 4.0 y maximizar la medición del LTV, verifica que tu esquema cumpla con los siguientes requisitos de ingeniería:

• [ ] Objetivo de optimización principal: Define si tu campaña se optimiza para los hitos de interacción temprana o para los ingresos acumulados en 48 horas.
• [ ] Asignación de valores detallados en la Ventana 1: Asigna valores enteros discretos de 6 bits (0–63) a los pasos secuenciales del embudo o a los tramos de ingresos.
• [ ] Asignación de valores generales en la Ventana 1: Configura rangos de cadenas generales de tipo low, medium y high para envíos con bajo anonimato de la multitud.
• [ ] Asignación de valores generales en las Ventanas 2 y 3: Establece la lógica de seguimiento general para las ventanas de postbacks de 3 a 7 días y de 8 a 35 días.
• [ ] Precedencia de eventos y reglas de bloqueo: Define una precedencia de eventos determinista y configura lockWindow: true exclusivamente en los eventos de conversión finales.

Errores comunes en el diseño de esquemas de SKAN 4.0 que reducen la calidad de la medición

• Comprimir los tramos de gasto en el valor 63: Agrupar compras de 10 $ y de 1 000 $ en el mismo tramo superior reduce la diferenciación de ingresos disponible para el análisis y la optimización de las campañas.

• Ejecución prematura de LockWindow: Llamar a lockWindow: true en un evento de registro temprano bloquea la Ventana de conversión 1 de forma permanente, descartando las compras posteriores que ocurran dentro del plazo de 48 horas.

• Sobrecargar las Ventanas 2 y 3: Intentar asignar reglas generales complejas para postbacks que llegan hasta 35 días después complica la evaluación de las campañas sin mejorar la optimización de las pujas iniciales.

Cómo solucionar valores nulos en los postbacks de SKAdNetwork y caídas en el anonimato de la multitud

Diagnóstico de altas tasas de valores de conversión nulos: comprender el bajo anonimato de la multitud en las campañas

Al inspeccionar el rendimiento de las campañas de SKAN en los paneles de atribución, los analistas observan con frecuencia postbacks que devuelven valores null o carecen de valores de conversión. Una alta proporción de valores de conversión faltantes puede indicar que el nivel de datos del postback aplicable no permite a Apple revelar información sobre dichos valores.

Para resolver las caídas en el anonimato de la multitud y mejorar la visibilidad de los valores de conversión, los equipos de rendimiento consolidan las claves de las campañas y evalúan la densidad de su estructura para garantizar que el volumen de instalaciones supere los umbrales de anonimato.

Solución de desajustes de secuencias y trampas de degradación del valor de conversión

En SKAdNetwork 4.0, los valores de conversión se pueden actualizar de forma flexible durante la Ventana 1, pero los desarrolladores deben gestionar los estados de lockWindow con cuidado.

Si una aplicación establece lockWindow: true en un evento de bajo valor (por ejemplo, Value 2 = Registro), la ventana se bloquea permanentemente. Si el usuario completa posteriormente una compra de 100 $ diez minutos más tarde dentro de la ventana de 48 horas, el sistema no podrá actualizar el valor de conversión, lo que se traducirá en un LTV de campaña infravalorado. Los desarrolladores deben asegurarse de que lockWindow: true se ejecute en eventos de conversión finales y de alto valor.

Gestión de los rangos de retraso aleatorios impuestos por el sistema de atribución de Apple

Para evitar que los anunciantes intenten reidentificar a usuarios individuales cruzando las marcas de tiempo de las conversiones con los registros de clics web, Apple aplica un retraso aleatorio obligatorio en todos los envíos de postbacks.

Para la Ventana de conversión 1, el sistema prepara el postback cuando se cierra la ventana de conversión o cuando la app la bloquea. A continuación, Apple aplica un retraso aleatorio de 24 a 48 horas. Las Ventanas 2 y 3 utilizan un retraso aleatorio de 24 a 144 horas tras el cierre o bloqueo de su ventana correspondiente. Las canalizaciones de ingeniería de datos deben tener en cuenta estos retrasos sistemáticos y evitar el establecimiento de ajustes de ofertas automatizados a corto plazo basados en los flujos de datos de SKAN.

Puntos clave

• Medición multiventana: SKAN 4.0 amplía la medición a lo largo de tres ventanas de postbacks (0-2 días, 3-7 días, 8-35 días), utilizando valores detallados (0-63) y generales (low, medium, high).

• Umbrales de anonimato de la multitud: Un mayor volumen de instalaciones en las campañas puede permitir el uso de valores detallados, mientras que las campañas con bajo volumen reciben valores generales o sufren la supresión de datos con null para preservar la privacidad.

• Uso estratégico de LockWindow: Ejecutar lockWindow: true en los eventos de conversión finales puede reducir el tiempo de espera antes del bloqueo de la ventana, permitiendo obtener comentarios más rápidos sobre las campañas.

Resumen y marco de decisiones

Optimizar la medición de campañas en iOS bajo las directrices de privacidad de Apple requiere configurar un esquema de valores de conversión de SKAdNetwork bien estructurado. Pasar del seguimiento tradicional con IDFA a los postbacks multiventana de SKAN 4.0 permite a los equipos de rendimiento evaluar tanto la activación inmediata como la retención de usuarios a largo plazo.

Al asignar valores detallados de 6 bits para la interacción inmediata en 48 horas y valores generales para ventanas ampliadas de 35 días, los equipos de crecimiento capturan señales críticas de ingresos y retención. Integrar los SDKs de los clientes con herramientas automatizadas de esquemas de SKAN proporciona la infraestructura necesaria para descifrar los postbacks agregados y ofrecer señales de optimización para la eficiencia de las campañas en iOS.

Para explorar cómo la medición móvil unificada puede optimizar la estrategia de crecimiento de tu aplicación, consulta la referencia de implementación de atribución móvil de OpoInstall o registra una cuenta en la consola de desarrolladores de OpoInstall.

Recursos relacionados

Para profundizar en tu comprensión de la medición en SKAdNetwork, la infraestructura de atribución móvil y el crecimiento de aplicaciones respetuoso con la privacidad, explora nuestras guías técnicas:

• SKAdNetwork frente a la atribución de MMP: diferencias clave explicadas: Comprende cómo se compara el marco nativo SKAdNetwork de Apple con los modelos de atribución independientes de socios de medición móvil (MMP) y cómo operan ambos sistemas de forma conjunta.

• Cómo implementar un SDK de seguimiento de referencias con deep linking diferido y atribución de instalaciones: Aprende cómo las apps móviles preservan el contexto de adquisición a través de los flujos de instalación en las tiendas de aplicaciones utilizando deep linking diferido y flujos de trabajo con SDKs de atribución.

• Cómo funcionan los socios de medición móvil (MMP): Explora cómo las plataformas de MMP ingieren señales de atribución, procesan eventos posteriores a la instalación y generan informes de medición de campañas agregados.

Temas relacionados

• Conceptos: SKAdNetwork, valor de conversión, ventana de postback, anonimato de la multitud, LockWindow

• Tecnologías: Socios de medición móvil (MMP), StoreKit, AdAttributionKit, postback de servidor a servidor

• API: Capacidades de registro de eventos de atribución móvil de OpoInstall, API de SKAdNetwork de Apple, API de AdAttributionKit de Apple

• Documentación oficial y referencias:

  • Documentación para desarrolladores de Apple sobre el marco SKAdNetwork

  • Documentación para desarrolladores de Apple sobre AdAttributionKit

  • Estándares del grupo de trabajo de rendimiento web del W3C