Visão geral: Os relatórios de dados brutos descrevem as instalações e os eventos na aplicação bloqueados pelo motor Protect360, assim como as regras de validação adicionadas manualmente.
Sobre os relatórios de dados brutos do Protect360
Relatórios de dados brutos:
- Apresentam dados sobre:
- Cliques, instalações, e eventos na aplicação identificados como fraudulentos pelo motor Protect360.
- Instalações e eventos na aplicação identificados através de regras de validação.
- Incluir a razão do bloqueio para cada clique, instalação ou evento na aplicação.
- São usados pelos anunciantes para reconciliar contas de redes de publicidade, otimizar e ajustar painéis de atribuição para fraudes pós-atribuição.
- Podem ter alguns campos restritos ou indisponíveis se Privacidade Avançada Agregada (AAP) da AppsFlyer.
- Os tipos de relatórios e a sua disponibilidade para download, API, e Data Locker (bucket S3) são descritos nas secções seguintes.
- A retenção de relatórios históricos de dados brutos é de até 90 dias, dependendo da ferramenta de relatório e da origem dos dados brutos.
Nota
Devido a restrições nos dados brutos relacionadas com a privacidade, os relatórios podem apresentar campos com valores vazios. Um exemplo disso são os campos de contribuidor.
Tipos de relatório
Tipos de relatório de dados brutos do Protect360
| 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 media, mas posteriormente identificadas como fraudulentas. O Protect360 corrige a atribuição. |
| Eventos na aplicação bloqueados |
Os relatórios incluem eventos na aplicação de:
|
| Eventos in-app pós-atribuição |
Os relatórios incluem eventos in-app:
|
| Cliques | Os relatórios incluem cliques bloqueados com os respetivos motivos. |
| Postbacks de instalação bloqueados | Os relatórios incluem cópias dos postbacks de rejeição enviados para fontes de mídia que registaram instalações bloqueadas. |
Relatórios pós-atribuição
- Os relatórios de fraude de dados brutos pós-atribuição têm a mesma estrutura dos relatórios de fraude bloqueada.
- O relatório pós-atribuição do mês atual (pela data de instalação) continua a ser atualizado até ao sétimo dia do mês seguinte (data de deteção).
- Os relatórios de dados brutos pós-atribuição estão disponíveis apenas para anunciantes. As agências necessitam de permissões ativadas para aceder.
- Os relatórios incluem eventos de fraude pós-atribuição identificados pelo Protect360 e abrangem todas as fontes de mídia num único relatório. Nota: Se não forem identificados eventos de fraude pós-atribuição para o intervalo de datas selecionado, o relatório será devolvido vazio,
-
Os relatórios de fraude de dados brutos pós-atribuição estão disponíveis da seguinte forma:
- Interface do utilizador do painel: limitada a uma fonte de mídia por um mês de calendário.
- API Pull: inclui todas as fontes de mídia. (Limitação: Disponível apenas para proprietários de aplicações.)
Utilização de relatórios pós-atribuição
- Selecione qualquer combinação de intervalos de datas de instalação/IAE e deteção conforme necessário.
- Tenha em conta que o Protect360 realiza a deteção pós-atribuição durante o mês da instalação e até ao sétimo dia do mês seguinte. Isto significa, por exemplo, que para instalações em novembro, o Protect360 verifica fraudes até 7 de dezembro.
- A prática recomendada para utilizar esta API Pull é a seguinte:
- Suponha que obtém o relatório diariamente.
- Defina o intervalo de datas de instalação para os 60 dias anteriores ao dia atual.
- Defina o intervalo de deteção para a data anterior ao dia atual.
Isso significa que receberá a lista das fraudes pós-atribuição detetadas ontem. Se não tiver extraído o relatório durante alguns dias, ajuste o intervalo de datas de deteção e extraia o relatório.
Exemplo
Exemplo A: Durante dezembro, 15 instalações são atribuídas à example_media. A 3 de janeiro, o Protect360 identifica a example_media como uma fraude. Como resultado, as 15 instalações atribuídas à example_media são listadas como fraudulentas no relatório de fraude pós-atribuição, para ação adicional por parte do proprietário da aplicação.
Exemplo B: Durante o mês de dezembro, foram atribuídas 15 instalações à example_media. A 9 de janeiro, o Protect360 identifica a example_media como uma fraude. Neste caso, não será tomada qualquer ação pelo Protect360 porque a fraude foi identificada após o fecho do mês, a 7 de janeiro.
Disponibilidade de dados brutos por tipo de ferramenta
Disponibilidade de dados brutos do Protect360 por tipo de ferramenta
| Relatório | Relevância dos dados | Extrair API | Página de Exportação de Dados | Armazenamento de dados |
|---|---|---|---|---|
| Instalações | Em tempo real | ✓ | ✓ | ✓* |
| Eventos na aplicação bloqueados | Em tempo real | ✓ | ✓ | ✓ |
| Cliques | Em tempo real | ✓ | ✓ | ✓ |
| Postbacks de instalação bloqueados | Em tempo real | - | ✓ | - |
| Instalações pós-atribuição |
Diariamente às 10h00 UTC |
✓ |
✓ | ✓* |
| Eventos in-app pós-atribuição |
Diariamente às 10h00 UTC |
✓ | ✓ | - |
|
* Limitações para relatórios via Data Locker:
|
||||
Obtenção de relatórios de dados brutos
Os relatórios de dados brutos estão disponíveis por download, Pull API e Data Locker (bucket S3). Pode também dar acesso aos parceiros aos relatórios.
Transferir
Para fazer download:
- No painel do Protect360, aceda a Relatórios de dados brutos > Bloqueados ou Pós-atribuição.
- Para relatórios pós-atribuição, escolha a fonte de mídia e o mês.
- Selecione o relatório Protect360 e Regras de Validação para descarregar.
OU
- No painel da AppsFlyer, vá a Exportar Dados.
- Selecione o relatório Protect360 e Regras de Validação para descarregar.
Nota: Os relatórios descarregados da página Exportar Dados incluem todas as fontes de mídia.
Extrair API
Para descarregar os relatórios de dados brutos disponíveis via Pull API:
Antes de começar:
É necessário um token Pull API. Obtenha o token de um utilizador administrador.
- Vá a Relatório > Acesso à API.
A página da API Pull abre-se. - Na secção de relatórios de fraude do Protect360, escolha a chamada Pull API necessária.
- Preencha os parâmetros conforme necessário. A tabela seguinte apresenta os parâmetros.
- Extraia o relatório.
Parâmetros do relatório de dados brutos da API Pull
| Parâmetro | Descrição | Formato | Obrigatório |
|---|---|---|---|
| ID_da_aplicação | ID da aplicação conforme aparece na AppsFlyer | Texto | Sim |
| api_token | Recupere a chave do painel. Vá a Relatório > Acesso à API. Somente um utilizador administrador pode recuperar o token API. | Texto | Sim |
| de |
Início do intervalo de datas:
|
AAAA-MM-DD | Sim |
| para |
Fim do intervalo de datas:
|
AAAA-MM-DD | Sim |
| nome_do_evento |
[Opcional para fraude de eventos na app pós-atribuição] Filtrar eventos por eventos na aplicação. Restringa o relatório a eventos específicos. Pode incluir um ou mais eventos. Exemplo de uso: |
Texto |
Não
|
| campos_adicionais=valor_motivo_rejeitado |
[Opcional para fraude de eventos na app pós-atribuição] rejected_reason_value exibe o contribuinte válido (fonte de mídia) para instalações ou eventos na app que foram sequestrados. Preenchido com contributor[1-3] ou orgânico. |
Texto |
Não |
| detetar de |
[Opcional para instalações pós-atribuição] Início do intervalo de datas para deteção de fraude. (O padrão é começar de.) (Usado em fraude de instalação pós-atribuição.) |
AAAA-MM-DD | Não |
| detetar até |
[Opcional para instalações pós-atribuição] Fim do intervalo de datas para deteção de fraude. (O padrão é finalizar em.) |
AAAA-MM-DD | Não |
Armazenamento de dados
O Data Locker grava dados brutos num bucket AWS S3.
Estrutura do relatório Protect360
Os relatórios do Protect360 têm a mesma estrutura geral que os campos dos relatórios de aquisição de utilizadores.
Para além dos campos normais do relatório de dados brutos, os relatórios do Protect360 também incluem campos para retargeting e motivos de bloqueio, conforme apresentado a seguir:
Razões para bloqueio
Razões para bloqueio ao nível de clique
Ao nível de clique, os cliques são bloqueados e o processo de atribuição ignora-os.
| Motivo do bloqueio | Descrição |
|---|---|
| ip_lista negra | Baseado numa lista criada dinamicamente (detalhes) |
| impressão digital_inválida | Apenas cliques S2S: Parâmetros inválidos são enviados pela origem (para correspondência probabilística) |
| limitação_de_cliques | Foram detetadas taxas extremamente elevadas de fraude de cliques nessa rede de publicidade. Saiba mais |
| assinatura de clique | A assinatura do clique não é validada. Saiba mais |
| validação_de_entrada | Nome da fonte de media inválido |
Razões para bloqueio ao nível de instalação
Ao nível de instalação, conseguimos identificar informações suficientes no momento da instalação para determinar:
- Uma instalação falsa, significando que o utilizador que instala a aplicação não é uma pessoa real. Nesse caso, a atribuição é completamente bloqueada.
- Roubo de atribuição, onde o utilizador é real, mas o envolvimento é falsificado. Nesse caso, o envolvimento fraudulento é bloqueado e a atribuição é reatribuída à primeira rede de publicidade válida que contribuiu.
As tabelas seguintes listam as possíveis razões de bloqueio ao nível de instalação:
Nível de instalação: Razões secundárias para bloqueio de instalações falsas
| Motivo do bloqueio | Submotivo do bloqueio | Descrição |
|---|---|---|
| bots | parâmetros_de_dispositivo_falsos | Comportamento não humano detetado em parâmetros relacionados com o dispositivo durante o processo de instalação da aplicação |
| bots | parâmetros_instalação_falsa | Comportamento não humano detetado nos parâmetros relacionados com a instalação durante o processo de instalação da aplicação |
| bots | rede_bayesiana | Identificação de padrões fraudulentos através de redes bayesianas |
| validação_loja_instalação | - |
Falha na validação do recibo de instalação da Apple App Store |
| validação_robôs | parâmetros_de_dispositivo_inválidos | Incompatibilidade de expectativas em campos específicos do dispositivo - definido pelo cliente |
| validação_robôs | regras_de_validação |
Regras onde o resultado são instalações bloqueadas com base em regras de validação definidas manualmente |
| bots | ai_layer |
Modelos de IA são usados para analisar grandes volumes de dados, aprimorando as capacidades de detecção para identificar atividades fraudulentas em dispositivos e instalações. |
Nível de instalação: Motivos secundários para bloqueios de sequestro de atribuição
| Motivo do bloqueio | Submotivo do bloqueio | Descrição |
|---|---|---|
|
anomalias_ctit |
ctit_curto |
Instalação bloqueada devido a CTIT curto: Definido pelo Protect360 |
|
sequestro_de_instalação |
sequestro_de_referenciador |
Tentativa de sequestro bloqueada com base nos parâmetros da API do GooglePlay e do SDK da AppsFlyer |
|
sequestro_de_instalação |
integração_temporariamente_bloqueada |
Instalação bloqueada porque o parceiro (pid) apresenta taxas de fraude extremamente altas e anomalias significativas em todo o tráfego |
|
sequestro_de_validação |
ctit_curto |
Instalação bloqueada devido a CTIT curto: Definido pelo cliente |
|
sequestro_de_validação |
site_id_vazio |
Instalação bloqueada devido a ID do site não preenchido. A implementação da regra ocorre por fases |
|
sequestro_de_validação |
regras_de_validação |
Regras em que o resultado é atribuição bloqueada com base em uma regra de validação definida manualmente |
Razões de bloqueio ao nível do cluster
Quando se deteta um padrão de fraude, a fonte da fraude é colocada na lista de exclusões. As instalações provenientes desta lista de exclusão são bloqueadas devido a:
- Uma instalação falsa, significando que o utilizador que instala a aplicação não é uma pessoa real. Nesse caso, a atribuição é completamente bloqueada.
- Roubo de atribuição, onde o utilizador é real, mas o envolvimento é falsificado. Neste caso, o engajamento fraudulento é bloqueado e a atribuição é reatribuída à primeira rede de anúncios válida.
As tabelas seguintes apresentam possíveis razões para bloqueios ao nível do cluster:
Nível de cluster: Motivos de bloqueio de instalação falsa
| Motivo do bloqueio | Submotivo do bloqueio | Descrição |
|---|---|---|
| bots | anomalias_temporais | Anomalias relacionadas com tempos de clique no fluxo de atribuição e outros registros de data e hora obtidos do dispositivo |
| bots, lista_negra_de_sites | emuladores_de_dispositivos | Instalações geradas em larga escala por scripts automáticos em ambientes virtuais |
| lista_negra_de_sites | fazendas_de_dispositivos | Altas taxas de dispositivos desconhecidos (novos) |
| anomalias_comportamentais | anomalias_comportamentais | Comportamento suspeito dentro da aplicação em comparação com o padrão comum de comportamento do utilizador da aplicação |
Nível de cluster: Razões para bloqueio de sequestro de atribuição
| Motivo do bloqueio | Submotivo do bloqueio | Descrição |
|---|---|---|
| anomalias_ctit, sequestro_de_instalação | anomalias_ctit | Padrão de CTIT anormal em relação aos padrões da aplicação |
| inundação_de_cliques | inundação_de_cliques | Volume de cliques anormalmente alto em distribuições de CTIT longas |
| sequestro_de_instalação | aglomerados_de_cliques | Cliques gerados por malware a nível do dispositivo |
Razões para bloqueios ao nível da aplicação
Os eventos na aplicação podem ser bloqueados pelos seguintes motivos:
- A instalação inicial foi identificada como falsa.
- Devido a uma regra de validação estabelecida.
- Porque o nosso algoritmo deteta fraude.
A tabela a seguir lista os possíveis motivos de bloqueio a nível da aplicação.
Motivos de bloqueio a nível da aplicação
| Motivo do bloqueio | Submotivo do bloqueio | Descrição |
|---|---|---|
| Herda da instalação | Herda da instalação | Instalação inicial identificada como falsa com base no motivo de instalação ou lista de exclusão |
| inapps_bots | parâmetros_de_dispositivo_falsos | Algoritmo da AppsFlyer deteta fraude |
| validação_na_loja_de_apps | - | A validação do recibo para compras na aplicação falha. |
| validação_inapps | regras_de_validação |
Baseado na regra de validação definida manualmente |
Redirecionamento
Os dados brutos do Protect360 incluem instalações e sessões fraudulentas de campanhas de redirecionamento (conhecidas como reatribuições e reengajamentos, respetivamente). Os dados são apresentados utilizando os campos nome do evento e tipo de conversão de retargeting . Estão marcados como um dos seguintes:
- 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 para bloqueios em tempo real e fraudes identificadas após a atribuição da seguinte forma:
| Relatório | Exportar dados | Extrair API | Armazenamento de dados |
|---|---|---|---|
| Instalações | ✓* | ✓* | - |
| Instalações pós-atribuição | ✓ | ✓ | ✓ |
|
* Dados de reengajamento não disponíveis |
|||
Correção de atribuição para instalações sequestradas
Para instalações sequestradas, a AppsFlyer bloqueia a atribuição à rede fraudulenta e, em alternativa, atribui à última fonte legítima de contribuição.
Para instalações sequestradas, use o campo rejected_reason_value para identificar o colaborador válido (fonte de media), ou seja, o contribuidor que deveria ter recebido a atribuição originalmente.
- O campo rejected_reason_value é preenchido com contributor[1-3] ou orgânico. Verifique os campos colaborador[1-3] fonte de media/parceiro para visualizar os detalhes do contribuidor e reconciliar.
- Se os campos de contribuidor não aparecerem no seu relatório, podem ser adicionados na página de Exportar dados.
Nota: Quando as instalações sequestradas são bloqueadas em tempo real, as atribuições corretas são exibidas nos dashboards e relatórios da AppsFlyer (não apenas no Protect360). Quando as instalações usurpadas são identificadas após a atribuição, as atribuições corretas são mostradas apenas nos dados brutos do Protect360.
Características e limitações
| Característica | Comentário |
|---|---|
| Relatórios nas aplicações |
Os relatórios nas aplicações não incluem o campo de contribuidor. Os campos de contribuidor estão disponíveis apenas no relatório de instalações. |
| Valores em branco | Devido a restrições nos dados brutos relacionadas com a privacidade, os relatórios podem apresentar campos com valores vazios. Um exemplo disso são os campos de contribuidor. |