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.
Uma convenção de nomes que você pode copiar
A maioria das equipes não precisa inventar uma convenção, só colocá-la por escrito. Esta é curta o bastante para ser lembrada e rígida o bastante para manter o catálogo fácil de pesquisar:
| Regra | Faça | Não faça |
|---|---|---|
| Primeiro o objeto, depois a ação | invite_sent | sent_invite |
| No passado, porque já aconteceu | project_created | create_project |
| Minúsculas com underscores | plan_upgraded | PlanUpgraded, plan-upgraded |
| Nomeie o resultado, não o controle | report_exported | export_button_clicked |
| Variações vão nas propriedades | report_exported com format: csv | report_exported_csv |
| Nada de dados pessoais em nomes ou valores | plan: team | email: ana@acme.com |
Coloque a convenção no topo do plano de tracking e revise cada evento novo com base nela, como você revisa código com base em um guia de estilo. Um nome ruim é pago toda vez que alguém procura o evento e não o encontra.
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.
Um exemplo prático: um plano de tracking para um app SaaS B2B
Veja como ficam doze eventos em um produto SaaS típico baseado em equipes. Cada um existe porque responde a uma pergunta que alguém já faz em uma revisão semanal.
| Evento | Dispara quando | Propriedades-chave | A pergunta que responde |
|---|---|---|---|
signup_completed | A conta existe, não quando o formulário é enviado | source | Quais canais trazem pessoas que realmente concluem? |
workspace_created | O primeiro workspace é salvo | team_size | Quantos cadastros chegam a configurar algo? |
teammate_invited | Um convite é enviado | role | A conta está se espalhando para além de uma pessoa? |
invite_accepted | A pessoa convidada entra | role | Os convites viram colegas de equipe? |
integration_connected | Uma conexão dá certo | integration | Quais integrações as equipes retidas usam? |
project_created | Um projeto é salvo | template | O objeto principal está sendo criado, afinal? |
report_viewed | Um relatório termina de renderizar | report_type | O que as pessoas voltam para ver? |
report_exported | O arquivo é gerado | format | O resultado está saindo do produto? |
plan_upgraded | O faturamento confirma a mudança | from_plan, to_plan | O que acontece logo antes de as pessoas pagarem mais? |
payment_failed | O provedor de pagamentos informa uma falha | reason | Quanto do churn é involuntário? |
subscription_cancelled | O cancelamento entra em vigor | reason | Por que as equipes vão embora? |
feedback_submitted | O formulário de feedback é enviado | category | O que os usuários pedem, com as próprias palavras? |
Vale notar duas coisas. A maioria desses eventos dispara com um resultado, não com um clique: um convite pode ser clicado e mesmo assim falhar. E os eventos de faturamento nem acontecem no navegador. Eles chegam pelos webhooks do seu provedor de pagamentos, então uma análise só de navegador nunca vai vê-los. Tudo bem, desde que ninguém trate um clique em “Fazer upgrade” como receita.
A ativação costuma ser uma combinação desses eventos, e não um só, por exemplo um workspace criado e um colega convidado na primeira semana. Escolha essa definição de propósito; benchmarks de funil de ativação explica como.
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.
Erros de rastreamento de eventos que quebram relatórios em silêncio
- Disparar no clique em vez de no resultado. Um clique em “Exportar” não é uma exportação. Se a requisição falhar, o evento já mentiu. Envie eventos de resultado depois que a ação der certo.
- Disparo duplo em aplicações de página única. Um componente que renderiza de novo ou uma rota montada duas vezes pode enviar o mesmo evento duas vezes. Confira algumas sessões manualmente antes de confiar em uma contagem.
- Dados pessoais nas propriedades. E-mails, nomes e URLs com tokens na query string acabam em todo relatório e toda exportação. Envie um ID ou uma categoria no lugar.
- Rastrear antes do consentimento. Onde o GDPR se aplica, a análise não deve começar até o visitante concordar. Isso é uma propriedade da sua configuração, não de cada evento, então resolva uma vez, com um gerenciador de consentimento de cookies que segure o rastreamento até lá.
- Mudar o significado de um evento sem renomeá-lo. Se
project_createdpassa a contar projetos duplicados, todos os gráficos de antes e depois da mudança discordam e ninguém sabe por quê. Um novo significado ganha um novo nome, ou uma propriedade que diferencie os dois. - Eventos sem dono. Cada evento do plano precisa de uma pessoa que perceba quando ele para de disparar. Eventos sem dono são os primeiros a se degradar e os que continuam recebendo confiança por mais tempo.
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.
Definir eventos depois do fato
A captura automática muda a pergunta de “lembramos de instrumentar isto?” para “conseguimos encontrar isto no que foi capturado?”. O PulsePanda registra cada clique com o id do elemento, as classes, o texto visível, a tag e a posição na página, então um evento pode ser definido depois a partir desses dados, e a definição vale para cliques capturados antes de ela existir. Uma pergunta feita na quinta-feira pode ser respondida com os dados de segunda.
O que torna isso confiável é um ponto de apoio estável no markup. Classes mudam a cada redesign e o texto visível muda a cada ajuste de texto e tradução. Um id nos poucos controles que importam só muda quando alguém decide que deve mudar:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/pt/billing">Upgrade</a>Um evento definido como cliques em #export-report sobrevive a um redesign, e um clique no ícone ou no rótulo dentro do botão continua contando, porque o caminho registrado sobe até o elemento mais próximo com um id.
Um evento definido continua sendo um clique, com o limite descrito acima: diz que alguém tentou, não que deu certo. Para resultados, o sinal mais honesto costuma ser a página para onde o sucesso leva. Uma etapa de funil “chegou a /onboarding” depois de “chegou a /signup” conta os cadastros concluídos sem evento nenhum.
Como verificar um evento antes de confiar nele
- Dispare-o você mesmo e encontre a sua própria sessão. O evento deve aparecer uma vez, com todas as propriedades preenchidas.
- Compare a contagem com uma fonte de verdade. Se o banco de dados diz que 140 projetos foram criados na semana passada e a análise diz 95, encontre a diferença antes que alguém monte um gráfico em cima disso. Bloqueadores de anúncios, consentimento e requisições com falha deixam as contagens do navegador abaixo das do servidor. A diferença deve ser estável, não uma surpresa.
- Assista a um replay de sessão em que ele disparou. Um número diz que aconteceu; uma gravação diz que aconteceu quando você acha que aconteceu.
- Coloque-o em um funil. Um evento que aparece sem a etapa que deve vir antes está disparando do lugar errado.
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.