Guia básico para integração do SDK

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

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

• Enviar eventos in-app de servidor para servidor.
• Combine o 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 o appsflyer_id para analisar o comportamento e as jornadas do usuário.

Definir seu próprio CUID no SDK da AppsFlyer permite que você cruze seu ID exclusivo com o AppsFlyer ID e outros identificadores. O CUID está disponível nos relatórios de dados brutos da AppsFlyer. Também é possível usá-lo em APIs de postback para referência cruzada com seus IDs internos.

Para saber mais sobre o CUID, consulte este artigo.

GOOGLE PLAY INSTALL REFERRER

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 referral do Google Play (como, por exemplo, a versão do app no momento em que foi instalado pela primeira vez).

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

GAID

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

Com a AppsFlyer, você pode atribuir instalações provenientes 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 Android ID. Entretanto, se houver necessidade de coletar esses identificadores (por exemplo, para apps no mercado chinês) seu desenvolvedor poderá implementar um dos seguintes tipos de coleta:
  • Coleta manual: o aplicativo envia o IMEI ou Android ID para o SDK usando a API setImeiData ou setAndroidIdData (veja a referência da função nas abas abaixo). O SDK envia os dados para os servidores da AppsFlyer.
    Android nativeUnity

    Consulte a referência do Android SDK para:

    • setImeiData 
    •  setAndroidIdData 

    Consulte a referência do Unity SDK para:

    • setImeiData
    • setAndroidIdData
  • Opt-in da coleta de device ID: força o SDK a coletar o IMEI ou ID do Android usando setCollectIMEI e setCollectAndroidID (consulte a referência da função nas abas abaixo).
    Android nativeUnityReact Native

    Consulte a referência do Android SDK para:

    • setCollectIMEI
    • setCollectAndroidID

    Consulte a referência do Unity SDK para:

    • setCollectIMEI
    • setCollectAndroidID

    Consulte a referência do React Native para:

    • setCollectIMEI
    • setCollectAndroidID
• OAID: OAID: atribui instalações de lojas de aplicativos externas no Android. Para mais informações, veja o guia de implementação do OAID.
• Install referrers: o SDK é compatível com a recuperação de dados de referral da Samsung Gallery e da Huawei AppGallery.

CONTEXTO

A partir do iOS 14.5, a coleta do IDFA requer o consentimento do usuário. Na prática, isto significa que o acesso ao IDFA é regulado pela estrutura App Tracking Transparency (ATT). Em dispositivos iOS 14+, o SDK usa o framework da ATT para obter acesso ao IDFA do dispositivo.  Para uma introdução à ATT, veja o artigo princípios da ATT.

Quando a atribuição ocorre usando IDFA, é importante que o IDFA seja enviado na primeira inicialização.  Por esse motivo, o SDK fornece o método waitForATTUserAuthorization.

Visão geral da função waitForATTUserAuthorization

waitForATTUserAuthorization permite que você configure por quanto tempo o SDK deve adiar e esperar pelo status da ATT antes de enviar dados aos servidores da AppsFlyer.

Quando um usuário inicia o aplicativo, o status da ATT é notDetermined.  Durante o tempo de espera do waitForATTUserAuthorization, o SDK coloca na fila o evento de abertura e os eventos in-app consecutivos na memória, assim como acontece quando eventos offline são registrados:

• Se o usuário consentir com a solicitaçã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 a notificação da ATT: O SDK inicia e envia eventos armazenados em cache sem IDFA (sem esperar que o tempo limite termine).
• Se o tempo limite terminar e o status da ATT permanecer como notDetermined: o SDK inicia e envia eventos em cache sem IDFA.

Considerações

• Chamar requestTrackingAuthorization sem definir waitForATTUserAuthorization resultará no envio de aberturas e eventos sem IDFA para dispositivos com 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 fechar 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 indique claramente o propósito da solicitação pode ajudar a aumentar as taxas de adesão dos usuários.

Considere o seguinte ao criar sua mensagem:

• Use a linguagem que melhor explique aos usuários por que o aplicativo está pedindo o consentimento.
• Informe aos usuários sobre como os dados serão usados. Saiba mais sobre privacidade do usuário e uso de dados.

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