App Tracking Transparency: qué es seguir, cuándo preguntar y qué se rompe si no

Hay una confusión que sobrevive en casi todas las conversaciones sobre este tema y conviene disolverla antes de escribir una línea de código: el marco de transparencia del seguimiento no pregunta si puedes hacer publicidad, ni si puedes medir, ni siquiera si puedes recoger datos. Pregunta por una operación específica y bien definida, la de vincular información obtenida en tu app con información obtenida por otras empresas en sus propias apps, webs o canales fuera de línea, con fines publicitarios o de medición publicitaria. Todo lo que no sea esa operación queda fuera, por muchos datos que manejes; y todo lo que sea esa operación queda dentro, aunque no toques el identificador de publicidad. Quien entiende que la unidad regulada es el enlace entre dominios de datos, y no el dato ni el identificador, deja de hacer las preguntas equivocadas.

Qué cuenta exactamente como seguimiento

La definición operativa tiene dos ramas y ambas hay que memorizarlas. La primera es el enlace entre dominios: tomar datos de una persona o de un dispositivo recogidos en tu app y combinarlos con datos de esa misma persona o dispositivo recogidos por otra empresa en sus propias propiedades, con la finalidad de publicidad segmentada o de medición de publicidad. La segunda rama es el intermediario: compartir datos con un corredor de datos, un actor cuyo negocio consiste en agregar y revender información sobre personas. Esa segunda rama sorprende porque no exige que tú hagas nada con el resultado: basta con entregarlo.

Igual de importante es el conjunto complementario, porque es donde se equivocan los equipos prudentes por exceso. No es seguimiento vincular datos de distintas apps o webs de tu propia empresa, siempre que sean tuyas y así se declare. No es seguimiento el enlace que ocurre y termina en el dispositivo, sin que salga de él información que permita reconstruirlo. No es seguimiento compartir datos con un corredor exclusivamente para prevención del fraude o para detección de fraude publicitario y seguridad. Y no es seguimiento la analítica de producto que se queda dentro de tu propio perímetro, que es exactamente el motivo por el que la mayoría de las apps que muestran el diálogo no tendrían por qué mostrarlo.

Sobre esa definición se apoya una prohibición que muchos equipos descubren tarde y que es más severa que el propio diálogo. La creación de huellas de dispositivo —derivar un identificador estable a partir de señales del hardware, la configuración o el entorno para reconocer al usuario entre apps— está prohibida siempre, con autorización y sin ella. El permiso concedido habilita el identificador de publicidad y el enlace declarado; no convierte en legítimo un método que las reglas de la plataforma vetan por sí mismo. De ahí que las APIs de motivo requerido de la lección anterior y este marco sean dos caras del mismo diseño: una cierra la puerta técnica, la otra regula la puerta legítima.

Pedir bien, una sola vez

La API es minúscula y ahí empieza el problema: su simplicidad esconde tres condiciones de uso que provocan la mayoría de los fallos en producción. La primera es que la petición solo se procesa con la app en primer plano y activa. Llamarla durante el arranque, desde el inicializador de la app o antes de que la escena alcance el estado activo, no muestra ningún diálogo y devuelve el estado indeterminado sin error, con lo que el equipo concluye que el usuario dijo que no. La segunda es que la cadena NSUserTrackingUsageDescription debe existir en el Info.plist, con las mismas exigencias de concreción que cualquier otra. Y la tercera es que el diálogo se muestra una única vez por instalación: no hay segunda oportunidad salvo desinstalación, y si el usuario ha desactivado globalmente la posibilidad de que las apps pregunten, el estado será denegado sin que ningún diálogo llegue a aparecer.

import AppTrackingTransparency
import SwiftUI

struct RaizApp: View {
    @Environment(\.scenePhase) private var fase
    var body: some View {
        Contenido()
            .task(id: fase) {
                guard fase == .active else { return }
                // pequena espera: la escena activa no garantiza ventana presentable
                try? await Task.sleep(for: .milliseconds(500))
                _ = await ATTrackingManager.requestTrackingAuthorization()
            }
    }
}

Alrededor del diálogo hay reglas de presentación que la revisión aplica con rigor. Puedes anteponer una pantalla propia que explique el beneficio, y es recomendable por el mismo motivo que en cualquier otro permiso: absorbe el rechazo sin gastar el intento. Lo que no puedes hacer es incentivar la respuesta afirmativa con recompensas, monedas virtuales o funcionalidad extra; tampoco condicionar el uso de la app a la aceptación; tampoco imitar el aspecto del diálogo del sistema ni redactar tu pantalla de modo que el usuario crea que el botón de permitir es el que cierra un anuncio. Y hay un detalle de secuencia que decide la conversión más que cualquier texto: el diálogo debe llegar cuando el usuario ya ha experimentado valor, no en el primer segundo de la primera sesión, donde compite con la ráfaga de permisos y pierde siempre.

flowchart TD
a[Arranque] --> b[Escena activa y valor entregado]
b --> c[Pantalla propia de contexto]
c -->|rechaza| d[Estado indeterminado, reintento posible]
c -->|acepta seguir| e[Dialogo del sistema]
e -->|autorizado| f[Identificador disponible y enlace permitido]
e -->|denegado| g[Identificador a ceros y dominios bloqueados]
g --> h[Medicion agregada sin identidad]

Lo que se rompe con la negativa

Aquí conviene ser concreto porque la consecuencia más citada es la menos importante. Sí, el identificador de publicidad pasa a devolver un valor compuesto íntegramente de ceros, idéntico en todos los dispositivos y por tanto inútil como clave. Pero el efecto de mayor alcance técnico es otro: los dominios que hayas declarado en la clave de dominios de seguimiento de tu manifiesto quedan bloqueados a nivel de red mientras no exista autorización. Las conexiones a esos hosts fallan, no se degradan; y si tu SDK de atribución los usa para todo, incluida la telemetría que no es seguimiento, verás errores de red masivos que ningún cambio en tu código arregla. La lectura correcta de ese diseño es que Apple no confía en la declaración: la hace cumplir.

La respuesta madura a este escenario no consiste en optimizar el diálogo hasta el último píxel sino en rediseñar la medición para que no dependa de la identidad. El sistema ofrece mecanismos de atribución donde la red publicitaria recibe una notificación firmada por el dispositivo con un valor de conversión reducido, sin identificador de usuario, tras una ventana temporal aleatorizada y sujeta a umbrales que suprimen los datos cuando el volumen es demasiado bajo para preservar el anonimato. Trabajar con eso exige una mentalidad estadística distinta: se abandonan los embudos por usuario y se razona con cohortes, campañas y elasticidades; se codifica en unos pocos bits la única señal que de verdad importa; se aceptan intervalos de confianza en lugar de cifras exactas. Muchos equipos descubren, al hacer el ejercicio, que las decisiones de inversión que tomaban no necesitaban la granularidad que creían necesitar.

Falta una advertencia que evita errores caros en Europa. Esta autorización no es consentimiento en el sentido del reglamento europeo de protección de datos, y el consentimiento europeo no sustituye a esta autorización: son dos capas independientes, con definiciones, bases jurídicas y titulares distintos. Una app que opera en la Unión Europea necesita ambas, en el orden correcto, y con coherencia entre ellas: no tiene sentido que la plataforma de gestión de consentimiento registre un sí para publicidad personalizada cuando el estado del sistema es denegado, porque el estado del sistema manda sobre lo que técnicamente puede ocurrir. Conviene además saber que la implementación de este marco ha sido objeto de expedientes de competencia en varios países europeos, con sanciones ya impuestas, de modo que sus detalles operativos pueden cambiar por vía regulatoria y no solo por decisión de la plataforma.