O plano de rastreamento de eventos para startups

O que é um plano de rastreamento

Um plano de rastreamento é um documento único que lista todos os eventos que o seu produto registra, as propriedades associadas a cada um, o momento exato em que ele é acionado e a pessoa responsável por ele. É o contrato entre o código que emite os dados e os painéis que os leem. Trate-o como uma especificação viva que muda com o produto, não como um documento que você escreve uma vez e esquece. Para a versão em uma linha, veja plano de rastreamento; este guia mostra como montar um.

Por que um plano é melhor que o rastreamento improvisado

Sem um plano, o rastreamento vai se acumulando. Um engenheiro registra signup, outro registra Sign Up, um terceiro registra user_registered — três nomes para uma ação, e todo funil que passa pelo cadastro se divide ou quebra sem aviso. Isso é desvio, e é o principal motivo para as análises deixarem de ser confiáveis. Um plano fixa o vocabulário antes de o código ir para produção, para que os números que você puxar daqui a seis meses ainda signifiquem o que você pensa. Eventos limpos e consistentes também são a base de um roadmap de experimentação — não dá para medir um teste por uma métrica que você registra de três jeitos diferentes.

Nomeie os eventos como object_action e não abra exceção

A convenção que a maioria das ferramentas de análise recomenda é object_action: o objeto e depois o que aconteceu com ele — subscription_started, invite_sent, checkout_completed. Segment, Amplitude e PostHog descrevem, cada um, uma variante (o Segment usa “Object Action”, o PostHog snake_case em minúsculas, a Amplitude um substantivo mais um verbo no passado). A capitalização exata importa bem menos do que escolher uma e nunca quebrá-la. Duas regras concentram a maior parte do valor: mantenha o tempo verbal consistente e nunca monte nomes de eventos dinamicamente — um evento chamado plan_${name}_upgraded cria um evento por cliente e não dá para consultá-lo.

Os 8–10 eventos que mapeiam o seu funil

Resista à tentação de rastrear tudo. Comece com o punhado de eventos que acompanham um usuário do primeiro contato ao pagamento — cadastro, ativação e receita — e instrumente bem esses eventos antes de ganhar profundidade. Abaixo está um conjunto inicial para um SaaS B2B típico; renomeie os eventos com os substantivos do seu produto. Cada um vira uma linha do seu plano e, juntos, formam o seu primeiro conjunto de dados first-party — a matéria-prima de cada funil, coorte e curva de retenção que você vai construir. Onde cada evento é instrumentado — no navegador ou no servidor — é uma decisão à parte: rastreamento server-side vs. client-side trata dessa divisão.

As propriedades carregam o detalhe; os responsáveis mantêm tudo limpo

Mantenha os eventos poucos e genéricos; jogue os detalhes para as propriedades. Em vez de um evento separado para cada plano, registre subscription_started com as propriedades plan_name e amount_usd — um único evento, bem descrito, continua consultável. Mantenha enxuto o conjunto de propriedades de cada evento — um punhado que você realmente consulta vale mais que dezenas que você nunca usa. Depois, defina a responsabilidade: na maioria das equipes pequenas, ela fica com um Growth Engineer ou com quem entrega a instrumentação, e todo evento novo deve passar por essa pessoa para que o plano e o código nunca se afastem. Por fim, saiba onde os eventos vão parar. Enviá-los para uma ferramenta de análise hospedada ou uma CDP é rápido, mas coloca os seus dados comportamentais nos servidores de outra empresa; mantê-los first-party — Postgres auto-hospedado, o seu próprio data warehouse — mantém esses dados com você, que é o dilema central entre código aberto e SaaS nas ferramentas de engajamento.