Um evento é uma decisão que você tomou, não algo que aconteceu
Todo produto emite uma quantidade ilimitada de coisas que acontecem: cliques, rolagens, passagens de cursor, mudanças de rota. Um evento é o pequeno subconjunto que você decidiu que merecia um nome, porque diz algo sobre o qual você agiria. Essa decisão, e não a instrumentação, é o trabalho inteiro.
A consequência prática é que um plano de medição é um documento de produto antes de ser de engenharia. Se você não consegue dizer o que faria de diferente conforme um evento dispare ou não, ele ainda não precisa existir.
Nomeie eventos por resultados, não por interfaces
clicked_blue_button deixa de ser verdade no instante em que o design publica um redesenho. report_exported sobrevive a ele, porque nomeia o que a pessoa alcançou e não o que ela tocou.
Escolha uma convenção e mantenha: objeto primeiro, ação no passado, minúsculas com underscores — invite_sent, project_created, payment_failed. A consistência importa mais do que qual convenção você escolheu, porque nomes inconsistentes são o que torna um catálogo de eventos impesquisável dois trimestres depois.
De dez a vinte eventos, não duzentos
A falha comum é rastrear tudo com a teoria de que os dados podem ser úteis depois. O que se obtém é um catálogo em que ninguém consegue navegar, três eventos que significam quase a mesma coisa e nenhum acordo sobre qual é o oficial.
Parta das perguntas que você já faz nas revisões — as pessoas estão conseguindo configurar, estão voltando, onde desistem — e instrumente apenas o que as responde. Um plano de medição que cabe em uma tela é mantido. Um que cabe em uma planilha, não.
As propriedades carregam o detalhe; o evento carrega o verbo
Resista a um evento por variante. report_exported_csv, report_exported_pdf e report_exported_xlsx deveriam ser um único evento, report_exported, com uma propriedade format. A regra prática: se em algum momento você quiser ver os números somados, é um evento com uma propriedade.
Mantenha os valores das propriedades de baixa cardinalidade e estáveis. Uma propriedade que guarda uma URL crua ou texto livre é uma coluna que você não consegue agrupar, o que a torna decoração em vez de dado.
Autocaptura e eventos explícitos respondem perguntas diferentes
A autocaptura registra interações de interface sem exigir planejamento, o que é genuinamente útil no começo: os dados de uma pergunta que você ainda não tinha feito já estão lá, e o deploy sai do ciclo. O que ela não consegue é conhecer o seu domínio. Nada num fluxo de cliques sabe que uma assinatura foi elevada.
O arranjo que funciona é ter os dois: autocaptura para explorar e para as perguntas ainda não feitas, e uma lista curta de eventos explícitos e bem nomeados para os números sobre os quais você reporta e define metas.
Por onde começar esta semana
Escreva os cinco momentos que mais importam no seu produto, nomeie-os com a convenção acima e instrumente apenas esses. Confira uma semana depois que cada um dispara quando você espera e que suas propriedades vêm preenchidas — um evento que dispara num caminho de código que ninguém usa é pior do que nenhum evento, porque ele será levado a sério.
Se quiser ver como os eventos que você já envia estão se comportando antes de acrescentar mais, o rastreamento de eventos no PulsePanda mostra cada evento, seu volume e suas propriedades em um só lugar, e alimenta os mesmos dados direto nos funis e nos caminhos.