O que entra em um plano de tracking e o que ele não consegue detectar

O que é um plano de tracking?

Em análise de produto, um plano de tracking é a especificação escrita que lista cada evento que um produto envia, o momento exato em que cada um dispara, as propriedades que carrega com seus tipos, a origem que o emite e a pessoa responsável por ele, tudo acordado antes de alguém escrever o código de instrumentação. A documentação do Protocols, do Segment, o define como "a data spec outlining the events and properties you intend to collect across your Segment Sources." A versão da Amplitude acrescenta o motivo de cada linha: "A tracking plan defines every event and property you collect, why you collect each one, and which source emits it."

O plano é o contrato, e o código de tracking é a implementação. Quando os dois discordam, alguém precisa decidir qual está errado, e sem um plano não há nada contra o que conferir o código. O tracking de eventos é a prática de registrar o que os usuários fizeram. O plano de tracking é o documento que diz o que "fez" significa para cada evento.

Quais colunas um plano de tracking precisa ter?

Um plano de tracking precisa de uma linha por evento e de colunas suficientes para que um engenheiro consiga implementar o evento sem fazer nenhuma pergunta. As colunas abaixo são as que evitam discussões reais mais tarde. O editor de Tracking Plan do Segment usa uma parte delas, com os nomes Name, Description, Status, Data Type e Permitted Values.

A lista de tipos de dados do Segment é um padrão razoável para a coluna Tipo: "any, array, object, boolean, integer, number, string, null, Date time", com date-times "required to be in ISO-8601 format." A coluna Permitted Values aceita "simple regular expressions to validate property values", e isso só funciona em propriedades do tipo string.

Como é uma linha preenchida de um plano de tracking?

Uma linha preenchida parece uma pequena especificação. Aqui está um evento de um fluxo de cadastro de SaaS, escrito do jeito que um plano guardado em um repositório o manteria:

event: signup_completed
trigger: >
  Fires once, from the server, after the account row is written.
  Not on button click. Not on page load of /welcome.
answers: Signup-to-activation funnel, weekly signups by channel
source: backend
owner: growth-eng
status: live
properties:
  plan:
    type: string
    required: true
    allowed: [team, pro]
  signup_method:
    type: string
    required: true
    allowed: [email, google, github]
  invited:
    type: boolean
    required: false

O texto do gatilho é a parte que a maioria dos planos erra. "Dispara no cadastro" não diz se um envio de formulário com falha conta, se uma nova tentativa dispara duas vezes, nem se o evento vem do navegador ou do servidor. Escrever "not on button click" descarta a duplicação mais comum, em que o clique dispara e depois o servidor rejeita o formulário. O estilo de nomenclatura é uma escolha separada, e escolher uma convenção de nomes de eventos antes da primeira linha evita uma renomeação depois.

O que uma ferramenta de plano de tracking consegue validar, e o que não consegue?

Uma ferramenta de plano de tracking valida os eventos que chegam contra os eventos que o plano descreve, e não consegue avisar sobre os eventos que nunca chegam. Essa segunda metade é a coisa mais útil a saber sobre essas ferramentas, e os próprios fornecedores dizem isso.

A documentação do Segment descreve o lado da verificação: "Violations generate when an event doesn't match the spec'd event in the Tracking Plan." Depois, na descrição da coluna Status: "You can't require a Track call because Segment is unable to verify when a Track call should be fired." O Segment consegue verificar se um evento tem as propriedades obrigatórias, mas não tem como saber que o evento deveria ter disparado e não disparou.

A Amplitude cuida da direção oposta. Eventos que chegam sem estar no plano aparecem como "Unexpected", e a Amplitude diz "You can add them to your plan, or delete them to stop ingestion and remove them from your data catalog." Para a direção dos eventos ausentes, a Amplitude publica um guia separado com o título "Planned events that never arrived: confirm the problem", que manda "Compare your tracking plan with observed data and your planning records to find planned events that never reached Amplitude." A mesma página diz "Data Assistant doesn't identify these entries" e que o Observe, a visão que mostra se um evento chegou, cobre "the selected time range, up to 14 days."

Então um painel de validação todo verde significa que cada evento que chegou bateu com a sua especificação. Não significa que cada evento da especificação está chegando. A correção prática é uma verificação a cada release. Liste os eventos marcados como ativos no plano, consulte os dados recentes para cada nome e sinalize qualquer um com contagem zero. O guia da Amplitude traz a ressalva certa: um evento sem atividade "might belong to a rare workflow, a disabled feature, or a future release", então pergunte ao dono antes de apagar a linha.

Quais limites de destino pertencem ao plano?

Os limites de cada ferramenta para onde os eventos vão pertencem ao plano, porque uma linha que ultrapassa um limite falha em silêncio no destino. O Google Analytics diz isso com todas as letras: "Google Analytics doesn't log events, event parameters, and user properties that exceed the following limits."

As duas ferramentas falham de formas diferentes quando um plano passa desses limites. O GA4 descarta o item. O exemplo dele é que "Analytics doesn't process the 26th user property nor does it process an event name with more than 40 characters." A Amplitude continua recebendo os dados, mas "stops indexing new values", então os dados existem nas exportações e não podem ser consultados em gráficos. A Amplitude acrescenta que eventos acima do limite de tipos de evento "still count toward the monthly event volume", o que significa que um bug de instrumentação descontrolado custa dinheiro por dados que ninguém consegue colocar em um gráfico.

O Segment tem um limite próprio para planos gerenciados como arquivos: um CSV de Tracking Plan enviado "must be smaller than 15 mb" e precisa "have fewer than 100,000 rows and 2,000 rules."

Quantos eventos a primeira versão deve ter?

A primeira versão deve ter os poucos eventos que respondem às perguntas que a equipe já faz toda semana, e nada além disso. O guia de implementação da Amplitude diz "resist the urge to track everything upfront" e sugere "starting with two important events in your product to give you initial insights." O playbook de taxonomia da Amplitude ordena o trabalho assim: primeiro os objetivos de negócio, depois as métricas principais, depois os eventos e as propriedades de que essas métricas precisam.

Essa ordem é a certa. Comece pela métrica da revisão semanal, como a métrica north star, escreva a pergunta que ela levanta e adicione só os eventos necessários para respondê-la. Um fluxo de cadastro que precisa de uma análise de funil precisa de um evento por etapa e de uma propriedade que divida o resultado, não de quarenta eventos para cada clique na página. Se você usa o Flowsery, o tracking de metas dele "regista cadastros, compras, downloads e eventos personalizados num só lugar", e o plano é onde você decide quais dessas metas vale a pena definir.

Como manter um plano de tracking atualizado?

Um plano de tracking continua atualizado quando uma mudança no código de tracking não pode entrar sem uma mudança correspondente no plano. Todo o resto é um lembrete que as pessoas ignoram.

A coluna Status faz a maior parte do trabalho. Marcar um evento como descontinuado em vez de apagar a linha impede que um engenheiro novo reintroduza o nome antigo seis meses depois. As duas ferramentas guardam histórico. O Segment diz que as mudanças no plano feitas por upload são "reflected in the Audit Trail and Tracking Plan changelog", e a exportação em CSV nomeia cada arquivo como workspaceSlug-trackingPlanName--yyyy-mm-dd--hh-mm-utc. Um plano que vive no repositório ao lado do código ganha histórico de graça pelo controle de versão.

Perguntas frequentes

Qual é a diferença entre um plano de tracking e uma convenção de nomes de eventos?

Uma convenção de nomes de eventos é uma regra dentro de um plano de tracking: como os nomes são formados, por exemplo object_action em snake case. O plano de tracking é a lista completa de eventos que seguem essa regra, com o gatilho, as propriedades, os tipos, a origem e o dono de cada evento.

Quem deve ser o dono do plano de tracking?

Uma pessoa nomeada deve aprovar as mudanças, vinda da equipe que mais lê os dados, com os engenheiros propondo as linhas. Um plano que qualquer um pode editar sem revisão caminha para o mesmo estado de não ter plano nenhum.

O plano de tracking deve ficar em uma planilha ou em uma ferramenta?

Uma planilha funciona para uma primeira versão com algumas dezenas de eventos. Uma ferramenta como Segment Protocols ou Amplitude Data acrescenta a validação dos eventos recebidos contra o plano, e um arquivo no repositório de código acrescenta revisão e histórico por meio de pull requests.

Eventos do lado do servidor devem ir no mesmo plano de tracking?

Sim. Mantenha um único plano com uma coluna Origem, porque o mesmo nome de evento enviado pelo navegador e pelo servidor é contado duas vezes, a menos que o plano diga qual dos dois é o registro oficial. A própria definição de plano de tracking da Amplitude inclui "which source emits it".

Como encontrar eventos planejados que nunca dispararam?

Compare os eventos marcados como ativos no plano com os nomes de eventos vistos nos dados recentes e sinalize qualquer um com contagem zero. O Segment afirma que não consegue exigir uma chamada Track, e a Amplitude diz que o Data Assistant não identifica essas entradas, então nenhum painel de validação levanta o problema sozinho.

O autocapture elimina a necessidade de um plano de tracking?

Não. O autocapture registra cliques e visualizações de página, mas não registra o que um clique significou, como qual plano o usuário escolheu ou se o servidor aceitou o formulário. Os eventos que alimentam as métricas de receita e de ativação continuam precisando de um gatilho escrito e de uma lista de propriedades.

O que a coluna de trigger deve dizer?

Deve nomear o único momento em que o evento dispara, em palavras simples, incluindo o que não conta. "Dispara no cadastro" não deixa claro se um envio com falha ou uma nova tentativa conta, nem se o evento vem do navegador ou do servidor. "Dispara uma vez, pelo servidor, depois que a linha da conta é gravada. Não no clique do botão" não deixa nada para adivinhar.

Com quantos eventos um plano de tracking deve começar?

Comece com os poucos eventos que respondem a perguntas que o time faz toda semana. O guia de implementação da Amplitude diz "resist the urge to track everything upfront" e sugere começar com dois eventos importantes. Adicione outros só quando uma métrica precisar deles.

O que acontece quando um plano passa dos limites do GA4 ou da Amplitude?

O GA4 descarta o item, então uma 26ª propriedade de usuário ou um nome de evento com mais de 40 caracteres nunca é processado. A Amplitude continua ingerindo, mas para de indexar valores novos, e os dados aparecem nas exportações sem poder ser consultados em gráficos. Eventos além do limite de tipos de evento continuam contando no volume mensal de eventos.

Por que marcar um evento como deprecated em vez de apagar a linha?

Uma linha deprecated impede que um engenheiro novo reintroduza o nome antigo meses depois. O histórico também fica no plano. Antes de apagar a linha de um evento sem atividade, pergunte ao responsável, pois o evento "might belong to a rare workflow, a disabled feature, or a future release".