Guia básico para integração do SDK

Um ID AppsFlyer é criado automaticamente para cada nova instalação da aplicação. Nenhuma ação é necessária por parte do profissional de marketing.

Pode usar este identificador para realizar as seguintes ações:

• Enviar eventos in-app de servidor para servidor.
• Associar o ID da AppsFlyer com os registos de utilizador nos seus sistemas backend.
• Descarregar o relatório de eventos in-app com dados brutos e utilizar o appsflyer_id para analisar o comportamento e a jornada do utilizador.

Defina o seu próprio ID de utilizador (CUID) no SDK da AppsFlyer para cruzar o ID único do seu sistema BI com o ID da AppsFlyer e outros identificadores. O CUID está disponível nos relatórios de dados brutos da AppsFlyer. Também pode ser utilizado nas APIs de postback para cruzar referências com os seus IDs internos.

Para saber mais sobre o CUID, consulte este artigo.

REFERENTE DE INSTALAÇÃO DO GOOGLE PLAY

A API Google Play Install Referrer melhora a precisão da atribuição, oferece proteção contra fraudes de instalação e permite a recuperação segura de dados de referência do Google Play (como, por exemplo, a versão da app no momento em que foi instalada pela primeira vez).

Recomendamos que forneça ao seu programador instruções para adicionar a API do Google Play Install Referrer.

GAID

A partir do SDK V4.8.0, a AppsFlyer recolhe automaticamente este identificador de dispositivo.

Com a AppsFlyer, pode atribuir instalações de lojas de apps de terceiros, como Amazon, Opera, GetJar, Baidu e Huawei. Isto permite-lhe promover as suas apps e alcançar públicos maiores em mercados onde a Google Play Store não está disponível.

A AppsFlyer suporta a atribuição no contexto de lojas de apps de terceiros da seguinte forma:

• IMEI ou ID Android: O SDK não recolhe automaticamente o IMEI ou o ID do Android. No entanto, se houver necessidade de recolher estes identificadores (por exemplo, para aplicações no mercado chinês), o seu programador pode implementar um dos seguintes métodos de recolha:
  • Recolha manual: A aplicação transmite o IMEI ou o ID do Android para o SDK utilizando a API setImeiData ou setAndroidIdData (consulte a referência das funções nas abas abaixo). O SDK envia os dados para os servidores da AppsFlyer.
    Android nativoUnity

    Consulte a referência do SDK Android para:

    •  
    •   

    Consulte a referência do SDK Unity para:

    • setImeiData
    • setAndroidIdData
  • Ativação da recolha de ID do dispositivo: Obriga o SDK a recolher o IMEI ou o ID do Android usando setCollectIMEI e setCollectAndroidID (consulte a referência das funções nas abas abaixo).
    Android nativoUnityReact Native

    Consulte a referência do SDK Android para:

    • setCollectIMEI
    • setCollectAndroidID

    Consulte a referência do SDK Unity para:

    • setCollectIMEI
    • setCollectAndroidID

    Consulte a referência do React Native para:

    • setCollectIMEI
    • setCollectAndroidID

• OAID: Atributos de instalações a partir de lojas de aplicações Android de terceiros. Para mais informações, veja o guia de implementação de OAID.
• Referenciadores de instalação: O SDK suporta a recuperação de dados de referência da Samsung Gallery e da Huawei AppGallery.

ANTECEDENTES

A partir do iOS 14.5, a recolha de IDFA necessita do consentimento do utilizador. Na prática, isto significa que o acesso ao IDFA é regulado pela estrutura App Tracking Transparency (ATT). Nos dispositivos com iOS 14+, o SDK utiliza a estrutura ATT para obter acesso ao IDFA do dispositivo. Para uma introdução à ATT, veja Princípios da ATT.

Quando a atribuição ocorre utilizando o IDFA, é crucial que o IDFA seja enviado logo no primeiro lançamento. waitForATTUserAuthorizationPor essa razão, o SDK fornece o método waitForATTUserAuthorization.

Visão geral da função waitForATTUserAuthorization

waitForATTUserAuthorization permite-lhe configurar quanto tempo o SDK deve adiar e esperar pelo estado ATT antes de enviar dados para os servidores da AppsFlyer.

Quando um utilizador inicia a aplicação, o estado ATT é notDetermined. Durante o tempo de espera, o SDK coloca na fila o evento de lançamento e os eventos consecutivos na aplicação em memória, tal como acontece quando os eventos offline são registados:

• Se o utilizador consentir com o aviso da ATT (recolha de IDFA):
  • O SDK adiciona o IDFA aos eventos em cache.
  • O SDK então inicia e envia os eventos em cache com IDFA (sem esperar pelo final do tempo de espera).

• Se o utilizador recusar o aviso da ATT: O SDK inicia e envia eventos em cache sem IDFA (sem esperar pelo final do tempo de espera).
• Se o tempo de espera terminar e o estado ATT continuar como notDetermined: O SDK inicia e envia eventos em cache sem IDFA.

Considerações

• Chamar sem definir resultará no envio de lançamentos e eventos sem IDFA para dispositivos com iOS 14+.
• Se o utilizador mover a aplicação para segundo plano durante o tempo de espera:
  • O temporizador pausa até que a aplicação volte para o primeiro plano.
  • Os eventos são armazenados na memória em cache.

• Se o utilizador encerrar a aplicação, e ela for terminada durante o tempo de espera:
  • O temporizador é reiniciado na próxima abertura da aplicação.
  • Os eventos em cache são perdidos.

Pode personalizar o aviso ATT. Uma mensagem que esclareça claramente o propósito do pedido pode ajudar a aumentar as taxas de adesão dos utilizadores.

Considere o seguinte ao criar a sua mensagem:

• Utilize uma linguagem que melhor explique aos seus utilizadores por que razão a aplicação está a pedir o consentimento.
• Informe os utilizadores sobre como os seus dados serão utilizados. Saiba mais sobre a privacidade dos utilizadores e o uso dos dados.

Assim que concluir a mensagem, forneça ao seu programador o texto e as instruções para implementação.