Como montar um tracking plan antes da feature ir ao ar

Um time envia Product Clicked. Outro, no mesmo projeto, envia Product Click. Um terceiro manda product_clicked. Para as pessoas, é o mesmo clique. Para a ferramenta, são três eventos.

Esse é um dos erros de tracking que mais vejo. A boa notícia é que ele quase sempre pode ser evitado antes de o código existir.

Resumo rápido: um tracking plan é a tabela que diz quais eventos existem, como se chamam, quando disparam e quem responde por eles. Monte-o antes da feature. Defina um padrão de nome por ferramenta, um dono por evento e uma revisão no pull request. O custo de fazer isso é baixo. O de não fazer aparece depois, em dashboards sem dado.

O que é um tracking plan

Tracking plan é um documento, em geral uma tabela, que descreve cada evento medido. Para cada um, registra o nome, o momento do disparo, as propriedades enviadas e o responsável.

Ele funciona como um contrato entre produto, engenharia e análise. Sem contrato, cada time escreve o evento do seu jeito, e a diferença só aparece quando alguém monta um relatório.

O erro mais comum: cada time com o seu padrão

Nos projetos por onde passei, adotamos snake_case no GA4 e Title Case no Amplitude, sempre no padrão objeto_ação. O mesmo clique vira product_clicked no GA4 e Product Clicked no Amplitude. Funciona porque a regra é a mesma e está escrita.

O problema começa quando existem muitos times e nenhuma regra compartilhada. Os desvios que mais aparecem:

• Verbo diferente: Product Clicked num time e Product Click no outro.
• Ordem diferente: Product Clicked e Clicked Product.
• Formato diferente: um time envia Title Case e outro snake_case para a mesma ferramenta.

As duas ferramentas tratam essas variações como eventos distintos. O GA4 diferencia maiúsculas de minúsculas e aceita só letras, números e sublinhados nos nomes (consultado em 17/10/2026). O guia de taxonomia do Amplitude informa que Song Played e song played são dois eventos. Song Played e Played Song também são (consultado em 17/10/2026).

Erro de tracking é mais do que erro de convenção

Um nome fora do padrão parece um detalhe de estilo. Na prática, tem duas consequências.

Perde-se visibilidade. Um dashboard ou uma métrica filtra por um nome exato. Se parte dos cliques chega como Product Click, essa parte não entra no gráfico. O número cai e ninguém sabe por quê. Esse efeito segue direto do funcionamento descrito pelas duas ferramentas, mas a magnitude depende do seu caso.

Acumula-se sujeira. Eventos duplicados ou fora do padrão ficam na base. Quem monta um relatório novo precisa descobrir qual nome usar e se os outros contam. Com o tempo, a confiança nos dados cai. Isso aproxima este tema do que expliquei em Por que Amplitude e GA4 não mostram o mesmo número?: parte da diferença que o time vê vem do próprio plano, não das ferramentas.

Como montar o plano antes da feature

1. Defina o padrão de nome para cada ferramenta

Escolha uma regra e escreva-a. A que uso é objeto_ação, com o verbo no passado:

• GA4: snake_case, como product_clicked. Use só letras, números e sublinhados, começando por letra.
• Amplitude: Title Case, como Product Clicked. Nos eventos padrão, o guia do Amplitude usa o substantivo seguido do verbo no passado, sob a ótica do usuário. Ele aceita uma convenção própria, se for consistente.

O mais importante é que o padrão seja um só e que todos os times o conheçam. Se o seu time já adota outro, siga o dele.

Evite nomes reservados do GA4 para eventos customizados. A documentação do GA4 lista nomes como click, error, page_view e form_submit, e avisa para não usá-los.

2. Escreva a tabela

Crie uma linha por evento. Antes de começar a feature, o time de produto e o de engenharia preenchem juntos.

Acrescente uma coluna para as propriedades de cada evento, com nome e tipo. Os exemplos acima são ilustrativos, não vêm de um projeto real.

3. Dê um dono a cada evento

Cada linha tem um responsável. Ele responde por mudar o evento, aposentá-lo ou resolver uma dúvida. Evento sem dono vira evento que ninguém ousa mexer. Essa regra é minha prática; os guias das ferramentas não tratam de quem é o dono do plano.

4. Gere os nomes a partir de um único lugar

Se cada pessoa digita o nome no código, o desvio acontece. Centralize os nomes e derive as duas versões:

type TrackedEvent = 'product_clicked' | 'cart_viewed';

const amplitudeNames: Record<TrackedEvent, string> = {
  product_clicked: 'Product Clicked',
  cart_viewed: 'Cart Viewed',
};

export function track(event: TrackedEvent, properties?: Record<string, string>) {
  window.dataLayer?.push({ event, ...properties });
  // o envio ao Amplitude usa amplitudeNames[event]
}

O tipo faz o compilador rejeitar um nome que não esteja no plano. Escrever Product Click deixa de compilar.

5. Revise no pull request

Inclua no template do pull request uma pergunta: esta mudança adiciona ou altera um evento? Se sim, o plano foi atualizado, e o nome segue o padrão? A revisão custa minutos e pega o desvio antes de ele chegar à produção.

6. Confira depois do deploy

Antes de divulgar a feature, abra as duas ferramentas e confirme que o evento chegou com o nome esperado. Depois, de tempos em tempos, procure eventos fora do padrão. O ideal é encontrá-los antes de alguém montar um dashboard em cima deles.

O que fazer agora

Pegue os cinco eventos mais importantes do seu produto e escreva-os na tabela, com nome nas duas ferramentas, momento do disparo e dono. Se já existir variação de nome entre eles, você acabou de encontrar o primeiro item a corrigir.

Nota de IA: usei inteligência artificial na pesquisa e no rascunho deste texto. A experiência com os padrões de nomes vem de projetos em que trabalhei, e a revisão e as opiniões são minhas. Trabalho com Amplitude e tenho a certificação Amplitude Data Management, sem patrocínio nem parceria com Amplitude ou Google. Como escrevo.