"Minhas tags parecem configuradas corretamente, mas meus números parecem mais baixos do que o número real de visitantes." Uma causa comum são os ad blockers e recursos de prevenção de rastreamento interrompendo suas tags de mensuração. Como não é um erro de configuração, é difícil identificar isso nos seus dashboards — e seus números perdem silenciosamente justamente os usuários que estão bloqueando.
Alguma dessas situações soa familiar?
- Sua contagem de usuários no GA4 parece mais baixa do que o tráfego que você realmente vê
- Seus logs de acesso do servidor e as contagens de sessão do GA4 claramente não batem
- Seu pixel do Meta ou tag de conversão não dispara para alguns usuários
- Os usuários mais técnicos ou com navegadores específicos parecem estar caindo fora da sua mensuração
Este guia explica como os ad blockers realmente bloqueiam seus pixels e tags, por que as conversões são subcontadas, por que é difícil medir isso com precisão, e até que ponto você consegue mitigar o problema — sob a perspectiva de quem lida com isso no dia a dia. Também vamos separar isso da recusa no consent mode, que é um fator diferente.
Primeiro princípio: ad blockers bloqueiam requisições específicas
O erro comum é achar que um ad blocker apenas "esconde banners de anúncio". Na realidade, a maioria dos ad blockers e recursos de prevenção de rastreamento bloqueia as requisições que sua página envia para domínios externos de mensuração logo de início. Esconder banners é apenas parte do que eles fazem.
Veja como as ferramentas mais comuns aplicam seu bloqueio:
| Ferramenta / recurso | Como bloqueia |
|---|---|
| uBlock Origin / extensões AdBlock | Bloqueia requisições para domínios listados em listas de filtros |
| Brave Shields (nativo do navegador) | Bloqueia requisições para rastreadores por padrão |
| Firefox Enhanced Tracking Protection (ETP) | Bloqueia com base em listas de rastreadores conhecidos |
| Extensões content-blocker do Safari | Bloqueia requisições que correspondem a regras de filtro |
Muitas dessas ferramentas compartilham listas de filtros públicas, como a EasyPrivacy. Essas listas contêm um grande conjunto de domínios "conhecidos por mensuração e rastreamento", e o navegador verifica as requisições contra a lista no carregamento da página e interrompe as que correspondem.
O que é bloqueado: os domínios de fato
Os domínios que as listas de filtros costumam bloquear são exatamente os que usamos para mensuração.
google-analytics.com… requisições de mensuração do GA4 (collect, etc.)googletagmanager.com… Google Tag Manager (o próprio container do GTM)googleadservices.com… rastreamento de conversão do Google Adsfacebook.com/tr… envio de eventos do pixel do Meta
Isso significa que quando o próprio container do GTM não consegue carregar, todas as tags de GA4, ads e Meta dentro dele podem parar de funcionar juntas. O fenômeno de "a tag está implementada corretamente, mas nunca dispara para certos usuários" costuma ser exatamente isso.
Armadilha comum: olhar para sua própria aba Network e concluir "o
collectestá disparando, então está tudo bem" pode simplesmente significar que você não tem um bloqueador instalado. Abra a mesma página em um navegador com um bloqueador ativado, e essa requisição pode desaparecer completamente.
Como as conversões são subcontadas
O que torna os ad blockers tão traiçoeiros é que eles não aparecem como um "erro". Quando uma requisição é bloqueada, o navegador trata esse evento como se ele nunca tivesse existido. Do ponto de vista da tag, ela simplesmente "não disparou" — sem aviso, sem log de erro.
O resultado disso são duas coisas.
1. Os resultados dos usuários bloqueadores somem por completo
Quando um usuário com ad blocker converte, esse evento nunca chega ao Google ou ao Meta. O resultado realmente aconteceu, mas nos seus relatórios ele nunca ocorreu.
2. Seus dados ficam enviesados para o segmento "sem bloqueio"
O que sobra sendo contado são apenas usuários sem bloqueador. Então seus números se tornam um retrato enviesado de apenas parte da sua audiência. Isso importa mais do que um simples "a contagem caiu": suas taxas de conversão e análises de audiência ficam todas enviesadas para os usuários sem bloqueador.
Armadilha comum: "Meu produto é B2B ou voltado para tecnologia, mas o GA4 parece mais baixo do que a realidade." Usuários mais técnicos e preocupados com privacidade tendem a ter maior adoção de bloqueadores, então em alguns setores a perda é mais forte.
Você não consegue saber precisamente quanto está sendo bloqueado
Essa é a parte mais espinhosa do problema dos ad blockers. Não existe forma de saber com precisão "qual porcentagem do meu site está sendo bloqueada" pelo lado da tag de mensuração. O motivo é simples: eventos bloqueados nunca chegam, então eles nem sequer podem ser contados.
Os números de adoção variam muito entre estudos e mudam conforme navegador, região, setor e dispositivo. É exatamente por isso que você não deve travar em "é X por cento" — você precisa aproximar sua própria situação com mensuração real.
Uma aproximação comumente usada é esta comparação:
- Logs de acesso do servidor … a página em si é servida, então isso fica próximo do alcance real
- Mensuração client-side (GA4, etc.) … sai mais baixa exatamente na quantidade bloqueada
A diferença entre os dois te dá uma noção aproximada de escala de quantos usuários estão bloqueando suas tags (trate como uma estimativa, já que bots e outros fatores também entram em jogo).
Benchmarks do setor: quanto está sendo bloqueado
Embora não exista um número universal (varia por audiência, região e dispositivo), dados do setor de 2025–2026 oferecem benchmarks úteis:
| Segmento | Adoção aproximada de ad blocker |
|---|---|
| Média global (todos os dispositivos) | 25–30% das sessões web |
| Usuários desktop | 30–40% |
| Usuários mobile | 10–15% (menor porque navegadores mobile têm menos opções de extensões) |
| Audiências tech / desenvolvedores | 50–70% |
| Mercados UE / preocupados com privacidade | 35–45% |
Impacto no rastreamento de conversão: Com 25–30% das sessões bloqueadas, as plataformas costumam registrar de 20–40% menos conversões do que realmente ocorrem. No caso específico do Meta — cujos domínios de pixel estão entre os mais agressivamente visados pelas listas de filtros — a diferença pode ser ainda maior.
Esses números são direcionais, não definitivos. O ponto é: se você ainda não mediu sua própria diferença (logs do servidor vs. analytics client-side), pode estar subreportando conversões de forma significativa sem saber.
Até onde dá para mitigar: server-side tagging
Dá para prevenir? Não completamente — mas dá para mitigar uma parte. A abordagem mais usada é o server-side tagging.
A mensuração normal via navegador envia requisições diretamente do navegador do usuário para domínios como google-analytics.com, o que os torna alvos fáceis para as listas de filtros. Com o server-side tagging, os dados vão primeiro para seu próprio domínio first-party (por exemplo, analytics.seusite.com), e o servidor então encaminha para o Google ou o Meta.
- Como o destino é seu próprio domínio, filtros que olham apenas o nome do domínio têm menos chance de bloquear
- Mas isso não é uma bala de prata. Os bloqueadores estão cientes dessa técnica, e filtros mais avançados começaram a detectar e bloquear também a mensuração first-party
Em resumo, o server-side tagging é uma mitigação que "evita alguns bloqueadores", não uma solução que "recupera tudo". Não crie expectativas exageradas.
A abordagem híbrida: client + server com deduplicação
A melhor prática na prática em 2026 não é "client-side ou server-side" — é os dois juntos, com deduplicação. Veja como funciona:
- Mantenha suas tags client-side (GA4, Meta Pixel, Google Ads) rodando normalmente
- Adicione o rastreamento server-side em paralelo (sGTM, Meta CAPI, etc.)
- Marque cada evento com um
event_idúnico (outransaction_idpara compras) - A plataforma de anúncios recebe o evento pelos dois caminhos e deduplica usando o ID
Por que isso funciona: Para usuários sem bloqueador, os dois caminhos disparam e a plataforma deduplica — sem contagem duplicada. Para usuários com bloqueador, o caminho client-side falha silenciosamente, mas o caminho server-side tem sucesso — a conversão continua sendo capturada.
O Meta recomenda explicitamente esse padrão para o CAPI: rodar Pixel + CAPI juntos, enviar o mesmo event_id, e deixar o Meta cuidar da deduplicação. O Google oferece suporte semelhante com Enhanced Conversions e sGTM.
Bloqueio em nível de DNS: o que nem o server-side consegue resolver
Uma categoria crescente de bloqueio opera em nível de DNS, antes mesmo de o navegador fazer a requisição:
- Pi-hole — bloqueador de DNS para toda a rede, que bloqueia domínios de rastreamento para todos os dispositivos na rede
- NextDNS / AdGuard DNS — serviços de DNS em nuvem com listas de filtros embutidas
- Bloqueio de DNS integrado ao navegador — alguns navegadores resolvem domínios de rastreamento para
0.0.0.0
O bloqueio em nível de DNS pode neutralizar o roteamento por domínio first-party se a lista de filtros do serviço de DNS incluir seu subdomínio de mensuração (por exemplo, analytics.seusite.com). A adoção atual é baixa (estimada em 2–5% dos usuários), mas está crescendo em segmentos preocupados com privacidade.
O que isso significa na prática: sempre vai existir um segmento de usuários que você não consegue rastrear com nenhum mecanismo client-side. A resposta não é uma correção técnica — é construir sua estratégia de mensuração para tolerar uma margem de conversões não mensuradas, usando os dados de backend como fonte da verdade para os totais.
Isso é um fator diferente da recusa no consent mode
É fácil confundir esses dois conceitos, então vamos separá-los. "Queda na mensuração" tem duas origens amplamente diferentes.
| Fator | O que acontece |
|---|---|
| Ad blockers | A requisição é fisicamente bloqueada do lado do navegador do usuário, independentemente das configurações de consentimento do seu site |
| Recusa no consent mode | O usuário não consente, então o comportamento da tag é restringido — um mecanismo e uma correção diferentes |
Como acontecem de forma independente, resolver apenas um deixa as perdas do outro intactas. O mecanismo e a verificação do lado do consent mode são abordados em um artigo separado (este aqui foca em ad blockers). Vale notar também que o ITP (Intelligent Tracking Prevention) do Safari é da mesma família de fator — mensuração perdida do lado do navegador.
Como verificar "estou sendo bloqueado" em produção
Método 1: abrir a página em um navegador com um bloqueador ativado
A verificação mais intuitiva.
- Em um navegador com uBlock Origin (ou Brave), abra a página que você quer verificar
- Abra a aba "Network" no DevTools e filtre por
collect,googletagmanager,facebook.com/tr, etc. - Veja se as requisições são enviadas ou bloqueadas (as bloqueadas costumam aparecer como falha ou canceladas)
- Compare com o bloqueador desativado e veja quais requisições desaparecem
Método 2: reconciliar logs do servidor com a mensuração client-side
Como mencionado acima, comparar o alcance do lado servidor com as contagens de sessão do GA4 (etc.) permite estimar a escala do bloqueio. Mesmo que não seja um número exato, isso te diz se é uma escala que você não pode ignorar ou se está dentro da margem de erro.
O que checar na sua própria máquina não consegue te dizer
Os métodos acima são úteis, mas testar uma vez na sua própria máquina tem dois pontos cegos específicos de ad blockers:
- Seu ambiente não é o ambiente dos seus usuários em produção. Quem executa o teste geralmente tem o bloqueador desativado para desenvolvimento, ou sempre ativado — de qualquer forma, as condições diferem dos visitantes reais. O que você vê na sua "única máquina" é apenas uma entre inúmeras combinações de navegador/extensão/configuração. Usuários reais chegam com configurações que você nunca testou.
- Reproduzir qualquer coisa com um clique em anúncio carrega o risco de política de autoclique. Para ver rigorosamente "como um usuário que veio via anúncio e usa um bloqueador é tratado", você precisaria clicar em um anúncio ao vivo para recriar o caminho — o que carrega o risco de violação da política de anúncios como autoclique.
As perdas de ad blocker acontecem no ambiente do "outra pessoa rodando um bloqueador", não do "você que desativou o bloqueador". O fato de parecer tudo certo na sua máquina é exatamente o que esconde a perda.
Um checklist para verificar com confiança
- Você confirmou que as requisições de mensuração disparam em um navegador com um bloqueador ativado?
- O container do GTM (
googletagmanager.com) em si não está sendo bloqueado? - As requisições do GA4 (
google-analytics.com) não estão sendo bloqueadas? - O pixel do Meta (
facebook.com/tr) está disparando? - Você estimou a escala aproximada do bloqueio pela diferença entre logs do servidor e mensuração client-side?
- Você levou em conta o seu setor e audiência (usuários com perfil técnico tendem a maior adoção)?
- Você está enquadrando o server-side tagging corretamente como uma mitigação, não uma bala de prata?
- Você não está confundindo a recusa no consent mode com o bloqueio por ad blocker?
Perguntas frequentes
P. Quanto os ad blockers reduzem as conversões? R. Não há uma resposta única. A adoção varia entre estudos e muda bastante conforme navegador, região, setor e dispositivo. É por isso que, em vez de travar em uma porcentagem específica, a abordagem prática é estimar sua própria escala a partir da diferença entre seus logs de servidor e a mensuração client-side.
P. Se eu não veiculo banners de anúncio, os ad blockers não se aplicam a mim? R. Não. Independentemente de você veicular banners de anúncio, a maioria dos bloqueadores bloqueia requisições para os próprios domínios de mensuração e rastreamento. Um site que roda apenas GA4 ou um pixel do Meta ainda é afetado.
P. Se eu migrar para server-side tagging, consigo recuperar tudo? R. Não. Rotear por meio de um domínio first-party evita alguns bloqueadores, não todos. Filtros avançados já começaram a detectar também a mensuração first-party. Trate isso estritamente como uma mitigação.
P. Ser "recusado" em um banner de consentimento é o mesmo que ser bloqueado por um bloqueador? R. Não — são fatores diferentes. A recusa no consent mode significa "o comportamento da tag é restringido porque o usuário não consentiu"; um ad blocker significa "a requisição é fisicamente bloqueada do lado do navegador do usuário". Os mecanismos e as correções são diferentes, e ambos podem acontecer ao mesmo tempo.
P. Consigo ver no meu dashboard se estou sendo bloqueado? R. Não. Eventos bloqueados nunca chegam, então os dashboards do GA4 e de anúncios nem sequer registram que algo está "faltando". É exatamente por isso que você precisa checar visualmente em um navegador com um bloqueador ativado e reconciliar com os logs do servidor.
Conclusão: verifique com "o usuário em produção rodando um bloqueador", não com "você que desativou o bloqueador"
As perdas por ad blocker não aparecem nos seus dashboards, porque não são um erro de configuração — e seus números perdem silenciosamente exatamente o segmento que bloqueia. O que importa é verificar — até o nível de cada requisição individual — como suas requisições de mensuração são tratadas no ambiente real de um usuário com um bloqueador ativado.
O ConversionOK executa sua página ao vivo em um navegador independente e isolado e intercepta as requisições de tags de mensuração e pixels realmente enviadas, para então verificá-las — sem precisar clicar no seu próprio anúncio e sem interferência do ambiente do seu escritório. Comece com uma verificação estática gratuita para confirmar que o ponto de entrada da sua mensuração se sustenta antes mesmo de os bloqueadores entrarem em cena.
Artigos relacionados