O filtro por hostname muda a lógica de combate ao spam no Google Analytics: em vez de tentar adivinhar todos os domínios suspeitos e bloqueá-los um por um, você define quais domínios são legítimos. É uma abordagem mais sustentável, mas não transforma o Analytics em um firewall e não substitui a validação dos dados na origem.
Segundo o Eurisko.com.br, a opção de filtro de dados do tipo “Incluir” para hostnames começou a aparecer nas propriedades do Analytics em 21 de setembro. Para quem mantém vários sites, trabalha com clientes ou investiga tráfego estranho com frequência, a mudança pode reduzir bastante o trabalho de limpeza dos relatórios — desde que a lista de domínios permitidos esteja correta.
Como funciona o filtro de hostname no Google Analytics
Um hostname é o domínio que aparece na URL visitada, como www.exemplo.com.br ou app.exemplo.com.br. No GA4, a dimensão Hostname ajuda a identificar o domínio associado aos eventos coletados em um site.
O problema que esse filtro tenta resolver é conhecido por quem já analisou relatórios contaminados: eventos aparecem em uma propriedade, mas não vieram do site esperado. Em vez de adicionar cada hostname suspeito a uma lista de exclusão, o modelo de inclusão parte de uma lista positiva. Só o tráfego associado aos hostnames autorizados deve ser considerado pelo filtro.
Essa diferença importa porque a lista de bloqueio envelhece rápido. Um domínio suspeito pode mudar, surgir outro endereço ou o tráfego indesejado chegar por uma origem que ainda não foi identificada. Uma lista de permissão tende a ser mais simples de manter quando o conjunto de domínios legítimos é pequeno e conhecido.
Hostname não é a mesma coisa que origem de tráfego
Vale separar três conceitos que costumam ser misturados: hostname, referenciador e origem/mídia. O hostname identifica o domínio associado à página; o referenciador indica de onde o navegador veio; e origem/mídia classifica a aquisição, como google / organic ou newsletter / email.
Isso significa que o filtro não é uma solução universal para qualquer dado estranho. Ele pode ajudar a descartar eventos associados a hostnames fora da lista, mas não corrige parâmetros UTM malformados, tráfego interno não identificado, eventos duplicados ou campanhas configuradas incorretamente. Primeiro descubra que dimensão está errada; depois aplique o controle adequado.
O filtro reduz spam, mas não bloqueia requisições
Na minha análise, o ponto mais importante é entender onde esse controle atua. Um filtro do Analytics é uma regra de processamento dos dados da propriedade. Ele não impede que alguém faça uma requisição ao endpoint de coleta, não autentica o visitante e não torna o Measurement ID secreto.
O código de medição de uma propriedade web é público por natureza: ele precisa chegar ao navegador. Um terceiro pode tentar enviar eventos usando endpoints de coleta ou o Measurement Protocol. Além disso, campos enviados por clientes podem ser falsificados. Por isso, filtro de hostname ajuda a proteger a qualidade dos relatórios, mas não deve ser tratado como controle de segurança ou prova de que um evento veio realmente do seu site.
Também não conte com o filtro para recuperar dados antigos. Filtros de dados do GA4 são aplicados a partir da configuração e ativação; eles não limpam retroativamente o histórico já coletado. Como a filtragem pode ser permanente para os dados afetados, eu começaria em modo de teste, quando disponível, e confirmaria o comportamento antes de aplicar uma regra definitiva.
Quando vale a pena usar uma lista de hostnames permitidos
O filtro faz sentido quando a propriedade recebe dados de um conjunto bem definido de domínios, como um site principal e alguns subdomínios controlados pela mesma equipe. Nesse cenário, a lista positiva reduz a dependência de monitoramento contínuo de novos hostnames suspeitos.
Antes de configurar a regra, levante todos os domínios que realmente precisam enviar eventos. Uma aplicação pode usar www.exemplo.com.br, enquanto o checkout está em checkout.exemplo.com.br. Uma migração pode manter o domínio antigo ativo por algumas semanas. Se você esquecer um hostname legítimo, os eventos desse fluxo podem deixar de aparecer nos relatórios filtrados.
Eu manteria ambientes de desenvolvimento e homologação fora da propriedade de produção sempre que possível. Se isso não for viável, documente os hostnames e avalie uma propriedade ou fluxo separado. Misturar produção, staging e localhost dificulta a análise, mesmo quando existe um filtro para controlar o que entra.
Na Prática: como auditar e configurar o filtro
- Liste os domínios esperados. Inclua o domínio principal, subdomínios que enviam eventos e domínios de checkout ou autenticação, se fizerem parte da medição.
- Confira os hostnames observados. Use os relatórios do GA4 e, se a exportação estiver habilitada, consulte os eventos no BigQuery. Não copie uma lista antiga sem validar se ela ainda corresponde à arquitetura atual.
- Crie a regra de inclusão. Na área de administração da propriedade, procure os filtros de dados e configure a condição de hostname conforme as opções disponíveis na interface. Os rótulos e a localização podem variar com atualizações do produto.
- Teste antes de aplicar permanentemente. Compare eventos esperados com os descartados e faça uma navegação real pelos fluxos mais importantes: páginas, login, checkout e conversão.
- Monitore depois da ativação. Verifique se os eventos continuam chegando para todos os domínios legítimos. Registre a lista permitida no repositório ou na documentação da propriedade.
Uma consulta no BigQuery ajuda a descobrir hostnames presentes na exportação. Ajuste o projeto, o número da propriedade e o intervalo de datas para o seu ambiente:
SELECT
NET.HOST((
SELECT value.string_value
FROM UNNEST(event_params)
WHERE key = 'page_location'
)) AS hostname,
COUNT(*) AS total_eventos
FROM `meu-projeto.analytics_123456.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930'
GROUP BY hostname
ORDER BY total_eventos DESC;A consulta não decide se um hostname é legítimo. Ela só mostra o que aparece em page_location nos eventos exportados. Analise os resultados com cuidado: eventos sem esse parâmetro podem retornar hostname nulo, e a exportação não substitui a conferência dos relatórios e da configuração da propriedade.
Uma proteção complementar no código do site
Também é possível evitar que o seu próprio código inicialize o Google Analytics em domínios não autorizados. Isso reduz erros de configuração, por exemplo quando uma cópia de staging carrega o mesmo template da produção. O trecho abaixo usa correspondência exata de hostname e só carrega o gtag.js na lista permitida:
const allowedHosts = new Set([
'exemplo.com.br',
'www.exemplo.com.br',
'checkout.exemplo.com.br'
]);
const measurementId = 'G-XXXXXXXXXX';
if (allowedHosts.has(window.location.hostname)) {
window.dataLayer = window.dataLayer || [];
window.gtag = function () {
window.dataLayer.push(arguments);
};
window.gtag('js', new Date());
window.gtag('config', measurementId);
const script = document.createElement('script');
script.async = true;
script.src =
'https://www.googletagmanager.com/gtag/js?id=' +
encodeURIComponent(measurementId);
document.head.appendChild(script);
}Esse código é uma defesa contra a inicialização acidental no seu próprio site; não bloqueia eventos enviados diretamente por terceiros e não substitui o filtro da propriedade. Se você usa Google Tag Manager, implemente uma condição equivalente no acionamento das tags e teste também os contêineres publicados em staging. Evite regras vagas como “qualquer subdomínio termina com exemplo.com.br” sem validar a correspondência: um teste de sufixo mal feito pode aceitar domínios que não pertencem à sua organização.
Erros comuns ao filtrar hostnames no GA4
- Ativar a regra sem inventariar subdomínios. Login, checkout, blog ou aplicação podem estar em hosts diferentes. O resultado é perder eventos legítimos e investigar um falso problema de coleta.
- Tratar o filtro como bloqueio de bots. Ele ajuda a controlar os dados processados pela propriedade, mas não interrompe requisições nem protege endpoints.
- Confundir hostname com domínio de referência. Um relatório de aquisição estranho não prova que o hostname está errado. Confira a dimensão que contém o valor suspeito antes de alterar a coleta.
- Esquecer migrações e campanhas temporárias. Um domínio antigo, landing page externa ou checkout de parceiro pode ser necessário por um período. Defina responsável e prazo para revisar exceções.
- Assumir que a regra limpa o histórico. O filtro não corrige dados anteriores à ativação. Para análises históricas, considere segmentação nos relatórios ou tratamento na camada de dados.
- Usar uma allowlist como única validação. Hostname é um sinal útil, não uma credencial. Sistemas que recebem eventos críticos devem validar dados no servidor e aplicar controles próprios.
Filtro de hostname ou alternativas: qual usar?
Para reduzir ruído em relatórios do GA4, o filtro de inclusão é uma alternativa direta quando você conhece os domínios válidos. Para investigar o problema, relatórios por hostname e consultas no BigQuery oferecem mais visibilidade antes de descartar dados. Para separar ambientes, propriedades ou fluxos distintos costumam ser uma solução mais organizada do que acumular exceções em uma única configuração.
Já para impedir abuso de um endpoint ou validar conversões importantes, o controle precisa estar fora do Analytics: validação no backend, limites de taxa, autenticação apropriada e verificações de integridade. Não existe um único filtro capaz de resolver qualidade de dados, segurança e atribuição ao mesmo tempo.
FAQ sobre filtros de hostname no Google Analytics
O filtro de hostname remove spam dos relatórios do GA4?
Ele pode excluir dados associados a hostnames que não estejam na lista permitida, ajudando a reduzir esse tipo de ruído. Mas não corrige todos os tipos de spam nem impede que requisições cheguem ao sistema de coleta.
Posso recuperar eventos removidos pelo filtro?
Não conte com essa possibilidade. Filtros aplicados ao processamento podem afetar os dados de forma permanente a partir da ativação. Teste a configuração e confirme os hostnames legítimos antes de aplicar uma regra definitiva.
Devo incluir subdomínios na lista?
Inclua cada hostname que realmente envia eventos para a propriedade, como www, checkout ou aplicação. Não presuma que liberar o domínio principal cobre automaticamente todos os subdomínios; confira a condição e o comportamento na interface do GA4.
O filtro impede que alguém envie eventos falsos?
Não. Ele é um controle de processamento e qualidade dos dados, não uma camada de autenticação. Um hostname pode ser falsificado em determinadas formas de envio, então eventos importantes devem ser validados também no servidor.
Na prática, esse recurso troca uma rotina reativa de bloqueio por uma política mais clara: só entram os domínios que a equipe reconhece. Eu considero isso uma melhoria útil, desde que a implantação venha acompanhada de auditoria, teste e documentação — e que ninguém confunda relatório mais limpo com proteção contra fraude.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.