ATT iOS: qué es, mecanismo de solicitud de seguimiento e IDFA

¿Qué es ATT (App Tracking Transparency)?

App Tracking Transparency es un framework de Apple para proteger la privacidad de los usuarios, presentado en iOS 14.5. Exige que las aplicaciones obtengan permiso explícito para acceder al identificador publicitario del dispositivo (IDFA) antes de usarlo para el seguimiento.

Antes de ATT, los desarrolladores podían leer el IDFA sin solicitar permiso, lo que permitía a las redes publicitarias crear perfiles de usuarios y rastrear su actividad entre aplicaciones y sitios web. Apple consideró esto una violación de la privacidad e introdujo un diálogo de consentimiento obligatorio.

El framework ha estado disponible desde iOS 14.0, pero se volvió obligatorio para todas las aplicaciones que usan IDFA con el lanzamiento de iOS 14.5 en abril de 2021. Según Flurry Analytics, tras la implementación de ATT, menos del 25% de los usuarios en EE. UU. dieron su consentimiento al seguimiento, lo que cambió radicalmente el mercado de la publicidad móvil.

ATT verifica el permiso a través de un diálogo especial del sistema que la aplicación no puede modificar ni eludir. El usuario ve un popup estándar con el texto proporcionado por el desarrollador y elige entre “Permitir” o “Solicitar a la aplicación que no rastree”.

Cómo se relaciona ATT con la privacidad en iOS

Apple posiciona ATT como parte de su estrategia general de privacidad, que también incluye Etiquetas de privacidad nutricional en la App Store y el Manifiesto de privacidad. Los tres mecanismos funcionan juntos: las etiquetas muestran qué datos recopila la aplicación, el Manifiesto declara las razones del uso de API y ATT otorga al usuario control sobre el seguimiento.

Rechazar el seguimiento no bloquea el funcionamiento de la aplicación en sí — los usuarios pueden seguir usando todas las funciones, pero las redes publicitarias no recibirán el IDFA para personalización y atribución. Las alternativas de Apple al IDFA incluyen SKAdNetwork y la Atribución Probabilística.

Según Branch Metrics, tras la introducción de ATT, la proporción de aplicaciones que reciben IDFA cayó del 70% al 20% a nivel mundial. Esto llevó a replantear los enfoques de atribución de instalaciones y monetización mediante publicidad.

Cambios en iOS 15 y 16

En iOS 15, Apple no endureció los requisitos de ATT, pero añadió el Informe de privacidad de aplicaciones — un informe que muestra al usuario con qué frecuencia las aplicaciones acceden a sensores y datos. iOS 16 amplió el control: el usuario puede cambiar la configuración de seguimiento en cualquier momento a través de Ajustes → Privacidad → Seguimiento.

Es importante: si el usuario selecciona “Solicitar a la aplicación que no rastree” en el diálogo de ATT, la aplicación no recibe el valor del IDFA, sino que devuelve una cadena de ceros: 00000000-0000-0000-0000-000000000000. Intentar leer el IDFA por otros medios o métodos alternativos conduce al rechazo de la aplicación en la App Store.

A partir de iOS 17, Apple reforzó las comprobaciones: si una aplicación solicita IDFA sin mostrar el diálogo del sistema ATT, recibe una denegación a nivel del sistema operativo, no solo un identificador vacío. Esto elimina la posibilidad de recopilación en segundo plano de IDFA sin conocimiento del usuario.

Cómo funciona la solicitud de seguimiento en iOS

El proceso de solicitud ATT consta de tres etapas: comprobación del estado, visualización del diálogo del sistema y procesamiento de la respuesta. El desarrollador no puede omitir ningún paso — el sistema operativo controla cada etapa.

Comprobación del estado de autorización

Antes de llamar al diálogo, la aplicación debe verificar el estado actual a través de ATTrackingManager. Los posibles estados son: notDetermined (aún no solicitado), restricted (prohibido por políticas del dispositivo), denied (usuario rechazó), authorized (permitido).

Si el estado ya está determinado (authorized o denied), no es posible volver a llamar al diálogo — el usuario ha tomado una decisión permanente. La única forma de cambiar la decisión es a través de los ajustes del sistema iOS.

Para verificar el estado se utiliza la propiedad ATTrackingManager.trackingAuthorizationStatus. La llamada debe realizarse en el hilo principal, ya que el diálogo del sistema es un componente de la interfaz de usuario.

import AppTrackingTransparency
import AdSupport

func checkTrackingStatus() {
    let status = ATTrackingManager.trackingAuthorizationStatus
    switch status {
    case .notDetermined:
        requestTrackingPermission()
    case .authorized:
        readIDFA()
    case .denied, .restricted:
        useAlternativeTracking()
    @unknown default:
        break
    }
}

Visualización del diálogo del sistema

Para mostrar el diálogo, se llama al método requestTrackingAuthorization con un cierre que recibe el resultado de la elección del usuario. Importante: el diálogo se muestra solo una vez. Si el desarrollador intenta llamarlo de nuevo, el sistema ignora la solicitud.

El texto del diálogo consta de dos partes: un encabezado del sistema (que no se puede cambiar) y un mensaje personalizado que el desarrollador especifica en Info.plist mediante la clave NSUserTrackingUsageDescription.

El diálogo debe aparecer en un contexto natural — no inmediatamente al iniciar la aplicación, sino en el primer intento de usar funcionalidad relacionada con el seguimiento. Apple recomienda mostrar el diálogo después de que el usuario haya comprendido el valor de la funcionalidad.

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        DispatchQueue.main.async {
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                print("IDFA: \(idfa)")
            case .denied:
                print("Usuario denegó el seguimiento")
            default:
                break
            }
        }
    }
}

IDFA y restricción de acceso

IDFA (Identifier for Advertisers) es un identificador publicitario único de los dispositivos iOS, utilizado para publicidad dirigida y atribución de instalaciones. Antes de ATT, los desarrolladores lo obtenían a través de ASIdentifierManager sin restricciones. Después de ATT, el acceso a IDFA está bloqueado hasta que el usuario dé su consentimiento explícito.

Qué es IDFA y para qué sirve

IDFA es una cadena UUID única para cada dispositivo iOS. Las redes publicitarias usan IDFA para: rastrear instalaciones de aplicaciones (atribución), mostrar anuncios relevantes basados en intereses del usuario, medir la efectividad de campañas publicitarias y retargeting — recuperar usuarios que no completaron una acción deseada.

Después de que el usuario rechace el seguimiento, ASIdentifierManager devuelve el valor 00000000-0000-0000-0000-000000000000. La aplicación aún puede leer el IDFA con fines técnicos (como antifraude), pero no puede transmitirlo a redes publicitarias.

Según Singular (2024), la tasa global de consentimiento en ATT es del 25–35%, siendo Europa (RGPD) más alta (40–50%) que EE. UU. (15–25%). Esto llevó a las plataformas publicitarias a desarrollar métodos alternativos de atribución.

Alternativas a IDFA: SKAdNetwork y Atribución Probabilística

SKAdNetwork es un framework de Apple para la atribución de instalaciones sin revelar el IDFA. Funciona a nivel del sistema operativo: la red publicitaria envía un postback firmado, Apple lo verifica y lo transmite al desarrollador. La atribución se produce sin identificar a un usuario concreto, solo a nivel de campaña.

La Atribución Probabilística utiliza múltiples señales del dispositivo — modelo, versión de iOS, zona horaria, brillo de pantalla — para hacer coincidir probabilísticamente instalaciones con impresiones publicitarias. Sin embargo, Apple prohíbe este método en sus normas y su uso puede conllevar el rechazo de la aplicación.

Google, Adjust y AppsFlyer han desarrollado sus propias soluciones híbridas que combinan SKAdNetwork con datos agregados propietarios. Por ejemplo, el Seguimiento de Conversiones de Google Ads utiliza postbacks de SKAdNetwork y sus propios modelos de machine learning para la atribución sin IDFA.

Implementación de ATT en el código de la aplicación

Para integrar ATT, es necesario añadir la clave NSUserTrackingUsageDescription en Info.plist e importar el framework AppTrackingTransparency. A continuación se muestran los pasos para Swift y Objective-C.

Configuración de Info.plist

El primer paso es añadir la clave NSUserTrackingUsageDescription en Info.plist con un texto que explique por qué la aplicación necesita el seguimiento. Este texto se mostrará en el diálogo del sistema. Ejemplo: “Su IDFA se utiliza para mostrar anuncios personalizados y realizar un seguimiento de la efectividad de las campañas.”

Sin esta clave, la llamada a requestTrackingAuthorization provocará un bloqueo de la aplicación — Apple verifica explícitamente la presencia de NSUserTrackingUsageDescription antes de mostrar el diálogo. El texto debe ser conciso, específico y reflejar el uso real de los datos.

Importante: la clave se añade manualmente a través de la pestaña Info de Xcode o editando el código fuente XML de Info.plist. Después de añadirla, recompile el proyecto y verifique que la clave aparezca en el binario final.

<!-- Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>This identifier is used to deliver
personalized ads and measure campaign performance.</string>

Integración completa en Swift

En un proyecto real, es mejor llamar a la solicitud ATT antes del primer lanzamiento de un módulo publicitario o tracker. Se recomienda explicar primero el valor del consentimiento en una pantalla separada (pre-permission prompt) — esto aumenta las tasas de consentimiento en un 20–30%.

Un pre-permission prompt es una interfaz de usuario personalizada que muestra el beneficio de activar el seguimiento (“Ayúdenos a mostrarle anuncios relevantes”). Solo después de tocar “Continuar” aparece el diálogo del sistema ATT. Adjust (2024) registró un aumento del 40% en el consentimiento al usar una pantalla de pre-permission.

final class TrackingManager {
    static let shared = TrackingManager()

    func requestTrackingIfNeeded() {
        guard ATTrackingManager.trackingAuthorizationStatus
            == .notDetermined
        else { return }

        ATTrackingManager.requestTrackingAuthorization { _ in
            NotificationCenter.default.post(
                Notification(Name("trackingStatusChanged"))
            )
        }
    }
}

Errores al trabajar con ATT

Los desarrolladores suelen cometer errores típicos al integrar ATT, que provocan una menor conversión de consentimientos o el rechazo de la aplicación por parte de los revisores de la App Store. Analicemos los cinco problemas más comunes.

Solicitar ATT inmediatamente después de iniciar la aplicación

El error más común es mostrar el diálogo del sistema ATT en la primera pantalla justo después de cargar la aplicación. El usuario aún no comprende el valor de la aplicación y es muy probable que presione “Denegar”. IronSource (2023) mostró una caída del 32% en el consentimiento al solicitar en la primera pantalla en comparación con después de la tercera sesión.

Recomendación: solicite el seguimiento después de que el usuario haya realizado una acción valiosa (visto contenido, iniciado la incorporación) o después de 3–5 sesiones de uso de la aplicación. Esto aumenta la confianza y la percepción del valor.

Falta de pantalla de pre-permission

Mostrar el diálogo del sistema ATT sin una explicación previa es un error que reduce la conversión al 15–20%. El usuario ve una solicitud inesperada y la rechaza instintivamente. Una pantalla de pre-permission que explique el beneficio aumenta el consentimiento al 35–45%.

El texto de pre-permission debe ser específico: “Permítanos mostrarle anuncios relevantes — esto nos ayuda a seguir siendo gratuitos.” Evite frases vagas — reducen la confianza. GameAnalytics demostró en 2023 que una pantalla de pre-permission que explica el beneficio genera un 28% más de consentimientos que una pantalla vacía.

Ignorar el estado restricted y denied

Si el usuario ya ha denegado el seguimiento o el estado es restricted (control parental, políticas corporativas), la aplicación no debe volver a llamar al diálogo ATT. Una llamada repetida no funciona y se percibe como una violación de la privacidad. En su lugar, cambie a SKAdNetwork y publicidad contextual.

En el estado restricted, la aplicación no puede determinar si la opción “Permitir solicitudes de seguimiento” está activada en los ajustes. En este caso, use siempre SKAdNetwork como único método de atribución y no muestre una pantalla de pre-permission.

Leer IDFA sin llamar a ATT

Leer el IDFA a través de ASIdentifierManager.shared().advertisingIdentifier sin el permiso previo de ATT devuelve una cadena de ceros. Algunos desarrolladores intentan usar métodos antiguos de acceso al IDFA a través de API privadas — esto garantiza el rechazo durante la revisión de la aplicación.

Apple utiliza análisis estático de código y machine learning para detectar soluciones alternativas. Incluso si la aplicación supera la revisión, las actualizaciones posteriores o las comprobaciones automáticas pueden revelar la infracción y provocar la prohibición de la cuenta del desarrollador.

Texto incorrecto de NSUserTrackingUsageDescription

Un texto demasiado largo, vago o engañoso en la clave NSUserTrackingUsageDescription es motivo de rechazo por parte de los revisores. Apple verifica que la descripción coincida con el uso real de los datos. Si la aplicación no tiene anuncios pero indica “con fines publicitarios”, el revisor rechazará la compilación.

Formato recomendado: una descripción específica del propósito del uso del IDFA, de 2 a 3 oraciones. Ejemplo para una aplicación sin anuncios: “El identificador se utiliza para análisis y prevención de fraude. Los datos no se comparten con terceros ni se utilizan para la elaboración de perfiles.”