Análise de comportamento com Clarity

Quando usar

Use quando já se sabe qual página ou etapa perde (a skill analise-de-funil-no-ga4 diz isso) e a pergunta é por quê. Exige a página com pelo menos 1.000 sessões no período e o Clarity instalado há pelo menos 2 semanas. Com menos de 200 sessões o mapa de calor é ruído. Não use para medir conversão (GA4) nem para decidir o que testar sem antes quantificar o padrão.

O que você precisa

1. Acesso ao projeto do Clarity e a confirmação de que a tag dispara nas páginas em questão.
2. A página e a ação única que ela deve provocar (botão, formulário, clique em produto).
3. A queda que motivou a análise: etapa do funil, número, período.
4. Divisão por dispositivo do tráfego da página, para ler celular e computador separados.
5. Mudanças recentes de layout ou campanha, para não analisar duas páginas diferentes como uma.
6. Mascaramento conferido: campos de formulário e textos sensíveis mascarados (modo restrito nas configurações). Gravação com dado pessoal é problema de LGPD, não achado.

Passo a passo

1. Confira a instalação: sessões chegando da página no painel; mascaramento em modo restrito para páginas com formulário; IPs internos e ambientes de teste excluídos por filtro.
2. Escreva o plano de observação antes de abrir qualquer mapa: qual é a ação da página, onde ela fica na dobra do celular, o que compete por atenção. Sem plano, você olha para o que chama a atenção, não para o que importa.
3. Mapa de cliques, por dispositivo: parcela de cliques na chamada principal (abaixo de 10% numa página de conversão é achado); cliques em elementos que não são clicáveis (imagem, título, ícone), somando pelo menos 5% das sessões, viram achado de design; cliques em menus e links de saída que competem com a ação. Mapa de rolagem: porcentagem de usuários que chega até a chamada e até o formulário. Se 25% ou mais não chegam à chamada, ela está baixa demais. Anote a linha da dobra média que o Clarity desenha.
4. Painel de insights: cliques mortos, cliques de raiva, rolagem excessiva, retorno rápido e erros de JavaScript. Para cada métrica, anote a porcentagem de sessões e abra o segmento correspondente. Erro de JavaScript em página de conversão vai direto para o time técnico: é bug, não hipótese.
5. Gravações com roteiro: filtre um segmento por padrão (por exemplo, celular, visitou a página, clique de raiva) e assista 15 a 20 sessões por padrão. Registre em cada uma: o que a pessoa fez logo antes de sair, onde o cursor ou o dedo hesitou, campo do formulário em que parou, mensagem de erro que apareceu, tempo até a primeira interação. Pare quando 3 gravações seguidas não trouxerem nada novo.
6. Quantifique cada padrão: sessões no filtro divididas pelas sessões da página no período. Só vira achado o padrão com 3% ou mais das sessões, ou qualquer padrão que bloqueie a ação principal.
7. Cruze com o GA4: o padrão coincide com a etapa do funil que caiu? Com um segmento (dispositivo, origem)? Padrão que existe mas não bate com a queda vai para o backlog.
8. Separe bug de hipótese. Link quebrado, erro de script, botão que não responde: corrigir, sem teste. O resto vira hipótese no formato "Porque observamos [padrão em X% das sessões], acreditamos que [mudança] vai [resultado], medido por [métrica]" e segue para a skill plano-de-teste-ab.
9. Deixe o acompanhamento armado: evento inteligente para a chamada principal e checagem semanal de cliques de raiva e erros de JavaScript.

Formato da entrega

1. Ficha da página: sessões no período, divisão por dispositivo, dobra média, parcela de cliques na chamada, porcentagem que rola até a chamada e até o formulário.
2. Tabela de padrões: padrão, evidência (porcentagem de sessões e número de gravações), onde acontece, causa provável, ação, tipo (bug, teste, conteúdo).
3. Capturas dos mapas de cliques e de rolagem por dispositivo, com anotações.
4. Gravações de exemplo: 2 ou 3 links por padrão, com o minuto do momento relevante.
5. Hipóteses priorizadas e a lista de bugs enviada ao time técnico.

Critérios de qualidade

• Todo achado tem porcentagem de sessões e número de gravações assistidas.
• Celular e computador lidos e reportados separados.
• Bugs em lista própria, fora das hipóteses.
• Mascaramento confirmado antes de assistir qualquer gravação.
• Nenhuma conclusão a partir de menos de 10 gravações ou de página com menos de 200 sessões.
• Cada hipótese aponta a etapa do funil ou o segmento que ela explica.

Armadilhas

• Assistir gravações aleatórias e "encontrar" o que já se acreditava.
• Contar cliques em vez de parcela de cliques: a página com mais tráfego sempre "clica mais".
• Ler mapa de calor com celular e computador misturados: as dobras são diferentes.
• Concluir que "ninguém rola" sem olhar onde está a dobra e o que há acima dela.
• Gravar formulário sem mascaramento e guardar dado pessoal.
• Analisar a página durante uma campanha que trocou o público.
• Testar em A/B o que é bug: corrija e meça.
• Tratar um padrão de 1% como prioridade porque a gravação foi marcante.