Migração de outros fornecedores para a AppsFlyer

Visão geral: planeje sua migração para a AppsFlyer a partir de outro fornecedor de atribuição. Entenda como evitar cobranças duplas e duplicação e perda de dados durante o período de migração.

fluxo de migração

Visão geral

A migração de outro fornecedor para a AppsFlyer inclui as seguintes tarefas principais:

Você pode trabalhar nessas tarefas simultaneamente. No entanto, recomendamos que você:

  • Conclua todas as tarefas antes de lançar seu aplicativo atualizado com o SDK da AppsFlyer. 
  • Pause as campanhas de marketing existentes antes de executar a migração da ID do dispositivo.

 Observação

Se você quiser comparar a métrica de atribuição entre seu MMP atual e a AppsFlyer para as mesmas campanhas e fontes de mídia, confira este artigo.

Tarefas

A tabela a seguir descreve o escopo de trabalho necessário para cada tarefa. Para ver um detalhamento preciso das tarefas gerais na ordem em que você deve realizá-las, assim como registrar seu progresso, faça o download desta planilha

Escopo do trabalho

Tarefa Ação necessária Quem está envolvido Tempo estimado Observações
Pré-requisitos
  1. Crie uma conta da AppsFlyer.
  2. Adicione o aplicativo à AppsFlyer.
  3. [Opcional] Altere a janela de reatribuição padrão de 90 dias para alinhar com a sua definição de usuários ativos.
Usuário do dashboard do profissional de marketing/AppsFlyer

2 horas

 
Integração do SDK
  • Integre o SDK da AppsFlyer ao seu aplicativo.
  • Mapeie eventos in-app S2S ou SDK.
  • Atualize a versão do aplicativo nas app stores.
Desenvolvedores de aplicativos

1-2 semanas

  • Recomendado: integre o SDK da AppsFlyer em um aplicativo de pré-produção para teste.
  • O aplicativo de produção deve ser atualizado nas lojas de aplicativos depois que todas as outras tarefas tenham sido concluídas.
Migração de dispositivos [opcional] Migre os IDs dos dispositivos para evitar a dupla atribuição dos seus usuários existentes. Engenheiro de dados 1-2 semanas
  • Considere pausar campanhas existentes antes da migração e as retome após a atualização da versão do aplicativo. 
  • Considere repetir a migração de dispositivos na data final da migração para garantir cobertura completa. 
Migração de campanha
  • Integre suas ad networks na AppsFlyer
  • Migre campanhas existentes de: 
    • SRNs
    • Ad networks que não são SRN
    • Mídia Própria
Profissional de marketing/Gerente de UA 1-3 semanas
Configuração do relatório de dados
  • Adapte/mapeie as estruturas dos seus relatórios atuais para as estruturas da AppsFlyer.
  • Prepare-se para receber relatórios da AppsFlyer.
Engenheiro de dados 2-4 semanas  

Integração do SDK

Integração do SDK

O SDK da AppsFlyer integrado ao aplicativo é a conexão entre o aplicativo e a plataforma da AppsFlyer. Ele relata instalações de aplicativos, abertura de aplicativos, eventos in-app e outros.

Para fazer a integração do SDK da AppsFlyer:

  1. Integre o SDK da AppsFlyer ao aplicativo.Consulte os guias de integração do SDK para Android e iOS.
  2. Mapeie os eventos in-app que você quer registrar usando os esquemas da AppsFlyer.
    Isso pode ser feito via SDK ou S2S.
  3. Remova o SDK do fornecedor de atribuição do concorrente.
    Você pode fazer isso imediatamente e mudar exclusivamente para a AppsFlyer, ou executar os dois SDKs simultaneamente por algumas semanas. Veja os detalhes sobre essas opções na tabela abaixo.
    Opção O que acontece após
    o lançamento da versão atualizada do aplicativo
    Impacto
    Remova o SDK do concorrente (recomendado) Apenas a AppsFlyer registra novas instalações e a atualização de usuários.
    O concorrente ainda mostra eventos realizados pelos usuários, até que os usuários também atualizem seu aplicativo.
    • Transição rápida.
    • Sem atribuição dupla.
    Mantenha o SDK do concorrente para um período de transição A AppsFlyer e o concorrente atribuem novas instalações e registram eventos. Após determinado tempo, remova o SDK do concorrente.
    • A validação de dados é possível. Ou seja, você pode comparar dados da AppsFlyer e do outro fornecedor.
    • Atribuição dupla, que pode causar cobranças duplas com ad networks. Veja o exemplo abaixo.
    • Maior carga de trabalho.
  4. Depois que todas as outras tarefas no escopo do trabalho forem concluídas, atualize a versão do aplicativo com o SDK da AppsFlyer para o mercado. Novos usuários são atribuídos pela AppsFlyer. 
    Observação:
    • Certifique-se de atualizar o aplicativo para iOS, Google Play e outros mercados relevantes fora da loja Android.
    • Seu aplicativo Android pode existir em sites de APK não oficiais, mesmo que você não os conheça (pesquise na internet o nome do pacote do seu aplicativo para saber). Os sites de APK levam algum tempo para atualizar para a versão mais recente, portanto podem trazer usuários orgânicos, que instalam versões antigas sem o SDK da AppsFlyer.
    • Os lançamentos de atualizações do aplicativo nas app stores podem levar alguns dias para serem totalmente concluídos. Os usuários que fizerem a instalação durante essa fase ainda podem obter a versão anterior.

Migração de dispositivosopcional

Sobre a migração de dispositivos

A migração de dispositivos é o processo de fazer upload de uma lista de IDs de dispositivos dos seus usuários existentes (IDFA, IDFV, GAID, CUID) para a AppsFlyer. Você deve realizar esse processo antes de lançar a nova versão do aplicativo, que incluirá o SDK da AppsFlyer. Há duas opções ao migrar dispositivos, migração atribuída ou não atribuída.

A migração de dispositivos resolve os problemas de dados relacionados aos usuários existentes do aplicativo, que fizeram o download do aplicativo e foram atribuídos pelo fornecedor anterior. Por exemplo, as cobranças duplas da SRN, que ocorrem quando os usuários originalmente atribuídos a uma SRN pelo seu fornecedor anterior, e que ainda estão dentro da janela de lookback, são reivindicados pela SRN novamente na AppsFlyer.

 Exemplo

  • Um novo usuário clica em um anúncio no Facebook e instala seu aplicativo no dia 15 de junho.
  • No dia 24 de junho, o usuário atualiza o aplicativo para a versão com o SDK da AppsFlyer e o inicializa. Para a AppsFlyer, esse é um novo usuário, que precisa ser atribuído em tempo real.
  • A AppsFlyer consulta o Meta ads com o ID do dispositivo do usuário. Como o usuário ainda está dentro da janela de lookback de 28 dias do Meta ads, o Meta ads auto-atribui o usuário. Isso causa uma cobrança dupla para o proprietário do aplicativo em relação ao mesmo usuário.

Depois de migrar os dispositivos, os dados são refletidos na AppsFlyer da seguinte maneira:

  • Dados de instalação: assim como as Reinstalações, os dispositivos migrados não têm dados de instalação. As instalações de dispositivos migrados não são exibidas na AppsFlyer.
  • Eventos in-app e dados de sessões: são registrados e exibidos como orgânicos para o método de migração de dispositivo não atribuído ou atribuído à fonte de mídia e campanha, caso esteja usando o método atribuído
  • Retargeting: reatribuições e reengajamentos são exibidos normalmente.
  • Dados da atividade: exibidos normalmente.
  • Dados de retenção e cohort: dispositivos migrados não têm data de instalação. Portanto, eles não estão associados a qualquer cohort e não podem ser exibidos nos relatórios de retenção e cohort. 

Como migrar dispositivos

Para migrar dispositivos: 

  1. Escolha qual população de usuários migrar. Você pode migrar todos os usuários existentes (o que pode impedir que você receba dados de reatribuição precisos da AppsFlyer) ou apenas os usuários que instalaram seu aplicativo recentemente (o que pode levar a cobranças duplas de usuários mais antigos).
    Recomendamos migrar usuários ativos durante o período da janela de reatribuição atual.Por exemplo, se o aplicativo tiver uma janela de reatribuição de 90 dias, migre os usuários que tiveram pelo menos uma sessão durante os 90 dias anteriores.
  2. [Opcional] Peça ao profissional de marketing/gerente de UA para pausar campanhas de marketing existentes (de SRNs, ad networks não SRN, mídias próprias etc.) até depois da migração do dispositivo.
    Se você decidir não pausar as campanhas, migre as IDs de dispositivo que permaneceram no outro fornecedor assim que a versão atualizada do aplicativo com o SDK da AppsFlyer for lançada para as lojas de aplicativos.
  3. Prepare um arquivo CSV com base na população de usuários selecionada, usando a estrutura de migração atribuída ou não atribuída. Veja um exemplo de CSV
  4. Envie o CSV ao seu CSM da AppsFlyer.
    Seu CSM migrará os IDs de dispositivo para a AppsFlyer. 

Migração atribuída

Os dispositivos migrados para a AppsFlyer com esse método têm seus eventos in-app e sessões gravados e exibidos de acordo com a fonte de mídia reportada pelo fornecedor de atribuição anterior, e de acordo com as políticas de retenção de dados das ad networks.

Estrutura CSV de migração de dispositivo atribuído

Nome da
coluna
Descrição Obrigatório Exemplos
app_id

ID do aplicativo como aparece no dashboard da AppsFlyer

Sim
  • Android: com.great.app1 
  • iOS: id123456789

platform

Plataforma do dispositivo: iOS ou Android

Sim
  • ios
  • android

device_id

  • Android: gaid 
  • iOS: IDFV (recomendado, se disponível) ou IDFA
  • Não duplique a mesma combinação de ID de dispositivo e ID do aplicativo em várias linhas. Se ocorrer duplicação, a última ocorrência no arquivo será usada.

 

Sim
  • gaid (minúsculas): 9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFV (maiúsculas): A7328D98-A973-402A-8B87-D22A8611F2AF
  • IDFA (maiúsculas): 9876F1SS-2983-3855-27RR-2R626772VFNB
id_type
  • Android: advertiserId (também compatível com amazon_aid) 
  • iOS:idfa ou idfv
  • Atualmente, outros identificadores, como OAID, IMEI e Android ID não são compatíveis. 
    Use a migração não atribuída para usuários Android, que não são do Google Play.
Sim
  • ID do anunciante
  • idfa
  • idfv
install_time

O horário original da instalação do aplicativo com o formato ISO 8601 UTC:
aaaa-mm-ddTHH:MM:SS.SSS

  • Prática recomendada: deixe esse campo vazio. Nesse caso, coloque o tempo de migração no lugar dele
  • Se você preencher a data, ela deve ser uma data anterior válida, não anterior à janela de reatribuição.
    • Em alguns casos, os dispositivos migrados na primeira inicialização são tratados como novas instalações.
      Exemplo 1: um dispositivo com horário de instalação anterior à data de criação do arquivo menos a janela de reatribuição do aplicativo não é migrado com atribuição. Na primeira inicialização, o dispositivo é tratado como uma nova instalação (provavelmente orgânica).
      Exemplo 2: um dispositivo é migrado com um horário de instalação, mas a primeira inicialização só acontece após a migração e fora da janela de reatribuição. Nesse caso, uma nova instalação é gravada.
Não

2018-01-22T08:45:33.412

media_source
  • Ou:
    • ID do parceiro AppsFlyer como aparece no dashboard da AppsFlyer
    • Fonte de mídia personalizada (não pode ser o ID de um parceiro).
  • Para obter a lista de IDs de parceiros, conforme exigido pela AppsFlyer:
  • Formato: valores diferenciam maiúsculas e minúsculas
Sim


Não orgânico: facebook_int, googleadwords_int

Orgânico: organic

integrated_partner
  • Indica se a fonte de mídia é ou não um parceiro integrado. Ou seja, fonte de mídia orgânica ou personalizada.
  • Formato: valores diferenciam maiúsculas e minúsculas
Sim  
  • Sim
  • não (se media_source for personalizado)
campanha

Para obter detalhes de atribuição mais granulares, forneça o nome da campanha original.

Formato: sequência

Não  
campaign_id

 Para obter detalhes de atribuição mais granulares, forneça o ID da campanha original.

Formato: sequência sem espaços permitidos

Não  

Regras de arquivo CSV:

  • O arquivo CSV pode conter dispositivos de usuários de vários aplicativos.
  • Não duplique a mesma combinação de ID de dispositivo e ID do aplicativo em várias linhas. Se ocorrer duplicação, a última ocorrência no arquivo será usada.
  • Todos os cabeçalhos de coluna devem ser incluídos: app_id, platform, device_id, id_type, install_time, media_source, integrated_partner, campaign, campaign_id. Observação: a ordem dos campos é importante e deve ser mantida.
  • Você pode adicionar o IDFV e o IDFA para o mesmo dispositivo, mas eles devem estar em linhas separadas. Todos os campos nas linhas separadas devem ser os mesmos, exceto device_id.
  • Cada linha deve conter exatamente 9 campos separados por vírgulas.
  • Deixe os campos não obrigatórios vazios (em branco).
  • Os arquivos podem conter até 20 milhões de linhas.
  • Caso você tenha vários arquivos, dê a cada arquivo um nome exclusivo.
  • Codifique dados usando UTF-8.
  • [Opcional] Compacte arquivos usando ZIP ou GZIP.

Veja um exemplo de CSV

Migração não atribuída

Os dispositivos migrados para a AppsFlyer com esse método são registrados (mas não são exibidos) como usuários orgânicos. Seus eventos in-app e dados de sessões também são registrados e exibidos como orgânicos.

Estrutura de arquivo CSV de migração de dispositivos não atribuídos

Colunas Quando usar Exemplo
ID do aplicativo + IDFA/GAID/IDFV
  • Se todos os usuários Android tiverem identificadores GAID.
  • Somente usuários do iOS 
device_migration_file_option_1.png
ID do aplicativo+ ID do dispositivo + Tipo de ID do dispositivo
  • Se alguns dos seus usuários Android tiverem apenas IMEI ou ID Android, mas não GAID (mercados fora da loja, versões Android anteriores à versão 4.4.2).
  • O Android ID precisa ter um formato hexadecimal.

Observação:

  • Use as strings específicas para a coluna do tipo de ID: advertiserId (também compatível com amazon_aid), idfa, idfv, android_id, imei.
  • Se você usar android_id ou imei e, posteriormente, a AppsFlyer receber um identificador melhor, uma nova atribuição poderá ser registrada.
device_migration_file_option_2.png

Regras de arquivo CSV:

  • O arquivo CSV pode conter dispositivos de usuários de vários aplicativos.
  • Cada linha contém um ID de dispositivo único por aplicativo. 
  • Os arquivos devem incluir todos os cabeçalhos de coluna, conforme descrito abaixo:
    • Opção 1: o arquivo deve incluir todos os cabeçalhos de coluna da seguinte maneira: app_id, device_id 
    • Opção 2: app_id, device_id, id_type 
  • IDs de aplicativos em letras minúsculas
  • Identificadores Android em letras minúsculas
  • IDFA/IDFV em maiúsculas
  • Até 25 milhões de linhas permitidas

Veja um exemplo de CSV

Migração de campanha

Transfira as campanhas de marketing existentes para a AppsFlyer para habilitar a atribuição da AppsFlyer, evitando assim cobranças duplicadas e perda de dados de atribuição.

Observação: você pode optar por migrar apenas algumas campanhas de marketing de cada vez. Nesse caso, você pode segmentar as que deseja migrar por fonte de mídia (por exemplo, ad network ou agência), geolocalização ou campanha. 

SRNs

As SRNs respondem aos Parceiros de Mensuração Mobile (MMPs) quando consultados sobre engajamentos de dispositivos específicos. Se duas MMPs, como a AppsFlyer e um fornecedor de atribuição concorrente, consultarem a mesma SRN sobre a mesma instalação do dispositivo, isso poderá resultar em cobranças duplas.

Para migrar campanhas SRN:

  • Ative e configure as SRNs relevantes na AppsFlyer.

 Observação

  • SRNs podem executar várias MMPs (exceto Meta ads e Twitter).
  • O Meta ads não pode corrigir eventos in-app duplicados.

Ad networks que não são SRN

Os links de atribuição de ad networks registram os engajamentos dos usuários e, posteriormente, são usados para a atribuição dos engajamentos, que se tornam instalações reais.

Para migrar campanhas de ad networks que não são SRNs:

  1. Ative as ad networks relevantes na AppsFlyer.
  2. Gere links de atribuição da AppsFlyer para cada ad network.
  3. Troque os links existentes em cada uma das suas campanhas pelos links de atribuição da AppsFlyer. 

Mídia Própria

Mídia própria se refere aos links de atribuição que você usa em:

  • Compartilhamento de conteúdo
  • Web-to-app
  • E-mail
  • SMS
  • Posts de mídia social
  • Blogs
  • Comunidades da Internet (Quora etc.)
  • e outros...

Para essas campanhas, a AppsFlyer usa links personalizados do OneLink. Os links personalizados do OneLink redirecionam os usuários com base em seus dispositivo para a app store correta, diretamente para o aplicativo ou para uma URL/landing page do site.

Para trocar os seus links de outros fornecedores por OneLinks da AppsFlyer:

  • Entre em contato com seu CSM, que auxiliará na migração em massa de todos os seus links. 

SKAN

Para a atribuição da SKAdNetwork (SKAN), você só pode ter um SDK para atualizar o valor da conversão. Caso contrário, os dados de SKAN não têm utilidade. Portanto, certifique-se de que, após a migração, apenas o SDK da AppsFlyer poderá atualizar o valor de conversão da SKAN.

Saiba mais sobre como configurar o valor de conversão da SKAN na AppsFlyer.

Configuração do relatório de dados

Adaptar e mapear estruturas de relatório

Antes da migração, seus sistemas armazenam seus dados de atribuição do fornecedor atual de acordo com as estruturas, campos e parâmetros de relatórios que você configurou com eles. Para que a AppsFlyer relate corretamente os dados, você deve adaptar e mapear suas estruturas de relatório atuais para a estrutura, campos e parâmetros de relatório da AppsFlyer.

Para adaptar/mapear suas estruturas de relatório:

  • Entre em contato com o CSM da AppsFlyer para obter ajuda para adaptar/migrar rapidamente as estruturas de dados dos seus relatórios do Adjust, Branch/Tune ou Kochava para a AppsFlyer.

Preparar métodos de relatório

Você pode obter dados brutos e agregados dos relatórios da AppsFlyer usando diversos métodos. Familiarize-se com os métodos e configure os que são relevantes para você.

Os métodos de relatório incluem:

  • Exportar CSV
  • API de push
  • Pull API
  • Data Locker