¿Cómo optimizar las tasas de aceptación de App Tracking Transparency (ATT)? Mejorar la experiencia de los permisos de ATT implica proporcionar un contexto claro previo al permiso, redactar una descripción precisa en NSUserTrackingUsageDescription y elegir un momento relevante en el recorrido del usuario para presentar la solicitud de autorización del sistema. El impacto en la tasa de autorización debe medirse de forma empírica.
El Identificador para Anunciantes (IDFA) es un identificador de dispositivo restablecerle proporcionado por Apple que se utiliza para la atribución y medición publicitaria en iOS. Bajo el marco de App Tracking Transparency (ATT), las aplicaciones pueden acceder al IDFA únicamente tras recibir el consentimiento explícito del usuario mediante el aviso de autorización de
ATTrackingManager.
| Término | Definición |
|---|---|
| IDFA | Identificador publicitario a nivel de plataforma de Apple regulado por App Tracking Transparency. |
| App Tracking Transparency | El marco de Apple que exige la autorización del usuario antes de realizar un seguimiento entre aplicaciones y sitios web. |
| ATTrackingManager | La API nativa AppTrackingTransparency utilizada para solicitar la autorización de seguimiento. |
| Pantalla de pre-permiso | Una pantalla personalizada en la app que se muestra antes del aviso del sistema para explicar por qué se solicita la autorización. |
La economía del acceso al IDFA y la optimización del consentimiento de ATT
El rol del acceso autorizado al IDFA en la medición moderna de iOS
El acceso autorizado al IDFA permite respaldar los flujos de trabajo de medición y atribución publicitaria a nivel de usuario cuando el uso de los datos de seguimiento por parte de la aplicación cumple con ATT y con los requisitos de sus socios de medición y publicidad. Cuando no se dispone de la autorización de seguimiento, los equipos que necesiten medir el rendimiento de sus iniciativas de marketing pueden utilizar enfoques mediados por la plataforma permitidos de forma independiente, tales como AdAttributionKit o integraciones existentes de SKAdNetwork.
Cuando se otorga la autorización, el IDFA proporciona una clave de combinación determinista para las integraciones de redes publicitarias compatibles, lo que permite la reconciliación de conversiones a nivel de campaña sin necesidad de modelos estadísticos. Si se deniega la autorización, las aplicaciones trasladan su medición a los marcos nativos de la plataforma.
El problema de los avisos inmediatos en el primer inicio de la app
Mostrar solicitudes de autorización de seguimiento de forma inmediata durante el primer inicio de la app está técnicamente permitido por Apple, pero puede ofrecer un contexto menor para tomar una decisión informada, ya que el usuario aún no ha experimentado la funcionalidad de la aplicación:
- Ausencia de confianza en el producto: Los usuarios nuevos aún no han desarrollado confianza en las funciones de la aplicación, el valor de la marca ni las prácticas de seguridad de datos.
- Contexto poco claro: El cuadro de diálogo nativo del sistema aparece sin una explicación previa, lo que lleva a los usuarios reacios al riesgo a seleccionar por defecto la opción "Pedir a la app que no rastree".
- Fatiga de permisos: Acumular múltiples diálogos de permisos del sistema (como notificaciones push, ATT y ubicación) durante el inicio inicial de la app genera fricción y aumenta el abandono en el proceso de incorporación. La documentación de la API de Apple señala que si ya hay una alerta de permisos activa, las solicitudes de autorización posteriores no se mostrarán.

Evaluación empírica del rendimiento de aceptación
La tasa de consentimiento alcanzable varía según la categoría de la app, la confianza de la audiencia, el momento en que se muestra el aviso y la claridad del texto. Los equipos deben evaluar las variantes de optimización mediante pruebas A/B controladas en lugar de asumir puntos de referencia fijos de la industria.
Véase también: IDFA ──> Modelo de atribución móvil
Mecánica técnica del marco AppTrackingTransparency
Los cuatro estados de autorización
El acceso al IDFA se rige estrictamente por la enumeración ATTrackingManager.AuthorizationStatus:
notDetermined(0): Al usuario todavía no se le ha mostrado el diálogo de autorización.restricted(1): El dispositivo está restringido por controles parentales, perfiles de configuración educativa o soluciones corporativas de MDM; no se pueden conceder permisos de seguimiento y el interruptor de configuración está deshabilitado.denied(2): La aplicación no tiene autorización para acceder a los datos relacionados con la app con fines de seguimiento después de que el usuario rechace la solicitud.authorized(3): El usuario autoriza el seguimiento. En dispositivos compatibles con iOS y iPadOS, esto normalmente permite el acceso a un identificador publicitario distinto de cero.

La regla del aviso único del sistema
El sistema operativo iOS aplica una regla de presentación única para ATTrackingManager.requestTrackingAuthorization. Una vez que el usuario interactúa con la ventana modal nativa seleccionando «Permitir» o «Pedir a la app que no rastree», el sistema recuerda el estado determinado y no vuelve a mostrar el aviso durante esa instalación de la aplicación.
Aunque el aviso del sistema no volverá a aparecer, los usuarios pueden ajustar manualmente su autorización de seguimiento en cualquier momento dentro de la configuración de iOS.
Cómo aplica iOS el vaciado de identificadores cuando se retiene la autorización de seguimiento
En iOS 14.5 y versiones posteriores, el identificador publicitario normalmente devuelve solo ceros (00000000-0000-0000-0000-000000000000) cuando no se ha otorgado la autorización de seguimiento. Los desarrolladores deben verificar tanto el estado de autorización de ATT como el valor del identificador devuelto bajo demanda, en lugar de asumir que una cadena en caché sigue siendo válida entre distintos inicios de la aplicación.
Arquitectura UX de alta conversión: La estrategia de la pantalla de pre-permiso
Anatomía de una pantalla explicativa eficaz: Restricciones de las HIG de Apple
Según las Directrices de interfaz humana de Apple sobre privacidad, las aplicaciones pueden presentar una pantalla personalizada previa a la alerta antes de una solicitud de permisos del sistema si se necesita contexto adicional. Sin embargo, Apple impone reglas de diseño estrictas sobre estas pantallas de pre-permiso:
- Botón de acción única: La pantalla de pre-permiso debe proporcionar un único botón (como «Continuar» o «Siguiente») que conduzca directamente al aviso del sistema. No debe ofrecer ningún botón de «Cancelar», «Cerrar» o «Ahora no» que evite o posponga la alerta del sistema.
- Sin imitación de la interfaz de usuario: La pantalla previa nunca debe imitar visualmente el cuadro de alerta nativo del sistema iOS ni mostrar botones simulados etiquetados como «Permitir».
- Sin coacción visual: La interfaz no debe utilizar gráficos, flechas o estilos de alto contraste diseñados para manipular o guiar a los usuarios hacia la selección de «Permitir» en el posterior aviso del sistema.
Cumplimiento de la directriz 5.1.2 de revisión de la App Store
Bajo la sección 5.1.2 de las directrices de revisión de la App Store de Apple, Apple establece límites claros con respecto a las solicitudes de permisos:
- Prohibición de seguimiento incentivado: Está estrictamente prohibido que las aplicaciones ofrezcan incentivos financieros, moneda virtual, contenido prémium o descuentos a cambio de otorgar el consentimiento de ATT. Hacerlo infringe la directriz 5.1.2 y puede dar lugar al rechazo de la aplicación.
- Sin bloqueo de funciones principales: Las aplicaciones no pueden bloquear funciones principales, impedir la creación de cuentas ni degradar el rendimiento de la app si un usuario rechaza la autorización de seguimiento.
- Primacía de la elección del usuario: La decisión real de seguimiento del usuario siempre debe tomarse en el aviso nativo del sistema Apple.

Stage 1: User Onboarding / Core Value Realization
│
▼
Stage 2: Contextual Pre-Permission Primer Screen
(Single "Continue" Action ── Explains Purpose)
│
▼
Stage 3: Native iOS ATTrackingManager System Modal
(User Selects "Allow" or "Ask App not to Track")
│
┌────────────┴────────────┐
▼ ▼
[.authorized] [.denied]
ATT Authorized Graceful Fallback
(IDFA normally to Platform APIs
available) (AdAttributionKit / SKAN)
Optimización del texto NSUserTrackingUsageDescription
Configuración de Info.plist para la transparencia de propósitos
La clave NSUserTrackingUsageDescription en Info.plist define la cadena explicativa que se muestra directamente dentro de la alerta nativa del sistema ATT de Apple. Según la documentación de Apple, este texto debe ser conciso, específico y explicar con precisión cómo se utilizan los datos de seguimiento.
Pruebas de variantes de texto claro sin modificar la divulgación subyacente
Al probar variaciones de texto, cada variante evaluada debe describir con precisión y completitud las prácticas de seguimiento reales de la aplicación:
- Enfoque en la personalización: Explica cómo se utilizan los datos para personalizar las recomendaciones de contenido y las sugerencias de productos.
- Enfoque en la relevancia de los anuncios: Explica cómo se utilizan los datos para ofrecer promociones relevantes y evitar anuncios repetitivos.
- Enfoque en la medición de campañas: Explica cómo se utilizan los datos para medir el rendimiento de las asociaciones publicitarias.
La siguiente configuración ilustra un ejemplo de NSUserTrackingUsageDescription. Úselo únicamente si la redacción describe con precisión las prácticas reales de seguimiento de la app:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSUserTrackingUsageDescription</key>
<string>Your data will be used to deliver personalized product recommendations, relevant promotional offers, and measure advertising campaign performance.</string>
</dict>
</plist>
Diseño del momento óptimo para activar el aviso en el ciclo de vida del usuario
Consideraciones de timing a lo largo del recorrido del usuario
Aunque solicitar la autorización de ATT en el primer inicio está técnicamente permitido, mostrar el aviso después de que el usuario experimente la utilidad inicial del producto puede proporcionar un contexto más relevante para la solicitud de autorización:
- Activación posterior a la incorporación: Mostrar el aviso después de que el usuario complete la configuración de su cuenta y establezca sus preferencias iniciales.
- Activación por hito contextual: Mostrar el aviso tras completar una acción clave del usuario (por ejemplo, finalizar un tutorial de incorporación en un juego, guardar un artículo favorito en una aplicación de compras o marcar un artículo como favorito en una app de contenido).
Implementación técnica de ATTrackingManager en Swift
Gestión del estado activo de la aplicación y seguridad de hilos
Según la documentación de la API de Apple, ATTrackingManager.requestTrackingAuthorization muestra el diálogo modal únicamente cuando el estado de la aplicación es .active. Si otro aviso de permisos está activo o pendiente, la alerta del sistema no aparecerá y las solicitudes concurrentes no se pondrán en cola por parte del sistema operativo.

La siguiente implementación separa la gestión del estado de autorización de una vista personalizada de pre-permiso orientada a ilustrar el proceso:
import UIKit
import AppTrackingTransparency
import AdSupport
final class ATTManager {
static let shared = ATTManager()
private init() {}
/// Evaluates current authorization status
var currentStatus: ATTrackingManager.AuthorizationStatus {
return ATTrackingManager.trackingAuthorizationStatus
}
/// Determines if tracking authorization can be presented
var canRequestAuthorization: Bool {
return currentStatus == .notDetermined
}
/// Requests tracking authorization with application active state verification
/// - Parameter completion: Closure returning the resolved authorization status
func requestAuthorization(completion: @escaping (ATTrackingManager.AuthorizationStatus) -> Void) {
guard canRequestAuthorization else {
completion(currentStatus)
return
}
// Verify application is active before invoking requestTrackingAuthorization
guard UIApplication.shared.applicationState == .active else {
print("ATT request skipped: application is not active. Call again once active if status remains notDetermined.")
completion(currentStatus)
return
}
DispatchQueue.main.async {
ATTrackingManager.requestTrackingAuthorization { status in
DispatchQueue.main.async {
switch status {
case .authorized:
// Read the current advertising identifier on demand; do not persist a cached IDFA.
let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
print("ATT Authorized - IDFA available: \(idfa)")
case .denied:
print("ATT Denied - Advertising identifier returns zeroes")
case .restricted:
print("ATT Restricted by system profile")
case .notDetermined:
print("ATT State unresolved")
@unknown default:
print("ATT Unknown state encountered")
}
completion(status)
}
}
}
}
}
/// Illustrative custom UIViewController for a HIG-aligned pre-permission primer
final class ATTPrimerViewController: UIViewController {
private let continueButton = UIButton(type: .system)
private let titleLabel = UILabel()
private let descriptionLabel = UILabel()
var onContinueTapped: (() -> Void)?
override func viewDidLoad() {
super.viewDidLoad()
setupUI()
}
private func setupUI() {
view.backgroundColor = .systemBackground
// Prevent interactive swipe-to-dismiss when presented modally to ensure single-path navigation
isModalInPresentation = true
titleLabel.text = "Help Us Personalize Your Experience"
titleLabel.font = .boldSystemFont(ofSize: 20)
titleLabel.textAlignment = .center
titleLabel.numberOfLines = 0
descriptionLabel.text = "We use data to tailor product recommendations and deliver relevant promotional offers. On the next screen, you will see Apple's standard permission prompt to confirm your choice."
descriptionLabel.font = .systemFont(ofSize: 15)
descriptionLabel.textAlignment = .center
descriptionLabel.textColor = .secondaryLabel
descriptionLabel.numberOfLines = 0
// Apple HIG guidance calls for a single Continue or Next action
continueButton.setTitle("Continue", for: .normal)
continueButton.titleLabel?.font = .boldSystemFont(ofSize: 17)
continueButton.addTarget(self, action: #selector(handleContinue), for: .touchUpInside)
let stack = UIStackView(arrangedSubviews: [titleLabel, descriptionLabel, continueButton])
stack.axis = .vertical
stack.spacing = 20
stack.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(stack)
NSLayoutConstraint.activate([
stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
stack.centerYAnchor.constraint(equalTo: view.centerYAnchor),
stack.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32),
stack.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32)
])
}
@objc private func handleContinue() {
// Presentation and dismissal mechanics are illustrative and should be adapted to the app's navigation architecture.
dismiss(animated: true) { [weak self] in
self?.onContinueTapped?()
}
}
}
Recuperación tras la denegación: Cómo guiar a los usuarios a la configuración del sistema sin infringir las políticas
Cuándo introducir flujos de configuración secundarios
Cuando un usuario selecciona «Pedir a la app que no rastree», el estado de autorización se establece como .denied. Las llamadas posteriores a requestTrackingAuthorization devuelven .denied sin mostrar ningún diálogo. Sin embargo, si un usuario inicia posteriormente una función que se beneficia explícitamente del seguimiento (como solicitar ajustes de publicidad personalizada en su perfil de usuario), la aplicación puede ofrecer una ruta no coercitiva hacia la configuración de iOS.
Uso de UIApplication.openSettingsURLString
Para guiar al usuario hacia el panel de configuración de la app, utilice UIApplication.openSettingsURLString:
if let settingsURL = URL(string: UIApplication.openSettingsURLString),
UIApplication.shared.canOpenURL(settingsURL) {
UIApplication.shared.open(settingsURL, options: [:], completionHandler: nil)
}
Tenga en cuenta que esta API abre la página de configuración específica de la aplicación; no proporciona un enlace profundo directo a la pantalla global de Configuración > Privacidad y seguridad > Seguimiento.
Límites de las políticas de la App Store
- Sin insistencia persistente: No muestre banners recurrentes que inciten a los usuarios a activar el seguimiento en la configuración.
- Sin bloqueo de funciones: Nunca deshabilite las funciones principales debido a que el seguimiento permanezca desactivado en la configuración.
Matriz de decisión comparativa: Estrategias de pre-permiso frente a avisos en el inicio de la app
| Dimensión | Aviso predeterminado en el inicio | Modal de permiso de bloqueo estricto | Pantalla previa compatible con las HIG |
|---|---|---|---|
| Contexto del usuario antes del aviso | Bajo (Sin interacción con el producto) | Variable (Bloquea el acceso) | Contextual (Se muestra tras una interacción relevante) |
| Guía de interfaz/permisos de Apple | Permitido cuando la solicitud y el uso de datos cumplen las normas | No permitido cuando el acceso o la compensación dependen del seguimiento | Permitido cuando se siguen las restricciones de pre-alerta de las HIG y las reglas de seguimiento |
| Restricciones de interfaz previa de Apple | N/A | N/A | Acción única de Continuar/Siguiente; sin alertas falsas |
| Momento de interrupción del permiso | Inmediato al iniciar | Bloqueante | Hito contextual |
| Tasa de aceptación observada | Debe medirse de forma empírica | No permitido | Debe medirse de forma empírica |
Preguntas frecuentes (FAQ)
¿Puede una aplicación ofrecer moneda virtual o descuentos dentro de la app a cambio de otorgar el permiso de ATT?
¿Puede una aplicación mostrar un segundo aviso de ATT si el usuario selecciona inicialmente «Pedir a la app que no rastree»?
¿Viola una pantalla de pre-permiso las directrices de la App Store de Apple?
Resumen y marco de decisiones
Mejorar la experiencia de los permisos de ATT requiere una divulgación clara de los propósitos y un timing adaptado al contexto. Cuando se necesita una explicación adicional, una pantalla de pre-permiso alineada con las HIG puede proporcionar contexto antes del aviso del sistema, alineando al mismo tiempo la experiencia de permisos con las directrices de interfaz y seguimiento publicadas por Apple.
Si todavía se requiere contexto de atribución o incorporación después de una denegación de ATT, las aplicaciones pueden utilizar mecanismos permitidos de forma independiente como AdAttributionKit, integraciones existentes de SKAdNetwork o enrutamiento contextual genuinamente propio (first-party) que se mantenga dentro de las normas de seguimiento de Apple.
Para consultar el comportamiento de atribución y el enrutamiento contextual específicos de su producto, revise la documentación de OpoInstall y evalúe la implementación frente a los requisitos de seguimiento aplicables de Apple.
Materiales relacionados
-
Conceptos: App Tracking Transparency, optimización del IDFA, pantallas de pre-permiso, embudos de consentimiento
-
Tecnologías: StoreKit Framework, AppTrackingTransparency Framework, SDK móvil de OpoInstall
-
Estándares: Directrices de interfaz humana de Apple sobre privacidad, sección 5.1.2 de las directrices de revisión de la App Store
-
APIs:
ATTrackingManager.requestTrackingAuthorization,UIApplication.openSettingsURLString,ASIdentifierManager
Documentación oficial
-
Documentación para desarrolladores de Apple sobre App Tracking Transparency
-
Directrices de interfaz humana de Apple sobre la solicitud de permisos
-
Sección 5.1.2 de las directrices de revisión de la App Store de Apple
-
Documentación para desarrolladores de Apple sobre la privacidad del usuario y el uso de datos
Share this article



