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.
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 por download, API e Data Locker (bucket S3) são descritos nas seções a seguir.
- A retenção do relatório de dados brutos históricos é de até 90 dias, dependendo da ferramenta de relatório e da origem dos dados brutos.
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 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:
|
| Eventos in-app de pós-atribuição |
Os relatórios incluem eventos in-app:
|
| 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. Observação: se nenhum evento de fraude de pós-atribuição for identificado para o intervalo de datas selecionado, o relatório retornará vazio,
-
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:
- Supondo que você gere 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:
|
||||
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.
- Selecione o relatório do Protect360 e Regras de Validação para fazer o download.
OU
- No dashboard da AppsFlyer, vá para Exportar dados.
- 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. Peça o token de um usuário administrador.
- Acesse Integração > Acesso à API.
A página da Pull API é aberta. - Na seção Relatórios de fraude do Protect360, selecione a chamada necessária da Pull API.
- Preencha os parâmetros conforme necessário. A tabela a seguir lista os parâmetros.
- 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 um usuário administrador pode recuperar o token da API. | Sequência de caracteres | Sim |
| a partir de |
Início do intervalo de datas:
|
DD-MM-AAAA | Sim |
| até |
Fim do intervalo de datas:
|
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: |
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 |
Data Locker
OData Locker re dados brutos em um bucket AWS S3.
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 |
| input_validation | Nome do canal de mídia inválido |
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.