31 dias sem lead: o que a investigação encontrou
Um commit trocou o CTA da home e o site ficou 31 dias sem gerar lead. O post-mortem: causa raiz, dois bugs silenciosos e uma métrica de GA4 mal configurada.
Trinta e um dias. Foi esse o tempo que o site ficou sem receber um único lead novo, um número feio o bastante para nos fazer parar tudo e investigar. O resultado foi um post-mortem com uma causa raiz clara e mais dois bugs que não tinham nada a ver com ela, mas que escondiam o problema real havia semanas sem disparar nenhum alarme.
A causa raiz: um clique que virou o CTA errado
Rastreando os commits, achamos o responsável um dia depois do último lead recebido: um commit trocou o link do botão principal do hero da home. Antes ele apontava para /contato. Depois da troca, passou a apontar para o Raio-X, nossa ferramenta de diagnóstico automático que grava a tela do visitante para gerar um relatório. A partir daquele commit, quem clicava no botão mais visível da home não caía mais no formulário de contato: caía em outra funcionalidade.
Por que o Raio-X nunca convertia
O Raio-X não estava parado: registramos 159 requisições em 3 dias só na etapa de gravação de tela. Nenhuma delas virou lead. A causa é uma dependência de plataforma: o Raio-X usa a API getDisplayMedia do navegador para capturar a tela, e essa API simplesmente não existe no Safari do iOS nem no Chrome do Android. Tráfego frio vindo de redes sociais é majoritariamente mobile, então a maior parte de quem clicava esbarrava numa funcionalidade inacessível no aparelho que estava usando.
O fix teve duas partes. Primeiro, o CTA principal do hero voltou a apontar para /contato: o Raio-X virou uma opção secundária. Segundo, adicionamos uma checagem de compatibilidade antes de tentar gravar a tela. Quando o navegador não suporta, o visitante não trava mais sem alternativa: agora vê um aviso que leva a um caminho de upload de vídeo manual.
Um segundo bug, achado no caminho: tempo negativo
Investigando o funil, apareceu um bug independente no próprio formulário de contato. A proteção anti-robô rejeita envios que acontecem em menos de 5 segundos após o formulário abrir, um sinal comum de automação. O cálculo de tempo decorrido não tinha proteção contra valor negativo: se o relógio do computador de quem preenchia o formulário estivesse adiantado em relação ao nosso servidor, o tempo decorrido dava um número negativo, que é menor que 5 segundos igual a qualquer outro. O envio era descartado em silêncio, mas a resposta para o visitante continuava sendo sucesso (HTTP 200). Tinha gente preenchendo o formulário, vendo a confirmação de envio na tela, e o lead nunca chegava a lugar nenhum.
Um terceiro problema, num sistema totalmente separado
A investigação também esbarrou num terceiro bug, sem relação com os dois primeiros: a rotina automática de reengajamento de leads que não respondem (o lead-nurture) estava quebrada em produção havia semanas. A causa era um erro de tipo na consulta ao banco, uma comparação entre um enum e um texto. O efeito era o mesmo dos outros dois: a rotina retornava código de sucesso mesmo falhando, então nenhum e-mail de reengajamento estava saindo e ninguém percebeu, porque nada ali parecia uma falha.
O GA4 também estava errado, só que ao contrário
Reconfigurando as métricas de conversão no Google Analytics 4 depois dos fixes, encontramos mais uma peça solta: duas conversões estavam marcadas como "conversão principal" no GA4, mas nenhuma das duas existia de fato no código do site. A plataforma mostrava "nenhum dado" para as duas desde sempre. Ou seja, o zero de conversões que aparecia antes não media o que a gente achava que estava medindo: era um problema de configuração, não um retrato real da performance do site.
A lição: bug silencioso não dispara alarme
Dois dos três bugs de código compartilham uma característica perigosa: o formulário que descarta o envio e responde 200, e a rotina de lead-nurture que falha na consulta e responde 200 assim mesmo. Nos dois casos, o sistema reportava sucesso enquanto fazia a coisa errada, sem que nenhum log de erro aparecesse. O problema do CTA era de outra natureza (um link apontando para o lugar errado, sem status code envolvido), mas teve o mesmo efeito prático: nada quebrava visivelmente, o clique acontecia, a página carregava. Falha silenciosa, seja em forma de um HTTP 200 indevido ou de um link mal configurado, é o tipo de problema mais perigoso justamente porque não existe alarme pronto para disparar. A única forma de pegar isso foi quando um número essencial (leads novos) ficou visivelmente zerado por tempo longo demais, e alguém foi atrás do porquê.
A configuração de GA4 que corrigimos aqui foi só o começo: a arquitetura completa de atribuição de conversão (como medimos origem de campanha e indicação sem exigir banner de cookies) está detalhada em Como medimos atribuição de conversão sem banner de cookies.
Se o funil do seu site também depende de um CTA, um formulário e uma rotina de automação rodando sem ninguém checando o resultado real, vale a pena revisar com a mesma lente antes que o número zerado apareça. Conta pra gente o contexto e vemos se faz sentido olhar isso junto.