Prevenção de fraudeGIVT vs SIVT: as 9 categorias de tráfego inválido do Google DV360
GIVT vs SIVT, mapeados: uma consulta de IP enxerga com clareza 2 das nove categorias de tráfego inválido do Google DV360 e a maioria nem um pouco. Veja quais, com 5 consultas de IP reais.
Você viu cliques inválidos no Google Ads e depois a página de um fornecedor chamou parte do seu tráfego de "SIVT". As siglas dizem quem deve pegar cada tipo de tráfego ruim e se você mesmo pode fazer algo.
A seguir, citamos as nove categorias do Google ao pé da letra, colocamos cada uma ao lado do padrão do MRC, indicamos qual campo de IP consegue enxergá-la e passamos cinco endereços reais pela nossa API. Para o caso mais amplo de detectar fraude de cliques por IP sem uma lista de exclusão, comece pelo nosso guia principal.
Abrimos todas as páginas do Google e do MRC citadas aqui às 05:38 UTC de 21 de outubro de 2026.
O que é tráfego inválido (IVT)?
Tráfego inválido é atividade publicitária que não vem de uma pessoa real com interesse real. A página de Qualidade do tráfego de anúncios do Google resume em uma linha:
"Tráfego inválido é qualquer atividade que não vem de um usuário real com interesse genuíno."
Cliques, impressões, interações e conversões podem ser inválidos, e nem tudo isso é malicioso. Os exemplos do Google vão de cliques acidentais a "cliques fraudulentos de anunciantes concorrentes" e "botnets de publicidade".
A ajuda do Google Ads não usa os termos GIVT e SIVT. Eles vêm do MRC, e o Google os usa na ajuda do DV360, onde estão as nove categorias.
Não confunda as nove com os próprios exemplos da página de Qualidade do tráfego de anúncios. Essa lista tinha onze títulos quando verificamos: atividade de usuário inválida, cliques acidentais, ocultação de anúncios, injeção de anúncios, empilhamento de anúncios, botnets, clickjacking, inventário representado falsamente, representação incorreta de vídeo in-stream e out-stream, malware e anúncio pop-under. O Google a chama de "lista não exaustiva" e não a separa em níveis.
Publishers têm suas próprias regras na página de tráfego inválido do AdSense.
GIVT vs SIVT: o que separa os dois níveis e quem decide
Os níveis diferem na forma como o tráfego é encontrado, não no quanto ele é ruim. O Invalid Traffic Detection and Filtration Standards Addendum, June 2020 Update do MRC define o GIVT na página 5 como tráfego "identificado por meios de filtragem de rotina, executados pela aplicação de listas ou por outras verificações de parâmetros padronizadas". O SIVT, na página 6, abrange "situações mais difíceis de detectar, que exigem análise avançada, corroboração/coordenação em múltiplos pontos, intervenção humana significativa etc. para serem analisadas e identificadas".
A página Filtrar tráfego inválido para garantir a qualidade do DV360 diz o mesmo em palavras mais simples: o GIVT "é identificado com listas de spiders e robôs conhecidos ou outras verificações de rotina", enquanto o SIVT "exige intervenção humana ou uma análise mais aprofundada".
O momento da detecção decorre disso. O DV360 diz que o Google remove o tráfego inválido "antes de o inventário receber lances ou depois que um evento ocorre", e o MRC observa na página 8 que a detecção de SIVT "pode levar tempo para ser executada e pode não ser viável em processos em tempo real".
Um clique pode se encaixar em mais de uma categoria. O MRC diz na página 49 que as categorias "muitas vezes não são mutuamente exclusivas, pois o tráfego inválido provavelmente será detectado por mais de uma categoria ou resultará de mais de uma".
Vários grupos dividem o trabalho:
- O MRC escreve o padrão e credencia fornecedores de mensuração com base nele.
- Listas do setor alimentam o GIVT. O MRC cita a IAB/ABC International Spiders & Bots List na página 9 e a lista de IPs de data center do Trustworthy Accountability Group (TAG) na página 10.
- Plataformas e fornecedores o aplicam. A página de Qualidade do tráfego de anúncios do Google afirma que "os processos de detecção de Tráfego Inválido Sofisticado (SIVT) do Google são credenciados pelo Media Rating Council".
As nove categorias de tráfego inválido do Google ao lado das listas do MRC
O Google classifica o tráfego inválido em três categorias de GIVT e seis de SIVT, e a maioria tem uma contraparte aproximada nas listas do MRC. O texto do Google é copiado da página do DV360. A coluna do MRC é um pareamento nosso, porque o DV360 remete à seção 1.1.2 do MRC como um todo, não item por item.
| Nível | Categoria do DV360 e definição do Google | Texto do MRC mais próximo (nosso pareamento, adendo de 2020) | Campo de IP que você pode verificar | Nossa consulta, 21 out. 2026 |
|---|---|---|---|---|
| GIVT | Data center: "Tráfego de anúncios originado de servidores em data centers cujos IPs estão ligados a atividade inválida (normalmente tráfego não humano)." | "Tráfego de data center sabidamente inválido (determinado como fonte consistente de tráfego inválido; sem incluir artefatos de roteamento de usuários legítimos ou navegação legítima em máquinas virtuais)" (p. 5) | detection.is_hosting, asn.asn_type | 45.33.32.156: hosting, pontuação 10, allow |
| GIVT | Rastreador conhecido: "Tráfego de anúncios de um programa ou script automatizado que solicita conteúdo e se declara como não humano (por diversos mecanismos de identificação)." | "Bots e spiders ou outros rastreadores" (p. 5) | threat.crawler.verified | 66.249.66.1: Googlebot verificado, pontuação 0, allow |
| GIVT | Padrão irregular: "Tráfego de anúncios que inclui um ou mais atributos (por exemplo, um cookie de usuário) associados a padrões irregulares conhecidos, como tráfego de atualização automática ou cliques duplicados." | "Filtragem baseada em atividade, usando dados no nível de transação e parâmetros de dados de campanha ou de aplicativo" (p. 5) | Nenhum na consulta. Conte os cliques por IP e prefixo no seu próprio log | Nenhuma |
| SIVT | Navegação automatizada: "Um programa ou script automatizado que solicita conteúdo da web (incluindo anúncios digitais) sem envolvimento do usuário e sem se declarar como rastreador, como, e principalmente, botnets." | "Navegação automatizada a partir de um dispositivo dedicado" e "a partir de um dispositivo não dedicado: dispositivos infectados e sequestrados" (p. 6); rastreadores "disfarçados de usuários legítimos" (p. 7) | Parcialmente: threat.is_scanner, threat.is_botnet | 162.142.125.10: scanner, pontuação 0, allow |
| SIVT | Representação falsa: "Uma solicitação de anúncio para um inventário diferente do inventário efetivamente fornecido, incluindo solicitações em que o anúncio real é renderizado em outro site ou aplicativo, dispositivo ou outro alvo (como a geografia)." | "Representação incorreta de domínio e de app: falsificação de App ID, lavagem de domínio e domínio / localização de site falsificados" (p. 7) | Nenhum na camada de IP | Nenhuma |
| SIVT | Interface do usuário enganosa: "Uma página da web, aplicativo ou outro elemento visual modificado para incluir falsamente um ou mais anúncios. Isso inclui renderizar anúncios que não são visíveis para o usuário, injetar anúncios sem o consentimento do publisher ou induzir usuários a clicar em um anúncio." | "Veiculação de anúncios ocultos/empilhados/cobertos/transparentes/invisíveis ou intencionalmente ofuscados de outra forma" e "adware e malware que executam ações enganosas, incluindo injeção de anúncios" (p. 7) | Nenhum na camada de IP | Nenhuma |
| SIVT | Comportamento manipulado: "Um navegador, aplicativo ou outro programa que aciona uma interação com o anúncio sem o consentimento do usuário, como um clique não intencional, uma conversão inesperada ou a atribuição falsa da instalação de um aplicativo para dispositivos móveis." | "Atividade manipulada: abertura forçada de nova janela do navegador, abertura forçada de aba, instalação forçada de aplicativo móvel (redirecionamento móvel), comportamento de clique forçado" (p. 6) | Nenhum na camada de IP | Nenhuma |
| SIVT | Comportamento incentivado: "O uso de um incentivo explícito para levar usuários a interagir com um ou mais anúncios com o único propósito de receber esse incentivo e sem que o anunciante saiba de sua existência." | "Atividade humana inválida incentivada" (p. 6) | Nenhum na camada de IP | Nenhuma |
| SIVT | Classificação não divulgada: "Tráfego inválido que não pode ser classificado em nenhuma das outras categorias da taxonomia, ou tráfego inválido sensível que não pode ser divulgado." | Nenhum item único do MRC | Nenhum | Nenhuma |
| SIVT (apenas MRC) | Sem rótulo próprio no DV360 | "Tráfego de proxy inválido (originado de um dispositivo proxy intermediário que existe para manipular contagens de tráfego ou criar/repassar tráfego inválido, ou que de outra forma não atende à validação de protocolo)" (p. 7) | Parcialmente: detection.is_vpn, is_proxy, is_tor, is_relay | 185.213.155.73: Mullvad, 100, block. 185.220.101.1: Tor, 100, block |
Duas linhas têm uma ressalva. Hosting não é automaticamente inválido: o DV360 conta IPs "ligados a atividade inválida", e o MRC exclui o roteamento de usuários legítimos e a navegação em máquinas virtuais. Nem todo proxy é inválido também: o MRC conta aquele "que existe para manipular contagens de tráfego". O MRC também lista itens de GIVT que o DV360 não nomeia, como tráfego de pré-carregamento e posicionamentos 0x0 ou 1x1.
Tráfego inválido é o mesmo que fraude de cliques?
Não. A fraude de cliques é a parte deliberada do tráfego inválido, e uma grande parte do IVT não tem nenhuma intenção de enganar. Rastreadores de busca verificados, páginas pré-carregadas e toques acidentais contam como inválidos, e nenhum deles é fraude.
O Googlebot mostra a diferença. Na nossa consulta, 66.249.66.1 voltou como um Googlebot verificado, pontuação 0, allow. Ele é GIVT na categoria Rastreador conhecido, e você também o quer no seu site, então mantenha-o fora das contagens de anúncios e de analytics, mas nunca o bloqueie. Se uma requisição alega ser o Googlebot, verifique se uma requisição do Googlebot realmente vem do Google antes de confiar no nome. O Google publica as faixas que usa em sua página de verificação de rastreadores.
Você recebe reembolso por tráfego inválido?
Se o Google o detecta a tempo, você nunca é cobrado. A página Sobre o tráfego inválido do Google diz que o tráfego inválido encontrado antes do fim do mês é removido do faturamento e dos relatórios. Se for encontrado depois que você foi cobrado, "você receberá créditos na forma de um ajuste de faturamento pelo valor da atividade inválida". Você pode solicitar uma investigação de atividades "dos últimos 60 dias".
O Relatório de créditos por atividade inválida detalha esses créditos por campanha, e a mesma página traz o link para o Formulário de qualidade de cliques, usado para solicitar investigações.
Quais categorias de tráfego inválido uma consulta de IP consegue ver e quais não?
Uma consulta de IP enxerga duas das nove categorias do Google com clareza e uma parcialmente. Suas próprias contagens de cliques cobrem uma quarta, e a camada de IP não consegue ver as outras cinco.
Enxerga com clareza:
- Data center.
detection.is_hostingeasn.asn_typedizem que o endereço pertence a uma rede de hospedagem. Se essa rede está ligada a atividade inválida, como a definição do Google exige, é um julgamento separado. Explicamos o que torna um endereço um IP de datacenter em um post separado. - Rastreador conhecido.
threat.crawler.verifiedé true quando o endereço está em um dos 19 feeds oficiais de faixas de 10 operadores.
Enxerga parcialmente:
- Tráfego de proxy inválido. Os sinais de VPN, proxy, Tor e relay mostram a rota. Eles não conseguem mostrar se o proxy "existe para manipular contagens de tráfego".
- Navegação automatizada.
threat.is_scannermarca faixas conhecidas de scanners de toda a internet.threat.is_botnete o grupothreat.botnetvêm de dados de comando e controle de botnets, que descrevem os servidores que operam botnets, não os dispositivos domésticos sequestrados que enviam os cliques. Não temos nenhum endereço marcado como botnet que seja seguro mostrar. - Rastreadores falsificados. A API nunca vê um User-Agent. Um bot que alega ser o Googlebot só é pego quando seu código compara o nome alegado com
crawler.verified. - Padrão irregular. Esta é sua própria contagem de cliques por IP e por prefixo /24 ou /64, não um campo.
Não consegue ver: pré-carregamento e pré-renderização, sessões sem renderização, user agents que não são navegadores (dados de cabeçalho, não de IP), posicionamentos inválidos, anúncios ocultos ou empilhados, clickjacking, atividade manipulada, mensuração falsificada, falsificação de domínio e de app, tags sequestradas, injeção por adware, cookie stuffing, conteúdo apropriado indevidamente, humanos incentivados e fazendas de cliques, e tráfego enviado por proxies residenciais. Fazendas de cliques e proxies residenciais chegam em endereços comuns de ISP, e a camada de IP não consegue distingui-los de clientes reais.
Cinco consultas reais
Consultamos cinco endereços públicos entre 05:30 e 05:31 UTC de 21 de outubro de 2026, sem chave, o que nossa API permite a 30 por minuto. Nenhum deles enviou um clique em anúncio para ninguém. Eles representam endereços que um log de cliques contém.
| IP, o que é | Campos principais | Pontuação, ação | detection_methods | O que mostra |
|---|---|---|---|---|
| 45.33.32.156, scanme.nmap.org na Akamai Connected Cloud (Linode) | asn_type hosting, is_hosting true, crawler.verified false | 10, allow | datacenter_ip | Um IP de data center é candidato a GIVT, não um veredito |
| 66.249.66.1, Googlebot | is_hosting true, crawler.verified true, name Googlebot, category search_engine | 0, allow | datacenter_ip, verified_crawler | Rastreador conhecido: GIVT e bem-vindo |
| 185.213.155.73, servidor da Mullvad em Frankfurt | is_vpn true, vpn_provider Mullvad, is_hosting true, is_anonymous true | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | Uma VPN é um sinal de risco, não um nível de IVT |
| 185.220.101.1, nó de saída Tor em Hamburgo | is_tor true, is_hosting true, is_spammer true, dnsbl_sources zen.spamhaus.org | 100, block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | A evidência de proxy mais forte, ainda não é prova para um único clique |
| 162.142.125.10, scanner da Censys em Ann Arbor | is_scanner true, threat_types scanner, is_hosting false, asn_type unknown | 0, allow | (vazio) | Automação que um filtro de hosting não pega |
Um endereço, de ponta a ponta
A requisição coloca o IP no caminho:
curl https://api.geoiphub.com/v1/lookup/45.33.32.156 \
-H "x-api-key: YOUR_API_KEY"
Esta é uma cópia resumida da resposta das 05:30 UTC, com a estrutura aninhada mantida e os valores sem edição:
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting"
},
"detection": {
"is_vpn": false,
"is_tor": false,
"is_hosting": true
},
"threat": {
"is_scanner": false,
"crawler": {
"verified": false,
"name": "none"
}
},
"scoring": {
"fraud_score": 10,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
O sinal de data center disparou e nenhum outro, então a pontuação ficou em 10. Pelos dois padrões, este endereço é candidato a revisão de GIVT, não inválido por padrão. O Googlebot em 66.249.66.1 também está em uma rede de hospedagem, mas é verificado, e recebeu pontuação 0.
Você pode verificar se um IP pertence a um data center gratuitamente ou ler a referência de campos da API.
Três coisas que as consultas nos ensinaram
Um IP de hospedagem não é automaticamente GIVT. Um servidor de nuvem comum sem nenhum outro sinal permanece em allow.
Nosso block não é um rótulo de IVT. Mullvad e Tor receberam pontuação 100 e block, um veredito de risco para o seu próprio fluxo. O MRC exclui "artefatos de roteamento de usuários legítimos" do GIVT de data center, e um usuário de VPN pode ser um comprador real.
O scanner escapa de um filtro de hosting. A Censys retornou is_hosting: false, pontuação 0 e detection_methods vazio, mas threat.is_scanner era true. O sinal não altera a pontuação, então leia-o diretamente.
Onde a evidência de IP está ficando mais fraca
O próprio MRC avisa que a filtragem baseada em IP está se enfraquecendo. Suas 2024 IVT Interim Updates, publicadas em 24 de abril de 2024, dizem na página 2 que "endereço IP limitado ou ausente e string de User Agent (UA) menos granular podem prejudicar abordagens baseadas em listas, em particular as abordagens atuais de Identificação Específica e de GIVT de data center" e as técnicas baseadas em atividade. A página 6 diz que todas as organizações de mensuração "devem avaliar periodicamente (pelo menos anualmente) a dependência da capacidade de detecção de IVT em relação ao endereço IP, ao UA e à análise no nível do usuário".
Nossos próprios limites são claros. O GeoIPHub não classifica IVT e não tem credenciamento do MRC. Nós retornamos evidências de rede, e o anunciante ou a plataforma classifica. As consultas são um retrato de um momento, porque faixas e listas mudam diariamente.
O que fazer com cada categoria
Filtre o tráfego de data center e de rastreadores por campo, atribua pontuação aos anonimizadores e pare de esperar que uma verificação de IP encontre SIVT que ela não consegue ver. Esta é a regra por categoria.
| Categoria | O que fazer | Campo a ler |
|---|---|---|
| Data center | Atribua pontuação no momento do clique e mantenha-o fora dos sinais de conversão. Não o exclua em bloco, porque o limite de 500 exclusões de IP do Google Ads não comporta uma rede de hospedagem | detection.is_hosting, asn.asn_type |
| Rastreador conhecido | Permita-o e mantenha-o fora das contagens de anúncios e de analytics | threat.crawler.verified, threat.crawler.name |
| Tráfego de proxy inválido | Atribua pontuação e reforce a verificação em ações arriscadas. Não bana saídas compartilhadas | detection.is_vpn, is_proxy, is_tor, is_relay |
| Navegação automatizada | Leia os sinais de scanner e botnet. Compare o User-Agent alegado com crawler.verified no seu código | threat.is_scanner, threat.is_botnet |
| Padrão irregular | Limite a taxa por IP e por prefixo /24 ou /64 no seu próprio log | Nenhum, suas contagens |
| Todo o resto | Conte com a filtragem do Google, seus relatórios de posicionamento e o processo de créditos | Nenhum |
Para rastreadores, a escolha de quais deixar entrar é sua. Tratamos de decidir quais rastreadores de IA bloquear e de verificar rastreadores de IA por DNS reverso e faixas publicadas em posts separados. Para o Tor, nosso guia explica como funciona a detecção de nós de saída Tor. Para bots em geral, leia o que um IP pode e não pode dizer sobre um bot.
Um cuidado vale para todas as linhas. threat.is_cgnat marca endereços de NAT de operadora, em que um endereço carrega muitos usuários, então nunca bana um deles com base em contagem de cliques. Quando um veredito surpreender você, scoring.detection_methods lista os motivos por trás dele.
Como medir o tráfego inválido na sua própria conta
Comece pelo que o Google já filtrou e depois acrescente sua própria visão. A página de ajuda do Google orienta você a adicionar a coluna "Cliques inválidos" à tabela de campanhas. Ela mostra os cliques que o Google filtrou antes do faturamento, e o Google não cobra por eles.
Sua própria visão vem do seu servidor. Registre o ID do clique e o IP do cliente na sua landing page, faça uma consulta por IP e conte os cliques por campo: hosting, rastreador verificado, VPN, Tor, scanner. Depois conte por prefixo /24 e /64 para encontrar padrões irregulares. Essa é a parte do seu tráfego inválido visível pelo IP. O resto fica com os filtros do Google e o processo de créditos.
Escolha um dia de cliques pagos, consulte cada endereço e compare o que encontrar com a coluna "Cliques inválidos".
Perguntas frequentes
Qual é a diferença entre GIVT e SIVT?
O tráfego inválido geral é detectado com listas e verificações de rotina, como rastreadores conhecidos e IPs de data center ligados a atividade inválida. O tráfego inválido sofisticado exige análise avançada e revisão humana, como bots que se passam por usuários, dispositivos sequestrados e cliques incentivados.
Quais são as categorias de tráfego inválido do Google?
A ajuda do Display & Video 360 do Google cita três categorias de GIVT (data center, rastreador conhecido, padrão irregular) e seis categorias de SIVT (navegação automatizada, representação falsa, interface do usuário enganosa, comportamento manipulado, comportamento incentivado, classificação não divulgada).
Tráfego de VPN é GIVT ou SIVT?
Nenhum dos dois por padrão. O MRC exclui do GIVT de data center os artefatos de roteamento de usuários legítimos e só conta um proxy como SIVT quando ele existe para manipular contagens de tráfego. Um sinal de VPN informa a rota, não a intenção.
Todo tráfego de data center é tráfego inválido?
Não. A categoria do Google abrange IPs de data center ligados a atividade inválida, e o MRC exclui a navegação legítima em máquinas virtuais. Na nossa consulta, um servidor de nuvem comum recebeu pontuação 10 e foi permitido.
Tráfego inválido é o mesmo que fraude de cliques?
Não. O tráfego inválido inclui atividade sem intenção de enganar, como rastreadores de busca verificados e requisições de pré-carregamento. A fraude de cliques é a parte deliberada dele.
Uma consulta de IP consegue detectar tráfego inválido sofisticado?
Apenas parte dele. Uma consulta de IP pode mostrar anonimizadores, scanners e correspondências com feeds de botnets. Ela não enxerga fazendas de cliques, proxies residenciais, anúncios ocultos ou empilhados, cookie stuffing nem falsificação de domínio.
A equipe por trás da API do GeoIPHub
Escrito pela equipe do GeoIPHub, as pessoas que constroem a API de inteligência de IP do GeoIPHub e seu scanner. Os rascunhos são preparados com auxílio de IA e editados pela equipe; os exemplos de API são consultas reais à API em produção, salvo quando indicados como ilustrativos.
