Em mais de 20 auditorias, encontramos os mesmos 4 sintomas em contas sem server-side tracking. Veja como cada um aparece no seu painel e como detectar.
Em mais de 20 auditorias de tracking conduzidas pela Uaify no último ano, encontramos um padrão recorrente em contas que ainda dependem exclusivamente de pixel client-side depois do iOS 14.5 (2021), do ITP do Safari e da expansão dos bloqueadores de anúncio.
Quatro sintomas aparecem quase sempre juntos:
(1) conversão fantasma; o painel da Meta marca venda que o pixel não recebeu;
(2) bloqueador matando a tag em silêncio, sem erro no console;
(3) consent mode mal configurado mantendo o tracking em “denied” mesmo após o aceite do usuário;
(4) viés de atribuição para Android + Chrome, distorcendo a decisão de mídia.
Os quatro são consequência da mesma causa: o navegador deixou de ser um lugar confiável para coletar dado de conversão. Este artigo mostra como detectar cada sintoma com testes de 10 minutos, antes mesmo de considerar a migração para server-side.
A coleta de dado de conversão dentro do navegador depende de três coisas que foram, uma por uma, sendo cortadas pelos próprios fabricantes de navegador e pelos usuários: cookies de terceiros, execução livre de scripts e ausência de bloqueio. O Safari começou em 2017 com o Intelligent Tracking Prevention (segundo o anúncio original do WebKit). O iOS 14.5 forçou opt-in explícito para tracking entre apps em 2021.
Bloqueadores de anúncio passaram a estar embutidos em navegadores como Brave por padrão. O resultado: o pixel client-side virou uma coleta com furos, mas o painel de mídia continuou mostrando números completos, porque as plataformas passaram a preencher o que falta com modelagem.
Esse contraste entre “dado parcial coletado” e “número completo exibido” é o pano de fundo dos quatro sintomas que descrevemos a seguir.
Quais são os 4 sintomas de pixel client-side quebrado?
Sintoma 1: a conversão fantasma
O painel do Meta Events Manager registra a compra. Quando você cruza com o Tag Assistant ou com o log do GTM, o evento Purchase nunca foi disparado pelo navegador do usuário. A leitura imediata é “o pixel falhou”. A leitura correta é mais incômoda: o Meta atribuiu a venda usando modelagem; o caminho até o número foi probabilístico, não medido. Como a documentação oficial da Conversions API da Meta descreve, quando o sinal client-side não chega, a plataforma combina sinais do servidor com modelagem para estimar a conversão.
Como isso aparece para você: ROAS aparente alto, conferência com comercial nunca bate, e a decisão de aumentar orçamento naquele canal acontece em cima de número estimado. Quanto mais agressiva a modelagem (mais sinal faltando), mais o painel diverge da realidade do CRM.
Sintoma 2: o bloqueador mata a tag em silêncio
Bloqueadores de anúncio modernos (uBlock Origin, AdBlock Plus, Brave Shields, Firefox Enhanced Tracking Protection) bloqueiam requisições para domínios conhecidos de tracking antes mesmo do script carregar. Não há erro JavaScript. Não há aviso no console. A tag simplesmente não existe para aquele usuário. Ele converte. O dado some.
Como detectar em 10 minutos: instalar uBlock Origin em modo anônimo, abrir o seu site, fazer uma conversão de teste, abrir o Tag Assistant da Google ou o Pixel Helper da Meta. Se nenhum evento aparece e nenhum erro foi gerado, você reproduziu o que acontece silenciosamente com uma fatia do seu tráfego todos os dias. O percentual exato varia por nicho, mas existe em todos.
Sintoma 3: o consent management mente
Desde o Consent Mode v2 do Google (segundo a documentação oficial do Google Consent Mode), a tag não dispara enquanto o status de consentimento estiver denied. O default recomendado pela maioria dos CMPs (Cookiebot, OneTrust, Iubenda) é justamente denied por padrão, esperando o usuário aceitar.
O problema: muita implementação esquece o passo seguinte: chamar gtag (‘consent’, ‘update’, { analytics_storage: ‘granted’, ad_storage: ‘granted’ }) quando o usuário aceita o banner. O banner mostra verde. O usuário acha que aceitou. A tag continua bloqueada por configuração e não por escolha do usuário.
Resultado: tracking zerado em quem ACEITOU, exatamente o oposto do que o consent mode deveria fazer.
Como detectar: abrir o site em aba anônima, aceitar os cookies, abrir o console do navegador e rodar gtag(‘get’, ‘GTM-XXXX’, ‘consent’); se o retorno continua denied, o handler de update não está sendo chamado.
Sintoma 4: a atribuição fica enviesada para Android + Chrome
Quando todos os três sintomas anteriores acontecem, o tracking que sobrevive é tendencioso. Android + Chrome (sem ITP, com bloqueador menos comum, com consent mode geralmente bem configurado quando o CMP é internacional) viram superrepresentados nos eventos. iOS Safari, iOS Chrome (que usa o WebKit por baixo dos panos no iOS), Brave, qualquer combinação com bloqueador ativo, todos viram subrepresentados.
Como detectar: no GA4 ou no Events Manager da Meta, abrir o relatório de conversões por sistema operacional e por navegador dos últimos 30 dias. Comparar com o tráfego total (não convertido) no mesmo recorte. Se o share de Android+Chrome nas conversões for muito maior do que o share de Android+Chrome no tráfego total, o seu dado de conversão está enviesado.
A consequência prática é mais grave do que a anterior: a decisão de qual canal “performa melhor” vira reflexo de qual navegador o pixel conseguiu medir. Comparar a performance de Meta vs Google nesse cenário é comparar quanto cada plataforma se beneficia do mesmo viés, não qual canal realmente trouxe receita.
Como os 4 sintomas se conectam?
Os quatro são consequência da mesma causa estrutural: o navegador deixou de ser um lugar confiável para coletar dado de conversão. Cada sintoma é uma camada do mesmo problema; coleta no navegador é incompleta, e o painel preenche o vazio com modelagem ou simplesmente perde o sinal.
A migração para server-side tracking (envio de eventos pelo servidor, via CAPI da Meta, GA4 Measurement Protocol, server-side GTM) resolve a coleta no ponto onde o navegador falha. Mas migrar sem documentar o gap atual é trocar de fornecedor sem entender o problema. Antes de qualquer migração, rodar os 4 testes e tirar print do resultado é o que transforma “achismo técnico” em “diagnóstico defensável”, e o que justifica o investimento em arquitetura nova para quem aprova orçamento.
Como auditar você mesmo em 40 minutos?
- Teste 1 (10 min): abra o Events Manager da Meta. Pegue uma compra recente. Cruze com o Tag Assistant: o evento Purchase foi disparado no navegador? Se não, anote como “fantasma”.
- Teste 2 (10 min): instale uBlock Origin em aba anônima. Faça uma conversão de teste. O pixel disparou? Se não, anote como “bloqueador”.
- Teste 3 (10 min): aceite o banner de cookies em aba anônima. Rode gtag(‘get’, ‘…’, ‘consent’) no console. Se voltou denied, anote como “consent”.
- Teste 4 (10 min): compare share de Android+Chrome em conversões vs share no tráfego total dos últimos 30 dias. Se a diferença for > 15 pontos percentuais, anote como “viés”.
Se 2 ou mais testes vierem marcados, você tem o padrão das auditorias.
Bônus: respostas a perguntas frequentes que recebemos sobre o tema:
O server-side tracking resolve os 4 sintomas?
Resolve 3 dos 4. O envio via servidor (Conversions API, GA4 Measurement Protocol, server-side GTM) elimina dependência do navegador para a coleta. O sintoma 3 (consent mode mal configurado) precisa ser corrigido na implementação do CMP: server-side respeita o status de consentimento exatamente como client-side.
Eu preciso jogar fora o pixel client-side?
Não. O modelo recomendado é híbrido: client-side continua coletando o que consegue (especialmente para enriquecimento e debugging), server-side cobre o que o navegador derruba. Os dois rodando juntos com deduplicação por event_id é o padrão atual.
Quanto custa migrar?
Depende do volume de eventos. Server-side GTM rodando em Cloud Run para um e-commerce médio brasileiro fica abaixo de R$ 100/mês de infraestrutura. O custo real é de implementação e manutenção, não de hosting.
Qual a diferença entre CAPI e server-side GTM?
CAPI é o endpoint da Meta para receber eventos de servidor. Server-side GTM é uma camada de orquestração que pode enviar para CAPI, para GA4, para TikTok Events API e para outros destinos simultaneamente. Quem tem mais de uma plataforma de mídia ativa quase sempre se beneficia de ter o server-side GTM como camada de orquestração.
Em quanto tempo dá pra rodar os 4 testes?
São 40 minutos no total. Se você nunca abriu o Events Manager nem o Tag Assistant, conte 1 hora.
Eu já tenho CAPI configurada: isso me protege dos 4 sintomas?
Parcialmente. Se a sua CAPI está enviando o evento direto do backend (no momento da compra confirmada no servidor), você está coberto no sintoma 1. Se ela está só “espelhando” o evento client-side via Conversions API Gateway sem evento server-original, você ainda depende do navegador disparar primeiro, o gap continua.
Se este texto foi útil e você quer análises técnicas como esta toda semana, assina a LinkedIn Newsletter da Uaify. É onde detalhamos os padrões que vemos repetidos nas auditorias de tracking e performance dos nossos clientes.
Leituras internas relacionadas:
- O código invisível que decide o seu marketing: por que a camada de medição é o ponto onde a maioria das decisões de mídia já está sendo distorcida
- Modelo de atribuição GA4: last-click vs data-driven: atribuição correta exige sinal correto; sem coleta confiável, qualquer modelo vira ruído
- A vez que o ROAS caiu e o cliente quase me demitiu: o que ocorre quando o número que está mantendo o cliente confiante na verdade é estimativa
Referências externas:
- WebKit — Intelligent Tracking Prevention (Apple, 2017): https://webkit.org/blog/7675/intelligent-tracking-prevention/
- Meta — Conversions API documentation: https://developers.facebook.com/docs/marketing-api/conversions-api
- Google — Consent Mode v2 documentation: https://developers.google.com/tag-platform/security/guides/consent
