Qué recopila AppsFlyer

El SDK de AppsFlyer inicializa una sesión tan pronto como la aplicación host se inicia y, por defecto, recopila un conjunto de identificadores y señales contextuales: el identificador publicitario a nivel de dispositivo (IDFA en iOS, GAID en Android), el IDFV con ámbito de proveedor en iOS, un ID de instalación generado por AppsFlyer que persiste entre sesiones, la dirección IP (utilizada para geo-IP y para coincidencia probabilística tipo huella digital), user agent, modelo de dispositivo, versión del sistema operativo, operador y zona horaria. Después de la instalación, el SDK informa el evento de instalación a los servidores de AppsFlyer, donde se empareja con los datos de clics reenviados por las redes publicitarias. Los eventos posteriores dentro de la aplicación — Compra, RegistroCompletado, Tutorial Completado, Personalizado — se activan a través del mismo SDK y heredan el mismo conjunto de identificadores.

Los reguladores han sido explícitos en que esto constituye procesamiento de datos personales bajo el GDPR. El IDFA y el GAID son datos personales porque son identificadores persistentes a nivel de dispositivo. La coincidencia probabilística por huella digital que se ejecuta en paralelo es aún más difícil de defender sin consentimiento porque es, por definición, un intento de identificar a un usuario sin su cooperación explícita. La CNIL, el Garante italiano y la AEPD española han abierto investigaciones contra editores cuyas pilas de atribución se activaron antes del consentimiento.

Controles nativos de privacidad de AppsFlyer

AppsFlyer expone un conjunto significativo de primitivas de privacidad nativas. No son un sustituto de un marco de consentimiento real, pero comprenderlas es esencial porque son las palancas que un CMP utiliza para controlar el comportamiento del SDK.

La API Start SDK

El SDK soporta un modo de inicialización donde se configura pero no transmite ningún dato hasta que se llama explícitamente a start(). Este es el gancho más importante para el control por consentimiento — por defecto, el SDK se inicia automáticamente al lanzar la aplicación, lo cual es el comportamiento incorrecto para cualquier jurisdicción con requisito de consentimiento previo. Establezca isStopped en true durante la inicialización, o utilice la API de inicio diferido, y solo llame a start() cuando la señal de consentimiento haya sido registrada.

API Stop

Si el consentimiento se retira durante la sesión, llamar a stop() detiene toda transmisión posterior. No elimina retroactivamente los datos ya enviados. Para una eliminación completa, debe presentar una solicitud de eliminación de datos del interesado a través del portal de privacidad de AppsFlyer — una integración que los equipos deben automatizar a través de la API de AppsFlyer en lugar de un flujo de trabajo manual.

setSharingFilter

Esto filtra qué redes publicitarias posteriores reciben datos de postback. Es la primitiva correcta para el consentimiento granular por socio — por ejemplo, permitir la atribución en general pero bloquear los reenvíos a una red específica que el usuario ha rechazado.

Integración con Apple App Tracking Transparency

En iOS, AppsFlyer lee el estado de autorización ATT y ajusta su comportamiento automáticamente — si el usuario rechazó ATT, el IDFA no se transmite. ATT es independiente del consentimiento GDPR, y muchos editores los confunden. ATT controla una única señal a nivel de iOS; el consentimiento GDPR controla todo lo demás.

Integración en iOS

El patrón confiable en iOS es instalar el SDK de AppsFlyer pero diferir la inicialización hasta que tanto ATT como el flujo de consentimiento dentro de la aplicación hayan completado. La secuencia mínima es: la aplicación se lanza, el SDK se configura con isStopped = true, el banner de consentimiento dentro de la aplicación se muestra, el usuario acepta las categorías relevantes, la bandera isStopped del SDK se desactiva y se llama a start(). Si la aplicación también necesita ATT (lo cual es necesario para cualquier usuario donde el IDFA sea significativo), el aviso de ATT se muestra junto con o después del banner dentro de la aplicación. La mayoría de los CMP que soportan móvil tienen una API basada en callbacks que entrega la decisión de consentimiento; ese callback es el lugar correcto para llamar a start().

Integración en Android

La implementación en Android es paralela a iOS con dos diferencias. Primero, no existe un equivalente de ATT — GAID está disponible a menos que el usuario haya invocado su configuración a nivel de dispositivo "Eliminar ID de publicidad", lo cual la mayoría de usuarios no hace. Segundo, el ciclo de vida de Android es más agresivo con el envío a segundo plano, por lo que la inicialización del SDK necesita estar vinculada al estado de consentimiento almacenado de forma persistente. Lea el estado de consentimiento desde el almacenamiento local al lanzar la aplicación, configure el SDK en consecuencia, y vuelva a verificar al reanudar en caso de que el usuario haya actualizado su elección mientras la aplicación estaba en segundo plano.

Integración en la web móvil

AppsFlyer también opera en la web móvil a través de sus productos de banner inteligente y OneLink. Estos son esencialmente herramientas de analítica web y enlaces profundos que establecen cookies y llaman a los servidores de AppsFlyer desde el navegador. Siguen las mismas reglas que cualquier otra superficie de rastreo web: configúrelos detrás de la categoría de marketing del CMP, no permita que el script del banner inteligente se ejecute antes de que se otorgue el consentimiento, y asegúrese de que cualquier evento activado por OneLink desde campañas de correo electrónico o push respete el estado de consentimiento del usuario.

Errores comunes

Cuatro errores de integración aparecen repetidamente en las auditorías de implementaciones de AppsFlyer.

Tratar ATT como consentimiento GDPR

ATT y el consentimiento GDPR son señales diferentes con ámbitos diferentes. Un usuario que acepta ATT ha autorizado el uso del IDFA para rastreo entre aplicaciones; no ha autorizado todo lo demás que hace el SDK. Para el tráfico de EU y UK ambas señales son necesarias, siendo el banner dentro de la aplicación la vinculante y ATT una capa específica de iOS adicional.

Permitir que el SDK se inicialice al lanzar

Este es el defecto individual más común. La integración por defecto llama a start() inmediatamente, lo que dispara el evento de instalación con la carga completa de identificadores antes de que el usuario haya visto el banner de consentimiento. La solución es directa: configure isStopped = true en el momento de la integración y llame a start() solo desde el callback de consentimiento.

Olvidar manejar la revocación

Si un usuario acepta y luego revoca, se le debe indicar al SDK que deje de transmitir. Use la API stop() y actualice el estado de consentimiento persistido para que el siguiente lanzamiento de la aplicación respete la nueva decisión.

Ignorar los postbacks servidor a servidor

AppsFlyer reenvía eventos de conversión a una larga cola de redes publicitarias integradas a través de postbacks del lado del servidor. Cada reenvío porta datos personales y hereda el ámbito de consentimiento del evento original. Use setSharingFilter para asegurar que los reenvíos solo vayan a socios cubiertos por las elecciones de consentimiento del usuario, no a todos los socios en su panel de AppsFlyer.

Lista de verificación de auditoría

Seis preguntas concretas a responder para cualquier implementación de AppsFlyer que toque tráfico de EU, UK o California.

• ¿El SDK espera el consentimiento? En una instalación nueva en un dispositivo de prueba ubicado en la EU, confirme que ningún endpoint de AppsFlyer recibe ninguna solicitud antes de que el usuario haya aceptado el banner.
• ¿Está ATT separado del consentimiento dentro de la aplicación? Confirme que el banner dentro de la aplicación es la señal de consentimiento controlante y que ATT se trata como una capa adicional específica de iOS.
• ¿El reenvío a socios está limitado al consentimiento? Confirme que setSharingFilter está configurado para excluir socios que el usuario no ha autorizado.
• ¿La revocación detiene el SDK? Confirme que llamar a stop() funciona al revocar el consentimiento y que el nuevo estado persiste entre lanzamientos.
• ¿Se auditan los postbacks del servidor? Confirme que la lista de "Integraciones configuradas" del panel de AppsFlyer se corresponde claramente con los socios de marketing divulgados en el banner.
• ¿Está automatizada la eliminación de datos? Confirme que las solicitudes DSAR activan la API de eliminación de AppsFlyer, no un ticket manual.

Dónde encaja AppsFlyer en una pila orientada al consentimiento

La atribución móvil es una de las superficies con mayor densidad de identificadores en la pila de marketing, y el SDK de AppsFlyer es una de sus integraciones individuales más importantes. La buena noticia es que la plataforma expone las primitivas — Start SDK, Stop, filtros de compartición, APIs de eliminación — necesarias para hacer que la aplicación del consentimiento sea limpia y verificable. El trabajo para los editores es conectar esas primitivas a un CMP que posea la decisión vinculante de consentimiento, tratar ATT como una señal complementaria en lugar de un reemplazo, y asegurar que el reenvío a socios del lado del servidor no pueda escapar del sobre de consentimiento que el banner registró. Hecho correctamente, el resultado es una pila de atribución que satisface a los reguladores mientras preserva los datos de instalación y eventos de los que dependen los equipos de adquisición de usuarios.