O que o AppsFlyer Coleta

O SDK do AppsFlyer inicializa uma sessão assim que o aplicativo host inicia e, por padrão, coleta um conjunto de identificadores e sinais contextuais: o identificador de publicidade em nível de dispositivo (IDFA no iOS, GAID no Android), o IDFV com escopo de fornecedor no iOS, um ID de instalação do AppsFlyer gerado que persiste entre sessões, endereço IP (usado para geo-IP e correspondência probabilística estilo fingerprint), user agent, modelo do dispositivo, versão do SO, operadora e fuso horário. Após a instalação, o SDK relata o evento de instalação aos servidores do AppsFlyer, onde é comparado com os dados de clique encaminhados pelas redes de anúncios. Eventos subsequentes no aplicativo — Purchase, RegistrationComplete, Tutorial Complete, Custom — são disparados pelo mesmo SDK e herdam o mesmo conjunto de identificadores.

Os reguladores foram explícitos de que isso é processamento de dados pessoais sob o GDPR. O IDFA e o GAID são dados pessoais porque são identificadores persistentes em nível de dispositivo. A correspondência probabilística de fingerprint que ocorre em paralelo é ainda mais difícil de defender sem consentimento porque é, por definição, uma tentativa de identificar um usuário sem sua cooperação explícita. O CNIL, o italiano Garante e o espanhol AEPD abriram investigações contra editores cujas pilhas de atribuição dispararam antes do consentimento.

Controles de Privacidade Nativos do AppsFlyer

AppsFlyer exibe um conjunto significativo de primitivos de privacidade nativos. Eles não são um substituto para uma estrutura de consentimento real, mas entendê-los é essencial porque são as alavancas que um CMP usa para controlar o comportamento do SDK.

O Start SDK API

O SDK suporta um modo de inicialização onde está configurado, mas não transmite nenhum dado até que start() seja explicitamente chamado. Este é o gancho mais importante para o bloqueio de consentimento — por padrão, o SDK inicia automaticamente no lançamento do aplicativo, o que é o comportamento errado para qualquer jurisdição com um requisito de consentimento prévio. Defina isStopped como true na inicialização, ou use a API de início adiado, e chame start() somente quando o sinal de consentimento for registrado.

Stop API

Se o consentimento for retirado no meio de uma sessão, chamar stop() interrompe toda a transmissão adicional. Não exclui retroativamente os dados já enviados. Para exclusão completa, você precisa registrar uma solicitação de exclusão de titular de dados pelo portal de privacidade do AppsFlyer — que as equipes de integração devem automatizar via API do AppsFlyer em vez de um fluxo de trabalho manual.

setSharingFilter

Isso filtra quais redes de anúncios downstream recebem dados de postback. É o primitivo correto para consentimento granular por parceiro — por exemplo, permitindo atribuição em geral, mas bloqueando encaminhamentos para uma rede específica que o usuário rejeitou.

Integração com Apple App Tracking Transparency

No iOS, o AppsFlyer lê o status de autorização ATT e ajusta seu comportamento automaticamente — se o usuário recusou ATT, o IDFA não é transmitido. ATT é independente do consentimento GDPR, e muitos editores os confundem. ATT controla um único sinal em nível iOS; o consentimento GDPR controla todo o resto.

Integração no iOS

O padrão confiável no iOS é instalar o SDK do AppsFlyer, mas adiar a inicialização até que tanto o ATT quanto o fluxo de consentimento no aplicativo sejam concluídos. A sequência mínima é: o aplicativo é lançado, o SDK é configurado com isStopped = true, o banner de consentimento no aplicativo é exibido, o usuário aceita as categorias relevantes, o sinalizador isStopped do SDK é limpo e start() é chamado. Se o aplicativo também precisar de ATT (o que acontece para qualquer usuário em que o IDFA seja relevante), o prompt ATT é exibido junto com ou após o banner no aplicativo. A maioria dos CMPs que suporta mobile tem uma API baseada em callback que entrega a decisão de consentimento; esse callback é o lugar certo para chamar start().

Integração no Android

A implementação Android é paralela ao iOS com duas diferenças. Primeiro, não há equivalente ao ATT — o GAID está disponível a menos que o usuário tenha ativado a configuração de dispositivo “Excluir ID de publicidade”, o que a maioria dos usuários não faz. Segundo, o ciclo de vida do Android é mais agressivo em relação ao uso em segundo plano, portanto, a inicialização do SDK precisa estar vinculada ao estado de consentimento armazenado de forma persistente. Leia o estado de consentimento do armazenamento local no lançamento do aplicativo, configure o SDK adequadamente e verifique novamente ao retomar caso o usuário tenha atualizado sua escolha enquanto o aplicativo estava em segundo plano.

Integração na Web Mobile

O AppsFlyer também opera na web mobile por meio de seus produtos smart banner e OneLink. Essencialmente são ferramentas de análise e deep link do lado web que colocam cookies e chamam os servidores do AppsFlyer pelo navegador. Elas seguem as mesmas regras de qualquer outra superfície de rastreamento web: coloque-as atrás da categoria de marketing do CMP, não deixe o script do smart banner ser executado antes de o consentimento ser concedido, e garanta que todos os eventos acionados por OneLink de campanhas de e-mail ou push respeitem o estado de consentimento do usuário.

Armadilhas Comuns

Quatro erros de integração aparecem repetidamente em auditorias de implantações do AppsFlyer.

Tratar ATT como consentimento GDPR

ATT e consentimento GDPR são sinais diferentes com escopos diferentes. Um usuário que aceita ATT autorizou o uso de IDFA para rastreamento entre aplicativos; não autorizou tudo o mais que o SDK faz. Para o tráfego da EU e do UK, ambos os sinais são necessários, sendo o banner no aplicativo o vinculante e o ATT uma camada específica do iOS por cima.

Deixar o SDK inicializar no lançamento

Este é o defeito único mais comum. A integração padrão chama start() imediatamente, o que dispara o evento de instalação com carga total de identificadores antes de o usuário ter visto o banner de consentimento. A remediação é simples: configure isStopped = true no momento da integração e chame start() somente a partir do callback de consentimento.

Esquecer de tratar a revogação

Se um usuário aceitar e mais tarde revogar, o SDK precisa ser informado para parar de transmitir. Use a API stop() e atualize o estado de consentimento persistido para que o próximo lançamento do aplicativo respeite a nova decisão.

Ignorar postbacks servidor a servidor

O AppsFlyer encaminha eventos de conversão para uma longa cauda de redes de anúncios integradas via postbacks do lado do servidor. Cada encaminhamento carrega dados pessoais e herda o escopo de consentimento do evento original. Use setSharingFilter para garantir que os encaminhamentos vão apenas para parceiros cobertos pelas escolhas de consentimento do usuário, não para cada parceiro no seu painel do AppsFlyer.

Lista de Verificação de Auditoria

Seis questões concretas para responder para qualquer implantação do AppsFlyer que toque tráfego da EU, UK ou Califórnia.

• O SDK aguarda o consentimento? Em uma instalação nova em um dispositivo de teste localizado na EU, confirme que nenhum endpoint do AppsFlyer recebe qualquer solicitação antes de o usuário aceitar o banner.
• O ATT está separado do consentimento no aplicativo? Confirme que o banner no aplicativo é o sinal de consentimento controlador e que o ATT é tratado como uma camada adicional específica do iOS.
• O encaminhamento para parceiros está limitado ao consentimento? Confirme que setSharingFilter está configurado para excluir parceiros que o usuário não autorizou.
• A revogação para o SDK? Confirme que chamar stop() funciona na revogação do consentimento e que o novo estado persiste entre os lançamentos.
• Os postbacks do servidor são auditados? Confirme que a lista de “Integrações configuradas” no painel do AppsFlyer mapeia claramente para os parceiros de marketing divulgados no banner.
• A exclusão de dados é automatizada? Confirme que as solicitações DSAR acionam a API de exclusão do AppsFlyer, não um ticket manual.

Onde o AppsFlyer se Encaixa em uma Pilha com Consentimento em Primeiro Lugar

A atribuição móvel é uma das superfícies mais intensivas em identificadores na pilha de marketing, e o SDK do AppsFlyer é uma de suas integrações únicas mais consequentes. A boa notícia é que a plataforma exibe os primitivos — Start SDK, Stop, filtros de compartilhamento, APIs de exclusão — necessários para tornar a aplicação do consentimento limpa e verificável. O trabalho dos editores é conectar esses primitivos a um CMP que detenha a decisão de consentimento vinculante, tratar o ATT como um sinal complementar em vez de uma substituição, e garantir que o encaminhamento de parceiros do lado do servidor não possa escapar do envelope de consentimento registrado pelo banner. Feito corretamente, o resultado é uma pilha de atribuição que satisfaz os reguladores enquanto preserva os dados de instalação e eventos dos quais as equipes de aquisição de usuários dependem.