Eventos in-app – Visão geral

Sempre que enviar eventos in-app, como uma compra ou uma reserva de voo, envie-os com a receita associada. O único parâmetro que envia a receita em eventos in-app é af_revenue

• Registrar a receita no SDK
• Registrar a receita na Unity

Você também pode registrar uma receita negativa caso um usuário cancele uma compra ou emitir um reembolso. Para registrar a receita negativa, basta acrescentar o sinal de menos (-) ao valor da receita que você enviou para af_revenue

af_revenue é o único parâmetro que acumula a receita dos seus usuários. Use-o sempre com eventos in-app que representam a receita real segundo a lógica do seu negócio.

af_revenue também pode ter valores negativos de receita se for necessário registar 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 ou formate o valor da receita de outra forma. Isso significa sem vírgulas, símbolos monetários (por exemplo, $), caracteres especiais ou texto.
• A AppsFlyer fornece o valor da receita com precisão de até cinco casas decimais.
• O intervalo desse valor deve estar entre -1.000.000 a 1.000.000 em dólares ou o 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".

Atenção:

• A AppsFlyer apresenta a receita exata enviada pelo SDK. Isso não inclui cálculos de VAT ou comissões da loja de aplicativos, etc., a menos que tenham sido incluídos pelo desenvolvedor no lado do SDK antes de ser enviado para a AppsFlyer.

af_currency representa a moeda que está indicada em af_revenue (ou af_price). Se af_currency estiver ausente dos parâmetros do evento, a AppsFlyer 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 de “Adicionar ao carrinho”). Esse parâmetro se refere ao preço do item individual. O montante total de todas as compras é exibido sob o parâmetro af_revenue.

Os anunciantes utilizam a receita estimada para otimizar as suas campanhas logo no início do ciclo de vida do usuário, no momento em que eles preveem seu valor potencial. A receita estimada é calculada com base nas interações e comportamentos anteriores do usuário. Atenção: Fale com o suporte da AppsFlyer para saber se a sua ad network oferece suporte para receita estimada.

Como a receita estimada deve ser relatada à AppsFlyer?

Ao relatar a receita estimada para a AppsFlyer, ela deve ser enviada em eventos separados daqueles que contêm a receita real. Os anunciantes devem se assegurar de que:

• Eventos com receita real e eventos com receita estimada são tratados e relatados como eventos distintos.
• Os dados da receita estimada estão incluídos no valor do evento, por exemplo:

      "event_value": {
          "af_projected_revenue": 0.79
      }

Receita estimada no dashboard e relatórios da AppsFlyer

• A receita estimada não está incluída nos cálculos ou métricas de receita total apresentados no dashboard da AppsFlyer. Isso garante que o dashboard mostre apenas a receita real obtida.
• Nos dados brutos, a receita projetada não é apresentada em um campo específico mas pode ser encontrada no valor do evento que contém a quantidade de receita enviada pelo anunciante.

Envio de postbacks de receita prevista

Para saber como enviar postbacks com a previsão de receita para as ad networks, consulte compartilhar receita prevista.

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

A AppsFlyer lida com a diferença entre a moeda definida no aplicativo e e a moeda dos eventos in-app usando a conversão de moeda.

O diagrama acima ilustra o seguinte processo:

1. Os eventos in-app são enviados - cada evento com uma moeda diferente
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 de acordo com as 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 para a conversão de moeda. A taxa de câmbio é atualizada a cada hora Sempre que a AppsFlyer faz uma conversão de moeda, ela usa a taxa de câmbio da atualização da última hora.

Conversão de moeda

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 a moeda que você envia nos eventos in-app, a receita no dashboard é sempre apresentada 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 oferecem um contexto adicional ao evento e enriquecem os dados.
3. Faça o 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 para apps de jogos
	Eventos recomendados para apps de eCommerce
	Eventos recomendados para apps de entretenimento
	Eventos recomendados para apps de finanças e bancos
	Eventos recomendados para apps de empréstimos P2P
	Eventos recomendados para apps de educação online
	Eventos recomendados para apps de transporte
	Eventos recomendados para apps de reserva de voos
	Eventos recomendados para apps de reserva de hotéis
	Eventos recomendados para apps de saúde
	Eventos recomendados para apps de telecomunicações
	Eventos recomendados para apps de eWallet
	Eventos recomendados para 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 nos seguintes locais:

• Dashboard de visão geral: exibe a performance do LTV da aquisição de usuários (UA) em tempo real Atenção: isso 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 evenos in-app entre fontes de mídia
• Página de atividade: exibe as atividades in-app para o intervalo de datas selecionada.

• Relatório de dados brutos de eventos in-app: Fornece dados de atividades, ou seja, uma lista cronológica das ações efetuadas por toda a base de usuários. Esse relatório inclui valores de parâmetros de eventos, 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 garantir a consistência dos dados nos relatórios de dados brutos, recomendamos definir e utilizar 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 dos 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 mais informações sobre dados restritos, consulte 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 optar por 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.  Para saber mais sobre os parâmetros de monetização, consulte a imagem altrevenue_data.pngalt

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. No entanto, em relatórios e dashboards agregados (por exemplo, Visão geral ou Eventos), apenas letras minúsculas são permitidas e, portanto, 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 codificadas ou codificadas 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 dos eventos não devem ultrapassar 2.000 caracteres para evitar serem abreviados em relatórios de dados brutos. Porém, se o evento for originado a partir do SDK, aconselhamos que você fique abaixo de 1.000 caracteres para garantir que o payload não seja truncado ao ser enviado na solicitação HTTP.
• Se você incluir a URL de referência como um valor de evento, ela deverá ser codificada 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 no aplicativo que representam a geração de receita real em sua lógica de negócios.

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

Para 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ânicas quando:

• 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. 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, pode usar um array de 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 desduplicaçã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 menos de 10 segundos antecipadamente. 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
• App ID
• AppsFlyer ID

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.