Eventos na aplicação – Visão geral

Sempre que enviar eventos na aplicação, como uma compra ou uma reserva de voo, envie-os com a receita associada. Envie-os com a receita associada. O único parâmetro que gera receita em eventos na aplicação é af_revenue

• Registo de receita no SDK
• Registo de receita no Unity

Pode também registar receita negativa se um utilizador cancelar uma compra ou se emitir um reembolso. Para registar receita negativa, basta acrescentar o sinal de menos (-) ao valor da receita que se transmite para af_revenue

af_revenue é o único parâmetro que acumula a receita dos seus utilizadores. Use-o sempre com eventos dentro da aplicação que representam geração real de receita na 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 deste valor deve estar entre -1.000.000 a 1.000.000 em dólares ou o equivalente na moeda original. Valores fora deste intervalo sã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".

Nota:

• A AppsFlyer apresenta a receita exata enviada pelo SDK. Isso não inclui cálculos de IVA ou comissões da app store, 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á indicado em af_revenue (ou af_price). Se af_currency estiver ausente dos parâmetros do evento, a AppsFlyer envia-o com o valor padrão "USD".

Pode usar af_price como um parâmetro monetário que não é contado como receita (como num evento “Adicionar ao carrinho”). Este o parâmetro refere-se ao preço individual de cada artigo. 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 utilizador, ao prever o valor potencial do mesmo. A receita estimada é calculada com base nas interações e comportamentos anteriores do utilizador. Nota: Contacte o suporte da AppsFlyer para saber se a sua rede de anúncios suporta receita estimada.

Como deve ser a receita estimada reportada à AppsFlyer?

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

• Eventos com receita real e eventos com receita estimada são tratados e reportados 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 painel da AppsFlyer e em relatórios

• A receita estimada não está incluída nos cálculos ou métricas de receita total apresentados no painel da AppsFlyer. Isto garante que o painel reflete 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 o montante da receita enviado pelo anunciante. que contém o montante da receita enviado pelo anunciante.

Envio de postbacks de receita projetada

Para saber como enviar postbacks de receitas projetadas para as redes de anúncios, consulte Partilhar receita projetada.

É importante entender como a AppsFlyer gere as definições de moeda e a conversão de moeda.

A AppsFlyer lida com a diferença entre a moeda definida na aplicação e e a moeda dos eventos na aplicação, utilizando 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 normaliza todas as moedas para USD
3. A AppsFlyer processa os dados de receita
4. Os dados de receita no painel são apresentados de acordo com as definições da aplicação símbolos monetários
5. A AppsFlyer insere dados de receita nos relatórios de dados brutos tanto na moeda do evento como na da aplicação configurações de moeda do evento e da aplicação

A AppsFlyer utiliza Open Exchange Rates para a conversão de moeda. A taxa de câmbio é atualizada a cada hora em base. Sempre que a AppsFlyer faz uma conversão de moeda, utiliza a taxa de câmbio da última atualização horária. taxa de câmbio da última atualização horária.

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 definições da aplicação. A moeda que definiu nas definições da aplicação é a que que aparece no painel de controlo. Não importa a moeda que envia em eventos na aplicação, a receita no painel de controlo é sempre apresentada na moeda que definiu nas definições da aplicação.

Depois de determinar os eventos na aplicação que pretende medir, utilize o nosso gerador de eventos na aplicação para definir os eventos e parâmetros da seguinte maneira:

1. Escolha um nome de evento que melhor se adapte ao cenário que deseja registar.
2. Selecione os parâmetros de evento que deseja associar ao evento. Escolha parâmetros que forneçam contexto adicional ao evento e enriqueçam os dados.
3. Descarregue o ficheiro completo do gerador de eventos na aplicação e partilhe-o com o seu programador.

A tabela seguinte fornece ligações para artigos com exemplos e fluxos dos eventos típicos que recomendamos gravar por setor.

Setor Empresarial	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 boleias
	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 carteira eletrónica
	Eventos recomendados para apostas desportivas

Os eventos na aplicação são atribuídos à fonte de mídia responsável pela instalação ao longo da vida do utilizador. Os dados do evento são apresentados como Valor Vitalício ou dados de Atividade. 

Pode visualizar os seus dados de eventos na aplicação nos seguintes locais:

• Página de visão geral do painel de controlo : Apresenta o desempenho de aquisição de utilizadores (UA) LTV em tempo real. Nota: Isto inclui as receitas divididas entre utilizadores orgânicos e não orgânicos reportadas através de eventos na aplicação, e receitas de retargeting que são duplamente atribuídas.
• Página de eventos: Mostra o desempenho dos eventos LTV na aplicação através de várias fontes de mídia.
• Página de atividades: Exibe as atividades na aplicação para o intervalo de datas selecionado.

• Relatório de dados brutos de eventos na aplicação: Fornece dados de atividades, ou seja, uma lista cronológica das ações efetuadas por toda a base de utilizadores. Este relatório inclui valores de parâmetros de eventos, por exemplo:

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

  Note que os relatórios de dados brutos são uma funcionalidade premium.

Considere o seguinte ao definir nomes e parâmetros de eventos na aplicação:

• Para garantir a consistência dos dados nos relatórios de dados brutos, recomendamos definir e utilizar os mesmos nomes e estruturas de eventos na aplicação em todas as plataformas.
• Use um número mínimo de eventos para facilitar a comparação da qualidade dos utilizadores vindos de diferentes fontes.
• É essencial assegurar a privacidade dos seus utilizadores. Evite preencher valores de eventos na aplicação com dados restritos que os possam identificar diretamente. Por exemplo, endereço de email, 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.
• Tenha em mente que a AppsFlyer inclui o endereço IP dos dispositivos durante os engagements. Em algumas jurisdições ou cenários de utilização, o endereço IP pode ser considerado como informação pessoal identificável (PII). Utilizamos o endereço IP para determinar a localização geográfica ampla (cidade, distrito) do dispositivo, mas não o endereço específico. Se necessário, pode escolher mascarar os endereços IP para que não apareçam nos relatórios de dados brutos. 
• Os eventos na aplicação são a única fonte de dados de receita na AppsFlyer. Pode associar um valor específico de receita a cada evento e visualizá-lo no painel da sua aplicação. Para saber mais sobre os parâmetros de monetização, consulte a imagem altdados_da_receita.pngalt

Considere o seguinte ao definir nomes e parâmetros de eventos na aplicação:

• Recomendamos que utilize apenas caracteres alfanuméricos em minúscula (a-z e 0-9) para os nomes dos eventos na aplicação. Os nomes dos eventos distinguem maiúsculas de minúsculas, portanto, af_purchase e af_PURCHASE são considerados dois eventos distintos nos dados brutos. No entanto, em relatórios agregados (como Visão Geral ou Eventos), podem ser exibidos como um único evento.
• Existe um limite de cardinalidade de 300 eventos únicos por dia. Saiba mais
• Os utilizadores únicos são contabilizados apenas nos primeiros 100 eventos após instalarem a aplicação.
• Os nomes dos eventos não podem começar com os seguintes caracteres: " = + -
• Os valores dos eventos não devem conter o carácter +, exceto em URLs codificados ou conforme o ASCII.
• Os nomes dos eventos não podem conter espaços em branco. Pode usar sublinhados (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, é aconselhável mantê-lo abaixo de 1.000 caracteres para assegurar que a carga útil não é truncada ao ser enviada no pedido HTTP.
• Se incluir a URL de referência como um valor de evento, esta deve estar codificada como URL.
• Os anúncios Meta têm algumas limitações em relação aos nomes dos eventos e parâmetros. Leia sobre as limitações aqui.

Pode enviar valores de receita com qualquer nome de parâmetro e evento. Contudo, para registar a receita (incluindo receita negativa) nos dados brutos e agregados da AppsFlyer, DEVE utilizar o parâmetro af_revenue . Use-o sempre em eventos na aplicação que representam geração real de receita na lógica do seu negócio.

af_currency representa a moeda indicada em af_revenue (ou af_price). Se af_currency estiver ausente nos parâmetros do evento, a AppsFlyer enviará 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 na aplicação são atribuídos à fonte de media original da instalação da aplicação.

Na instalação de uma aplicação (primeira vez que é aberta), a AppsFlyer utiliza diversos métodos de atribuição para determinar a origem da instalação. Ao mesmo tempo, o SDK da AppsFlyer gera um novo ID único da AppsFlyer, que é associado aos detalhes da atribuição.

Cada evento subsequente na aplicação realizado pelo mesmo dispositivo possui este ID. Isto permite à AppsFlyer atribuir o evento à fonte de mídia original. Os anunciantes podem usar isto para monitorizar todo o percurso do utilizador na sua aplicação.

Os eventos de utilizadores recentemente retargetizados podem ter atribuição dupla.

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

• Passam mais de 24 meses após a data de instalação
• Os termos da fonte de mídia exigem a eliminação dos dados ao nível do utilizador
• O utilizador apaga os dados da aplicação armazenados no dispositivo, forçando a criação de um novo ID AppsFlyer.

Se um utilizador iniciar um evento sem ligação à Internet, a AppsFlyer ainda pode registá-lo. É assim que 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 é armazenado na cache.
3. Assim que a próxima resposta bem-sucedida é recebida, o evento armazenado é enviado novamente para o servidor.
4. Se existirem vários eventos na cache, são enviados ao servidor, um após o outro.

Os eventos complexos na aplicação permitem enviar múltiplos eventos numa única chamada de API.

São úteis quando se pretende agrupar várias ações de utilizadores intimamente relacionadas (por exemplo, adicionar vários produtos ao carrinho numa ú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"
   }
  ]
}

Sim, 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\"}"

Dispomos de um mecanismo de desduplicação de eventos na aplicação. Verifica todos os eventos in-app para verificar se houve um evento in-app idêntico proveniente do mesmo appsflyer_id menos de 10 segundos antes. Se tal evento for encontrado, remove-se o duplicado.

Consideram-se dois eventos idênticos se os seguintes campos em ambos forem iguais:

• Nome do evento
• Valor do evento
• ID da aplicação
• ID da AppsFlyer

A AppsFlyer retém os dados a nível do utilizador (dados brutos) por 24 meses, salvo indicação, exigência ou permissão legal em contrário. Alguns SRNs/parceiros exigem que os fornecedores de atribuição, incluindo a AppsFlyer, eliminem dados relacionados ao nível do utilizador antes do término do período de 24 meses.

Após a eliminação, os eventos relacionados com os utilizadores eliminados aparecem como orgânicos. Os dados agregados antigos não são alterados. Para mais informações, consulte Obrigações de retenção e eliminação de dados.

• O Android SDK e o iOS SDK adicionam automaticamente o parâmetro OS (sistema operativo).
• Para a API S2S, a partir de 1 de julho de 2021, deve enviar o parâmetro OS (sistema operativo) para as aplicações iOS. Se não enviar este parâmetro, os dados serão considerados como provenientes de um utilizador do iOS 14.5, o que afetará a forma como os dados brutos são disponibilizados.