Qual é a diferença entre um plano de rastreamento e um dicionário de dados?

Um plano de rastreamento é prescritivo: diz o que deve ser instrumentado, antes de o código ser entregue. Um dicionário de dados é descritivo: documenta os dados que já existem, com todos os defeitos. Equipes pequenas costumam juntar os dois — um único documento que é ao mesmo tempo a especificação e a referência.

Quem deve ser o responsável pelo plano de rastreamento?

Uma pessoa nomeada — em uma startup pequena, em geral o fundador mais próximo dos dados ou o growth engineer. Ser responsável significa aprovar cada novo evento e rejeitar nomes que quebram a convenção, não escrever pessoalmente cada entrada.

Quantos eventos um plano de rastreamento deve ter?

Menos do que você imagina. Comece com os eventos de que o seu funil e a sua métrica de ativação precisam, e acrescente um só quando uma pergunta real exigir. Cada evento é um compromisso de manutenção; tanto o Segment quanto a Amplitude recomendam manter a taxonomia enxuta.

Que ferramentas conseguem fazer cumprir um plano de rastreamento?

Ferramentas de validação de schema — Segment Protocols, Amplitude Data, Avo — bloqueiam ou sinalizam os eventos que não batem com o plano. Sem elas, um linter para os nomes de eventos e uma regra de revisão (nenhum evento novo sem entrada no plano) pegam a maior parte do desvio na escala de duas pessoas.

O que é um plano de rastreamento?

Um plano de rastreamento (tracking plan) é a especificação viva de cada evento de análise que um produto instrumenta: o nome de cada evento, suas propriedades, quando ele é acionado e quem é o responsável. É o contrato entre quem entrega o código e quem lê os dados, para que o mesmo comportamento seja sempre registrado da mesma forma.

Atualizado em 8 de jul. de 20262 min de leituraPor fromHello

O essencial

Uma linha por evento — nome, propriedades, gatilho, responsável — e o plano muda no mesmo pull request que o código.
Uma única convenção de nomes, em geral objeto_ação em snake_case (subscription_started), mantém os eventos consultáveis meses depois.
O desvio — renomeações, duplicatas, propriedades ausentes — corrompe em silêncio funis, segmentos e todos os relatórios que dependem deles.

O que entra em um plano de rastreamento?

No mínimo, uma linha por evento: o nome do evento, as propriedades associadas a ele, o momento exato em que ele é acionado e a pessoa responsável. Os bons planos também registram quais ferramentas recebem o evento e a pergunta que ele existe para responder — um evento que ninguém consulta é manutenção sem retorno. O formato importa menos que o hábito: uma planilha, um arquivo versionado no repositório ou uma ferramenta de schema como Segment Protocols ou Amplitude Data, todos funcionam, desde que o plano seja atualizado no mesmo pull request que o código de rastreamento.

Plano de rastreamento: A especificação viva de cada evento instrumentado — nomes, propriedades, gatilhos, responsáveis —, mantida em sincronia com o código entregue.
Evento: O registro, com data e hora, de uma ação, como subscription_started; a unidade que o plano descreve.
Propriedade: Um detalhe chave-valor associado a um evento — plano, origem, valor — que torna o evento filtrável e comparável.
Convenção de nomes: A regra comum para os nomes de eventos, em geral objeto_ação em snake_case, que mantém o conjunto de dados consultável.

O plano de rastreamento e os termos que o compõem.

Como nomear os eventos?

Escolha uma convenção e aplique-a em todo lugar. A mais comum é objeto_ação em snake_case: subscription_started, invoice_paid, report_exported. O objeto primeiro, para que os eventos relacionados fiquem juntos na ordenação; a ação no passado, porque o evento registra algo que aconteceu. A convenção escolhida importa menos que a uniformidade — Sign Up, signup e user_signed_up no mesmo conjunto de dados são três eventos que sua ferramenta de análise trata como desconhecidos entre si, e todo gráfico construído sobre eles está errado.

O que é desvio de rastreamento e por que ele destrói a análise?

O desvio (drift) é a distância que se abre entre o plano e o que o código de fato envia: um evento é renomeado sem atualizar o plano, uma propriedade muda de tipo, uma duplicata aparece com outro nome. Cada mudança é pequena; juntas, fazem os funis contarem a menos, os segmentos dinâmicos deixarem de pegar os usuários que deveriam e os painéis virarem ficção — e aí a equipe deixa de confiar nos dados de vez. A cura é de processo, não técnica: nenhum evento é entregue sem uma entrada no plano, e revisar essa entrada faz parte da revisão de código.

Por que isso importa para uma equipe de duas pessoas

Equipes pequenas pulam o plano porque ele tem cara de processo de uma empresa que elas ainda não são. A lógica é a inversa: com duas pessoas, ninguém lembra em outubro por que checkout_completed e order_completed existem ao mesmo tempo. Um plano de uma página escrito antes do primeiro evento custa uma tarde — é o primeiro trabalho de um growth engineer. Para ver como o plano se encaixa em uma configuração completa, do SDK ao consentimento, leia o guia de dados first-party e rastreamento.

Fontes

FAQ

Perguntas frequentes

Qual é a diferença entre um plano de rastreamento e um dicionário de dados?
Um plano de rastreamento é prescritivo: diz o que deve ser instrumentado, antes de o código ser entregue. Um dicionário de dados é descritivo: documenta os dados que já existem, com todos os defeitos. Equipes pequenas costumam juntar os dois — um único documento que é ao mesmo tempo a especificação e a referência.
Quem deve ser o responsável pelo plano de rastreamento?
Uma pessoa nomeada — em uma startup pequena, em geral o fundador mais próximo dos dados ou o growth engineer. Ser responsável significa aprovar cada novo evento e rejeitar nomes que quebram a convenção, não escrever pessoalmente cada entrada.
Quantos eventos um plano de rastreamento deve ter?
Menos do que você imagina. Comece com os eventos de que o seu funil e a sua métrica de ativação precisam, e acrescente um só quando uma pergunta real exigir. Cada evento é um compromisso de manutenção; tanto o Segment quanto a Amplitude recomendam manter a taxonomia enxuta.
Que ferramentas conseguem fazer cumprir um plano de rastreamento?
Ferramentas de validação de schema — Segment Protocols, Amplitude Data, Avo — bloqueiam ou sinalizam os eventos que não batem com o plano. Sem elas, um linter para os nomes de eventos e uma regra de revisão (nenhum evento novo sem entrada no plano) pegam a maior parte do desvio na escala de duas pessoas.

fromHello é um software de automação de marketing de código aberto: mensagens acionadas pelo que as pessoas fazem.

O fromHello Cloud está disponível em acesso antecipado pela lista de espera.

Entrar na lista de espera Dar uma estrela no GitHub

Ninguém empreende para ficar pequeno.

O acesso antecipado ao fromHello Cloud é liberado em etapas. O onboarding é assistido: ajudamos você a configurar tudo e a trazer seus contatos.

Ainda não quer entrar? Ver no GitHub