Tracking
Como rastrear formulários sem depender do HTML da página
Medição que lê seletor de CSS quebra no próximo deploy, em silêncio. Veja as três formas de capturar envio de formulário e qual sobrevive a mudança de layout.
Resposta rápida
Existem três formas de capturar o envio de um formulário: escutar o evento do navegador, detectar a página de confirmação, ou a aplicação publicar o evento numa camada de dados. As duas primeiras funcionam e dependem de detalhes que mudam sem aviso, como classe de CSS e URL de destino. A terceira é a única que sobrevive a redesenho, porque o evento passa a ser responsabilidade de quem constrói o formulário e não de quem configura a tag.
Medição de formulário é o tipo de coisa que funciona na demonstração e quebra três meses depois, sem erro no console e sem ninguém perceber. Vale entender por quê.
As três formas
1. Escutar o evento do navegador
A tag observa o envio nativo do formulário e dispara a conversão.
Funciona em formulário HTML tradicional. Falha em formulário construído com JavaScript que intercepta o envio para validar ou enviar por requisição, que é a maioria hoje. E não distingue qual formulário foi enviado quando há vários na página.
2. Detectar a página de confirmação
A conversão é contada quando a pessoa chega numa URL de obrigado.
Simples e com dois furos conhecidos: recarregar conta de novo, e quem chega ali por link direto ou pelo histórico é contado sem ter enviado nada. O primeiro problema é o que gera o padrão descrito em eventos duplicados.
3. A aplicação publica o evento
Quando o envio é concluído com sucesso, o próprio código do site publica um evento numa camada de dados, com os atributos que importam: qual formulário, qual valor, qual identificador único.
Por que a terceira é a que sobrevive
Medição que lê o HTML tem prazo de validade, e o prazo é o próximo redesenho. Alguém troca uma classe, refatora um componente, muda a URL de confirmação, e a conversão para de ser registrada.
O modo de falha é o pior possível: silencioso. Nada aparece quebrado na página, nenhum erro é lançado, e o gráfico simplesmente cai. Quando alguém investiga, semanas depois, a mudança já se perdeu no histórico.
Se a medição dos seus formulários foi configurada lendo o HTML da página, ela vai quebrar em silêncio no próximo deploy de front-end.
O que publicar junto com o evento
Não basta registrar que houve envio. Os atributos que transformam o evento em informação:
| Atributo | Para quê |
|---|---|
| Identificador do formulário | Distinguir contato de orçamento de newsletter |
| Identificador único do envio | Deduplicar e evitar contagem repetida |
| Valor estimado | Permitir otimização por valor |
| Origem da página | Saber qual conteúdo gerou o contato |
| Resultado da validação | Descobrir onde as pessoas travam |
Ordem de implementação
- Liste os formulários que importam e o que cada um significa para o negócio.
- Defina o nome e os atributos do evento antes de implementar.
- Publique pela aplicação, quando houver acesso ao desenvolvimento.
- Use a detecção de página como solução provisória declarada, com contagem por sessão.
- Gere identificador único por envio, para permitir deduplicação.
- Meça a falha de validação, não só o sucesso.
O container que consome esses eventos está em o que é o GTM.
Fontes e referências
- Enhanced measurement eventsAjuda do Google Analytics
- Introduction to Tag ManagerAjuda do Google Tag Manager
Perguntas frequentes
- Resolve em formulários HTML tradicionais, que disparam o evento nativo de envio ao serem submetidos. Ela falha em formulários construídos com JavaScript que interceptam o envio, que são a maioria em site moderno, e em formulários embutidos de terceiros. Quando funciona, também não distingue qual formulário foi enviado nem se houve erro de validação.