---
name: analise-de-comportamento-com-clarity
description: >-
  Transforma mapas de calor e gravações de sessão do Microsoft Clarity (ou ferramenta
  equivalente) em achados de conversão: confere mascaramento e filtros, define o que observar por
  página e objetivo, lê mapa de cliques e de rolagem por dispositivo, usa os painéis de cliques
  mortos, cliques de raiva, rolagem excessiva, retorno rápido e erros de JavaScript, assiste
  gravações com roteiro e amostra definida, quantifica cada padrão em porcentagem de sessões e o
  transforma em correção ou hipótese de teste. Use quando pedirem analisar heatmap, gravações de
  sessão, por que ninguém clica no botão, comportamento na página, dead clicks, rage clicks ou o
  que o Clarity mostra.
license: MIT
metadata:
  conecto-area: cro
  conecto-tools: microsoft-clarity
  conecto-version: "1.0.0"
  conecto-author: Ecto
---

# 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.