Como o rastreamento de eventos registra o que os usuários fizeram

O que é rastreamento de eventos na análise de produto?

As ferramentas de análise de produto usam o rastreamento de eventos para registrar ações nomeadas do usuário, como signup_completed ou checkout_started, junto com propriedades que descrevem cada ação, o que transforma dados de tráfego por página em um registro do que as pessoas realmente fizeram. Uma visualização de página diz que alguém chegou à tela de checkout. Um evento diz que a pessoa começou o checkout, no plano anual de equipe, vinda da página de preços, e nunca voltou. A Flowsery entrega rastreamento de metas e eventos junto do web analytics embutido, então a mesma conta guarda os números de tráfego e o registro no nível da ação.

Quais são as duas partes de um evento?

Um evento tem um nome e um conjunto de propriedades, e a divisão entre eles decide se o dado continua consultável um ano depois. O nome identifica a ação e permanece constante em toda ocorrência. As propriedades carregam as partes que mudam de uma ocorrência para a seguinte: qual plano, qual origem, quanto, por quanto tempo. Coloque a ação no nome e as variáveis nas propriedades, e toda pergunta sobre aquela ação vira um filtro em vez de um evento novo.

Cinco eventos com boas propriedades respondem mais perguntas que cinquenta eventos sem nenhuma. Esses cinco sustentam um funil de cadastro, uma comparação de checkout plano a plano, um relatório de cupons e uma métrica de expansão de equipe sem uma única chamada de rastreamento a mais. Os nomes de propriedade daquela tabela seguem o padrão object_adjective que o PostHog documenta nas suas boas práticas de análise de produto, com is_ reservado para booleanos.

Como é um evento mal nomeado ao lado de um bem nomeado?

Um evento mal nomeado empurra o detalhe variável para dentro do nome, o que bifurca uma ação em um evento novo para cada combinação. Aqui está o mesmo cadastro, rastreado de duas formas.

// Rastreado mal: o plano e a página entram dentro do nome
track("Clicked Signup Button On Pricing Page Annual");
track("clicked_signup_button_on_pricing_page_monthly");
track("Signup Btn - Homepage");
 
// Rastreado bem: um nome estável, as variáveis como propriedades
track("signup_completed", {
  signup_source: "pricing_page",
  plan_slug: "team_annual",
  is_invited: false
});

O primeiro bloco produz três nomes de evento para uma ação, então a resposta para "quantas pessoas se cadastraram na semana passada" é uma soma manual que quebra no momento em que alguém adiciona uma quarta página de preços. O segundo bloco produz um nome de evento e três filtros. Peça a alguém de marketing para dizer a ação em voz alta, depois confira se tudo o que a pessoa falou depois do verbo foi parar em uma propriedade, não no nome.

Qual convenção de nomes de eventos uma equipe deve escolher?

A convenção que funciona é a que está escrita e aplicada a todo evento, e as duas convenções publicadas discordam nos detalhes. As boas práticas de análise de produto do PostHog pedem snake_case em minúsculas, verbos no presente e uma estrutura category:object_action, como account_settings:forgot_password_button_click. O playbook de planejamento de dados da Amplitude pede Title Case com uma estrutura [Noun] + [Past-Tense Verb], como Song Played, mantida na perspectiva do usuário, de modo que Message Sent significa que o usuário enviou.

As duas funcionam. Misturá-las não, porque Signup Completed, signup_completed e signup:button_click viram três linhas sem relação na mesma lista. Os exemplos deste post usam snake_case com verbos no passado, o que se lê como objeto e depois ação e ordena todo evento relacionado junto em ordem alfabética: checkout_completed cai ao lado de checkout_started.

Uma restrição rígida fica embaixo de qualquer convenção que você escolha. Os limites de coleta de eventos do GA4 do Google limitam o nome de um evento a 40 caracteres, permitem 25 parâmetros de evento por evento, limitam o nome de um parâmetro a 40 caracteres e a maioria dos valores de parâmetro a 100 caracteres, e não impõem limite de eventos com nomes distintos em fluxos de dados da web, enquanto limitam os fluxos de dados de app a 500 por usuário do app. Um nome category:object_action mais um substantivo longo bate naquele teto de 40 caracteres mais rápido do que as equipes esperam, e o GA4 para de reportar em silêncio um nome longo demais como evento-chave.

Como o rastreamento de eventos difere do autocapture?

O rastreamento de eventos nomeia a ação no código da aplicação antes de ela subir, enquanto o autocapture registra automaticamente cada clique e envio de formulário e deixa você definir o significado depois, a partir da estrutura da página. O autocapture dá à equipe um fluxo funcionando no primeiro dia e quebra em silêncio quando um redesign muda o seletor CSS que ele casava. Um evento nomeado anda junto com o código em que vive, então renomear um componente leva a chamada de rastreamento junto. A maioria das equipes roda os dois: autocapture para a cauda longa exploratória, eventos nomeados para os números que aparecem em uma apresentação de conselho.

Como as propriedades transformam eventos em um funil?

Dois eventos com uma propriedade em comum viram uma etapa de conversão, que é como um funil de conversão é construído a partir de dados brutos de evento. A taxa de conclusão de uma etapa é uma divisão:

step conversion rate = completed events / started events x 100

Com 4,000 eventos checkout_started e 1,240 eventos checkout_completed em uma semana, a etapa de checkout converte a 31 por cento. Adicione plan_slug como quebra e esse número único se divide em uma taxa por plano, que é onde o problema de verdade aparece. As propriedades também são a matéria-prima das dimensões personalizadas, então o schema que você desenha para os eventos é o mesmo schema pelo qual seus relatórios vão segmentar depois.

Quantos eventos uma equipe deve instrumentar?

Instrumente as ações que aparecem em uma decisão, e pare. Um evento pelo qual ninguém filtrou em três meses é dívida de schema: custa cota, polui o seletor de eventos e apodrece sem ninguém notar. Comece pelas etapas do caminho até a receita, acrescente as ações que separam uma conta retida de uma que deu churn, e depois acrescente eventos novos quando uma pergunta específica não tiver dado por trás.

Um schema menor também mantém pequena a superfície de privacidade. A Flowsery é livre de cookies e hospedada na UE por design, e as propriedades que uma equipe escolhe não enviar são as que nunca precisam de política de retenção. As equipes que pesam esse trade-off contra uma configuração centrada no Google podem ler a comparação entre analytics com privacidade e GA4.

Como verificar se um evento está disparando corretamente?

Dispare a ação você mesmo, depois confirme que o evento chegou com o nome certo e as propriedades certas antes de confiar em qualquer gráfico construído sobre ele. A falha que custa mais caro é um evento que dispara com uma propriedade nula ou escrita errada, já que a contagem parece saudável enquanto cada quebra descarta linhas em silêncio. Assistir a uma sessão real ao lado do fluxo de eventos pega a divergência de um jeito que um dashboard não consegue: a Flowsery grava cada sessão de usuário e se conecta a gravações do PostHog ou da Amplitude já registradas, sem reinstrumentar nada, então a gravação e o log de eventos ficam lado a lado.

Rode essa verificação de novo depois de cada release de front-end que toque um fluxo rastreado. Um evento que parou de disparar produz uma linha reta, e uma linha reta parece um problema de produto até alguém abrir o código.

Perguntas frequentes

O que é um evento em analytics?

Um evento é uma única ação nomeada que um usuário fez, registrada com um timestamp e um conjunto de propriedades que a descrevem. checkout_started com plan_slug: team_annual é um evento. Uma visualização de página é um tipo específico de evento, registrado automaticamente pela maioria dos scripts de analytics.

Qual a diferença entre o nome de um evento e uma propriedade de evento?

O nome identifica a ação e permanece idêntico em toda ocorrência, para que possa ser contado. A propriedade carrega o detalhe que muda entre ocorrências, para que possa ser filtrado e agrupado. Qualquer coisa pela qual você queira filtrar pertence a uma propriedade, nunca ao nome.

Os nomes de eventos devem usar passado ou presente?

As duas convenções são publicadas e as duas funcionam, então escolha uma e imponha. O playbook de planejamento de dados da Amplitude documenta Title Case com verbos no passado, e as boas práticas do PostHog documentam snake_case em minúsculas com verbos no presente. O custo de trocar no meio do caminho são dois conjuntos de nomes descrevendo as mesmas ações.

Quantas propriedades um único evento deve carregar?

Envie as propriedades pelas quais você filtraria ou agruparia, e pule o resto. O GA4 permite 25 parâmetros de evento por evento, segundo os limites de coleta de eventos do Google, o que é um teto e não uma meta. De cinco a oito propriedades bem escolhidas em um evento central cobrem a maioria das perguntas de relatório.

O rastreamento de eventos exige cookies?

Não. Registrar que uma ação aconteceu não precisa de cookie, já que um cookie existe para persistir identidade entre visitas e não para capturar a ação em si. A Flowsery roda livre de cookies e hospedada na UE, e ainda registra eventos com suas propriedades.

O que quebra um schema de eventos com o tempo?

Eventos renomeados, eventos ad hoc adicionados sem convenção e propriedades que param de ser preenchidas depois de um refactor. Cada um deles deixa o gráfico com boa aparência enquanto o dado por baixo desliza. Uma convenção de nomes escrita, mais uma verificação depois de cada release nos fluxos rastreados, previne a maior parte disso.

O que é dívida de schema no rastreamento de eventos?

Dívida de schema é um evento que ninguém filtrou nos últimos três meses. Ela consome quota, lota o seletor de eventos e se deteriora sem que ninguém perceba, até alguém auditar o schema.

O autocapture pode substituir eventos nomeados?

A maioria das equipes usa os dois em vez de escolher um. O autocapture cobre a cauda longa exploratória e dá à equipe um fluxo funcional desde o primeiro dia, mas quebra silenciosamente quando um redesign muda o seletor CSS que ele usava. Eventos nomeados cobrem os números que aparecem num relatório para a diretoria, porque renomear um componente carrega a chamada de tracking junto com o código onde ela vive.

Qual é o limite de caracteres do GA4 para o nome de um evento?

O Google limita o nome de um evento no GA4 a 40 caracteres e também limita o nome de um parâmetro a 40 caracteres, com a maioria dos valores de parâmetro limitados a 100 caracteres. Uma estrutura category:object_action mais um substantivo longo esbarra nesse limite mais rápido do que as equipes esperam, e o GA4 para de reportar silenciosamente um nome longo demais como evento-chave.

Como calcular a taxa de conversão de um funil a partir de eventos?

Divida os eventos concluídos pelos eventos iniciados e multiplique por 100. Com 4.000 eventos checkout_started e 1.240 eventos checkout_completed numa semana, a etapa de checkout converte a 31 por cento. Detalhar esse número por uma propriedade como plan_slug transforma uma taxa única numa taxa por plano.