Principais destaques
- Lista de hostnames aprovados: administradores agora podem definir quais domínios são legítimos e bloquear automaticamente eventos de qualquer outro hostname.
- Adeus ao caça-spam manual: em vez de cadastrar cada domínio suspeito individualmente, o Analytics passa a trabalhar com uma espécie de lista de permissões.
- Erro pode custar dados: filtros ativos são permanentes, e eventos descartados não podem ser recuperados nem no Analytics nem nas exportações para o BigQuery.
O Google Analytics ganhou uma mudança pequena na interface, mas potencialmente importante para quem passa boa parte do tempo limpando relatórios de tráfego.
A partir de 21 de setembro, propriedades do Analytics passaram a contar com filtros de dados do tipo “Incluir” para hostnames. A novidade permite determinar quais domínios são autorizados a enviar dados para uma propriedade.
Na prática, o raciocínio mudou.
Antes, era preciso identificar um hostname suspeito e adicioná-lo à lista de exclusão. Agora, é possível informar quais são os hostnames legítimos e deixar que o Analytics descarte o restante.
Em vez de perseguir o spam, deixe-o do lado de fora 🛡️
O problema do modelo anterior era relativamente simples: ele dependia de uma lista que precisava ser constantemente atualizada.
Um domínio de spam aparecia? Era adicionado à exclusão.
O spammer mudava de hostname? O novo endereço poderia passar pelo filtro até ser descoberto novamente.
Com o novo modo Incluir, a lógica se inverte.
🔐 A lista passa a ser de confiança: o administrador cadastra os domínios legítimos da operação e os eventos provenientes de outros hostnames são filtrados automaticamente.
Para sites que recebem tráfego indesejado com frequência, isso pode reduzir bastante o trabalho de manutenção.
Mas há uma pegadinha importante ⚠️
O filtro não deve ser tratado como uma simples configuração que pode ser ligada e desligada sem consequências.
Os filtros de dados do Google Analytics são permanentes depois de ativados. Eventos atingidos pelo filtro deixam de ser processados e não ficam disponíveis posteriormente no Analytics ou nas exportações para o BigQuery.
💡 Uma lista de permissões errada não gera apenas um relatório ruim. Ela pode fazer dados legítimos desaparecerem permanentemente.
É justamente por isso que o Google recomenda testar a configuração antes de colocá-la em funcionamento definitivo.
Primeiro teste. Depois bloqueie. 🔎
O Analytics oferece um estado de Teste, no qual os eventos que seriam afetados pelo filtro são identificados por uma dimensão de diagnóstico, em vez de simplesmente descartados.
A aplicação do teste pode levar entre 24 e 36 horas para entrar em vigor.
Isso é particularmente importante em estruturas que não possuem apenas um domínio.
Imagine uma empresa com:
• domínio principal;
• blog em outro hostname;
• subdomínios;
• páginas de campanha;
• sistemas externos;
• configuração de acompanhamento entre diferentes domínios.
Se algum desses endereços legítimos ficar de fora da lista, seus eventos poderão ser filtrados.
E o Measurement Protocol? 🧩
Há uma exceção relevante na nova regra.
Eventos enviados pelo Measurement Protocol, mecanismo utilizado para enviar dados diretamente ao Google Analytics a partir de servidores e outros sistemas, ficam fora desse filtro de hostname.
Isso pode ser importante para operações que utilizam o Analytics em ambientes como:
• sistemas de ponto de venda;
• quiosques;
• aplicações próprias;
• serviços de backend.
Ou seja, nem todo dado que chega ao Analytics necessariamente seguirá a mesma lógica do tráfego associado a um hostname de página.
O hostname vazio também entra na mira
Outra decisão do Google chama atenção.
Eventos que chegam sem hostname são bloqueados automaticamente pelo filtro.
A justificativa apresentada pela empresa é que a ausência dessa informação geralmente está associada a spam ou tráfego anormal.
É uma regra simples, mas que reforça a mudança de filosofia do Analytics: em vez de esperar que o administrador descubra cada fonte problemática, o sistema começa a trabalhar com critérios mais restritivos de origem.
Ainda existem algumas dúvidas 🤔
A documentação da novidade não esclarece completamente alguns detalhes técnicos da correspondência de hostnames.
Entre os pontos que permanecem em aberto estão:
• suporte a curingas;
• utilização de expressões regulares;
• comportamento automático para subdomínios;
• tratamento de estruturas com múltiplos domínios.
Essas questões fazem diferença principalmente para empresas e agências que administram propriedades mais complexas.
🏢 Quanto maior a operação, maior o cuidado: uma lista de permissões funciona muito bem quando todos os hostnames legítimos são conhecidos, mas pode se transformar em uma fonte de perda de dados quando a arquitetura digital é mais espalhada.
E a nova API do Google?
Outro ponto ainda sem resposta envolve a Data Manager API, apresentada pelo Google como uma alternativa para eventos enviados de servidores para o Analytics.
A documentação do novo filtro não deixa claro como eventos recebidos por essa rota se comportam em relação às regras de hostname.
Não está definido, a partir das informações disponíveis no material, se esses eventos carregam um hostname relevante para o filtro ou se acabam enquadrados na regra aplicada aos eventos sem hostname.
É uma lacuna especialmente relevante para quem está migrando integrações server-side.
Mais uma peça na limpeza do Analytics 📊
A novidade também não chega isoladamente.
Ao longo de 2026, o Google vem adicionando controles para melhorar a qualidade e a organização dos dados no Analytics, incluindo recursos relacionados a grupos de origem, validação de campanhas, diagnóstico de GBRAID e janelas de conversão.
A direção é clara: o Analytics está oferecendo aos administradores mais ferramentas para definir o que deve ser considerado dado válido.
Só que existe uma troca.
Quanto mais poder o administrador ganha para filtrar os dados, maior também passa a ser a responsabilidade sobre essas configurações.
📌 O novo filtro troca o trabalho de encontrar cada spammer pela responsabilidade de conhecer exatamente todos os domínios legítimos da sua operação.
Para um site simples, isso pode ser uma configuração relativamente direta. Para uma empresa com múltiplos produtos, subdomínios, landing pages e integrações server-side, o processo merece uma auditoria antes da ativação.
No fim, a ideia parece quase a de uma portaria: em vez de descobrir quem entrou sem autorização depois que a festa começou, você define antecipadamente quem está na lista. O desafio é não esquecer justamente alguém que deveria estar lá.
