Clínica de problemas do GA4: investigar divergências antes de mexer na medição

Três sintomas comuns orientam este capítulo: receita duplicada, aumento de tráfego direto e divergência entre Google Ads e Analytics. Cada um tem várias causas possíveis, e a reunião costuma escolher a mais conveniente. Uma receita dobrada por tag repetida justifica um aumento de orçamento que o caixa não sustenta; um tráfego direto inflado por redirecionamento esconde a campanha que funcionava, e o corte cai justamente nela.

A primeira pergunta de qualquer investigação é em qual camada o número mudou. O negócio pode ter mudado de verdade: promoção, feriado, ruptura de estoque. A coleta pode ter mudado: a tag, o site, o banner de consentimento. O processamento pode ter mudado: um filtro, uma regra de canal, uma novidade do Google. Ou a leitura mudou: o relatório, o filtro, o denominador escolhido. Nenhuma correção deve ser feita antes de a camada estar identificada com evidência.

Onze sintomas e a primeira verificação de cada um

A tabela encurta o caminho: para cada sintoma, as causas que explicam a maioria dos casos e a primeira verificação a executar, antes de alterar a medição. Quando a verificação descarta a causa, a investigação testa a hipótese seguinte, na mesma camada ou em outra, conforme a evidência.

“(other)” e “(not set)” parecem o mesmo problema e pedem investigações diferentes. “(other)” é agrupamento: o Analytics juntou valores raros numa linha porque o relatório passou do limite de linhas da tabela usada no processamento. “(not set)” é ausência: o valor não chegou. O primeiro se resolve reduzindo a variedade de valores ou consultando a exportação; o segundo se resolve achando quem envia o evento sem o dado.

Relatório e exploração discordam por motivos documentados

Algumas divergências são esperadas pelas regras de processamento; essas hipóteses vêm antes de investigar a coleta. A ajuda oficial lista sete motivos para relatório e exploração mostrarem números diferentes: campos compatíveis, filtragem, segmentos e comparações, período, poucos usuários contabilizados, modelagem comportamental e tempo de processamento. Quem trata essas diferenças como falha passa semanas caçando o que está descrito numa página.

O método: hipótese, evidência, teste, correção, validação e registro

A hipótese é uma frase que nomeia a causa e a camada. A evidência é o dado que a hipótese prevê e que já existe no relatório, no DebugView ou na exportação. O teste confirma ou derruba a hipótese, de preferência com uma compra ou um envio de teste com número conhecido. Só então vem a correção, publicada em versão com nome e data, seguida da validação com o mesmo teste e do registro na propriedade: data, sintoma, causa, correção e o número antes e depois.

A comparação com uma fonte externa também segue esse método. A diferença aceitável entre a receita do Analytics e a da loja depende da população (só quem aceitou cookies ou todos), da forma de pagamento, do período e da política de receita, e cada empresa escreve a sua com o motivo de cada parcela. A Verde Vivo, com compra enviada pelo servidor, fechou agosto com 1.390 compras no Analytics para 1.650 pedidos pagos na loja e explica a diferença por categoria: recusa de medição, pedidos por telefone ou no balcão, bloqueadores e falhas pontuais. Diferença perto de zero só se espera no subconjunto conciliável, os pedidos do site com identificador gravado e medição aceita.

Primeiro caso: a receita dobrada

Em março de 2026, o relatório de monetização da Verde Vivo mostrou R$ 683.000 num mês em que a loja fechou R$ 354.750. A hipótese de Marina: dois emissores da compra, na camada de coleta. A evidência veio de uma compra de teste de R$ 89 no DebugView: duas compras em três segundos, uma com o número do pedido da loja, outra com um código do checkout lido da página de obrigado. Com dois números diferentes para o mesmo pedido, nada no Analytics podia reconhecer a repetição.

A integração nativa da plataforma da loja tinha sido ligada em fevereiro por alguém da operação, sem avisar Caio, que mantinha a tag de compra no Tag Manager. A correção manteve a tag do Tag Manager, que enviava os itens completos, e desligou a integração. A compra de teste repetida trouxe uma compra e um número. Em abril, a receita do Analytics ficou 1,8% acima da loja, e a lista de pedidos cancelados depois da compra explicou a diferença inteira.

Segundo caso: a campanha que virou tráfego direto

Na segunda semana de agosto, o tráfego direto subiu de 17% para 44% das sessões, e a campanha do clube de assinatura no Google Ads, que trazia cerca de 1.900 sessões por semana, apareceu com 410. Nada tinha mudado no Google Ads. A hipótese apontou para a coleta: um redirecionamento entre o clique e a página. O diagnóstico de identificadores perdidos do Analytics listava endereços em que os parâmetros do Google Ads chegavam vazios, todos de um domínio curto que a agência começara a usar em 4 de agosto.

O teste levou dois minutos: o link curto redirecionava para o domínio principal e descartava tudo depois do ponto de interrogação. Corrigido o redirecionamento, uma semana depois o tráfego direto voltou a 17% e a campanha a 1.850 sessões. O registro anotou o custo invisível: 11 dias de conversões da campanha creditadas ao tráfego direto e um lance automático que aprendeu esse tempo com metade do sinal.

Terceiro caso: o Google mudou, e a campanha não

Em 9 de outubro de 2026, a tag de remarketing da Verde Vivo passou a disparar quase o dobro de vezes, sem campanha nova e sem publicação no site. A hipótese apontou para uma mudança do fornecedor que alterou a coleta: a origem da mudança estava no Google, e a camada afetada era a coleta. As notas de versão do Tag Manager explicavam. Em 8 de outubro, o comando de configuração da Google tag passou a aparecer na camada de dados como um evento chamado gtag.config, e tags com acionador curinga (que disparam em qualquer evento) passaram a disparar também nele.

A correção foi trocar o acionador curinga da tag de remarketing por uma lista explícita de eventos, testada no modo de visualização antes de publicar. O caso mostra por que o histórico de novidades do Google entra na investigação ao lado do histórico do site: um número pode mudar porque o fornecedor mudou. A mesma lógica vale para os filtros de domínio, que desde 21 de setembro de 2026 aceitam a opção Incluir, com duas consequências que convém conhecer antes de suspeitar da tag: o filtro não alcança os eventos enviados pelo Measurement Protocol, e bloqueia eventos da web que chegam sem o domínio informado.

Para o próximo número que mudar sem explicação na sua empresa, escreva a hipótese em uma frase, com a camada, antes de abrir qualquer tag. Junte a evidência das quatro camadas, inclusive as notas de novidades do Google e do Tag Manager da semana, e faça um teste com número conhecido. Só depois corrija, valide com o mesmo teste e registre numa ficha com sintoma, hipótese, teste, resultado, correção, responsável e data. O registro de diagnósticos é a primeira peça reaproveitada em Projeto final: um plano de mensuração que a empresa consiga manter.