Desde iOS 14.5, la atribución móvil libra una batalla por la supervivencia. En iOS 17 y a mediados de 2026, hemos llegado a un punto: las señales determinísticas rondan el 15-20%, las conversiones modeladas son mayoritarias, SKAdNetwork 4 maduró pero no es estándar, y cada plataforma confía en su propia predicción. Los CMO aún no pueden responder "cuánto presupuesto asigno a cada canal" porque el stack de atribución es fragmentado y contradictorio. En este artículo explicamos la arquitectura de medición móvil post-iOS 17, la jerarquía de fiabilidad de las fuentes de señales y por qué el testing incremental se convirtió en algo más importante que la medición misma.

Las señales determinísticas ya no son mayoría

Cuando ATT (App Tracking Transparency) llegó en iOS 14.5, las tasas de opt-in de IDFA cayeron al 5-15%. En iOS 17, esta banda subió al 15-20%, pero sigue siendo minoría. La atribución determinística —emparejar el anuncio que un usuario clickeó con el evento que realizó en la app— ahora vive en los rangos de datos de muestra. Puedes usar este segmento demografifico como un segmento, pero no puedes extrapolar el desempeño agregado desde allí, porque los usuarios que optan por compartir datos son conscientes de privacidad y resistentes a anuncios, un perfil distinto del resto.

Para el 80-85% restante, hay tres fuentes de señales: SKAdNetwork (el framework privacy-preserving de Apple), matching probabilístico (restos de fingerprinting) y modelado de plataforma (predicciones de machine learning de Meta/Google). Ninguno es determinístico. Los postback de SKAdNetwork agregan eventos, llegan con retrasos de 24-144 horas, y el esquema de codificación de valor de conversión es limitado (un entero de 6 bits entre 0-63). El matching probabilístico está prohibido por Apple —las firmas detectadas corren riesgo de expulsión del App Store. Lo que queda es modelado —Meta Aggregated Event Measurement (AEM), los mecanismos de inyección de ruido de Privacy Sandbox de Google— pero estas predicciones no pueden reconciliarse cross-plataforma.

Resultado: tu stack de atribución ya no es determinístico sino probabilístico, y debes aceptarlo.

SKAdNetwork 4: maduro pero aún no estándar

SKAdNetwork avanzó a versión 4 en 2023. Las mejoras clave: los postback ahora son de 3 fases (0-2 días, 3-7 días, 8-35 días), se agregó soporte para atribución web-a-app (los installs desde web views compatibles con SKAdNetwork ahora pueden rastrearse), y con el identificador de origen jerárquico puedes definir la fuente de anuncio en 4 capas (campaña / grupo de anuncios / creativo). El esquema de encriptación de valor de conversión no cambió, pero Apple agregó un threshold de anonimato de multitud en los postback —un número mínimo de usuarios— que impide que algunas campañas de bajo tráfico reciban postbacks.

A mediados de 2026, la adopción ronda el 60%. Meta y Google soportan SKAdNetwork 4, pero redes como Unity Ads, ironSource y AppLovin aún están en transición entre versiones. Esto significa que la misma campaña se mide a través de diferentes DSP con diferentes versiones de SKAdNetwork, creando filas irreconciliables en los dashboards.

Otro problema: los postback de SKAdNetwork solo acreditan al último anuncio clickeado (atribución last-click). No hay view-through ni assisted touchpoints. En un customer journey multicanal, la red que realiza el último toque recibe todo el conversion value, los toques intermedios desaparecen.

Ejemplo de mapeo de valor de conversión

Postback 0 (0-2 días):
- conversion_value = 1 → install
- conversion_value = 2 → primer open + onboarding completado

Postback 1 (3-7 días):
- conversion_value = 10-20 → codifica el monto de compra in-app en primeros 7 días 
  en bandas de 10 USD

Postback 2 (8-35 días):
- conversion_value = 30-40 → codifica LTV estimado hasta día 35 en bandas de 50 USD

Por la limitación de 6 bits, no puedes enviar revenue directamente; defines el esquema de codificación y este puede variar entre campañas. Resultado: necesitas una capa de mapeo externa para comparaciones apples-to-apples.

Conversiones modeladas: no predicción sino señal mayoritaria

El AEM (Aggregated Event Measurement) de Meta y Privacy Sandbox de Google son ahora el centro del stack de atribución móvil. Estos modelos predicen el comportamiento de usuarios sin IDFA mediante machine learning: el usuario vio una campaña, instaló la app pero no se estableció un vínculo determinístico —el modelo predice estadísticamente basándose en el comportamiento pasado de usuarios con propiedades similares de campaña-cohorte-demográfica.

Según el reporte 2025 de Meta, el 70% de las conversiones de install en iOS son modeladas. En Google Ads ese porcentaje es 60-65%. Es decir, la mayoría de tus números ROAS en el dashboard son predicciones. ¿Qué tan cercanas son al reality? Meta reclama 85-90% de precisión en sus validaciones internas (comparándolas con tests de hold-out de incrementalidad). Pero esa precisión está a nivel agregado —si ejecutas un test de incrementalidad a nivel de campaña, puedes ver una desviación de ±30% entre el ROAS modelado y el lift real.

Segundo problema: las conversiones modeladas son platform-específicas. El modelo de Meta no habla con el de Google. Si el mismo usuario se modeló diferente en ambas plataformas, la deduplicación cross-platform es imposible. Sin MMM (Marketing Mix Modeling) o tests geo-holdout, no puedes saber cuánto contribuyó realmente cada plataforma.

Tercer problema: ritmo de actualización de modelos. Si Meta actualiza su modelo semanalmente y tú detienes una campaña, el aprendizaje del modelo se refleja con 7-14 días de retraso. Esto hace que los tests de "detengamos la campaña y veamos el impacto" sean complicados porque el modelo experimenta inercia.

Testing incremental: ahora es el mecanismo de decisión, no la medición

En un mundo donde el 70% es conversión modelada, no puedes confiar en los números del dashboard. La solución: testing incremental —experimentos controlados que miden el crecimiento causal real de una campaña. Los dos métodos más comunes son geo-holdout y audience holdout.

Geo-holdout: apagas la campaña en geografías específicas y mides la diferencia en installs o revenue. Por ejemplo, detienes tu campaña Meta de iOS en 10 estados, continúas en los otros 40, y después de 14 días ves cuánto cayó la tasa de install en las geografías apagadas. Esa caída es el efecto causal real de la campaña. La ventaja del geo-holdout: no requiere datos a nivel de usuario, es independiente de ATT. La desventaja: las diferencias macroeconómicas entre el control y treatment (feriados locales, densidad de competencia) pueden arruinar el resultado.

Audience holdout: usas campañas PSA (Public Service Announcement) o mecanismos de ghost bid para excluir aleatoriamente un grupo de usuarios de ver anuncios, comparándolo con el grupo que sí los ve. Meta lo ofrece como Conversion Lift tests, Google como Brand Lift tests. Si mantienes el holdout en 5-10%, necesitas mínimo 100.000 personas de muestra para poder estadístico —así que en campañas pequeñas no funciona.

Ambos métodos toman 14-28 días, lo que ralentiza la iteración. Pero en el stack post-iOS 17, no hay otro camino para distribuir presupuesto sin confiar en ROAS modelado. En nuestros trabajos de marketing de desempeño, ejecutamos testing incremental no antes del launch sino cada trimestre, monitoreando la desviación del modelo.

Privacy Sandbox y atribución web-a-app

En iOS 17, las reglas de ITP (Intelligent Tracking Prevention) de Safari se endurecen. Los usuarios redirigidos desde una web view hacia el App Store ahora entran en el flujo web-a-app de SKAdNetwork 4, pero aquí la ventana de conversión está limitada a 24 horas. Si un usuario vio una campaña en web hace 48 horas y recién instala la app, esa atribución se pierde.

El Topics API de Privacy Sandbox de Google y FLEDGE (First Locally-Executed Decision over Groups Experiment) ofrecen alternativas en web para Safari de iOS, pero aún no son estándar para atribución dentro de apps móviles. Hay rumores de que Apple lanzará algo similar a Topics en 2026, pero no hay anuncio oficial.

Detalle importante: las cadenas de atribución web-a-app, aunque sean sin cookies, SKAdNetwork aún no puede acreditar correctamente la campaña porque no puedes llevar el click ID del lado web a través de la redirección del App Store. Apple está probando un mecanismo de "web attribution token" dentro de StoreKit 2, pero aún no está en producción.

Post-lookback maturity: ¿son suficientes 35 días?

La ventana de postback más larga de SKAdNetwork es 35 días. Pero en apps de juegos, finanzas y suscripciones, el LTV real surge en 90-180 días. En el día 35, codificas una predicción de LTV por cohorte en el valor de conversión, pero esa predicción no captura churn tardío o monetización diferida.

La solución: las capas de modelado post-atribución de los MMP (Mobile Measurement Partner —Adjust, AppsFlyer, Singular). Estas herramientas toman los postback de SKAdNetwork y, entrenadose en su pool de datos determinísticos (usuarios opt-in), generan predicciones de LTV a 90 días. Pero esta predicción también es un modelo —si el datos de entrenamiento del MMP no refleja exactamente tu comportamiento app, la predicción se desvía.

Alternativa: hacer cohort analysis manual. Tomas los datos de SKAdNetwork de primeros 35 días, haces tracking manual del mismo cohorte hasta 90 días en dashboards BI propios, y retroactivamente ajustas el ROAS de campaña. Es manual, pero es el método más cercano a "ground truth" post-iOS 17.

Qué hacer ahora

El stack de atribución post-iOS 17 es disperso, lento y dominado por predicciones. Si no confías en los ROAS de tu dashboard, estás reaccionando correctamente. Sigue estos pasos: revisa tu mapeo de valor de conversión en SKAdNetwork 4; asegúrate de codificar correctamente los eventos de primeros 7-14 días. Extrae los porcentajes de conversiones modeladas de tus dashboards MMP —si exceden el 70%, el testing incremental es obligatorio. Al elegir entre geo-holdout y audience holdout, decide según tu volumen diario de installs —por debajo de 1.000 diarios, el audience holdout no alcanza significancia estadística. Si tienes flujos web-a-app, considera la ventana de atribución de 24 horas y prueba cambiar campañas de retargeting hacia canales con ventanas más amplias. Finalmente: no ignores la atribución, pero tampoco la conviertas en tu único input de decisión —construye un triángulo con MMM, análisis de cohorte LTV y testing incremental. En post-iOS 17, el juego se gana no con señales determinísticas, sino alineando predicción correcta con decisión correcta.