Na web, a fraude costuma ser um bot fingindo ser navegador. Nos apps é mais complicado: o fraudador controla não uma página, e sim um aparelho inteiro, pode falsificar sinais do SDK de anúncios e recebe por instalações e ações que foram atribuídas a ele. Os princípios gerais para pegar esses esquemas estão no artigo o que é um sistema antifraude. Ao mesmo tempo, o tráfego in-app é um mercado legítimo e grande: a publicidade em jogos e utilitários sustenta os desenvolvedores e dá aos anunciantes segmentação precisa por aparelho. A tarefa não é abrir mão dele, e sim aprender a separar usuários reais da fraude mobile.
O que é tráfego in-app
Tráfego in-app são impressões e cliques de anúncios dentro de aplicativos móveis. Os formatos principais:
| Formato | Como é | Característica do tráfego |
|---|---|---|
| Banner | Faixa na parte de baixo ou de cima da tela | Muitos toques acidentais |
| Intersticial (interstitial) | Anúncio em tela cheia entre telas | CTR alto, parte dos cliques é erro ao tentar fechar |
| Vídeo com recompensa (rewarded) | Vídeo em troca de bônus no jogo | Visualização incentivada, baixa intenção |
| Bloco nativo | Anúncio no feed do app | O mais próximo do comportamento comum |
Esse tráfego é comprado por redes de anúncios e exchanges que agregam milhares de apps. Para o afiliado, a fonte parece uma rede de native ou push: painel, lance, GEO, macros com o identificador do app ou do posicionamento. A diferença está no destino do clique. Se a oferta é um app, o clique leva à loja, e a instalação é registrada pelo sistema de atribuição mobile por meio do SDK dentro do app. Se a oferta é um site, o clique abre a página no navegador interno ou no WebView.
Por que há mais fraude nos apps do que na web
Os motivos estão na estrutura do mercado:
- Paga-se pelo resultado, não pela impressão. O modelo CPI (pagamento por instalação) cria um incentivo direto para atribuir a si a instalação de outra fonte.
- Atribuição pelo último clique. A instalação geralmente é creditada à fonte do último clique antes dela. Quem conseguiu enviar o último clique leva o dinheiro.
- Cadeia de intermediários. Entre o anunciante e o app há redes, exchanges e sub-redes. Cada camada acrescenta opacidade.
- O aparelho é um computador completo. O fraudador pode manter centenas de celulares reais ou milhares de virtuais e controlá-los por software.
Os principais esquemas de fraude mobile
Click spamming
Click spamming, ou inundação de cliques, é o envio em massa de cliques falsos em nome de muitos aparelhos. Um app fraudulento clica em segundo plano em anúncios que o usuário nunca viu. A conta é simples: parte dessas pessoas um dia vai instalar sozinha um app popular, e a instalação será atribuída ao último clique do fraudador.
Sinais:
- enorme quantidade de cliques com conversão minúscula em instalação;
- tempo entre clique e instalação espalhado uniformemente por horas e dias, sem o pico característico nos primeiros minutos;
- alta parcela de usuários com comportamento orgânico entre os atribuídos.
Click injection
Click injection é um esquema mais preciso, típico do Android. Um app malicioso no aparelho percebe que começou a instalação de outro app e envia um clique nesse momento. Esse clique acaba sendo o último antes da primeira abertura e leva a atribuição.
O sinal é um tempo anormalmente curto entre clique e instalação: segundos, nos quais uma pessoa fisicamente não conseguiria ir à loja, baixar e abrir o app. Outra pista é o clique que chega depois de o download já ter começado, se o sistema de atribuição consegue comparar esses registros.
Emuladores
O emulador é um programa que simula um celular em um computador comum ou em um servidor. Nele dá para rodar apps, clicar em anúncios e instalar ofertas sem nenhuma pessoa real.
Sinais:
- rede de data center ou hospedagem em vez de operadora móvel ou provedor residencial;
- incoerências nas características do aparelho: modelo, tela, sensores e versão do sistema não formam um celular real;
- uniformidade: centenas de aparelhos diferentes com os mesmos parâmetros.
Fazendas de aparelhos
A fazenda de aparelhos (device farm) são prateleiras com celulares reais controlados por software ou por trabalhadores mal pagos. Os aparelhos são reais, então verificações de emulador não os pegam.
Sinais:
- muitas instalações vindas de um pequeno conjunto de IPs ou de uma única sub-rede;
- comportamento idêntico após a instalação: abriram, fizeram a ação mínima e nunca mais voltaram;
- atividade por hora regular demais, sem o ritmo diário de pessoas reais;
- redefinição do identificador de publicidade do aparelho, para que um celular pareça vários novos.
SDK spoofing e instalações falsas
O esquema mais tecnológico: o fraudador estuda quais mensagens o SDK de atribuição envia ao servidor na instalação e nos eventos e as gera ele mesmo, sem aparelho nenhum. O combate acontece do lado dos sistemas de atribuição, com assinatura das mensagens e verificação de integridade. Para o afiliado, o sinal são eventos que nada mais confirma: nem receita, nem retenção.
Como reconhecer fraude no tráfego in-app
Nenhum sinal isolado prova fraude. Só funciona a combinação:
- Rede. Operadora móvel ou provedor residencial é normal; data center quase sempre é automação. Como esses endereços são detectados está no artigo sobre VPN, proxy e IPs de data center.
- Tempo. A distribuição do tempo entre clique e instalação ou lead. Curto demais é injeção; regular e longo demais é inundação.
- Aparelho. Coerência entre modelo, sistema, tela e navegador. Os sinais de automação estão no artigo sobre navegadores headless e fingerprint.
- Repetições. Número de cliques do mesmo endereço e aparelho por dia.
- Qualidade depois da conversão. Retenção, ações repetidas, receita. A fazenda gera instalação, mas não gera compras.
- Concentração. Se quase todo o tráfego suspeito vem de alguns poucos apps de posicionamento, o problema está neles, não na rede inteira.
A análise geral dos sinais de automação está no artigo tráfego de bots: sinais e como reconhecê-lo, e os esquemas que atacam o orçamento de anúncios, no material sobre fraude de cliques.
Dica. Compare a fonte suspeita com uma fonte de controle. Se um posicionamento tem tempo até a conversão, parcela de cliques repetidos e retenção muito diferentes dos demais, com o mesmo GEO e criativo, é motivo para investigar, não coincidência.
Rastreamento de campanhas in-app
No in-app, é importante montar o rastreamento desde o primeiro dia de forma que o resultado possa ser dividido por posicionamento.
O que enviar no link. As redes de anúncios inserem macros no link: identificador do app ou do posicionamento, ID da campanha e do criativo, tipo de aparelho, custo do clique, click id da rede. Os nomes das macros variam de rede para rede; confira na documentação. Os princípios de marcação estão no artigo parâmetros UTM e macros das plataformas.
Como ligar o clique ao resultado. O ID do seu clique precisa chegar a quem registra a conversão (rede de afiliados, sistema de atribuição ou seu site) e voltar no postback. Mais detalhes nos artigos click ID e sub ID e postback no marketing de afiliados.
O que olhar no relatório. Não só instalações ou leads, mas a cadeia: cliques → chegaram à oferta → conversões → conversões confirmadas → receita. A fraude muitas vezes aparece no último passo: há instalações, mas não há confirmações nem receita. Como ler os status está no artigo sobre status de conversão.
In-app ou web mobile: a diferença para a filtragem
Web mobile é a pessoa que abriu a sua landing no navegador comum do celular. In-app é a pessoa que clicou no anúncio dentro de um jogo ou utilitário, e a página abriu no navegador interno do app. Para o filtro, são dois perfis diferentes:
| Sinal | Navegador mobile | Navegador interno (WebView) |
|---|---|---|
| Referrer | Geralmente presente | Muitas vezes vazio |
| Sinais do navegador | Padrão | Fora do padrão, às vezes parecidos com automação |
| Rede | Operadora móvel ou Wi-Fi | A mesma coisa |
| Repetições do mesmo IP | Moderadas | Frequentes: atrás do CGNAT da operadora há muitos assinantes |
Daí a regra: configurações pensadas para tráfego desktop ou navegador mobile não podem ser levadas para o in-app sem teste. O que parece suspeito em um site é comportamento normal de um usuário real em um app.
O que disso aparece no ArtisanClo
O ArtisanClo filtra e contabiliza cliques no link do anúncio, ou seja, o que acontece antes da loja de apps ou do site da oferta. Instalações e eventos dentro do app são registrados pelo sistema de atribuição do anunciante, mas a qualidade do clique em si já é visível antes disso.
- Navegadores internos e WebView são reconhecidos. O sinal de automação neles não barra a visita na hora, e sim entra na pontuação de confiança junto com a rede, o tempo e o referrer, porque nesses navegadores ele costuma ser falso. Para campanhas em que quase todo o tráfego abre dentro de apps, escolha o rigor Equilibrado e não ligue o bloqueio de visitas sem referrer.
- Verificações de rede. Bloquear ASNs de data center e visitas sem provedor corta emuladores e cliques de servidor que não fingem ser operadora móvel.
- Cliques de um IP por dia (a partir do plano Professional): contra inundação vinda de um único endereço. Em endereços móveis, não deixe esse limite rígido demais: atrás de um IP de operadora há muitos assinantes.
- Relatório por posicionamento. Envie o ID do app ou do posicionamento em um marcador, por exemplo
sub1, e abra Dinheiro por recorte por esse marcador: cliques, conversões, receita, custo e ROI por app. - O motivo de cada decisão no log de cliques: Rede de alto risco, Cliques demais de um IP, Um programa, não um navegador, Navegador headless detectado e dezenas de outros.
- Deep link para o Google Play. Se a oferta é um app, no endereço da oferta dá para usar
market://details?id=pacoteno modo Redirecionamento. - Duplicados. Nos fluxos com tracker, um segundo lead do mesmo visitante vindo de outro clique dentro da janela de unicidade vai para Lixo com a marca de duplicado.
Dica. Se você suspeita que o filtro está cortando usuários reais de apps, com a conexão por arquivo PHP ligue o Modo sombra por algumas horas: todos vão para a oferta, e o log mostra quem o filtro teria barrado. Se entre os barrados houver conversões, a regra está rígida demais.
O que fazer com um posicionamento suspeito
- Junte provas. Relatório do posicionamento: cliques, parcela barrada e motivos, tempo até a conversão, confirmações da rede de afiliados.
- Exclua o posicionamento no painel da rede. Só lá isso para o gasto.
- Avise o gerente da rede. A maioria das redes tem um processo de análise de fraude e reembolso por tráfego inválido, mas ele só funciona com fatos.
- Não tire conclusões por um dia. Conversões atrasadas são normais em apps, principalmente em assinaturas e compras dentro do jogo.
- Fique de olho na repetição. Posicionamentos fraudulentos costumam voltar com outro identificador. Se um posicionamento novo mostra o mesmo perfil, não é coincidência.
Erros comuns
- Otimizar por instalações sem receita. Fazendas e injeções geram instalações. Dinheiro só vem de usuários que ficam.
- Bloqueio rígido de IPs móveis. Operadoras móveis colocam milhares de assinantes em endereços compartilhados; bloquear um IP corta pessoas aleatórias.
- Filtro rígido sem considerar o WebView. Navegadores internos parecem incomuns, e uma regra pensada para desktop corta tráfego mobile real.
- Sem ID do posicionamento no link. Sem ele não dá para localizar a fraude; só resta desligar a campanha inteira.
- Tratar a taxa de passagem como nota. Passagem alta em tráfego com click id verificado é normal. Preocupante é quando quase ninguém chega à oferta.
Em resumo
O tráfego in-app é uma fonte grande e que funciona, mas a fraude mobile nele é diferente da web: click spamming, click injection, emuladores, fazendas de aparelhos e falsificação de SDK. Ela se reconhece pela combinação de rede, tempo, aparelho, repetições e qualidade depois da conversão. Envie o ID do posicionamento em um marcador, filtre o tráfego de servidor e automatizado, conte o dinheiro por app e desligue os posicionamentos suspeitos na própria rede. O catálogo de fontes com que o ArtisanClo trabalha está na página de fontes de tráfego.
