Relatórios de dados brutos do Protect360

Visão geral: os relatórios de dados brutos descrevem instalações e eventos in-app bloqueados pelo mecanismo Protect360 e pelas Regras de Validação adicionadas manualmente.

Leitura relacionada: Visão geralDashboards|  Regras de validação

Sobre os relatórios de dados brutos do Protect360

Relatórios de dados brutos

  • Exibem dados sobre:
    • Cliques, instalações e eventos in-app identificados como fraudulentos pelo mecanismo do Protect360.
    • Instalações e eventos in-app identificados por meio de Regras de Validação.  
  • Incluem o motivo do bloqueio para cada clique, instalação ou evento in-app.  
  • São usados por anunciantes para reconciliar contas de ad networks, otimizar e ajustar dashboards de atribuição para fraudes pós-atribuição. 
  • Pode haver alguns campos restritos ou não disponíveisse a Privacidade Agregada Avançada da AppsFlyer (AAP).
  • Os tipos de relatório e sua disponibilidade para download, API e Data Locker (bucket S3) estão descritos nas seções a seguir.

Tipos de relatório

Tipos de relatório de dados brutos do Protect 360
Relatório Descrição
Instalações

Os relatórios incluem: 

  • Instalações falsas: instalações identificadas como fraudulentas pelo mecanismo do Protect360. Elas não aparecem em nenhum dashboard ou em dados brutos da AppsFlyer, exceto no dashboard e nos dados brutos do Protect360.
  • Hijacking de instalações: o usuário real instala no momento em que a atribuição é roubada, mas o Protect360 corrige a atribuição.
  • Regras de validação: a instalação foi bloqueada ou a atribuição foi bloqueada (o Protect360 corrige a atribuição). 
Instalações pós-atribuição

Os relatórios incluem instalações atribuídas a uma fonte de mídia, mas posteriormente classificadas como fraudulentas.O Protect360 corrige a atribuição.

Eventos in-app bloqueados

Os relatórios incluem eventos in-app de:

  • Instalações falsas: IAEs são bloqueados.
  • Instalações que sofreram hijacking
    • Nos relatórios de eventos in-app do Protect360, a fonte de mídia fraudulenta é exibida.
    • Nos relatórios de dados brutos de eventos in-app regulares, a fonte de mídia correta é exibida. 
  • Eventos in-app: identificados como fraudulentos independentemente das instalações originais.
  • Regras de validação:
    • IAEs de uma regra que bloqueou a instalação ou bloqueou a atribuição.
    • IAEs de uma regra que bloqueou o evento in-app. 
Eventos in-app de pós-atribuição

Os relatórios incluem eventos in-app:

  • Identificado após a atribuição.
  • De instalações atribuídas a uma fonte de mídia, mas posteriormente classificadas como fraudulentas. 
Cliques Os relatórios incluem cliques bloqueados com os motivos do bloqueio.
Postbacks de instalação bloqueados Os relatórios incluem cópias dos postbacks de rejeição enviados para fontes de mídia responsáveis por instalações bloqueadas.

Relatórios pós-atribuição:

  • Os relatórios raw data de fraude pós-atribuição têm a mesma estrutura dos relatórios de fraudes bloqueadas.
  • O relatório pós-atribuição do mês atual (por data de instalação) continua sendo atualizado até o sétimo dia do mês seguinte (data de detecção). 
  • Os relatórios de dados brutos pós-atribuição são limitados aos anunciantes. As agências precisam de permissões habilitadas para acessar.
  • Os relatórios contêm eventos de fraude pós-atribuição identificados pelo Protect360 e incluem todas as fontes de mídia em um único relatório.
  • Os relatórios de fraude de dados brutos pós-atribuição estão disponíveis da seguinte maneira:

    • Interface do usuário do dashboard: limitada a uma fonte de mídia durante um mês.
    • Pull API: possui todas as fonte de mídia. (Limitação: disponível apenas para proprietários do aplicativo)

Usando relatórios de pós-atribuição

  • Selecione qualquer combinação de instalação/IAE e detecte intervalos de datas conforme necessário.
  • Leve em consideração que o Protect360 executa a detecção pós-atribuição durante o mês civil do calendário da instalação e até o sétimo dia do mês seguinte. Isso significa, por exemplo, que para instalações feitas em novembro, o Protect360 verifica fraudes até o dia 7 de dezembro. 
  • Melhores práticas para usar esta Pull API:
    • Suponha que você gera o relatório diariamente. 
    • Defina o período de instalação para 60 dias a partir do dia atual.
    • Defina o intervalo detectar de/detectar até para o dia anterior ao dia atual.Isso significa que você receberá a lista de fraudes pós-atribuição detectadas ontem. Se você não gerou o relatório por alguns dias, ajuste o período de detecção e gere o relatório. 

Exemplo

Exemplo A: Em (data da instalação) de dezembro, 15 instalações foram atribuídas a example_media . No dia 3 de janeiro (data de detecção), o Protect360 identificou  example_media como fraudador. Consequentemente, as 15 instalações atribuídas a example_media  aparecem como fraudulentas no relatório de fraude pós-atribuição para que o proprietário do aplicativo tome as medidas necessárias. 

Exemplo B: Em dezembro, 15 instalações foram atribuídas a example_media. No dia 9 de janeiro, o Protect360 identificou example_media  como fraudador. Nesse caso, nenhuma ação é tomada pelo Protect360 porque o fraudador foi identificado após o fechamento do mês, em 7 de janeiro.  

Disponibilidade de dados brutos por tipo de ferramenta

Dados brutos do Protect360 disponíveis por tipo de ferramenta
Relatório Atualização de dados Pull API Página de Exportar Dados Data Locker
Instalações em tempo real ✓*
Eventos in-app bloqueados em tempo real
Cliques em tempo real
Postbacks de instalação bloqueados em tempo real - -
Instalações pós-atribuição

Diariamente, às 10:00 UTC

✓*
Eventos in-app de pós-atribuição

Diariamente, às 10:00 UTC

-

* Limitações para reportar via Data Locker:

  • Transparência da agência não suportada. O que significa que o tráfego conduzido por agência não contém o nome da fonte de mídia que envia a instalação. 
  • O relatório tem um conjunto exclusivo de campos em relação a outros relatórios do Data Locker. Essa lista não pode ser alterada. 
  • Os dados de redirecionamento não estão disponíveis no relatório de Instalações; somente no relatório de Instalações pós-atribuição. 

Obtendo relatórios de dados brutos

Os relatórios de dados brutos estão disponíveis através de download, Pull API e Data Locker (S3 bucket). Você também pode dar acesso aos relatórios para parceiros.

Baixar

Para fazer o download:

  1. No dashboard do Protect360, acesse Relatórios de dados brutos > Bloqueados ou Pós-atribuição.
    • Para relatórios pós-atribuição, selecione a fonte de mídia e o mês.
  2. Selecione o relatório do Protect360 e Regras de Validação para fazer o download.

OU

  1. No dashboard da AppsFlyer, vá para Exportar dados
  2. Selecione o relatório do Protect360 e Regras de Validação para fazer o download.

Observação: os relatórios baixados da página Exportar Dados contêm todas as fontes de mídia.

Pull API

Para fazer download dos relatórios de dados brutos disponíveis por Pull API:

Antes de começar:

Você precisará de um token da Pull API. Obtenha o token com o administrador

  1. Acesse Integração > Acesso à API.
    A página da Pull API é aberta.
  2. Na seção Relatórios de fraude do Protect360, selecione a chamada necessária da Pull API.
  3. Preencha os parâmetros conforme necessário. A tabela a seguir lista os parâmetros.
  4. Puxe o relatório. 
Parâmetros do relatório de dados brutos da Pull API
Parâmetro Descrição Formato Obrigatório
app_id  ID do aplicativo como aparece na AppsFlyer Sequência de caracteres Sim
api_token Recupere a chave do painel. Acesse Integração > Acesso à API.
Somente o administrador da conta pode recuperar o token da API.
Sequência de caracteres Sim
a partir de

Início do intervalo de datas:

  • Para instalações, esta é a data da instalação.
  • Para eventos in-app, esta é a data do evento.
DD-MM-AAAA Sim
até

Fim do intervalo de datas:

  • Para instalações, esta é a data da instalação.
  • Para eventos in-app, esta é a data do evento.
DD-MM-AAAA Sim
event_name

[Opcional para fraudes de eventos in-app pós-atribuição]

Filtrar eventos por evento in-app. Limite o relatório a eventos específicos.  Um ou mais eventos podem ser incluídos.

Exemplo de uso: &event_name=af_purchase,af_login

Sequência de caracteres

Não

 

additional_fields=rejected_reason_value

[Opcional para fraudes de eventos in-app pós-atribuição]

rejected_reason_value exibe o colaborador válido (fonte de mídia) para hijacking de instalações/eventos in-app. Preenchido com contributor[1-3] ou orgânico.

Sequência de caracteres

Não

detect-from

[Opcional para instalações pós-atribuição]

Início do intervalo de datas de detecção de fraudes. (O padrão é from.) (Usado em fraudes de instalação pós-atribuição.) (Usado em fraudes de instalação pós-atribuição.)

DD-MM-AAAA Não
detect-to

[Opcional para instalações pós-atribuição]

Fim do intervalo de datas de detecção de fraudes. (O padrão é to.)

DD-MM-AAAA Não

Estrutura dos relatórios do Protect360

Os relatórios do Protect360 têm a mesma estrutura geral que os campos de relatórios de aquisição de usuários.

Além dos campos de relatório de dados brutos regulares, os relatórios do Protect360 também têm campos de retargeting e motivo do bloqueio, como:

Motivos do bloqueio

Click level blocked reasons 

No nível de clique, os cliques são bloqueados e o processo de atribuição os ignora.

Motivo Bloqueado Descrição
ip_blacklist Com base em uma lista criada dinamicamente (detalhes)
invalid_fingerprint Apenas cliques S2S: parâmetros inválidos foram enviados pela fonte (para correspondência probabilística)
click_capping Taxas extremamente altas de fraude de cliques foram detectadas nessa ad network. Saiba mais
click_signing A assinatura no clique não foi validada. Saiba mais

Motivos bloqueados a nível de instalação

No nível da instalação, identificamos informações suficientes no momento da instalação para determinar se:

  • Há uma instalação falsa, o que significa que o usuário que instalou o aplicativo não é uma pessoa real. Nesse caso, a atribuição é completamente bloqueada.
  • Hijacking de atribuição, em que o usuário é real, mas o engajamento é falsificado. Nesse caso, o engajamento fraudulento é bloqueado e a atribuição é reatribuída à primeira ad network contribuinte válida.

As tabelas a seguir listam possíveis motivos de bloqueio a nível de instalação:

Nível de instalação: motivos de bloqueios de instalação falsa
Motivo Bloqueado Sub-motivo Bloqueado Descrição
Bots fake_device_parameters Comportamento não humano detectado em parâmetros relacionados ao dispositivo durante o processo de instalação do aplicativo
Bots fake_install_parameters Comportamento não humano detectado em parâmetros relacionados à instalação durante o processo de instalação do aplicativo
Bots bayesian_network Identificação da rede bayesiana de padrões fraudulentos
install_store_validation -

Falha na validação de recebimento de instalação da Apple App Store

validation_bots invalid_device_parameters Incompatibilidade de expectativa de campos específicos do dispositivo - definida pelo cliente
validation_bots validation_rules

Regras em que o resultado são instalações bloqueadas com base na regra de validação definida manualmente

Nível de instalação: motivos do bloqueio de hijacking da atribuição
Motivo Bloqueado Sub-motivo Bloqueado Descrição

ctit_anomalies

short_ctit

Instalação bloqueada devido ao CTIT curto: definido pelo Protect360

install_hijacking

referrer_hijack

Tentativa de hijacking bloqueada com base nos parâmetros da API do GooglePlay e do SDK da AppsFlyer

install_hijacking

integration_temporarily_blocked

Instalação bloqueada porque o parceiro (pid) tem taxas de fraude extremamente altas e anomalias significativas em todo o seu tráfego

validation_hijacking

short_ctit

Instalação bloqueada devido ao CTIT curto: definido pelo cliente

validation_hijacking

empty_site_id

Instalação bloqueada devido ao não preenchimento do ID do site. A implementação da regra é faseada 

validation_hijacking

validation_rules

Regras em que o resultado é atribuição bloqueada com base na regra de validação definida manualmente

Motivos de bloqueio a nível de cluster

Quando um padrão de fraude é detectado, a fonte de fraude é colocada na denylist. Instalações dessa fonte de denylist são bloqueadas devido a:

  • Há uma instalação falsa, o que significa que o usuário que instalou o aplicativo não é uma pessoa real. Nesse caso, a atribuição é completamente bloqueada.
  • Há hijacking de atribuição, no qual o usuário é real, mas o engajamento é falsificado. Nesse caso, o engajamento fraudulento é bloqueado e a atribuição é reatribuída à primeira rede de anúncios contribuinte válida.

As tabelas a seguir listam possíveis motivos de bloqueio a nível de cluster:

Nível de cluster: motivos do bloqueio de instalação falsa
Motivo Bloqueado Sub-motivo Bloqueado Descrição
Bots timestamp_anomalies Anomalias relacionadas aos tempos de clique no fluxo de atribuição e outros carimbos de data/hora coletados no dispositivo
bots, site_blacklist device_emulators Instalações geradas em larga escala por scripts automáticos trabalhando em ambientes virtuais.
site_blacklist device_farms Altas taxas de (novos) dispositivos desconhecidos
behavioral_anomalies behavioral_anomalies Comportamento in-app suspeito comparado ao padrão de comportamento do usuário comum do aplicativo
Nível do cluster: motivos do bloqueio do hijacking de atribuição
Motivo Bloqueado Sub-motivo Bloqueado Descrição
ctit_anomalies, install_hijacking ctit_anomalies Padrão CTIT anormal segundo os padrões do aplicativo
click_flood click_flood Volume de cliques anormalmente alto na distribuição de CTIT longo
install_hijacking click_clusters Cliques gerados por um malware a nível do dispositivo

Motivos de bloqueio no nível do aplicativo 

Eventos in-app podem ser bloqueados pelas seguintes razões:

  • A instalação inicial foi identificada como falsa.
  • Devido a uma regra de validação definida.
  • Porque nosso algoritmo detectou fraudes. 

A tabela a seguir lista possíveis motivos de bloqueio a nível do aplicativo:

Motivos de bloqueio a nível do aplicativo
Motivo Bloqueado Sub-motivo Bloqueado Descrição
Herdado da instalação Herdado da instalação Instalação inicial identificada como falsa com base no motivo no nível de instalação ou denylist
inapps_bots fake_device_parameters O algoritmo da AppsFlyer detecta fraudes
in_app_store_validation - Há uma falha na validação de recebimento para compras in-app. 
validation_inapps validation_rules

Com base na regra de validação definida manualmente

Retargeting

Dados brutos do Protect360 incluem instalações e sessões fraudulentas de campanhas de retargeting (conhecidas como reatribuições e reengajamentos, respectivamente). Os dados são exibidos usando os campos nome do evento e tipo de conversão de retargeting. Eles são marcados como:

  • Instalação (aplica-se ao nome do evento, mas não ao tipo de conversão de retargeting)
  • Reatribuição
  • REENGAJAMENTO
  • Reinstalação

Os dados brutos de retargeting do Protect360 estão disponíveis em blocos em tempo real e fraude identificada pós-atribuição da seguinte forma:

Relatório  Dados de exportação Pull API Data Locker
Instalações ✓* ✓* -
Instalações pós-atribuição
* Dados de reengajamento não disponíveis

Correção de atribuição de instalações com hijacking

Para hijacking de instalações, a AppsFlyer bloqueia a atribuição à ad network fraudulenta e, em vez disso, a atribui à última fonte contribuinte legítima. 

Para hijacking de instalaçõesuse ocamporejected_reason_valuepara identificar ocolaborador válido (fonte de mídia), ou seja, o colaborador que deveria ter recebido originalmente a atribuição.

  • O rejected_reason_value é preenchido com colaborador [1-3] ou orgânico. Verifique os campos de fonte de mídia/parceiro do colaborador [1-3] para visualizar os detalhes do colaborador e reconciliar.
  • Se os campos de colaborador não forem exibidos em seu relatório, eles estarão disponíveis para serem adicionados na página Exportar dados.

Observação: quando o hijacking de instalações é bloqueado em tempo real, as atribuições corretas são exibidas nos dashboards e relatórios da AppsFlyer (não apenas no Protect360). Quando o hijacking de instalações é identificado após a atribuição, as atribuições corretas são exibidas apenas em dados brutos do Protect360. 

Este artigo foi útil?