Eventos avançados dentro do aplicativo—Visão geral

Os eventos in-app que você deseja enviar exigem que o desenvolvedor implemente o código quando aplicável em seu aplicativo. Os nomes de eventos e os parâmetros de eventos são classificados da seguinte forma:

• Predefinido: são nomes de eventos e parâmetros de eventos que costumam ser usados entre aplicativos diferentes. É altamente recomendável usar nomes de eventos predefinidos e parâmetros de eventos tanto quanto possível, pelos seguintes motivos:
  • A nomeação predefinida permite o mapeamento automático de eventos para parceiros. 
  • Se a AppsFlyer decidir alterar o nome de qualquer parâmetro de evento ou evento, sua implementação será compatível com versões anteriores.
• Personalizado: são nomes de eventos e parâmetros que você define para cenários de usuário específicos que ocorrem no aplicativo. Você pode usar qualquer nome de evento personalizado ou string de nome de parâmetro, mas lembre-se de que eventos personalizados precisam de manutenção por parte do desenvolvedor. Consulte Dicas e Limitações.

Sempre que você envia eventos in-app, como uma compra ou reserva de voo, você o envia com sua receita associada. O único parâmetro que carrega receita em eventos in-app é af_revenue

• Registro da receita no SDK
• Registro da receita no Unity

Você também pode registrar receita negativa caso um usuário cancele uma compra ou se você emitir um reembolso. Para registrar a receita negativa, basta anexar o sinal negativo (-) ao valor da receita que você envia paraaf_revenue

af_revenue é o único parâmetro que acumula a receita dos seus usuários. Sempre o use com eventos in-app que representam a geração de receita real em sua lógica de negócios.

af_revenue também pode ter valores de receita negativos se você precisar registrar eventos como transações canceladas ou reembolsos.

O valor da receita deve conter apenas números (e ponto decimal, se necessário):

• Não inclua outros caracteres nem formate o valor da receita de outra forma. Ou seja, não insira vírgulas, sinais de moeda (ou $ por exemplo), caracteres especiais ou texto.
• A AppsFlyer fornece um valor de receita com precisão de até cinco casas decimais.
• O intervalo desse valor deve ser de -10.000 a 10.000 em dólares ou o valor equivalente na moeda original. Valores fora dessa faixa estão incluídos em relatórios de dados brutos, mas não em relatórios agregados.
• Exemplo: 1234,56
• Quando a receita é enviada como string, o valor entre aspas deve ser válido. Por exemplo: "1234,56".

Observação:

• A AppsFlyer exibe a receita exata enviada do SDK. Isso não inclui nenhum cálculo de IVA ou comissões de loja app, etc, a menos que o mesmo tenha sido incluído pelo desenvolvedor do lado do SDK antes de ser enviado à AppsFlyer.

af_currency representa a moeda que é declarada em af_revenue (ou af_price). Se af_currency estiver faltando nos parâmetros do evento, a AppsFlyer a envia com o valor padrão "USD".

Você pode usar af_price como um parâmetro monetário que não é contado como receita (como em um evento "Add to Cart"). Esse parâmetro se refere ao preço do item individual. O valor total de todas as compras aparece sob o parâmetro af_revenue.

Moeda da receita

É importante entender como a AppsFlyer lida com configurações de moeda e conversões de moeda.

A AppsFlyer lida com a diferença entre a moeda definida nas configurações do aplicativo e a moeda de eventos in-app usando a conversão de moedas.

O diagrama acima demonstra o seguinte processo:

1. Os eventos in-app são enviados - moedas diferentes para cada evento
2. A AppsFlyer padroniza todas as moedas para USD
3. A AppsFlyer processa os dados de receita
4. Os dados de receita no dashboard são exibidos nas configurações de moeda no aplicativo
5. A AppsFlyer preenche os dados de receita em relatórios de dados brutos tanto na moeda do evento como na moeda da configuração do aplicativo

A AppsFlyer usa Open Exchange Rates, ou taxas de câmbio abertas, para conversão de moeda. A taxa de câmbio é atualizada de hora em hora. Sempre que a AppsFlyer realiza a conversão de moeda, ela usa a taxa de câmbio da última atualização.

Conversão de moedas

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

Exibição da moeda

A moeda é definida nas configurações do aplicativo. A moeda que você define nas configurações do aplicativo é a moeda que aparece no dashboard. Não importa em qual moeda você envia eventos in-app, a receita no dashboard sempre aparece na moeda que você definiu nas configurações do aplicativo.

Depois de determinar os eventos in-app que você deseja mensurar, use nosso gerador de eventos in-app para definir os eventos e parâmetros da seguinte forma:

1. Selecione o nome de evento mais adequado ao cenário que você deseja registrar.
2. Selecione os parâmetros do evento que você deseja associar ao evento. Escolha parâmetros que oferecerão contexto adicional ao evento e enriquecerão os dados.
3. Faça download do arquivo completo do gerador de eventos in-app e compartilhe-o com seu desenvolvedor.

A tabela a seguir oferece links para artigos que incluem os exemplos e fluxos de eventos in-app típicos que sugerimos que sejam registrados por vertical.

Vertical de negócios	Título do artigo
	Eventos recomendados de aplicativos de jogos
	Eventos recomendados de aplicativos de e-commerce
	Eventos recomendados de aplicativos de entretenimento
	Eventos recomendados de aplicativos financeiros e serviços bancários
	Eventos recomendados do aplicativo de empréstimo P2P
	Eventos de aplicativos de educação on-line recomendados
	Eventos recomendados de aplicativo de transporte de passageiros
	Eventos recomendados de aplicativo de reserva de voos
	Eventos recomendados de aplicativo de reserva de hotel
	Eventos recomendados para aplicativos de saúde
	Eventos recomendados para aplicativos de telecomunicações
	Eventos recomendados de aplicativos de eWallet
	Eventos recomendados para aplicativos de apostas esportivas

Eventos in-app são atribuídos à fonte de mídia responsável pela instalação ao longo da vida útil do usuário. Os dados de eventos são apresentados como dados de Lifetime Value ou de Atividade. 

Você pode visualizar os dados de eventos in-app nestes locais:

• Página de visão geral do dashboard: exibe a performance do LTV da aquisição de usuários (UA) em tempo real. Observação: isto inclui a receita dividida igualmente entre usuários orgânicos e não-orgânicos reportados através de eventos in-app, e a receita de retargeting que é duplamente atribuída.
• Página de eventos: exibe a performance do LTV de eventos in-app entre fontes de mídia
• Página de atividades: exibe as atividades in-app para o intervalo de datas selecionada.
• Relatório de eventos in-app de dados brutos: exibe dados de atividade, ou seja, uma lista cronológica das ações executadas por toda a sua base de usuários. Esse relatório inclui valores de parâmetros de evento, por exemplo:

  {
    "af_level":"10",
    "af_score":"3387",
    "arena":"7",
    "char_type":"paladin"
  }

  Observação: o relatório de dados brutos é um recurso premium.

Ao definir nomes e parâmetros de eventos no aplicativo, lembre-se:

• Para obter consistência de dados em relatórios de dados brutos, recomendamos que você defina e utilize os mesmos nomes e estruturas de eventos in-app em todas as plataformas.
• Use um número mínimo de eventos para facilitar a comparação da qualidade dos usuários vindos de diferentes fontes.
• É importante garantir a privacidade de seus usuários. Não preencha valores de eventos in-app com dados restritos que possam identificá-los diretamente. Por exemplo, endereço de e-mail, nome, número de identidade e, em alguns locais, código postal. Para obter mais informações sobre dados restritos, leia a política de privacidade dos serviços.
• Observe que a AppsFlyer coleta o endereço de IP dos dispositivos durante os engajamentos. Em algumas jurisdições ou cenários de uso, o endereço de IP pode ser considerado uma PII. Usamos o endereço de IP para derivar a ampla localização geográfica (cidade, bairro) do dispositivo, mas não o endereço específico. Se necessário, você pode selecionar mascarar endereços de IP para que eles não apareçam nos relatórios de dados brutos. 
• Eventos in-app são a única fonte de dados de receita na AppsFlyer. Você pode anexar um valor de receita específico a cada evento e visualizá-lo no dashboard do seu aplicativo.  Saiba mais sobre os parâmetros de monetização.

  

Ao definir nomes e parâmetros de eventos no aplicativo, lembre-se:

• Recomendamos usar apenas caracteres alfa-numéricos minúsculos (a-z e 0-9) para seus nomes de eventos in-app. Os nomes de eventos diferenciam maiúsculas de minúsculas, o que significa que af_purchase e af_PURCHASE são dois eventos diferentes nos dados brutos. Entretanto, em relatórios agregados (por exemplo, Visão Geral, ou Eventos) eles podem ser exibidos como um único evento.
• Há um limite de 300 eventos exclusivos por dia. Saiba mais
• Os usuários exclusivos são contados somente para os primeiros 100 eventos após a instalação do aplicativo.
• Os nomes dos eventos não podem começar com esses caracteres: " = + - 
• Os valores de evento não devem conter o caractere + , exceto em URLs codificados ou codificados conforme ASCII.
• Os nomes de eventos não podem conter espaços vazios. Você pode usar espaços sublinhados (underline, ou traços baixos) antes ou depois do nome do evento.
• Os valores do evento não devem exceder 2.000 caracteres, pois podem ser reduzidos em relatórios de dados brutos. 
• Se você incluir a URL de referência como um valor de evento, ele deverá ser codificado por URL.
• O Meta ads tem algumas limitações em relação aos nomes e parâmetros de eventos. Leia sobre as limitações aqui.

Você pode enviar valores de receitas com qualquer nome de parâmetro e evento. No entanto, para registrar a receita (incluindo receita negativa) nos dados brutos e agregados da AppsFlyer, o parâmetro af_revenue DEVE ser usado. Sempre use ele com eventos in-app que representam a geração de receita real em sua lógica de negócios.

af_currency representa a moeda que é indicada emaf_revenue (ou af_price). Se af_currency estiver ausente nos parâmetros do evento, a AppsFlyer o enviará com o valor padrão "USD".

Para obter mais informações sobre o parâmetro af_revenue, consulte o Guia de Atribuição de Receita.

Os eventos in-app são atribuídos ao canal original da mídia da instalação do aplicativo.

Após a instalação de um aplicativo (primeira abertura do aplicativo), a AppsFlyer utiliza vários métodos de atribuição para determinar a atribuição da instalação. Ao mesmo tempo, o SDK da AppsFlyer cria um novo e exclusivo ID da AppsFlyer, que está associado com os detalhes de atribuição.

Cada evento in-app posterior, realizado pelo mesmo dispositivo no aplicativo, tem esse ID. Isso permite que a AppsFlyer atribua o evento ao canal original da mídia. Os anunciantes podem usar esse recurso para acompanhar a jornada completa do usuário no aplicativo.

Eventos de usuários que recentemente passaram por retargeting podem ter dupla atribuição.

A AppsFlyer atribui eventos de instalações atribuídas como orgânicos quando:

• Mais de 24 meses passam após a data de instalação
• Os termos do canal da mídia ditam a exclusão dos dados no nível de usuário
• O usuário exclui os dados armazenados no dispositivo, forçando a criação de um novo ID da AppsFlyer.

Se um usuário iniciar um evento quando a conexão à internet estiver indisponível, a Appsflyer ainda pode realizar o registro do evento. Confira como funciona:

1. O SDK envia os eventos para os servidores da AppsFlyer e aguarda uma resposta bem-sucedida.
2. Se o SDK não receber uma resposta bem-sucedida, o evento será armazenado no cache.
3. Uma vez que a próxima resposta bem-sucedida é recebida, o evento armazenado é enviado para o servidor novamente.
4. Se houver vários eventos no cache, eles serão enviados para o servidor, um após o outro.

Eventos complexos in-app permitem o envio de vários eventos em uma única chamada de API.

Eles são úteis quando você deseja ver várias ações de usuários intimamente relacionadas agrupadas, por exemplo adicionar vários produtos à cesta em uma única sessão.
Exemplo:

{
  "af_revenue":"50.87",
  "af_currency":"USD",
  "af_receipt_id":"57601333",
  "product":[ 
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1177_8185",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"0153_9077",
	 "af_price":"14.99",
	 "af_quantity":"1"
   }
  ]
}

Você pode adicionar vários itens a uma única transação. Em vez de valores únicos por parâmetro de evento, você pode ter vários itens descrevendo a transação, separados por vírgulas.  O formato deve ser uma string JSON.

"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"

Temos um mecanismo de deduplicação de eventos in-app. Ele verifica todos os eventos in-app para ver se há um evento in-app idêntico que veio do mesmo appsflyer_id anteriormente, há menos de 10 segundos. Se tal evento for encontrado, o mecanismo remove a duplicação.

Dois eventos são considerados idênticos se os seguintes campos em ambos eventos forem iguais:

• Nome do evento
• Valor do evento
• ID do aplicativo
• ID da AppsFlyer

A AppsFlyer retém dados a nível de usuário (dados brutos) por 24 meses, exceto quando indicado, exigido ou permitido por lei. Algumas SRNs/parceiros exigem que os provedores de atribuição, incluindo a AppsFlyer, excluam os dados a nível de usuário relacionados a SRN/parceiros antes da expiração do período de 24 meses.

Após a exclusão, os eventos relacionados a usuários excluídos são exibidos como orgânicos. Dados agregados antigos não são alterados. Para obter mais informações, consulte Obrigações de retenção e exclusão de dados.

• O SDK do Android e o SDK do iOS adicionam automaticamente o parâmetro OS (sistema operacional).
• Para a API S2S, desde 1 de julho de 2021, você deve enviar o parâmetro OS (sistema operacional) para aplicativos iOS. Se você não enviar esse parâmetro, os dados serão considerados como tendo vindo de um usuário do iOS 14.5, e isso afeta a forma como os dados brutos são disponibilizados.