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

  • Os relatórios de dados brutos são divididos da seguinte forma:
    • Relatórios bloqueados: instalações, cliques e eventos in-app de usuários cuja instalação/atribuição foi bloqueada e não foi atribuída a nenhuma fonte de mídia. 
    • Relatórios pós-atribuição:
      • Instalações atribuídas a uma fonte de mídia, mas posteriormente detectadas como fraudulentas. 
      • Eventos in-app de instalações identificadas como fraude após serem atribuídas a uma fonte de mídia.
      • Eventos in-app considerados fraudulentos, sem levar em conta a instalação em si.
  • Os anunciantes usam esses relatórios para reconciliar contas de redes de anúncios, otimizar e ajustar dashboards de atribuição para fraudes pós-atribuição.  
  • Os dados brutos estão disponíveis através de download, API e Data Locker (bucket S3) conforme descrito na tabela a seguir.
Dados brutos do Protect360 disponíveis por tipo de ferramenta
Tópico do relatório Atualização de dados Descrição Pull API Página de Exportar Dados Data Locker
Instalações em tempo real Instalações bloqueadas com o motivo do bloqueio
Eventos in-app em tempo real Eventos in-app bloqueados com o motivo do bloqueio
Cliques em tempo real Cliques realizados por usuários bloqueados
Postbacks de instalação bloqueados em tempo real Postback para a fonte de mídia que possui instalações bloqueadas - -
Instalações pós-atribuição

Diariamente, às 10:00 UTC

Instalações identificadas como pós-atribuição fraudulenta. 

O relatório pode ser filtrado opcionalmente segundo a data de detecção, como está descrito na seção a seguir. 

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

Diariamente, às 10:00 UTC

  • Eventos in-app realizados por instalações identificadas como fraudulentas.
  • Qualquer outro evento no aplicativo classificado como fraudulento, independente da instalação.

O relatório pode ser filtrado opcionalmente por tipo de evento no aplicativo, conforme descrito na tabela de parâmetros a seguir. 

-

* Limitações para reportar via Data Locker:

  • Não há suporte para a transparência da agência. O que significa que o tráfego conduzido pela agência não contém o nome da fonte de mídia repsonsável pelo envio da instalação. 
  • O relatório tem um conjunto exclusivo de campos em relação a outros relatórios de armazenamento de dados. Esta lista não pode ser alterada. 

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:

  • 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.

OU

  • Acesse a página Dados de exportação
    Observação: os relatórios baixados da página Dados de exportação 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

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

Sobre 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.
  • Para hijacking de instalações/IAEs, use o campo rejected_reason_value para identificar o colaborador válido (fonte de mídia), ou seja, o colaborador que originalmente deveria ter recebido a atribuição.
    O rejected_reason_value é preenchido com contributor[1-3] ou orgânico. Verifique os campos contributor[1-3] para visualizar os detalhes do colaborador e fazer a correspondência.
  • 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.  

Estrutura dos relatórios do Protect360

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

Além dos campos de relatório de dados brutos regulares, os relatórios do Protect360 têm os seguintes campos:

  • Motivo Bloqueado
  • Sub-motivo Bloqueado
  • Valor de Motivo Bloqueado
  • Regra de Motivo Bloqueado

Motivos de bloqueio do Protect360

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)
install_store_validation A discrepância entre os valores do Google Referrer da instalação
invalid_fingerprint Apenas cliques S2S: parâmetros inválidos enviados pela fonte (para correspondência probabilística)

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.
  • 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 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
validation_bots invalid_sdk Instalações com versões desatualizadas ou não utilizadas do SDK - definidas pelo cliente
validation_bots invalid_device_parameters Incompatibilidade de expectativa de campos específicos do dispositivo - definida pelo cliente
validation_bots invalid_app_version Instalações com versões desatualizadas ou não utilizadas do aplicativo - definidas 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
validation_inapps invalid_event_name Com base na regra de validação solicitada ou definida manualmente
validation_inapps invalid_event_source Com base na regra de validação solicitada ou definida manualmente
validation_inapps invalid_event_value Com base na regra de validação solicitada ou definida manualmente
validation_inapps validation_rules

Com base na regra de validação definida manualmente

Este artigo foi útil?