Como detectar fraude de cliques pelo endereço IP (sem uma lista de exclusão)

Todo anunciante descobre a fraude de cliques do mesmo jeito. O gráfico de gastos parece normal, o gráfico de cliques parece ótimo e o gráfico de conversões parece uma linha reta. Você abre os logs brutos, ordena por IP e lá está: o mesmo endereço, quarenta vezes, nenhuma conversão, tudo em uma única tarde.

Então você faz o óbvio. Cola esse endereço na lista de exclusão de IPs.

Funciona, por pouco tempo. Depois os cliques voltam de outro endereço, e de outro, e de mais outro, e em algum ponto perto da trigésima entrada na sua lista de exclusão você começa a suspeitar de que está jogando um jogo que não dá para ganhar. E está. A lista de exclusão não é uma versão fraca da ferramenta certa. É a ferramenta errada, e vale a pena entender exatamente por quê antes de olharmos para o que a substitui: uma pontuação de fraude para a rede por trás de cada clique.

O que as plataformas de anúncios realmente fazem com os cliques inválidos

Comece pelo que a maioria dos anunciantes presume que já está resolvido.

O Google filtra, sim, o tráfego inválido, e diz isso claramente. A documentação sobre tráfego inválido define tráfego inválido como "tráfego que não representa interesse genuíno na sua empresa" e afirma que "se o Google identificar uma interação como inválida antes do fim do ciclo de faturamento, você não paga por ela". Relemos essa página em 13 de outubro de 2026 e ela foi reescrita, então as citações desta seção correspondem à redação atual.

Isso é real e não é pouca coisa. Mas veja o que isso protege. Protege a fatura. O tráfego inválido identificado antes do fim do mês "é removido automaticamente dos seus relatórios de faturamento e de campanha, então não são necessários reembolsos". Se o Google o encontrar depois de você ter sido cobrado, "você receberá créditos na forma de um ajuste de faturamento no valor da atividade inválida". Nada disso diz qual palavra-chave, posicionamento ou público está atraindo fraude. Não impede que o tráfego polua a sua análise de dados e não impede que uma conversão falsa chegue ao seu modelo de lances.

Você pode pedir ao Google para investigar o tráfego que ele deixou passar, dentro de certos limites. O Google "limita as investigações aos últimos 60 dias", e a mesma página avisa que "uma investigação não poderá confirmar se cliques específicos foram marcados como válidos ou inválidos". O motivo do Google é que compartilhar esses detalhes ajudaria pessoas mal-intencionadas a contornar as defesas dele. É um motivo justo, e ainda assim deixa você sem uma resposta no nível do clique.

O mais próximo de um detalhamento é o Relatório de créditos por atividade inválida. Ele "detalha esses créditos por campanha e rede" e acrescenta os cliques e as interações por trás de cada crédito. Ele está disponível apenas para campanhas de Pesquisa e Performance Max e cobre créditos, que são emitidos para atividade inválida encontrada depois de uma fatura. O tráfego que o Google filtrou antes do faturamento nunca vira crédito, então não está neste relatório.

A divulgação equivalente da Meta é ainda mais escassa. A página sobre cliques inválidos diz que a Meta "toma várias medidas para reduzir o risco de abuso por cliques inválidos", faz uma revisão manual quando uma atividade suspeita é detectada ou denunciada e não cobra por cliques considerados inválidos. Esse é todo o compromisso.

As duas plataformas estão corrigindo a própria lição de casa, justamente na única métrica em que os interesses delas e os seus divergem. O que sobra depois do filtro delas é problema seu, e o seu problema é medido em estratégia, não apenas em dinheiro.

Por que uma lista de exclusão de IPs falha

• Ela fica sem espaço e não consegue nomear uma rede. O Google Ads limita as exclusões de IP a 500 por campanha e 500 por conta, a interface documenta apenas um curinga no último octeto, e a Performance Max só aceita exclusões no nível da conta. Cobrimos os limites exatos, as entradas CIDR pela API e quais endereços merecem uma vaga no guia sobre o limite de exclusão de IPs do Google Ads.
• Ela não existe na Meta. O Gerenciador de Anúncios da Meta não tem recurso de exclusão de IP. Toda ferramenta de terceiros contra fraude de cliques na Meta contorna isso colocando usuários suspeitos em uma exclusão de Público Personalizado, que é um mecanismo fundamentalmente diferente e mais grosseiro.

Esses são os limites mecânicos. O limite estratégico é pior.

Os endereços mudam mais rápido do que você consegue digitar

O lado profissional da fraude em anúncios não opera a partir de um endereço fixo. Ele aluga IPs residenciais aos milhões.

Em 2025, o Google processou os operadores da botnet BADBOX 2.0, que havia comprometido mais de 10 milhões de dispositivos Android não certificados. Veja para que um único desses dispositivos infectados era usado: criação de nós de proxy residencial, fraude em anúncios programáticos, anúncios ocultos e fraude de cliques. Tudo isso vindo de um único TV box comprometido na sala de alguém. A pesquisa PROXYLIB da HUMAN Security encontrou a cadeia de suprimentos que a alimentava: aplicativos Android, publicados no Google Play, inscrevendo silenciosamente os celulares dos usuários como nós de saída de proxy.

É a mesma infraestrutura sobre a qual escrevemos em por que há tantos proxies residenciais no seu tráfego. Para um anunciante, isso significa que o clique fraudulento que acabou de custar US$ 14 chegou de uma conexão de banda larga residencial real na sua cidade-alvo, pertencente a uma pessoa real que não faz ideia de que o roteador dela está para alugar. Não há um endereço para banir. Há dez milhões deles, e amanhã serão outros dez milhões.

E bani-los atinge clientes reais

Esta é a parte que, silenciosamente, custa mais do que a própria fraude.

Um endereço IP público não significa mais uma pessoa. O carrier-grade NAT coloca centenas ou milhares de assinantes móveis atrás de um único endereço público, e a RFC 6269, a avaliação da IETF sobre o que o compartilhamento de endereços quebra, previu a consequência há anos: quando um servidor penaliza um endereço compartilhado, "um usuário que falha em várias tentativas de login pode bloquear outros usuários que não fizeram nenhuma tentativa anterior".

Troque "tentativas de login" por "cliques fraudulentos" e você tem a sua lista de exclusão. Exclua permanentemente o IP da operadora móvel atrás do qual um fraudador por acaso estava e você terá apagado um número desconhecido de compradores móveis reais de todas as campanhas da conta: silenciosamente, sem relatório, para sempre. É a versão, no gasto com anúncios, do problema das recusas indevidas que abordamos em como detectar tráfego anonimizado sem bloquear clientes reais.

Uma lista de exclusão não tem o conceito de "provavelmente ruim". Ela só tem "banido". Essa é a falha fatal de design, e é por isso que a resposta não é uma lista mais longa.

A mudança de perspectiva: o IP é evidência, não veredito

Pare de perguntar "este endereço está na minha lista de bloqueados?" e comece a perguntar "de que tipo de rede vem este clique, e quanto eu confio nela?"

Essa pergunta tem uma resposta rica, porque um endereço IP carrega muito contexto que não tem nada a ver com o histórico de reputação dele. Esse contexto é difícil de falsificar para um fraudador, porque é uma propriedade da infraestrutura que ele está emprestando, e não da requisição que ele está enviando.

O setor já formalizou isso, e é a parte que a maioria dos conselhos sobre PPC deixa passar.

O que os padrões já exigem

Os IVT Detection and Filtration Standards do Media Rating Council dividem o tráfego inválido em dois níveis, e a divisão corresponde quase perfeitamente ao grau de dificuldade de ler o IP. O General Invalid Traffic (GIVT) é identificado "por meio da aplicação de listas ou de outras verificações de parâmetros padronizadas", e a primeira categoria que o MRC lista nele é o tráfego de datacenter sabidamente inválido. O Sophisticated Invalid Traffic (SIVT) é o nível mais difícil, que exige "análises avançadas, corroboração/coordenação em vários pontos e intervenção humana significativa", e o tráfego de proxy inválido fica ali. Percorremos todas as categorias dos dois níveis, ao lado das nove do próprio Google, e dizemos quais uma consulta de IP consegue ver, em GIVT vs SIVT: as categorias de tráfego inválido do Google.

As diretrizes Certified Against Fraud da TAG tornam obrigatória a metade referente a datacenters: uma empresa certificada "deve implementar filtragem de ameaças de IPs de datacenter em todas as transações monetizáveis (incluindo impressões, cliques, conversões etc.)", e a seção 4.8.a acrescenta que usar apenas a TAG Data Center IP List não conta. Daí decorrem duas coisas para um anunciante. Se os órgãos de padronização tratam a filtragem de IPs de datacenter como um piso de compliance, um anunciante que não a faz está abaixo do piso. E os padrões dizem o mesmo que este artigo: listas resolvem o nível fácil, e o nível difícil exige análise.

Os sinais do endereço IP que detectam fraude de cliques

Isto é o que ler no IP, mais ou menos em ordem de relação sinal-ruído para tráfego pago. Para as mesmas sinalizações aplicadas a bots além dos cliques em anúncios, e onde cada uma fica cega, veja quais sinais de IP identificam bots.

Repare na direção da última linha. Um bom modelo de pontuação não apenas soma pontos. Ele também os subtrai. Um ISP residencial e um rastreador verificado são motivos para ser mais tolerante, uma faixa de carrier-grade NAT tem a pontuação limitada, e um sistema que não tem esses elementos vai triturar o seu público móvel real em falsos positivos. Esse princípio é detalhado motivo por motivo em os motivos atenuantes por trás de uma pontuação de fraude, e ele importa mais em publicidade do que em quase qualquer outro lugar, porque no tráfego pago um falso positivo não é um login bloqueado. É um cliente que você pagou para adquirir e depois jogou fora.

Lendo tudo em uma única chamada

Concretamente, isto é uma única consulta ao IP que disparou o clique, antes de você decidir quanto ele valia. Você pode fazer a mesma verificação manualmente no verificador gratuito de pontuação de fraude de IP.

Os campos que importam para um clique pago ficam distribuídos em quatro grupos da resposta:

Um clique de hospedagem tem pontuação baixa, um clique de Tor tem pontuação 100

A pontuação sozinha não vai descontar um clique de datacenter para você, e duas consultas reais mostram por que você ainda precisa ler os campos. Consultamos os dois endereços em 13 de outubro de 2026 e os consultamos de novo em 14 de outubro de 2026 com os mesmos valores; o primeiro bloco é a resposta de 14 de outubro de 2026. Os resultados mudam conforme as faixas se movem. O primeiro é o IP de hospedagem da requisição acima: scanme.nmap.org, o host de testes público que o Nmap mantém na Akamai Connected Cloud em Fremont, na Califórnia. Ele não clicou no anúncio de ninguém. Ele representa qualquer servidor de nuvem comum:

O segundo é uma saída Tor em Hamburgo:

O servidor de nuvem tem pontuação 10 e allow, com datacenter_ip como único método. Isso é deliberado: a pontuação geral é feita para todo tipo de tráfego, incluindo chamadas de API e saída de redes corporativas, em que um endereço de hospedagem sozinho não é fraude. Um clique pago é diferente, porque um comprador não clica no seu anúncio a partir de um servidor, então, para o tráfego de anúncios, aplique a sua própria regra sobre asn.connection_type ou detection.is_hosting em vez de esperar que a pontuação diga block. A saída Tor não precisa de regra extra: ela tem pontuação 100 e block, e detection_methods nomeia quatro motivos independentes (saída Tor, uma faixa de datacenter em uma lista de bloqueio, DNS reverso típico de Tor, um spammer conhecido).

Uma VPN fica no meio. Até esta atualização, este post usava 45.83.220.7 como seu exemplo de hospedagem comum. Em 13 de outubro de 2026, a API o identifica como um servidor da Mullvad e lhe dá pontuação 46, review, com known_vpn_server e datacenter_ip. Essa é a ponderação que a tabela de sinais pede: um clique de VPN é motivo para olhar mais de perto, não para banir, e também é um lembrete para refazer qualquer consulta antes de confiar em um resultado antigo.

Esse campo é o que transforma isso de uma caixa-preta em algo que você consegue defender em uma revisão de qualidade de mídia. Quando um clique é descontado, você pode dizer exatamente por quê: conexão de datacenter em um clique pago, ou saída Tor mais uma listagem de spam. "A pontuação mandou" não é uma resposta que alguém deveria aceitar, muito menos das próprias ferramentas antifraude.

Proteja o sinal de lances, não apenas o clique

Esta é a parte que muda a economia, e é onde os anunciantes investem de menos de forma consistente.

Bloquear um clique fraudulento economiza o custo daquele clique. Impedir uma conversão fraudulenta evita algo consideravelmente mais caro: ensinar o seu algoritmo de lances a comprar mais fraude.

O Smart Bidding e a otimização da Meta funcionam aprendendo quais agrupamentos de sinais produzem conversões e dando lances mais altos para eles. Alimente esse ciclo com uma conversão falsa e você não perdeu um clique. Você pagou para treinar o modelo a ir atrás de mais tráfego exatamente igual ao tráfego que acabou de fraudar você. O sistema vai persegui-lo com entusiasmo e relatar resultados excelentes, porque, pela própria métrica, ele está tendo sucesso.

Para sermos precisos sobre o que está e o que não está documentado aqui: o Google não publica nenhuma declaração de que conversões fraudulentas envenenam os lances automáticos. O que a documentação do Smart Bidding do Google diz é que "se os dados de acompanhamento de conversões forem imprecisos, você poderá ver flutuações no seu volume, CPA ou ROAS", observando também que o Smart Bidding pode reagir e se ajustar a dados imprecisos. A afirmação mais forte acima é um argumento fundamentado em como a otimização funciona, não uma citação do Google, e você deve tratá-la como tal. Mas é um argumento simples: um otimizador maximiza aquilo que mandam ele contar.

O controle prático fica no servidor, e é o único lugar em que a Meta dá mais controle do que o Google, e não menos. Como a API de Conversões é um canal de servidor para servidor, o seu servidor decide quais eventos chegam a ser enviados à Meta. Uma consulta de IP no momento da conversão (não no momento do clique) permite reter o evento inteiramente quando o "cliente" é um endereço de datacenter. A Meta nunca aprende a querer mais disso. O mesmo vale para as importações de conversões off-line do Google.

Pontue o clique para proteger o orçamento. Filtre a conversão para proteger o modelo.

A lista de exclusão ainda tem um pequeno papel

Nada disso significa que você deve esvaziar a lista. Significa que você deve parar de tratá-la como a estratégia.

Uma lista de exclusão é a ferramenta certa para exatamente uma situação: um pequeno número de infratores reincidentes, estáveis e de alta confiança: a faixa do escritório de um concorrente, um scraper em um host fixo, um IP interno queimando o seu próprio orçamento. São poucas entradas, elas não fazem rodízio e nunca vão chegar perto de 500.

Todo o resto (tudo o que faz rodízio, tudo o que é compartilhado, tudo sobre o que você tem menos que certeza) pertence à pontuação, onde pode ser ponderado, perder peso com o tempo, ser corroborado com outros sinais e revertido amanhã quando as evidências mudarem. Banimentos são permanentes e binários. A fraude não é nenhuma das duas coisas.

Onde isso roda em produção

Eu construo isso dos dois lados, e vale a pena ser transparente sobre isso. A GeoIPHub é a camada de inteligência de IP descrita acima. O ClickFortify é o nosso produto contra fraude de cliques construído sobre ela. Ele pontua cliques em anúncios ao vivo no Google e na Meta, sincroniza o pequeno conjunto de infratores realmente de alta confiança com as exclusões de IP do Google Ads e filtra conversões suspeitas antes que cheguem à CAPI da Meta e ao Smart Bidding do Google.

A arquitetura é o argumento deste artigo em forma concreta: a inteligência de IP faz a pontuação, e a lista de exclusão é usada apenas para a fatia estreita de casos em que um banimento permanente é de fato a resposta correta. Se você preferir construir essa lógica por conta própria, a API acima é a mesma que ele chama.

Seis mudanças para fazer antes da sua próxima campanha

• Registre o IP em todo clique em anúncio. Você não consegue pontuar o que não registrou. Capture o endereço no acesso à página de destino, junto com o gclid/fbclid.
• Pontue, não bana. Passe o IP de cada clique por uma consulta e armazene a pontuação junto com a sessão, para poder segmentar seus relatórios por faixa de risco retroativamente.
• Comece pelo piso do datacenter. O tráfego de ASNs de hospedagem é a base de GIVT do MRC e o sinal de maior confiança e menor taxa de falsos positivos que você tem. É a vitória mais barata disponível.
• Filtre as conversões no servidor. Retenha eventos de conversão da CAPI e das importações off-line quando o IP for de alto risco. Isso protege o modelo de lances, que vale mais do que o clique.
• Limite o risco em IPs compartilhados. Garanta que faixas de CGNAT e de operadoras móveis sejam tratadas como compartilhadas, não como ruins. Essa é a proteção que impede que a prevenção de fraudes vire prevenção de receita.
• Mantenha a lista de exclusão curta. Reserve-a para infratores reincidentes, estáveis e certos, e configure-a no nível da conta para que ela cubra também a Performance Max.

O clique já disse de onde veio. A única questão é se você estava ouvindo com atenção suficiente para escutar mais do que um endereço.

Perguntas frequentes

Como detectar fraude de cliques pelo endereço IP?

Não comparando com uma lista de banimento, mas pontuando a rede de onde o clique veio. Os campos de sinal mais forte são o tipo de conexão (um clique vindo de um ASN de hospedagem/datacenter não é um comprador), as sinalizações de anonimizador (VPN, proxy público, Tor), as evidências de feeds de ameaças (botnet, scanner, spammer) com um timestamp de recência e a verificação de rastreador (uma requisição que alega ser o Googlebot vinda de um IP fora das faixas publicadas pelo Google falha na verificação; o seu código compara essa alegação com o campo verificado da API). Cada um deles é uma entrada ponderada de uma pontuação de risco, e é com base na pontuação, não no IP bruto, que você age.

É possível bloquear fraude de cliques nos anúncios da Meta por IP?

Não. O Gerenciador de Anúncios da Meta não oferece nenhum recurso de exclusão de IP, e é por isso que toda ferramenta de terceiros contra fraude de cliques na Meta funciona colocando usuários suspeitos em uma exclusão de Público Personalizado em vez de bloquear um endereço. Na Meta, a alavanca não é o clique, é a API de Conversões: como a CAPI roda no servidor, o seu servidor decide quais eventos de conversão são enviados à Meta, então uma conversão vinda de um IP de datacenter pode simplesmente ser retida.

O Google já não filtra os cliques inválidos para mim?

O Google filtra parte deles, e é explícito sobre como. A Ajuda do Google Ads diz que o tráfego inválido detectado antes do fim do mês 'é removido automaticamente dos seus relatórios de faturamento e de campanha, então não são necessários reembolsos', e que o tráfego inválido encontrado depois do faturamento volta como 'créditos na forma de um ajuste de faturamento'. Isso protege a sua fatura, não a estratégia da sua campanha. As investigações cobrem apenas os últimos 60 dias, e o Google diz que uma investigação 'não poderá confirmar se cliques específicos foram marcados como válidos ou inválidos', então você não consegue rastrear a fraude até as palavras-chave, posicionamentos ou públicos que a atraem.

Por que bloquear um endereço IP fraudulento é perigoso?

Porque na internet moderna um único endereço público é rotineiramente compartilhado por muitas pessoas sem relação entre si. A RFC 6269 documentou essa consequência há anos: quando um servidor penaliza um endereço compartilhado, um usuário abusivo pode bloquear outros usuários que não fizeram nada de errado. O carrier-grade NAT coloca centenas ou milhares de assinantes móveis atrás de um único IP público, então uma exclusão permanente mirando um fraudador pode apagar silenciosamente uma fatia do seu público móvel real de todas as campanhas.

O tráfego de datacenter é oficialmente considerado tráfego inválido?

O tráfego de datacenter sabidamente inválido é, mas não todo o tráfego de datacenter. Os IVT Detection and Filtration Standards do Media Rating Council listam o 'tráfego de datacenter sabidamente inválido' como a primeira categoria de General Invalid Traffic, excluindo a navegação legítima em máquinas virtuais e os artefatos de roteamento de usuários reais, e o MRC exige como base a filtragem do tráfego de datacenter das três maiores empresas de hospedagem (Amazon AWS, Google e Microsoft). As diretrizes Certified Against Fraud da TAG vão além e exigem que as empresas certificadas implementem filtragem de ameaças de IPs de datacenter em todas as transações monetizáveis.