R$100 mil recuperados de um parceiro que inflava instalação, sem pagar pelo Protect360

O contexto

Zipe é um e-commerce mobile exclusivo. Não existe versão web, só o app, em Android e iOS. Todo o crescimento vem de dentro do aplicativo: cadastro, navegação e compra.

O time de growth compra mídia em várias frentes. Uma delas é um parceiro de programática remunerado por CPA, custo por ação, pago em cima da primeira compra dentro do app. Esse modelo só funciona se a ação for real. Se o usuário não existe, a empresa paga por uma venda que nunca aconteceu.

A auditoria de fraude mobile é rotina, não exceção. Foi numa dessas revisões periódicas de conta que esse parceiro específico chamou atenção.

Por que o Protect360 não entrou na conta

A AppsFlyer vende um módulo antifraude próprio, o Protect360. Ele automatiza boa parte do que esse case descreve: detecção de click flooding, device farm, SDK spoofing. O problema é o preço, mais de 5 mil dólares por mês, fora do orçamento da Zipe nesse momento.

A saída foi construir a régua de fraude na mão, em cima do dado que a própria AppsFlyer já entrega sem custo extra: o dado bruto.

Meu papel

Toquei a investigação sozinho, de ponta a ponta. Puxei o dado bruto, montei a metodologia de detecção, validei os achados e levei o caso pronto pra negociação com o parceiro.

A metodologia

Sem Protect360, a régua de fraude nasceu de cruzar três sinais que, sozinhos, já contam boa parte da história. Juntos, fecham a conta.

O sinal que chamou atenção: instalação sem abertura

Comparei a taxa de conversão de instalação para primeira abertura entre parceiros. Em canal saudável, quase toda instalação vira abertura, quase na hora. Nesse parceiro, a taxa estava bem abaixo do baseline dos outros canais. Uma fatia grande das instalações creditadas a ele nunca abria o app de verdade.

Cruzamento por IP e device ID

O segundo sinal veio de cruzar IP e device ID das instalações suspeitas. Vi concentração de instalação saindo dos mesmos blocos de IP, e device ID se repetindo em instalações que deveriam ser de usuários diferentes.

Esse é o padrão clássico de click flooding. O parceiro, ou uma ponta da cadeia de programática abaixo dele, dispara um volume alto de cliques querendo roubar o crédito de qualquer instalação que aconteça no aparelho, não necessariamente a que ele influenciou de verdade. Emulador e device farm cobrem o resto, simulando o comportamento de um usuário que nunca existiu.

Validação contra receita real

Pra fechar a conta, cruzei as instalações suspeitas com a receita real gerada por elas. Praticamente nenhuma virava compra, mesmo sendo pagas por CPA em cima da ação de compra. Ou o usuário nunca existiu, ou nunca comprou nada. Não tinha meio-termo que sustentasse o valor cobrado.

Os resultados

As três pontas (abertura, IP/device ID e receita) apontavam pra mesma direção. Não dava pra chamar de coincidência.

(números representativos, anonimizados)

O desfecho

Levei o achado pro parceiro com o dado na mão: taxa de abertura, concentração de IP, device ID repetido e a ausência de receita real por trás das instalações cobradas. O resultado teve três partes. O parceiro foi bloqueado. Os valores futuros foram renegociados. E a Zipe conseguiu retroativo em cima do histórico de cobrança, porque o pagamento era por CPA em cima de uma ação de compra que, nesses casos, nunca tinha acontecido de verdade.

Depois do aprendizado, virou rotina. Montei uma consulta agendada que roda esse mesmo cruzamento (instalação, abertura, IP, device ID) todo mês, e um painel de acompanhamento que sinaliza quando um parceiro foge do baseline. Sem custar um Protect360, mas cobrindo boa parte da lacuna que ele cobriria.

Limitações, com honestidade

O modelo pega o padrão mais óbvio de fraude: click flooding, taxa de abertura anormal, IP e device ID repetido. Fraude mais sofisticada, com dispositivo real por trás e emulação mais refinada, pode passar batido. É exatamente esse tipo de caso que o Protect360 cobre melhor, e que fica como próximo investimento se o volume de mídia paga crescer o suficiente pra justificar o custo.

Próximos passos

Primeiro, evoluir o painel de acompanhamento com mais sinais, como velocidade de navegação dentro do app e padrão de digitação em formulário. Segundo, estender o mesmo cruzamento pros outros parceiros de mídia paga, não só o que já deu problema. Terceiro, reavaliar o Protect360 quando o volume de mídia justificar o investimento.

Stack de ferramentas

Estrutura do repositório

antifraude-programatica-mobile/
├── README.md                          # este case
├── docs/
│   ├── contexto.md                    # problema e discovery
│   └── metodologia.md                 # os tres sinais e a validacao
├── sql/
│   ├── taxa_instalacao_abertura.sql    # comparacao por parceiro vs baseline
│   ├── cruzamento_ip_device.sql        # concentracao de IP e device ID repetido
│   └── validacao_receita.sql           # instalacao suspeita vs receita real
├── rotina/
│   └── query_agendada_mensal.sql       # o mesmo cruzamento, todo mes
└── painel/
    └── dashboard_antifraude.md         # painel de acompanhamento por parceiro

Aprendizados

Não precisa de ferramenta paga pra ver fraude óbvia. Dado bruto, SQL e as perguntas certas já resolvem boa parte do problema.

CPA sem controle de qualidade é convite pra fraude. Quem é pago por ação tem incentivo pra fabricar ação, e o programático tem camadas demais pra confiar de olho fechado em qualquer ponta da cadeia. E fraude não é a única forma de um número de atribuição mentir: no case de atribuição multi-toque de CRM, o problema era um modelo de último clique escondendo 6x o valor real de um canal inteiro, sem fraude nenhuma envolvida.

O trabalho não acaba quando a fraude é provada. O valor de verdade está em transformar a investigação pontual numa rotina que continua vigiando, porque o próximo parceiro problemático não vai avisar antes.