Event tracking: o que é e como rastrear eventos de receita
Marketing te mostra um número de conversão, produto mostra outro, vendas tem um terceiro — e os três juram que puxaram “do dado”. Todos estão certos: cada um capturou o mesmo momento com um nome diferente, em uma ferramenta diferente. No fim do mês ninguém consegue dizer o que é uma “conversão” na empresa. Esse não é um problema de relatório, é um problema de captação. Este guia cobre o que é event tracking, onde o evento nasce, como implementar sem gerar caos e as armadilhas de quem já montou isso do zero.
O que é event tracking
Rastreamento de eventos é a camada de captura. Toda métrica que você opera — funil, ativação, retenção, atribuição de canal — é calculada em cima de eventos. Se o evento é capturado errado (ou não é capturado), o erro não fica na origem: ele se propaga pra cada painel, cada forecast e cada decisão que depende daquele número. Dado ruim não fica parado — ele viaja em velocidade industrial pela operação inteira.
Três confusões comuns valem separar. Event tracking não é page view tracking: contar visualização de página te diz onde a pessoa esteve; evento te diz o que ela fez — clicou em “Assinar”, adicionou ao carrinho, convidou um colega, cancelou. Página é lugar; evento é ação, e você não monta funil de comportamento com contagem de página. Event tracking não é o CRM: o CRM guarda o estado do negócio (estágio, dono, valor); o event tracking guarda o comportamento que levou àquele estado — um é a foto do deal, o outro é o filme de como ele chegou lá. Event tracking não é o modelo de dados: capturar o evento é diferente de modelá-lo — o evento cru entra, e a modelagem de receita e o star schema organizam esse cru em algo que a análise consulta. Rastreamento é a matéria-prima; modelagem é a fábrica. Capturar bem e modelar mal (ou o contrário) quebra igual.
O termo técnico é “event tracking” ou “instrumentação”. Produto costuma falar em “eventos de produto” (product analytics); marketing fala em “conversões”; o pessoal de dados fala em “telemetria” ou “eventos de comportamento”. É tudo a mesma coisa: registrar a ação como um dado estruturado, com um nome estável e propriedades que dão contexto. E o objeto que segura isso de pé tem nome próprio — o tracking plan: a lista viva dos eventos válidos, o que cada um significa, quais propriedades carrega e quem é o dono. Sem tracking plan, event tracking é cada time inventando o seu — que é exatamente o cenário do primeiro parágrafo.
Na prática, um evento bem definido é sempre a mesma anatomia — cinco partes que juntas transformam um clique anônimo em um dado que o funil consegue ler:
| Elemento | O que carrega | Exemplo |
|---|---|---|
| Nome do evento | a identidade canônica da ação (padrão “Objeto Ação”) | Checkout Started |
| Propriedades | o contexto que qualifica o evento | plan: Pro · value: 490 · currency: BRL |
| Identidade | quem fez — ligável entre client, server e CRM | user_id: 8821 |
| Timestamp | quando aconteceu, sempre em UTC | 2026-07-18T14:03:00Z |
| Origem (em evento de conversão) | o canal/campanha que trouxe a pessoa | utm_source: google · campaign: q3-brand |
Como implementar event tracking
O evento nasce em três lugares, e você precisa saber em qual antes de rastrear qualquer coisa. Client-side é o navegador ou o app, via SDK de analytics — bom pra capturar comportamento de UI, ruim porque adblock, o ATT do iOS e falha de rede comem parte dos eventos. Server-side é o backend disparando o evento quando a ação de fato aconteceu — mais confiável pra dinheiro (pagamento aprovado, assinatura criada), porque o servidor não mente sobre isso. E há as fontes já estruturadas — CRM, billing/ERP, gateway de pagamento — que já registram ações como dado. A jornada real quase sempre mistura os três, e por isso o destino comum de tudo é um data warehouse, onde os eventos de todas as fontes se encontram com a mesma identidade de usuário.
A ordem certa é contraintuitiva: o tracking plan vem antes do primeiro evento. Escrever o contrato — nome canônico de cada evento (padrão “Objeto Ação”: Checkout Started, não clicou_botao), propriedades obrigatórias, tipo de cada uma e o dono — é o passo que a maioria pula, e é o que separa dado confiável de caos. Depois vem padronizar identidade e tempo (um jeito único de identificar o mesmo usuário entre client, server e CRM; timestamps sempre em UTC), decidir client vs. server por evento, e só então instrumentar. O tracking plan funciona como a especificação dos eventos, validada por schema na ingestão — é a base do portão de validação[1].
Como event tracking não tem uma fórmula canônica como CAC ou NRR — é prática de arquitetura, não índice —, a métrica que você deveria operar é a taxa de conformidade: eventos recebidos que batem o tracking plan ÷ total de eventos recebidos, onde “bater o plano” quer dizer nome existe, propriedades obrigatórias presentes e tipos corretos. Ela é o termômetro que diz se o resto dos seus números merece confiança. E ela engana: 85% de conformidade parece “quase certo”, mas os 15% não-conformes não somem — caem em relatório como null, viram uma segunda linha de funil (checkout_start e Checkout Started contados como coisas diferentes), ou um value em texto zera sua receita por evento. Você não perde 15% do dado de forma limpa e visível; você ganha 15% de dado sujo disfarçado de bom, que contamina a média.
Padrões e boas práticas
Event tracking não tem um benchmark de mercado canônico como win rate ou NRR. O que existe são números sobre o custo do dado ruim — sólidos e citáveis — e taxas de erro de implementação reportadas por fornecedores de ferramentas de qualidade, que são apenas direcionais (a amostra é enviesada: quem audita já desconfia que tem problema). Use a primeira família como argumento de “por que isso importa” e a segunda só pra dimensionar ordem de grandeza — nunca como meta fechada.
| O que o número mede | Referência | Fonte |
|---|---|---|
| Custo médio anual do dado ruim por organização | ~US$ 12,9 milhões/ano | Gartner, 2021[2] |
| Custo do dado ruim para a economia dos EUA | ~US$ 3,1 trilhões/ano | IBM via HBR, 2016[3] |
| Registros recém-criados com ≥1 erro crítico | ~47% (média) | HBR, 2017[4] |
| Dados que atingem padrão “aceitável” de qualidade | ~3% | HBR, 2017[4] |
| Receita perdida por dado ruim (estimativa) | ~15%–25% da receita | MIT Sloan (Redman)[5] |
| Nº de tipos de evento num tracking plan saudável | ~10 a 200 | Amplitude[6] |
Duas réguas fecham a leitura. A primeira: um tracking saudável fica acima de ~95% de conformidade, não em “a maioria bate” — o intervalo entre 85% e 95% é onde moram as decisões erradas que ninguém rastreia até a origem[7]. A segunda: “10 a 200 eventos” é a faixa de sanidade, não de ambição[6]. Time que se orgulha de ter 900 tipos de evento quase sempre tem 900 nomes e 200 conceitos — o resto é duplicata que ninguém consulta. Menos eventos bem definidos medem melhor que muitos eventos vagos, a mesma lógica de estágio de funil: nomear demais é não medir nada.
Onde o evento nasce
Quem entra
- 1 Comece pela pergunta, não pelo evento. Liste as decisões que o dado precisa sustentar (onde o funil vaza, qual canal traz cliente que ativa) e rastreie o que as responde — não “tudo, por via das dúvidas”.
- 2 Escreva o tracking plan antes de instrumentar. Nome canônico (padrão “Objeto Ação”), propriedades obrigatórias, tipo de cada uma e o dono. É o passo que a maioria pula — e o que separa dado confiável de caos.
- 3 Padronize identidade e tempo. Um jeito único de identificar o mesmo usuário entre client, server e CRM; timestamps sempre em UTC. Sem isso, você tem cacos de comportamento de pessoas que o sistema acha diferentes.
- 4 Decida client vs. server por evento. Comportamento de UI pode ser client-side; qualquer evento que vira dinheiro vai server-side, onde adblock e ATT não apagam.
- 5 Coloque um portão de validação. Valide o evento contra o plano na entrada (schema validation) — o que não bate o contrato é barrado ou sinalizado antes de virar relatório, não depois.
- 6 Trate como código. Versione o plano, exija review pra mudar evento, teste no CI. Mudança de tracking sem review é a causa nº 1 de dado que quebra silenciosamente num deploy de sexta.
- 7 Monitore a saúde da captação. Taxa de conformidade e volume por evento num painel com cadência — queda súbita de volume quase sempre é tracking quebrado, não queda real de comportamento.
Armadilhas comuns
Estes são os erros que mais aparecem quando ajudamos um time a montar event tracking do zero — a maioria nasce de instrumentação e governança, não de ferramenta.
Instrumentar antes de escrever o tracking plan
O erro que mais aparece é já sair colocando evento no código “pra começar a ter dado”. Três semanas depois existem signup, sign_up, Signup Completed e user_registered — quatro nomes pro mesmo cadastro, cada um de um dev, cada um contado separado. O funil soma quatro linhas que são a mesma coisa e ninguém confia no total. O plano vem antes do primeiro evento, sempre: não é burocracia, é o contrato que impede o caos.
Rastrear tudo “por via das dúvidas”
O oposto do erro anterior e igualmente mortal. O time captura 800 eventos porque “melhor ter e não precisar”. Aí ninguém sabe qual dos 800 é o que importa, metade nunca é consultada, e a que importa está enterrada no ruído. Já vimos operação parada porque a pergunta “quantos ativaram?” não tinha resposta — não por falta de evento, por excesso. Rastreie o que responde uma pergunta de negócio; o resto é dado que você paga pra armazenar e nunca olha.
Confiar em captura client-side pra evento que vale dinheiro
O Purchase disparado no navegador some por adblock, por ATT do iOS, por aba fechada antes do script rodar. A gente vê o time reportar 15% menos receita no analytics do que no gateway de pagamento e culpar o “marketing que caiu” — quando é só o evento de compra sendo comido no client. Dinheiro se rastreia server-side, onde a ação de fato aconteceu. Client-side é pra comportamento de tela, não pra caixa.
Nenhuma identidade única entre as camadas
O usuário é anônimo no site, vira lead no CRM, vira cliente no billing — e os três sistemas guardam esse mesmo humano com três IDs que ninguém casou. A jornada fica picada: você tem o clique e tem a compra, mas não consegue ligar um no outro. O resultado é atribuição furada e funil que não fecha. Identidade única entre client, server e CRM é pré-requisito, não refinamento.
Tracking sem portão de validação
O plano existe, está bonito no Notion — mas nada impede um evento fora do plano de subir pra produção. Sem validação na entrada, o plano é decoração. A gente encontra sempre a mesma cena: o schema está documentado e o dado não bate o schema, porque o documento não barra nada. Contrato sem fiscal é sugestão. Valide na ingestão, ou o plano não vale o arquivo em que está escrito.
Mudar o código e esquecer que mexeu no tracking
Deploy renomeia um botão, refatora um componente, e o evento para de disparar — ou passa a disparar duas vezes. Ninguém percebe porque o site funciona; só o dado quebrou. Duas semanas depois o relatório mostra uma “queda de conversão” que é puro artefato de deploy. Event tracking quebra com mudança de código como qualquer dependência — precisa de teste no CI e de alerta de volume, senão você descobre tarde e olhando pro número errado.
Não rastrear a origem no evento de conversão
O evento Lead Created sobe limpo, com nome certo, tipo certo — e sem a campanha/canal que trouxe a pessoa. Aí marketing pede atribuição e não tem de onde tirar: o evento não carrega a origem. Já vimos time refazer meses de instrumentação só pra adicionar UTM/canal num evento que já estava “pronto”. Propriedade de origem no evento de conversão não é opcional — é o que faz a atribuição existir.
Checklist de implementação
FAQ
Perguntas frequentes sobre event tracking
As dúvidas que mais aparecem de quem instrumenta e opera os dados.
Monte a fundação antes de cobrar o número
Event tracking não se resolve com um painel — é arquitetura de captura: tracking plan, identidade única, portão de validação, decisão client vs. server. Alguém precisa estruturar essa fundação antes de qualquer número existir. É exatamente o trabalho de RevOps que a Incuca faz na sua operação: do contrato dos eventos ao painel que monitora a saúde da captação, para que funil, atribuição e ativação parem de divergir entre times.
Referências
- [1] Twilio Segment. Protocols — Tracking Plan (documentação de produto): especificação de eventos e propriedades, validação por schema na ingestão. https://segment.com/docs/protocols/tracking-plan/create/
- [2] Gartner. How to Improve Your Data Quality. 2021 — dado ruim custa às organizações uma média de ~US$ 12,9 milhões por ano. https://www.gartner.com/en/data-analytics/topics/data-quality
- [3] Redman, Thomas C. Bad Data Costs the U.S. $3 Trillion Per Year. Harvard Business Review, 2016 — estimativa IBM de ~US$ 3,1 trilhões/ano; conceito das hidden data factories. https://hbr.org/2016/09/bad-data-costs-the-u-s-3-trillion-per-year
- [4] Nagle, Redman & Sammon. Only 3% of Companies’ Data Meets Basic Quality Standards. Harvard Business Review, 2017 — ~47% dos registros recém-criados têm ≥1 erro crítico; ~3% atingem padrão aceitável. https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards
- [5] Redman, Thomas C. Seizing Opportunity in Data Quality. MIT Sloan Management Review, 2017 — dado ruim custa de ~15% a 25% da receita para a maioria das empresas. https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/
- [6] Amplitude. Common Event Tracking Pitfalls and How to Avoid Them (blog técnico) — faixa de sanidade de ~10 a 200 tipos de evento; tratar tracking como código. https://amplitude.com/blog/event-tracking-pitfalls
- [7] Trackingplan. Digital analytics root cause guide: fix tracking in 2026 — régua de event tracking saudável acima de ~95% de conformidade (direcional; fornecedor). https://webflow.trackingplan.com/blog/digital-analytics-root-cause-guide-fix-tracking-in-2026-en
