Assistir gravações aleatórias é o jeito mais caro de não descobrir nada. Veja um método para filtrar as sessões certas, registrar padrões e sair com hipóteses priorizadas.
Índice do artigo
- O erro de começar pela gravação
- Passo 1: comece pela pergunta e pelo funil
- Passo 2: filtre as sessões que respondem à pergunta
- Passo 3: use os sinais de frustração como atalho
- Passo 4: registre padrões, não casos
- Passo 5: complemente com mapas de calor e pesquisas
- Passo 6: escreva hipóteses testáveis
- Quantas gravações assistir?
- Os erros que mais aparecem
- Perguntas frequentes
O erro de começar pela gravação
Ferramentas como Microsoft Clarity, Hotjar, Fullstory e UXCam gravam milhares de sessões. Abrir a lista e assistir as primeiras gera histórias interessantes e nenhuma decisão. O replay é uma ferramenta de diagnóstico: ele explica um problema que o analytics já apontou.
Em uma frase: o analytics diz onde está o vazamento; a gravação mostra como a água escapa.
Passo 1: comece pela pergunta e pelo funil
Antes de abrir uma gravação, responda no GA4 ou na ferramenta de product analytics:
- Em qual etapa do funil a queda é maior que o esperado?
- Em qual dispositivo, navegador ou origem de tráfego ela se concentra?
- A queda é nova (algo mudou) ou histórica?
A pergunta vira algo como: “Por que 60% dos usuários mobile que chegam à etapa de frete não avançam para pagamento?”
Passo 2: filtre as sessões que respondem à pergunta
É aqui que os eventos personalizados pagam o investimento (Dicionário de eventos). Filtre:
- sessões que dispararam o evento da etapa (ex.: shipping_view) e não dispararam o seguinte (ex.: payment_view);
- pelo segmento da pergunta (mobile, origem, novo x recorrente);
- por atributos de usuário, quando existirem (plano, cliente recorrente), usando a Identify API do Hotjar, as tags do Clarity ou as propriedades do Fullstory e da UXCam.
Sem eventos, você só consegue filtrar por URL, o que em single-page apps e checkouts de etapa única não basta.
Passo 3: use os sinais de frustração como atalho
As ferramentas destacam comportamentos que indicam problema:
- Rage clicks / rage taps: cliques ou toques repetidos no mesmo ponto, geralmente algo que parece clicável e não é, ou que não responde.
- Dead clicks: cliques que não geram nenhuma reação na página.
- Retornos rápidos e navegação em círculo: usuário procurando informação que não encontra.
- Erros e crashes: a UXCam, por exemplo, liga crashes e ANRs à sessão gravada; no web, erros de JavaScript podem ser enviados como evento.
Dentro do filtro do passo 2, priorize as sessões com esses sinais.
Passo 4: registre padrões, não casos
Use uma planilha simples enquanto assiste:
Sessão
Segmento
O que aconteceu
Momento
Categoria
link
mobile, novo
tentou editar CEP 3 vezes, campo não respondeu
etapa de frete
bug
link
mobile, novo
rolou até o fim procurando prazo de entrega
etapa de frete
informação ausente
Categorias úteis: bug, informação ausente, usabilidade, confiança/segurança, performance, expectativa de preço/frete.
Um comportamento vira achado quando aparece em várias sessões do mesmo segmento. Um caso isolado vira nota, não hipótese.
Passo 5: complemente com mapas de calor e pesquisas
- Mapa de calor: confirma se o padrão visto nas gravações se repete em escala (ex.: muitos cliques num elemento não clicável).
- Pesquisa on-site: pergunte a quem vive o problema. No Hotjar, dá para disparar uma pesquisa por evento, como uma pergunta de saída só para quem abandonou na etapa de frete, e segmentar por atributos de usuário.
- Dados de atendimento: reclamações recorrentes confirmam ou refutam o achado.
Passo 6: escreva hipóteses testáveis
Formato recomendado:
Porque observamos [achado com evidência], acreditamos que [mudança] para [segmento] vai [efeito esperado], medido por [métrica principal].
Exemplo: “Porque observamos em 23 de 40 sessões mobile que usuários procuram o prazo de entrega antes de avançar, acreditamos que exibir o prazo junto de cada opção de frete para usuários mobile vai aumentar a taxa de avanço para pagamento, medida pelo evento payment_view.”
Priorize as hipóteses por impacto esperado, confiança na evidência e esforço de implementação, e escolha o modelo de teste adequado (Teste A/B client-side x server-side).
Quantas gravações assistir?
Não existe número mágico. Uma regra prática é assistir até parar de ver padrões novos: quando as últimas sessões só repetem o que já foi registrado, a análise daquele recorte está saturada. Em geral, isso acontece com algumas dezenas de sessões bem filtradas, não centenas de sessões aleatórias.
Os erros que mais aparecem
- Assistir gravações sem pergunta definida.
- Generalizar a partir de uma sessão marcante.
- Não usar eventos para filtrar, e depender só de URL.
- Registrar achados sem link para a sessão, impedindo revisão.
- Implementar a “solução” direto, sem teste, a partir do que foi visto.
Perguntas frequentes
Como analisar gravações de sessão?
Comece por uma pergunta vinda do funil, filtre as sessões pelo comportamento e segmento, priorize sinais de frustração, registre padrões e transforme em hipóteses testáveis.
O que é rage click?
Cliques repetidos no mesmo ponto, indicando que o usuário esperava uma reação que não aconteceu.
O que é dead click?
Um clique que não gera nenhuma resposta na página.
Quantas gravações preciso assistir?
Até os padrões pararem de se repetir; normalmente algumas dezenas de sessões bem filtradas.
Mapa de calor ou gravação de sessão?
Os dois: o mapa mostra o padrão em escala, a gravação explica o contexto.
Como transformar o que vi nas gravações em teste A/B?
Escrevendo uma hipótese com evidência, mudança, segmento, efeito esperado e métrica principal.