Selecione em qual classe iniciar o SDK

Selecione se deseja iniciar o SDK na classe Application global ou na classe Activity:

• Comece o SDK na classe Application global: Geralmente, inicializar o SDK na classe/subclasse Application global é uma boa prática porque a classe Application é carregada e inicializada antes de qualquer interface do usuário do aplicativo ser exibida. Isso garante que o SDK possa começar em qualquer cenário, incluindo deep linking.
• Comece o SDK em uma classe Activity (início adiado) para permitir que os usuários aceitem o compartilhamento de dados. Isso ocorre porque a obtenção do consentimento do usuário requer uma interface do usuário (IU) renderizada em uma classe Activity.

Selecione o cenário optar por participar/não participar

Selecione um cenário de optar por não participar descrevendo como chamar start de maneira que esteja em conformidade com os regulamentos de privacidade, como GDPR e CCPA. Por exemplo, selecione entre um cenário de optar por não participar na instalação, um cenário de optar por não participar único ou um cenário de prevenção de compartilhamento de dados com terceiros.

Para obter mais informações sobre os cenários de optar por não participar disponíveis, incluindo exemplos de código, consulte Cenários de optar por participar/não participar.

Instruções para o desenvolvedor Android

• Informe o desenvolvedor de sua decisão sobre o seguinte:
  • Em qual classe - Application ou Activity - iniciar o SDK?
  • Qual cenário de inclusão/exclusão usar?
• Envie ao seu desenvolvedor os seguintes links de referência:
  • Como executar o início adiado
  • Cenários comuns de optar por participar/não participar
  • Exemplos de código de optar por não participar

Um ID da AppsFlyer é criado automaticamente para cada nova instalação de aplicativo. Nenhuma ação é exigida pelo profissional de marketing.

Você pode usar esse identificador para realizar as seguintes ações:

• Enviar eventos in-app de servidor para servidor.
• Combine a ID da AppsFlyer com os registros do usuário em seus sistemas de back-end.
• Baixe o relatório de dados brutos de eventos in-app e use appsflyer_id para analisar o comportamento e as jornadas do usuário.

Defina seu próprio ID de usuário do cliente (CUID) no SDK da AppsFlyer para fazer referência cruzada do ID exclusivo do seu sistema de BI com o ID da AppsFlyer e outros identificadores. O CUID está disponível nos relatórios de dados brutos da AppsFlyer. Você também pode usá-lo em APIs de postback para fazer referência cruzada com seus IDs internos. 

Consulte as instruções do desenvolvedor para implementar o CUID.

Referenciador de instalação do Google Play

A API do Referenciador da instalações do Google Play melhora a precisão da atribuição, protege contra fraudes de instalação e permite a recuperação segura de dados de referência do Google Play (por exemplo, a versão do aplicativo no momento em que o aplicativo foi instalado pela primeira vez). 

É recomendável que você forneça ao desenvolvedor instruções para adicionar a API do Referenciador da instalação do Google Play. 

GAID

A partir do SDK V4.8.0, a AppsFlyer coleta automaticamente esse identificador de dispositivo.

Com a AppsFlyer, você pode atribuir instalações originadas de lojas de aplicativos de terceiros, como Amazon, Opera, GetJar, Baidu e Huawei. Isso permite que você promova seus aplicativos e alcance públicos maiores em mercados onde a Google Play Store não está disponível.

A AppsFlyer é compatível com a atribuição no contexto de lojas de aplicativos de terceiros da seguinte forma:

• IMEI ou Android ID: O SDK não coleta automaticamente o IMEI ou ID do Android. No entanto, se houver necessidade de coletar esses identificadores (por exemplo, para aplicativos no mercado doméstico chinês), seu desenvolvedor poderá implementar um dos seguintes tipos de coleção:
  • Coleção manual: o aplicativo passa o IMEI ou o ID do Android para o SDK (usando a API setImeiData ou setAndroidData). O SDK envia os dados para servidores da AppsFlyer. 
  • Aceitar coleta de ID do dispositivo: força o SDK a coletar o IMEI ou o ID do Android. 
• OAID: atribui instalações de lojas de aplicativos de terceiros Android. Para mais informações, veja o guia de implementação do OAID.
• Referenciadores de instalação: o SDK é compatível com a recuperação de dados de referência da Samsung Gallery e da Huawei AppGallery.

Fundo

A partir do iOS 14.5, a coleta do IDFA requer o consentimento do usuário. Praticamente, isso significa que o acesso ao IDFA é regido pela estrutura de transparência de rastreamento de aplicativos (ATT). Em dispositivos iOS 14+, o SDK usa a estrutura ATT para obter acesso ao IDFA do dispositivo. 

Para uma introdução à ATT, consulte princípios da ATT.

Quando a atribuição ocorre usando o IDFA, é importante que o IDFA seja enviado no primeiro lançamento. Por esse motivo, o SDK fornece o utilitário WaitForATTUserAuthorization.

Visão geral do waitForATTUserAuthorization

waitForATTUserAuthorization permite configurar quanto tempo o SDK deve adiar e aguardar o status ATT antes de enviar dados para os servidores da AppsFlyer.

Quando um usuário inicia o aplicativo, o status do ATT é notDetermined. Durante o tempo limite waitForATTUserAuthorization, o SDK enfileira o evento de inicialização e os eventos in-app consecutivos na memória, semelhante à maneira como os eventos off-line são registrados:

• Se o usuário der o consentimento na notificação da ATT (coleta de IDFA):
  • O SDK adiciona o IDFA a eventos em cache.
  • O SDK inicia e envia eventos armazenados em cache com IDFA (sem esperar que o tempo limite termine).
• Se o usuário recusar o prompt ATT: o SDK inicia e envia eventos em cache sem IDFA (sem aguardar o tempo limite terminar).
• Se o tempo limite terminar e o status ATT permanecer notDetermined: o SDK inicia e envia eventos em cache sem o IDFA.

considerações

• Chamar requestTrackingAuthorization sem definir waitForAttUserAuthorization resultará em aberturas do app e eventos sendo enviados sem IDFA para dispositivos iOS 14+.
• Se o usuário mover o aplicativo para o background durante o timeout:
  • O temporizador pausa até que o aplicativo volte para o primeiro plano.
  • Os eventos são armazenados em cache na memória.
• Se o usuário desligar o aplicativo, ele será eliminado durante o tempo limite:
  • O temporizador é reiniciado na próxima abertura do aplicativo.
  • Os eventos armazenados em cache são perdidos.

Você pode personalizar o prompt da ATT. Uma mensagem que indica claramente o propósito da solicitação pode ajudar a aumentar as taxas de aceitação para os usuários.

Considere o seguinte ao criar sua mensagem:

• Use a sequência de palavras que melhor explica aos usuários por que o aplicativo está pedindo o consentimento do usuário.
• Informe aos usuários sobre como seus dados serão usados. Saiba mais sobre a privacidade do usuário e o uso de dados.

Quando sua mensagem estiver concluída, forneça ao desenvolvedor o texto e as instruções de implementação.

Veja alguns exemplos externos de prompts da ATT.

SKAN é uma classe usada pelo iOS para validar instalações de aplicativos orientadas por anunciantes. O processo de validação da instalação do aplicativo envolve o aplicativo de origem e o aplicativo anunciado. 

Um aplicativo de origem é um aplicativo que participa de campanhas publicitárias exibindo anúncios de uma ad network. Configurar seu aplicativo para exibir anúncios não está dentro do escopo do SDK da AppsFlyer. Para configurar, siga as instruções da Apple.

Para o aplicativo anunciado (o aplicativo com o SDK da AppsFlyer), a solução para a SKAN da Appsflyer usa a SKAN para fornecer o postback de atribuição, enquanto a AppsFlyer coleta, traduz e agrega os dados, mantendo a privacidade do usuário. Quando o aplicativo é iniciado pela primeira vez, a plataforma da AppsFlyer usa a configuração definida pelo profissional de marketing para instruir o SDK sobre como definir o valor de conversão da SKAN.

Para usar a solução da SKAN:

• O profissional de marketing precisa configurar a mensuração da SKAN na AppsFlyer. O desenvolvedor não precisa realizar nenhuma tarefa.
• O SDK da AppsFlyer automaticamente chama as APIs de SKAN necessárias.
• Certifique-se de desativar as chamadas SKAN em outros SDKs se você confiar na AppsFlyer para atribuição SKAN.
• Não há outra ação ou processo de registro exigido pelo desenvolvedor ou pelo profissional de marketing na App Store. 

Para desativar a atribuição da SKAN, instrua o desenvolvedor a desativá-la no SDK. 

É possível enviar receita com qualquer evento in-app. Certifique-se de usar o parâmetro af_revenue para incluir receita. É o único parâmetro de evento que a AppsFlyer conta como receita real no painel e em relatórios de dados brutos. Saiba mais.

Para obter instruções de desenvolvedor, consulte Registrar receita.

O SDK da AppsFlyer oferece verificação do servidor para compras in-app. A validação da compra in-app envia automaticamente um evento de compra in-app à AppsFlyer. Ao enviar este evento você mesmo cria relatórios de eventos duplicados.

Veja nossa lista de eventos in-app recomendados por vertical, por exemplo, viagens, jogos ou e-commerce.

Para usuários sem o aplicativo instalado, o OneLink detecta o tipo de dispositivo e o redireciona para o destino correto (por exemplo, Google Play, Apple App Store, loja de aplicativos de terceiros ou página da web). Isso se baseia nas configurações do template do OneLink. Saiba mais

Para usuários com o aplicativo instalado, o OneLink abre o aplicativo. Além de abrir o aplicativo, você também pode fazer um deep link com usuários para uma atividade ou página específica dentro do aplicativo. Isso exige que seu desenvolvedor implemente o Unified Deep Linking (UDL).

Observação:

• O UDL requer SDK V6.1+
• Os clientes que já usam o OneLink para deep link podem estar usando o método legado, ao invés do UDL.

Consulte nosso guia sobre como configurar deep links e deferred deep linking.

Para usuários sem o aplicativo instalado, o OneLink detecta o tipo de dispositivo e os redireciona para o destino correto: Google Play, Apple App Store, loja de aplicativos de terceiros ou página da web. Depois que o usuário iniciar o aplicativo, você poderá usar deferred deep linking para redirecioná-los para uma atividade ou página específica dentro do aplicativo.

Isso requer que seu desenvolvedor implemente deferred deep linking estendidos.

Observação:

• O UDL requer SDK V6.1+
• Os clientes que já usam o OneLink para deferred deep linking podem estar usando o método legado, ao invés do UDL

Consulte nosso guia sobre como configurar deep links e deferred deep linking.