A maioria dos funis mede o produto, não o usuário

Abra uma ferramenta de análise típica e os funis são construídos a partir dos eventos que a equipe de engenharia por acaso instrumentou: route_loaded, account_created_v2, modal_opened. São tecnicamente precisas e quase inúteis para as decisões de produto, porque descrevem o que o software fez, não o que o usuário estava tentando fazer. Um funil que mede o seu código diz quando um componente foi renderizado; um funil que mede a intenção diz onde alguém desistiu.

A solução é construir os funis de trás para frente, a partir do comportamento observado — e validar cada etapa contra gravações reais antes de confiar em um único número. Aqui está o fluxo de trabalho.

Nomeie as etapas pela intenção do usuário

Os melhores funis se leem como uma história de usuário: chega aos preços → inicia o cadastro → cria um espaço de trabalho → instala o snippet → vê a primeira gravação. Cada etapa descreve o progresso do ponto de vista do usuário. Rótulos internos como account-created-v2 ou dashboard-route-loaded são úteis para o código, mas ocultam a intenção na revisão de produto.

Quando um funil é nomeado na linguagem do usuário, todos detectam a lacuna mais rápido. Se muitos usuários criam um espaço de trabalho mas não instalam o snippet, a próxima pergunta é óbvia — e você não precisa de um analista para traduzir. Um teste simples: se um novo contratado não consegue ler em voz alta as etapas do seu funil e entender o objetivo do usuário, as etapas estão nomeadas para engenheiros, não para decisões.

Valide cada etapa com gravações

Antes de tratar um funil como verdade, assista a sessões em torno de cada transição. Os erros de funil mais comuns não estão no gráfico — estão nas definições de eventos que o alimentam:

  • Dispara cedo demais: o evento dispara quando um componente é renderizado ou uma rota é carregada, não quando o usuário realmente conclui a ação — inflando essa etapa e ocultando o vazamento abaixo dela.
  • Dispara com frequência demais: uma nova tentativa, uma re-renderização ou um envio duplicado contam o mesmo usuário duas vezes, de modo que a conversão parece melhor do que é.
  • Dispara pelo motivo errado: o evento captura um efeito colateral em vez do estado de sucesso pretendido.

Gravações de sessão são a maneira mais rápida de detectar definições de eventos que parecem corretas em um painel, mas falham no contexto. Assista a três sessões por transição; se o evento corresponder ao que o usuário claramente pretendia, confie na etapa. Caso contrário, corrija a definição antes de agir sobre os dados.

Leia o abandono, depois vá assisti-lo

O trabalho de um funil não é exibir um número — é apontar para as gravações que explicam esse número. Quando uma etapa vaza, não redesenhe por palpite. Filtre os usuários que chegaram a essa etapa e abandonaram, assista a cinco das sessões deles e normalmente você encontrará uma de um pequeno conjunto de causas:

  • Um erro de validação ou um botão desativado sem explicação.
  • Um campo obrigatório ou uma permissão que o usuário não tinha e não conseguia resolver.
  • Um momento de confusão — a próxima ação não estava onde eles olhavam.
  • Nada de errado: eles conseguiram o que precisavam e saíram satisfeitos (um «vazamento» que não é um).

Esse último caso é por que os funis sozinhos enganam. O número diz «abandono»; a gravação diz «sucesso». Só o par diz a verdade.

Mantenha um funil de ativação sagrado

Equipes pequenas devem manter um único funil de ativação central e revisá-lo semanalmente. Resista à vontade de criar uma dúzia de funis sobrepostos — eles fragmentam a atenção e deixam todos escolherem o gráfico que favorece o próprio projeto. Um funil focado cria um ritmo operacional compartilhado: o que mudou esta semana, para onde a conversão se moveu e quais sessões explicam o movimento.

Em torno desse único funil sagrado, você pode criar funis efêmeros e descartáveis para investigações específicas e depois arquivá-los. A disciplina é ter um único número em que toda a equipe confia e ao qual retorna, não maximizar a quantidade de painéis.

Perguntas frequentes

As etapas do funil devem ser visualizações de página ou eventos?

Eventos, quase sempre. As visualizações de página descrevem a navegação, não a realização — um usuário pode carregar a página de «sucesso» sem ter sucesso, ou ter sucesso dentro de um aplicativo de página única sem navegação. Defina as etapas como os eventos que representam a intenção real do usuário.

Quantas etapas um funil deve ter?

Apenas as que contam a história — normalmente de quatro a seis. Cada etapa deve ser um ponto de decisão significativo. Se duas etapas adjacentes sempre convertem juntas, una-as; a diferença entre elas não está ensinando nada.

Por que a conversão do meu funil parece pior do que a realidade?

Normalmente uma etapa dispara cedo demais ou conta o mesmo usuário mais de uma vez, ou você não está deduplicando por usuário. Valide cada evento contra gravações e confirme que você está medindo usuários únicos, não eventos brutos.

Preciso de session replay para usar bem os funis?

Você pode executar funis sem isso, mas estará adivinhando as causas. Emparelhar cada abandono com as gravações por trás dele é o que transforma um funil de um relatório de status em uma fonte de correções. Veja session replay sem o ruído.