O dado está errado ou a implementação está errada?
Quando o número não bate, existem dois caminhos possíveis e eles levam a trabalhos completamente diferentes. Como decidir rápido em qual deles você está.
Toda semana alguém chega dizendo que o GA4 está errado. Às vezes está mesmo. Na maior parte das vezes o GA4 está reportando com precisão uma coisa que ninguém queria que ele reportasse.
Essas duas situações parecem iguais na tela e são completamente diferentes na prática. Se a implementação quebrou, o trabalho é de engenharia: achar o evento, corrigir, republicar, validar. Se a implementação está certa e o número é feio, o trabalho é de negócio: entender por que o comportamento mudou. Começar pelo caminho errado custa dias.
Este é o roteiro que eu sigo para descobrir em qual dos dois eu estou, geralmente em menos de uma hora.
#Antes de tudo: o número está errado em relação a quê?
"O dado está errado" nunca é uma afirmação completa. Errado comparado com o quê? Existem três referências possíveis e cada uma aponta para um lugar diferente.
Comparado com outra fonte (o backend, a plataforma de e-commerce, o gateway de pagamento). Aqui a divergência é mensurável e você tem um alvo. É a melhor situação.
Comparado com o próprio histórico. O número caiu 40% de terça para quarta. Isso vira uma investigação de data de corte, que é a mais fácil de todas.
Comparado com a expectativa de alguém. "Não pode ser que só 2% cheguem no checkout." Essa é a mais perigosa, porque muitas vezes não tem nada de errado além da expectativa. Trate com carinho, mas trate como hipótese, não como fato.
Se a pessoa não souber responder a qual referência está comparando, essa é a primeira coisa a resolver.
#O teste da data de corte
Coloque a métrica em série diária, com janela larga o suficiente para pegar antes e depois. Depois olhe o formato da curva.
Uma queda em degrau, de um dia para o outro, é quase sempre implementação. Comportamento humano não muda em bloco à meia-noite. Deploy, sim. Publicação de container, também.
Uma queda em rampa, ao longo de semanas, geralmente é comportamento, mix de tráfego ou sazonalidade. Pode ser implementação se algo foi sendo liberado por rollout progressivo, mas é menos comum.
Uma queda intermitente, que vai e volta, costuma ser condição de disparo: uma tag que só dispara em certo estado da página, um evento que depende de um elemento que nem sempre existe, uma corrida entre o dataLayer e a tag.
Achou o dia do degrau? Vá no histórico de versões do container e no log de deploy do site. Em geral a resposta está ali, e a investigação acabou.
#Os suspeitos de sempre
Quando não há degrau óbvio, eu passo por essa lista. Ela cobre a maior parte dos casos.
Duplicação. O mesmo evento disparando duas vezes é o problema mais comum e o mais fácil de disfarçar, porque a métrica sobe em vez de cair, e número subindo raramente é questionado. Em compra na Web, cheque o transaction_id: se ele estiver ausente ou não for único, o GA4 não consegue deduplicar. Essa deduplicação por ID é documentada para fluxos da Web, não para apps. Uma soma de receita maior que a do gateway é sinal clássico.
Consentimento e bloqueio. Se você implementou Consent Mode recentemente, ou mudou o texto do banner, ou o percentual de aceite mudou, o volume muda junto. Isso não é bug, é o sistema funcionando. Vale isolar a métrica por estado de consentimento antes de sair procurando culpado no código.
Cardinalidade e limiar. No GA4, dimensões com valores demais caem em (other), e relatórios com poucos usuários somem por limiar de dados. Um relatório que "esvaziou" pode não ter perdido dado nenhum, apenas ter cruzado uma linha de agregação. Se o total continua certo e só a quebra sumiu, suspeite disso primeiro.
Fuso horário. A propriedade do GA4 tem um fuso, o backend tem outro, a plataforma tem um terceiro. Comparar "ontem" entre duas fontes com fusos diferentes gera divergência garantida em torno da virada do dia. Sempre compare janelas fechadas e longas, nunca um único dia.
Escopo do parâmetro. Parâmetro de evento não é parâmetro de sessão nem propriedade de usuário. Muita divergência aparece quando alguém compara uma métrica de escopo de evento com uma leitura de escopo de sessão e espera que batam.
#O teste que decide
Se a lista acima não resolveu, existe um teste que separa os dois mundos de forma definitiva: reproduza o comportamento e observe o dado nascendo.
Abra o site, faça o percurso, olhe o dataLayer e o preview do container. Se o evento não dispara, ou dispara com o payload errado, acabou: é implementação, e você já sabe onde. Se o evento dispara certinho, com os parâmetros certos, e mesmo assim o relatório mostra outra coisa, o problema está entre a coleta e o relatório: processamento, filtro, definição de métrica, segmento aplicado sem ninguém perceber.
Esse teste parece óbvio e é justamente o que as pessoas mais pulam. Passa-se uma semana discutindo o número em reunião antes de alguém abrir o DevTools por dois minutos.
#Por que isso importa além do dado
O custo de errar esse diagnóstico não é o tempo perdido. É a confiança.
Quando um time apresenta um número que depois se revela quebrado, a próxima apresentação começa com desconfiança, mesmo que o dado esteja perfeito. E desconfiança em dado é caríssima, porque leva as pessoas a decidirem por intuição enquanto o painel fica aberto na tela, ignorado.
Por isso eu prefiro investir o tempo na frente. Reproduzir o evento, conferir o payload, confirmar a data de corte. É trabalho chato e é o que sustenta tudo que vem depois.
Não confio em número que eu não sei como foi coletado. E se eu sei como foi coletado, geralmente também sei onde ele quebra.