Guia de atribuição de receita de anúncios

Para:
Profissionais de marketing
Última atualização:

Visão geral: atribua a receita de anúncios para concluir a visualização de performance de LTV.

mceclip0.png

Atribuição de receita de anúncios

  • Os anúncios aparecem no aplicativo em banners, mural de ofertas, intersticiais etc. e geram receita publicitária.
  • A receita publicitária, combinada com compras in-app e a receita de assinatura fornecem a você o panorama completo do LTV do usuário. Ao combinar o LTV do usuário com a campanha de gastos com mídia, o ROI é determinado e está disponível para análise posterior na plataforma. 

Dados de receita publicitária atribuídos:

  • É adquirido das redes de mediação e/ou monetização de anúncios por meio de APIs de servidor ou por SDK de relatórios incorporados ao aplicativo (incluindo iOS 14).
  • São atribuídos ao canal de mídia originalmente responsável por captar o usuário. Por exemplo:
    • O usuário vê um anúncio da Rede A e faz download do seu aplicativo.
    • O anúncio é exibido dentro do aplicativo.
    • A receita de anúncios é atribuída à Rede A (responsável pela aquisição do usuário), independentemente de quem publicou o anúncio.
  • A granularidade dos relatórios depende da integração da rede de monetização e do tipo de atribuição da receita publicitária.

Tipos de integração para atribuição de receita publicitária

A atribuição da receita publicitária é compatível com diferentes métodos de granularidade. A granularidade depende da rede de monetização.

Tipos de integração para atribuição de receita publicitária
Tipo de integração de atribuição de receita publicitária Descrição

Nível agregado via API S2S
  • A AppsFlyer obtém a receita diária dividida por localização.
  • A receita efetiva por ação (eRPA) é obtida através da divisão da receita pelo número de instâncias de um evento trigger.
  • Os eventos de gatilho são eventos abertos ou eventos in-app específicos definidos no aplicativo. 
  • Se você estiver usando uma rede de mediação, desative as integrações de receita publicitária para parceiros de monetização que fazem a mediação por meio da rede de mediação antes de ativar a integração de receita publicitaria com a rede de mediação. Se isso não for feito, o resultado será  dados duplicados. 

Nível do usuário via API S2S
  • A rede de mediação ou monetização reporta a receita por usuário no nível do dispositivo. Nem todas as redes são compatíveis com a granularidade a nível de usuário.
  • Essa receita é atribuída à fonte de mídia que trouxe o usuário. Ou seja, a atribuição da receita de anúncios da AppsFlyer segue as regras de atribuição encontradas na plataforma, incluindo regras de atribuição de retargeting. 
  • Se você estiver usando uma rede de mediação, desative as integrações de receita publicitária para parceiros de monetização que fazem a mediação por meio da rede de mediação antes de ativar a integração de receita publicitaria com a rede de mediação. Se isso não for feito, o resultado será  dados duplicados. 
  • O nível de usuário via API S2S inclui 100% da receita publicitária e tem a maior precisão de dados dos tipos de integração de receita publicitária.
  • Os dados estão disponíveis em relatórios de dados brutos. Não enviamos retrocessos de dados a nível de usuário para parceiros integrados.
[Beta] Nível de impressão via SDK
  • O nível de impressão refere-se a como a AppsFlyer recebe os dados. Os dados podem acabar sendo relatados em outros níveis de granularidade (como o nível do dispositivo).
  • A rede de mediação ou monetização reporta a receita por usuário no nível da impressão. Nem todas as redes são compatíveis com granularidade a nível da impressão.
  • Essa receita é atribuída à fonte de mídia que trouxe o usuário. Ou seja, a atribuição da receita de anúncios da AppsFlyer segue as regras de atribuição encontradas na plataforma, incluindo regras de atribuição de retargeting. 
  • Se você estiver usando uma rede de mediação, desative as integrações de receita publicitária para parceiros de monetização que fazem a mediação por meio da rede de mediação antes de ativar a integração de receita publicitaria com a rede de mediação. Se isso não for feito, o resultado será  dados duplicados. 
  • O nível da impressão via SDK tem a melhor atualização de dados de todos os tipos de integração de receita publicitária.
  • Compatível com SKAN.
[Beta fechado] Nível de impressão (via SDK) com nível de usuário (via S2S API)
  • Permite que os dados em nível de impressão que chegam via SDK sejam atribuídos e reportados no Dia X, e sejam trocados com dados em nível de usuário que chegam via API no Dia 1 e seguintes.
  • Oferece o benefício da atualização dos dados para o Dia X com a precisão dos dados para os Dias X+1 e seguintes.
  • Compatível com SKAN.
[Beta fechado] Nível de impressão via SDK com nível agregado via API S2S
  • A AppsFlyer obtém diariamente a receita dividida por dimensões de monetização, tais como colocação, unidade de anúncio, tipo de anúncio etc.
  • A receita efetiva por ação (eRPA) é obtida através da divisão da receita pelo número de instâncias de um evento trigger.
  • Os eventos de gatilho são eventos de nível de impressão com dimensões de monetização enviados através do conector SDK. Observação: os valores de receita publicitária não estão incluídos nos dados de nível de impressão e só ficam disponíveis quando os dados de nível agregado são recebidos. 
  • Este tipo de atribuição é mais preciso do que o nível agregado padrão via API S2S.

Implementação

As seções a seguir descrevem os tipos de atribuição de receita de anúncios disponíveis, bem como os fluxos de trabalho e as etapas necessárias para implementação e manutenção.

Conectar a parceiros integrados de receita publicitária

ad_revenue_integration_2.png

Antes de começar:

  • Solicite que o parceiro integrado de receita de anúncios forneça as credenciais da API.

Para habilitar a integração da receita de anúncios com a rede de receita de anúncios:

  1. Na AppsFlyer, acesse Configuração > Parceiros Integrados.
    A janela de Parceiro Integrado é aberta. 
  2. Selecione um parceiro. Dica: selecione Ativo e Receita de anúncios para exibir seus parceiros existentes que possuem recursos de receita de anúncios.
    A janela de configuração do parceiro integrado será aberta.
  3. Acesse a aba de Receita de anúncios e habilite Obter dados de receita de anúncios.
  4. Selecione o tipo de dados de receita de anúncios que você deseja receber. Observação: nem todas as ad networks oferecem todas as opções listadas abaixo.
    • Receita atribuída. Ou seja, receita com base na fonte de aquisição do usuário. Os relatórios de receita atribuídos podem ser:
      • Nível agregado via API S2S
        • Selecione o evento no qual basear a receita publicitária. Por exemplo, se você escolher o evento af_app_opened, a receita total do anúncio será dividida entre todos os eventos abertos pelo aplicativo, o que lhe dará a receita de anúncios por abertura do aplicativo. 
      • Nível de usuário via API S2S. 
        • Observação: se você estiver habilitando a API de receita publicitária a nível de usuário de uma rede de mediação, você deve desativar as integrações de receita publicitária das redes de monetização que ela faz a mediação. Caso contrário, você terá dados duplicados. 
      • Nível de impressão via SDK.
      • [Beta fechado] Nível de impressão via SDK com nível agregado via API S2S.
      • [Beta fechado] Nível de impressão (via SDK) com nível de usuário (via S2S API)
      • Observação: se você estiver usando uma rede de mediação, desative as integrações de receita publicitária para parceiros de monetização que fazem a mediação por meio da rede de mediação antes de ativar a integração de receita publicitaria com a rede de mediação. Caso contrário, você terá dados  duplicados.
  5. Preencha as credenciais da API ou faça login, conforme exigido pelo parceiro integrado. Isto não é relevante para as integrações SDK.
  6. Clique em Salvar receita de anúncios.
  7. Se o botão Testar conexão for exibido, como na imagem acima, clique em Testar conexão.
  8. Se o botão Testar Conexão não aparecer, você concluiu o procedimento.
    A AppsFlyer coleta os dados do parceiro várias vezes por dia. 

Observação: se você mudar de um tipo de integração para outro, a mudança entra em vigor às 12h UTC do dia seguinte. 

Agregar granularidade usando a abertura de aplicativo ou eventos in-app

A granularidade agregada para receita publicitária funciona da seguinte forma:

  • A rede integrada relata a receita total por dia detalhada por geolocalização.
  • A AppsFlyer deriva a receita efetiva por ação (eRPA) dividindo a receita de anúncios pelo número de instâncias de um evento de gatilho.
  • A AppsFlyer cria um evento _monetizado, que inclui o eRPA total para cada dispositivo atribuído. Por exemplo, ad_matched_monetized.
  • O uso da receita de eRPA é atribuído a fontes de mídia.
  • Você pode usar um dos seguintes tipos de eventos: 
    • Evento in-app exclusivo de monetização requer modificações no aplicativo. 
    • evento af_app_opened que está disponível por padrão.
  • Não informe os valores de receita em eventos em paralelo a uma integração de receita publicitária. Isso faz com que a receita de anúncios seja duplicada no Dashboard, pois a AppsFlyer obtém os dados de receita da rede de monetização por integração. 
Receita de anúncios agregada que usa eventos
Método de evento Como é implementado considerações

Evento in-app exclusivo de monetização 
  • Um evento in-app é definido no momento da exibição do anúncio 
  • Isso fornece uma contagem distinta de ações do usuário, o que permite cálculos de eRPA melhores 
  • Isso pode ser ainda mais refinado com um evento in-app diferente para cada rede de monetização, permitindo que você divida a receita por rede de monetização
    Veja a tabela abaixo para mais informações. 
  • Requer que o desenvolvedor modifique o aplicativo
  • A receita pode ser separada de acordo com a rede de monetização no Dashboard

af_app_opened event
  • O evento af_app_opened é enviado pelo SDK da Appsflyer por padrão
  • É acionado por cada sessão de usuário 
  • Nenhuma modificação do aplicativo é necessária
  • Rápida implementação 
  • Os valores de eRPA ficam bastante distorcidos, a menos que você mostre apenas um aplicativo por sessão
  • Sem divisão da receita por rede de monetização
  • O evento pertence a todos os usuários que iniciam o aplicativo, de forma que você não possui um indicativo sobre se o usuário estaria disposto a assistir anúncios.
Comparação de métodos de eventos in-app
Método Prós Contras considerações
Use o mesmo evento para todas as redes. Por exemplo, ad_watched. Isso gera automaticamente o evento ad_watched_monetized contendo os detalhes da monetização Implementação mais simples Sem informações de qualidade, como o número de cliques e a receita de anúncios por rede
  • Mais adequado se o objetivo principal é encontrar fontes/campanhas que obtenham os usuários que possuem maior tendência a clicar em anúncios. 
  • Não é adequado para fazer a comparação entre o desempenho das redes de monetização.

(prática recomendada) Cada rede recebe um evento exclusivo para visualização de anúncios. Exemplo: ad_watch_admob,

 ad_watch_vungle.

 Visibilidade total e capacidade de comparar as redes de monetização no dashboard, além dos dados brutos. A receita de anúncios não é acumulada em um único evento. O número de eventos é equivalente ao número de redes Permite a comparação de redes de monetização no dashboard. A receita de anúncios é separada por rede usando um evento in-app por rede. 

Status e teste da API de receita de anúncios

  • O status operacional da integração da receita de anúncios fica disponível da seguinte forma:

    • Dashboard de controle de status da integração de receita de anúncios e custos: lista centralizada de parceiros para os quais a integração de receita de anúncios está habilitada para um ou mais aplicativos hospedados em sua conta. 
    • Alguns parceiros permitem que você teste a conexão da API. Quando disponível, um botão Testar conexão é exibido. mceclip0.png
    • Para verificar se a conexão da API é operacional:
    • Clique em Testar conexão. 
      A mensagem "Chave da API verificada" é exibida. Se esse não for o caso, siga as orientações de ação corretiva na tabela a seguir. 
Status Significado Observações/ação necessária
Chave de API verificada  Nenhuma
Credenciais inválidas.

Uma ou mais credenciais fornecidas estão incorretas.

 Obtenha as credenciais corretas do parceiro de receita de anúncios
Detalhes de configuração ausentes Um ou mais campos de credenciais estão incompletos Recupere as credenciais no dashboard do parceiro de receita de anúncios ou entre em contato com o parceiro e solicite as credenciais. 
Status da conexão da API de receita de anúncios

Dados de receita de anúncios

Os dados de receita de anúncios estão disponíveis por meio dos dashboards da AppsFlyer e relatórios de dados brutos.

Dados agregados de receita publicitária

A receita de anúncios mostra a qualidade dos usuários de diferentes fontes ao longo do tempo. À medida que os usuários continuam lançando o aplicativo e engajando com anúncios, o LTV aumenta.

Observação: pode haver discrepâncias entre os dados de receita de anúncios em diferentes dashboards e relatórios. Saiba mais. 

A atribuição de receita de anúncios está disponível da seguinte forma:

  • Baseado em LTV:
    • Dashboards: visão geral, eventos,
    • Relatórios LTV
    • Painel e relatórios de coorte
    • Master API
  • Baseado em atividades:
    • Dashboard: Atividade
    • Dados brutos de receita publicitária

Dashboard de visão geral - relatório de performance agregada

No dashboard de Visão geral:

  • Os valores, incluindo receita, são LTV. Consulte LTV vs. dados de atividade.
  • A coluna Receita inclui toda a receita, inclusive a receita de anúncios e de compras in-app.
  • Faça uma análise detalhada da hierarquia de anúncios (fonte de mídia, campanha, conjunto de anúncios, geolocalização) para visualizar os eventos monetizados no relatório.
Dashboard de eventos

No dashboard de Atividade:

  • Os valores, inclusive a receita, são baseados em dados de atividade. Consulte LTV vs. dados de atividade.
  • A média de ações por usuário indica a tendência dos usuários de interagir com os anúncios apresentados no aplicativo. 

Exemplos

Três usuários instalam um aplicativo em 31 de dezembro de 2017. Eles são atribuídos da seguinte forma:

  • Usuário A: rede A
  • Usuário B: rede B
  • Usuário C: orgânico

O aplicativo é integrado com cinco plataformas de monetização diferentes. Cada plataforma usa um evento in-app único no SDK da AppsFlyer, segundo mostram os dados abaixo:

  • Facebook Audience Network: fb_ad_view
  • Chartboost: chartboost_ad_view
  • Admob: admob_ad_view
  • Applovin: applovin_ad_view
  • IronSource: is_ad_view

Os usuários recebem anúncios quatro dias após a instalação, da seguinte forma:

Usuário

Rede de UA

fb_
ad_view

chartboost_
ad_view

admob_
ad_view

applovin_
ad_view

is_ad_view

Total

A

Rede A

31/12/2017

01/01/2018

US$1

02/01/2018

US$1

03/01/2018

US$1

04/01/2018

US$1

 

 US$4
 B

Rede B

31/12/2017

02/01/2018

US$1

 

04/01/2018

US$1

 

   US$2
 C

Orgânico

31/12/2017

01/01/2018

US$1

      

02/01/2018

US$1

US$2

Olhando para os dados, agora podemos resumir a receita coletada por usuário, por dia (e por evento in-app):

LTV do usuário

Usuário

01/01/2018

02/01/2018

03/01/2018

04/01/2018

LTV total
A

US$1

US$1

US$1

US$1

US$4
B   US$1   US$1 US$2
C US$1 US$1     US$2
Total US$2 US$3 US$1 US$2 US$8

Entendendo os relatórios:

Conforme mencionado, a receita de anúncios está vinculada ao LTV do usuário. Portanto, o período de tempo selecionado no dashboard representa o cohort de instalações para os quais a receita é agregada até a hora e o dia atuais. Vamos examinar um relatório com duas seleções de datas diferentes:

Relatório agregado: datas selecionadas: 31/12/2017-05/01/2018

Rede

Receita do LTV

Orgânico

US$2

Rede A

US$4

Rede B

US$2

Rede C

US$2

Nesse caso, o cohort são os usuários que instalaram o aplicativo de 31/12/2017 até o dia em questão, 05/01/2018. Toda a receita gerada por esses usuários está vinculada à fonte de aquisição e representada sob o LTV do usuário.

Dados brutos de receita publicitária

PremiumFeature.jpg

Os relatórios de dados brutos de receita publicitária contêm dados fornecidos por redes de monetização com integração de nível do usuário ou de impressão com a AppsFlyer. 

Princípios de dados brutos de receita de anúncios

  • Os dados são agregados pelo número de impressões exclusivas por usuário. Impressões exclusivas são derivadas da combinação de rede de monetização de anúncios, bloco de anúncios e posicionamento. 
  • Os dados brutos a nível de impressão são:
    • Agregados ao nível do usuário e disponíveis em relatórios de nível de usuário.
    • [Beta fechado] Disponível como em relatórios de nível de impressão no Data Locker.
    • Atualização de dados brutos é idêntica à da receita de anúncios a nível de usuário no dashboard de Atividade.
Relatório

Página de dados de exportação

 Pull API  Data Locker
Receita de anúncios atribuída (não-orgânica) ✓ ✓ ✓*
Receita publicitária orgânica ✓ ✓ ✓*
Receita de anúncios de retargeting  ✓ ✓ ✓*
Dados brutos em nível de impressão - - ✓ [Beta fechado]
* O relatório com versão controlada também está disponível, atualizado várias vezes por dia, com dados agregados no nível do dispositivo. Os relatórios do Data Locker sem versão controlada são diários.
 

Características e campos de dados

Os campos nos relatórios de receita de anúncios são preenchidos:

  • Pelo próprio evento de receita de anúncios, listado na tabela abaixo. Esses campos são divididos em:
    • Específico: campos específicos para a receita de anúncios. Por exemplo, impressões e posicionamento. Atenção! Os campos preenchidos diferem por parceiro de monetização, conforme mostrado na tabela Campos por rede nesta seção.
    • Contexto: campos com um significado semelhante em outros relatórios de dados brutos. Por exemplo, nome do evento, valor do evento, moeda. 
  • Como resultado da atribuição do evento à fonte de mídia que trouxe o usuário. Isso significa que esses campos são copiados do evento de conversão que trouxe o usuário. Por exemplo, fonte de mídia e campanha. Esses campos não estão listados na tabela a seguir. 
Campos preenchidos pela receita de anúncios
api_name Nome do campo Tipo de campo Descrição
event_time Data/hora do evento
Contexto		 A data à qual a receita é atribuída
event_name Nome do evento
Contexto
  • O padrão é definido para af_ad_revenue
  • Também pode ser um evento personalizado
event_revenue Moeda da receita do evento
Contexto
  • Valor da receita usando a moeda da receita do evento 
  • Um valor zero indica impressões sem receita
event_revenue_currency Moeda do evento
Contexto		 Moeda da receita do evento
 event_revenue_XXX Receita do evento XXX
Contexto
  • Na página de exportação: receita convertida para a moeda específica do aplicativo 
  • No Data Locker, é sempre em USD
  • Na Pull API, a moeda da receita é a mesma do Pull. 
país País


Contexto

 País de instalação da conversão de instalação
ad_unit

 Unidade do anúncio

Específico

Tipo de anúncio
segment Segment Específico Nome do posicionamento do anúncio
monetization_network Monetization network Específico Rede que envia o anúncio
Impressões Impressões Específico Número de vezes que o usuário viu o anúncio
mediation_network Mediation network Específico Rede de mediação que reporta o evento para a AppsFlyer
Campos por rede
Nome para exibição Admob ironSource AppLovin MAX Appodeal Fyber
Ad unit ✓ ✓ ✓ ✓ ✓
Segment - (1) - - -
Posicionamento - ✓ ✓ ✓ ✓
Monetization network ✓ ✓ - ✓ -
Impressões - - ✓ ✓ -
Mediation network - ✓ ✓ ✓ -
(1) O anunciante precisa configurar isso no ironSource

Atualização de dados

A atualização dos dados depende do tipo de integração e do método de relatório:

  • Para integrações da API S2S de nível agregado:
    • LTV e painéis e relatórios de atividades são Dia X+1, 14:00 UTC
  • Para integrações da API S2S de nível de usuário:
    • LTV e painéis e relatórios de atividades são Dia X+1, 14:00 UTC
    • Os relatórios de dados brutos são Dia X+1, 8 PM UTC
  • Para integrações do SDK de nível de impressão:
    • Painéis e relatórios LTV são Dia X+2, 5 AM UTC
    • [Painéis de atividades e relatórios são Dia X a partir das 5h UTC, atualizados a cada 4 horas.
    • Os relatórios de dados brutos são Dia X+1, 8 PM UTC
    • [Beta] Relatórios de dados brutos de nível de impressão (via Data Locker) são o Dia X a partir de 1 AM UTC, atualizados a cada hora.

Nos relatórios, a data do evento da receita publicitária é sempre o Dia X, ou seja, o dia em que o evento da receita publicitária ocorre (o dia em que o anúncio é exibido). Entretanto, os dados só podem ser exibidos 1 ou 2 dias após o evento (Dia X+1 ou Dia X+2).

Informações adicionais

Migrando de granularidade agregada para granularidade a nível de usuário

  • A migração não afeta os dados históricos de receita de anúncios. Esses dados permanecem inalterados.
  • Os dados de receita de anúncios são extraídos uma vez por dia às 14:00 UTC usando as opções de granularidade selecionadas nesse momento.
  • A granularidade a nível do usuário não exige que você defina eventos in-app (como você faz para relatórios a nível agregado). Você pode continuar enviando esses eventos, mas eles não afetam os relatórios de granularidade a nível do usuário na AppsFlyer.

Sinais de UA para ad networks

Pode ser que você queira trabalhar com ad networks que possam receber sinais da UA. Isto significa que as ad networks responsáveis pela aquisição de usuários podem receber dados das redes de mediação em relação à receita publicitária e utilizá-los para otimizar as campanhas dos UA de seus clientes. 

Para fornecer sinais às ad networks de UA, os parceiros de mediação devem ter integração de nível de impressão ou de nível de usuário.

Saiba mais sobre os sinais de UA

Lista de parceiros de mediação que podem enviar sinais de UA para ad networks de UA:

  • Applovin Max
  • Google AdMob
  • Appodeal
  • Chartboost
  • Fyber
  • Tapdaq
  • Topon
  • Unity
  • ironSource
  • Admost
  • Tradplusad
  • Yandex

 Lista de ad networks de UA que podem receber sinais de UA:

  • AdAction
  • Adamobi
  • Adjoe
  • Adonco
  • Adshow
  • Apprainbow
  • Aura
  • Betop
  • Bidswave
  • Brandscale
  • Chameleostudios
  • Chartboost
  • Datawave
  • DLab
  • Ecomonline
  • Etusdigital
  • Foregon
  • GNA Company
  • Happimobi
  • Hybrid
  • Inflecto
  • Irismedia
  • Lambadapp
  • Leadidadmonster
  • Lifestreet
  • Liftoff
  • Melodong
  • Mintegral
  • Mobrand
  • Moloco
  • Motive
  • Mpnd
  • Msla
  • Muvmobile
  • Nexamob
  • Nftdroper
  • Nsofmedia
  • Performadlive
  • Personalyrtb
  • Pitatroas
  • Rebornads
  • RTBhouse
  • Runfuns
  • Scmobi
  • Shalltry
  • Shareit
  • Smadex
  • Tapjoy
  • Targetmedia
  • Thepurpleline
  • Trademob
  • Truemoney
  • Unity Ads
  • Yandex
  • Yeahmobi
  • Z2A Digital
  • Zoyo

[Beta fechada] Postbacks de evento de receita publicitária para ad networks

Você pode configurar os postbacks de receita publicitária para ad networks. Isto significa que as ad networks responsáveis pela aquisição de usuários podem receber dados das redes de mediação em relação à receita publicitária e utilizá-los para otimizar as campanhas dos UA de seus clientes. 

Para enviar postbacks para ad networks de UA, é necessário ter uma integração em nível de impressão via SDK com a rede de mediação. A AppsFlyer gera automaticamente um evento af_ad_revenue por impressão. Esses eventos podem ser selecionados a partir da lista de eventos a serem enviados via postback para a ad networks UA.

Saiba mais sobre postbacks de eventos in-app

Lista de parceiros de mediação que podem enviar eventos de receita publicitária em nível de impressão para ad networks de UA:

  • Applovin Max
  • Google AdMob
  • Appodeal
  • Chartboost
  • Fyber
  • Tapdaq
  • Topon
  • Unity
  • ironSource
  • Admost
  • Tradplusad
  • Yandex

 Lista das ad networks de UA que podem receber postbacks de eventos de receita publicitária.

  • ironSource

FAQ

FAQ

Como posso obter a receita total de anúncios de cada plataforma?

  • A atribuição de receita de anúncios é vinculada e exibida em relação à fonte de aquisição de usuários.
  • Isso fornece a visão do LTV do seu ROI e KPIs.
  • Para visualizar a receita total de cada plataforma de monetização, use um evento in-app diferente para cada rede e siga o seguinte procedimento:
    1. No dashboard de Visão geral, acesse a tabela de relatório de performance agregada.
    2. Selecione até quatro eventos monetizados que representam as plataformas que você deseja consultar. 

      selecting_monetized_events.png

    3. Faça o download do relatório, clique em Exportar CSV.

    4. Resuma a coluna Receita do evento monetizado da plataforma solicitada

      revenue_sum_up.png

    Observação: essa receita de anúncios total são dados de LTV, ou seja, é toda a receita gerada por uma rede de monetização para o seu aplicativo vinda de usuários, que instalaram durante o período específico.

A receita de anúncios está disponível na página de atividades?

Sim. A página de Atividade relata a receita combinada de compras in-app e receita de anúncios. Observação: os dados de receita publicitária são enviados à AppsFlyer diariamente, no dia seguinte ao evento. 

Preciso ativar o parceiro na aba de Integração?

Se você engaja com o parceiro apenas para monetização de anúncios (receita de anúncios): não ative a opção Ativar parceiro na aba Integração.  Ative somente dados de Obter receita de anúncios na aba Receita de anúncios.

Como a receita de anúncios a nível do usuário é atribuída se um usuário tiver uma versão do aplicativo sem o SDK da AppsFlyer?

A receita de anúncios é atribuída como orgânica.

Há uma discrepância entre os dados de receita de anúncios em diferentes dashboards e relatórios? 

Podem haver discrepâncias entre os dados de receita de anúncios no dashboard de Visão geral e nos relatórios de dados brutos, além dos dashboards de Atividade e de Cohort. Isso ocorre porque: 

  • Os dados de receita publicitária nos painéis Coorte e Atividade, assim como os dados via Master API e Coorte API, são atualizados retroativamente; no painel Visão geral, e por meio da exportação de dados brutos e da Pull API, não é.
  • Às vezes, os dados são exibidos nos dashboards de Atividade e de Cohort antes de aparecerem no dashboard de Visão geral.
  • Os painéis incluem eventos marcados como af_ad_revenue e _monetized, enquanto os dados brutos incluem apenas eventos af_ad_revenue.

Características e limitações

Características e limitações da receita de anúncios
Característica Observações 
Acesso da ad network Não é possível acessar relatórios de Cohort
Acesso das agências

Agências:

  • Não é possível acessar as configurações da receita de anúncios
  • Pode ver todos os dashboards e dados relevantes para eles.
Transparência da agência Não suportado
Fuso horário

A receita publicitária é exibida em painéis e relatórios da AppsFlyer somente no fuso horário UTC. Ou seja, se os dados são reportados às 14h UTC+2, na AppsFlyer eles são exibidos como 14h UTC. processado diariamente.

Isto porque a AppsFlyer precisa normalizar os dados coletados de múltiplas fontes e parceiros, a maioria dos quais relata seus dados em UTC.
Moeda 

Na AppsFlyer:

  • O dashboard exibe a moeda específica do aplicativo do anunciante.
  • Os relatórios de dados brutos exibem a moeda original e também a convertem para a moeda específica do aplicativo do anunciante.
Limitações

Os eventos de receita de anúncios não estão disponíveis para:

  • Postback de evento in-app 
  • API de push
  • Painel de Retargeting

Limitações de granularidade a nível do usuário:
Tipo de dados Dados orgânicos e não-orgânicos são compatíveis.
Atualização de dados Receita de anúncios
Dados históricos/retroativos
  • Os dados são extraídos e ficam disponíveis a partir do dia da integração. Isso significa que dados históricos não ficam disponíveis antes da data da integração (dia 0).
  • Os dados de receita publicitária recebidos via API S2S para um dia específico são atualizados nos dias 1, 2, e 3.
  • Os dados de receita publicitária nos painéis Coorte e Atividade, assim como os dados via Master API e Coorte API, são atualizados retroativamente; no painel Visão geral, e por meio da exportação de dados brutos e da Pull API, não é. Se você tiver o pacote de receita avançada, os dados também são atualizados no Data Locker.
Acesso do usuário da conta Suportado
SKAN Compatível com conectores SDK de receita publicitária em nível de impressão.
Geolocalização/país No painel de Cooorte, quando a geolocalização é desconhecida (N/A), os dados marcados como N/A não são exibidos quando agregados pela geolocalização.

Lista de parceiros integrados de receita de anúncios

parceira Parâmetros de credenciais necessários Granularidade de dados

AdColony
  • chave de API
  • App ID
 Nível agregado com geolocalização

Admost
  • ID do aplicativo de rede
  • Token
 Nível do usuário com geolocalização

AppLovin
  • Chave de relatório
  • Nome do pacote do aplicativo
 Nível agregado com geolocalização

AppLovin MAX
  • Chave de relatório
  • Nome do pacote do aplicativo
 
  •  Nível do usuário com geolocalização
  • Nível de impressão (via SDK)

Appodeal
  • Chave do aplicativo
  • chave de API
  • ID do usuário
  • Nível agregado com geolocalização
  • Nível do usuário
Bytedance Ads - tráfego na China 
  • Chave de segurança
  • App ID
  • ID da conta
 Nível agregado com geolocalização
Chartboost
  • ID do usuário
  • Assinatura do usuário
  • App ID
 Nível agregado com geolocalização
Facebook
  • Login no Facebook
 Nível agregado com geolocalização
Fyber
  • Segredo do cliente
  • ID da API
  • ID do cliente
  • Nível de usuário com geolocalização 
  • Nível de impressão (via SDK)
Google Marketing Platform - DV360/CM (DoubleClick)
  • Login no Google Marketing Platform - DV360/CM
 Nível agregado com geolocalização
Google Admob
  • Id do aplicativo AdMob
  • Nível agregado com geolocalização
  • Nível de impressão (via SDK)
Google Ads
  • Autenticação de API por OAuth
 Nível agregado com geolocalização
IronSource
  • Chave secreta
  • Nome de usuário
  • App ID
  • Nível agregado com geolocalização
  • Nível do usuário
  • Nível de impressão (via SDK)

Mintegral
  • App ID
  • Chave secreta
  • Chave da API 
 Nível agregado com geolocalização

Tapjoy
  • App ID
  • Chave de Marketing API
 Nível do usuário com geolocalização

TikTok para Empresas
  • Chave de segurança
  • App ID
  • ID da conta

Nível agregado com geolocalização

TopOn
  • ID do aplicativo de rede
  • Chave do editor

Nível do usuário com geolocalização

Mediação Tradplus
  • chave de API
  • ID do aplicativo de rede

Nível do usuário com geolocalização

 

Unity Ads
  • chave de API
  • App ID
  • Nível agregado com geolocalização
  • Nível de impressão (via SDK)
Voodoo Ads
  •  ID do pacote
  • Token de acesso
 Nível agregado com geolocalização

Vungle
  • chave de API
  • App ID
 Nível agregado com geolocalização

Yandex

 N/D
  • Nível de impressão (via SDK)