Tecnoloxía23 de xuño de 2026 | FlexyConsent

Atribución móbil de AppsFlyer e consentimento de cookies: unha guía de integración 2026 para editores de aplicacións

Para os desenvolvedores de aplicacións, a medición móbil é un problema fundamentalmente diferente á medición web. As cookies das que se preocupan os editores web non existen dentro dunha aplicación nativa, pero os identificadores que as substitúen — IDFA, GAID, IDFV, ID de instalación, correos electrónicos con hash, impresións dixitais de dispositivos derivadas de IP — formulan as mesmas preguntas xurídicas e responden ante os mesmos reguladores. AppsFlyer, o socio de medición móbil máis amplamente despregado en xogos móbiles, fintech e aplicacións de consumo, atópase no centro desta canle. O seu SDK recolle identificadores de calidade de atribución, os seus servidores correlacionanos con postbacks de redes publicitarias, e a atribución resultante alimenta os orzamentos de adquisición de usuarios en todos os canles principais. Ningún dese procesamento ocorre sen base xurídica, e a base xurídica que o GDPR e a Directiva ePrivacy realmente requiren é o consentimento — recollido antes de que o SDK se inicialice, rexistrado como evidencia e propagado a cada integración augas abaixo. Esta guía percorre o que recolle AppsFlyer, como integralo cun marco de xestión de consentimento en iOS, Android e a web móbil, e como as primitivas de privacidade propias da plataforma (a API Start SDK, os sinais ATT e o Data Privacy Framework) encaixan na imaxe.

O que Recolle AppsFlyer

O SDK de AppsFlyer inicializa unha sesión en canto a aplicación host se inicia e, por defecto, recolle un conxunto de identificadores e sinais contextuais: o identificador publicitario a nivel de dispositivo (IDFA en iOS, GAID en Android), o IDFV de ámbito de provedor en iOS, un ID de instalación de AppsFlyer xerado que persiste entre sesións, enderezo IP (utilizado para xeo-IP e para correspondencia probabilística de estilo de impresión dixital), axente de usuario, modelo de dispositivo, versión do SO, operador e fuso horario. Despois da instalación, o SDK informa do evento de instalación aos servidores de AppsFlyer, onde se compara cos datos de clic enviados polas redes publicitarias. Os eventos posteriores na aplicación — Purchase, RegistrationComplete, Tutorial Complete, Custom — dispáranse a través do mesmo SDK e herdan o mesmo conxunto de identificadores.

Os reguladores foron explícitos en que isto é procesamento de datos persoais baixo o GDPR. O IDFA e o GAID son datos persoais porque son identificadores persistentes a nivel de dispositivo. A correspondencia probabilística de impresión dixital que funciona xunto a eles é aínda máis difícil de defender sen consentimento porque é, por definición, un intento de identificar a un usuario sen a súa cooperación explícita. A CNIL, o Garante italiano e a AEPD española abriron investigacións contra editores cuxas pilas de atribución dispararon antes do consentimento.

Controis de Privacidade Nativos de AppsFlyer

AppsFlyer expón un conxunto significativo de primitivas de privacidade nativas. Non son un substituto dun marco de consentimento real, pero comprendelas é esencial porque son os controis que un CMP usa para controlar o comportamento do SDK.

A API Start SDK

O SDK admite un modo de inicialización no que está configurado pero non transmite ningún dato ata que se chame explicitamente a start(). Este é o gancho máis importante para o control de acceso por consentimento — por defecto o SDK iníciase automaticamente ao lanzar a aplicación, o cal é o comportamento incorrecto para calquera xurisdicción cunha requisito de consentimento previo. Estableza isStopped en true na inicialización, ou use a API de inicio diferido, e só chame a start() cando se rexistre o sinal de consentimento.

API Stop

Se o consentimento se retira a mediados de sesión, chamar a stop() detén toda transmisión posterior. Non elimina retroactivamente os datos xa enviados. Para a eliminación completa, cómpre presentar unha solicitude de eliminación de suxeito de datos a través do portal de privacidade de AppsFlyer — os equipos de integración deberían automatizar isto a través da API de AppsFlyer en lugar dun fluxo de traballo manual.

setSharingFilter

Isto filtra que redes publicitarias augas abaixo reciben datos postback. É a primitiva correcta para o consentimento granular por socio — por exemplo, permitir a atribución en xeral pero bloquear os reenvíos a unha rede específica que o usuario rexeitou.

Integración de Apple App Tracking Transparency

En iOS, AppsFlyer le o estado de autorización ATT e axusta o seu comportamento automaticamente — se o usuario rexeitou ATT, o IDFA non se transmite. ATT é independente do consentimento GDPR, e moitos editores confúndenos. ATT controla un único sinal a nivel iOS; o consentimento GDPR controla todo o demais.

Integración en iOS

O padrón fiable en iOS é instalar o SDK de AppsFlyer pero diferir a inicialización ata que tanto ATT como o fluxo de consentimento na aplicación se completen. A secuencia mínima é: a aplicación lánzase, o SDK configúrase con isStopped = true, o banner de consentimento na aplicación móstrase, o usuario acepta as categorías relevantes, o indicador isStopped do SDK bórrase e chámase a start(). Se a aplicación tamén necesita ATT (o que fai para calquera usuario para o que IDFA é significativo), a solicitude ATT móstrase xunto ou despois do banner na aplicación. A maioría dos CMP que admiten móbil teñen unha API baseada en retorno de chamada que entrega a decisión de consentimento; ese retorno de chamada é o lugar correcto para chamar a start().

Integración en Android

A implementación de Android é paralela a iOS con dúas diferenzas. Primeiro, non hai equivalente de ATT — GAID está dispoñible a menos que o usuario teña invocado a súa configuración de nivel de dispositivo "Eliminar ID de publicidade", o que a maioría dos usuarios non fai. Segundo, o ciclo de vida de Android é máis agresivo en canto ao funcionamento en segundo plano, polo que a inicialización do SDK debe estar ligada ao estado de consentimento almacenado de forma persistente. Le o estado de consentimento desde o almacenamento local ao lanzar a aplicación, configura o SDK en consecuencia e volve comprobar ao reanudar por se o usuario actualizou a súa elección mentres a aplicación estaba en segundo plano.

Integración na Web Móbil

AppsFlyer tamén opera na web móbil a través dos seus produtos de banner intelixente e OneLink. Son esencialmente ferramentas de análise e ligazón profunda do lado web que depositan cookies e chaman aos servidores de AppsFlyer desde o navegador. Seguen as mesmas regras que calquera outra superficie de rastrexo web: colócaos detrás da categoría de mercadotecnia do CMP, non permitas que o script do banner intelixente se execute antes de que se conceda o consentimento, e asegúrate de que calquera evento desencadeado por OneLink de campañas de correo electrónico ou push respecte o estado de consentimento do usuario.

Escollos Comúns

Catro erros de integración aparecen repetidamente nas auditorías dos despliegues de AppsFlyer.

Tratar ATT como consentimento GDPR

ATT e o consentimento GDPR son sinais diferentes con diferentes ámbitos. Un usuario que acepta ATT autorizou o uso de IDFA para o rastrexo entre aplicacións; non autorizaron todo o demais que fai o SDK. Para o tráfico da UE e do Reino Unido requírense ambos sinais, sendo o banner na aplicación o vinculante e ATT sendo unha capa específica de iOS por riba.

Permitir que o SDK se inicialice ao lanzar

Este é o defecto único máis común. A integración predeterminada chama a start() inmediatamente, o que dispara o evento de instalación coa carga útil completa do identificador antes de que o usuario teña visto o banner de consentimento. A remediación é sinxela: configure isStopped = true no momento da integración e chame a start() só desde o retorno de chamada de consentimento.

Esquecer xestionar a retirada

Se un usuario acepta e máis tarde revoga, o SDK debe ser informado de que deteña a transmisión. Use a API stop() e actualice o estado de consentimento persistido para que o seguinte lanzamento da aplicación respecte a nova decisión.

Ignorar os postbacks de servidor a servidor

AppsFlyer reenvía eventos de conversión a unha longa cola de redes publicitarias integradas a través de postbacks do lado do servidor. Cada reenvío leva datos persoais e herda o ámbito de consentimento do evento orixinal. Use setSharingFilter para asegurarse de que os reenvíos van só a socios cubertos polas opcións de consentimento do usuario, non a cada socio no seu panel de AppsFlyer.

Lista de Verificación de Auditoría

Seis preguntas concretas que responder para calquera despregamento de AppsFlyer que toque o tráfico da UE, Reino Unido ou California.

Onde Encaixa AppsFlyer nunha Pila de Consentimento Primeiro

A atribución móbil é unha das superficies máis cargadas de identificadores na pila de mercadotecnia, e o SDK de AppsFlyer é unha das súas integracións únicas máis consecuentes. A boa noticia é que a plataforma expón as primitivas — Start SDK, Stop, filtros de compartición, API de eliminación — necesarias para facer que a aplicación do consentimento sexa limpa e verificable. O traballo para os editores é conectar esas primitivas a un CMP que posúa a decisión de consentimento vinculante, tratar ATT como un sinal complementario en lugar dun substituto, e asegurarse de que o reenvío de socios do lado do servidor non poida escapar do sobre de consentimento que rexistrou o banner. Feito correctamente, o resultado é unha pila de atribución que satisface aos reguladores mentres preserva os datos de instalación e evento dos que dependen os equipos de adquisición de usuarios.

← Blog Ler todo →