Onde rage clicks vs dead clicks realmente se separam

Qual é a diferença entre rage clicks e dead clicks?

A diferença entre rage clicks vs dead clicks é de causa: um rage click registra um usuário repetindo uma ação, e um dead click registra um clique único que a página nunca respondeu. Um é comportamental, o outro é estrutural. Eles se sobrepõem o tempo todo, e por isso as ferramentas listam os dois lado a lado, mas a correção de cada um é diferente.

Um rage click diz que a pessoa continuou tentando. Isso acontece quando o alvo está lento, quando a resposta é invisível e também quando a interface legitimamente convida ao clique repetido. Um dead click diz que um elemento recebeu um clique e não produziu mudança. Isso acontece quando o elemento não está conectado, quando um handler lançou erro e também quando a mudança foi real mas o detector não conseguiu enxergar.

Quais limiares cada fornecedor publica?

Dois dos cinco publicam números. Três descrevem o comportamento em prosa e param aí.

Fornecedor	Regra de rage click	Regra de dead click
PostHog	$rageclick dispara em "three clicks that are each within 30 pixels and 1 second of the previous one". Configurável como click_count: 3, threshold_px: 30, timeout_ms: 1000	$dead_click é "a click which isn't followed by a change to the page". Nenhuma janela numérica publicada
Hotjar	"when a user clicks on the same element five times within 500ms of one another"	O filtro de dead click acha sessões em que os usuários "clicked on a button, link, or a specific element of your site but didn't get any reaction". Sem números
FullStory	"clicking or tapping multiple times, rapidly, in the same area". Sem números	"If nothing on the page changes within a few seconds of a click or tap, it will get marked as a Dead Click". Sem números
LogRocket	"a series of rapid, repeated clicks on the same element". Sem números	"a click that did not result in a DOM change". Sem números
Microsoft Clarity	"the user clicks multiple times in a clustered area in rapid succession". Sem números	"a user clicks on an element but gets no feedback in a reasonable amount of time... the visual status doesn't change, and there's no navigation away from the page". Sem números

As duas regras publicadas não concordam, e não estão nem perto. O PostHog precisa de três cliques dentro de uma janela de um segundo e permite que o ponteiro ande 30 pixels entre eles. O Hotjar precisa de cinco cliques dentro de 500 milissegundos e exige que sejam no mesmo elemento. Um usuário que clica três vezes em 800 milissegundos está enfurecido no PostHog e invisível no Hotjar. Um usuário que clica cinco vezes ao longo de quatro segundos em um botão não está enfurecido em nenhum dos dois.

Isso importa mais que os números em si. Contagens de rage click não são comparáveis entre ferramentas, e uma migração entre fornecedores muda o número sem que nada mude no seu site.

O que conta como mudança de página para um dead click?

Nenhum fornecedor se compromete com uma resposta em público, que é o ponto mais frágil do sinal inteiro.

O LogRocket é o mais específico, e ainda assim entrega uma categoria e não um limiar: um dead click é "a click that did not result in a DOM change". O Clarity acrescenta duas condições em prosa, que o status visual não muda e que não há navegação para fora da página, sem dizer quanto tempo espera. A FullStory diz "within a few seconds". O PostHog diz apenas "a change to the page".

Tudo que é ambíguo cai nessa lacuna:

• Um clique que dispara uma requisição de rede cuja resposta chega depois da janela de detecção.
• Um clique que muda um canvas, uma cena WebGL ou um elemento de vídeo, nenhum dos quais altera o DOM.
• Um clique que abre um diálogo nativo, dispara um download ou copia para a área de transferência.
• Um clique que alterna uma classe CSS sem efeito visível no breakpoint atual.

Cada um deles produz um dead click em pelo menos uma ferramenta e nada em outra. Trate uma contagem bruta de dead clicks como um índice de busca sobre sessões e não como contagem de defeitos, e confirme cada cluster contra o replay antes que ele vire um ticket. O fluxo prático é o descrito em análise de dead clicks.

Por que rage clicks disparam em interfaces que funcionam?

Porque o detector mede cadência, não intenção, e muita interface correta pede cliques rápidos e repetidos.

A FullStory descreve o problema na própria documentação, sob o título "Why don't Rage Clicks work for me?": alguns componentes de interface, como botões de próximo e anterior, naturalmente convidam ao clique repetido, o que aciona a heurística mesmo com o comportamento sendo intencional. O PostHog chega à mesma conclusão e entrega padrões para compensar. Com defaults: '2026-05-30' ou posterior, o PostHog ignora automaticamente controles de navegação com texto como next, previous, > e <, seletores de quantidade marcados com + e -, e cliques repetidos em superfícies de seleção de texto como inputs, textareas e elementos contenteditable, já que clicar três vezes para selecionar uma linha não é fúria.

Os dois fornecedores entregam uma saída de emergência na marcação:

Fornecedor	Suprimir rage clicks	Suprimir dead clicks
PostHog	Classe .ph-no-rageclick, ou rageclick.css_selector_ignorelist	Classe .ph-no-deadclick, ou capture_dead_clicks.css_selector_ignorelist
FullStory	Classe fs-ignore-rage-clicks, ou configurações da conta	Classe fs-ignore-dead-clicks, ou configurações da conta

A FullStory acrescenta um detalhe que vale planejar: a supressão vale só para sessões novas, e sessões existentes não são reclassificadas retroativamente.

A documentação do PostHog fecha o ciclo com a instrução certa: confirme rage clicks contra session replays antes de tratar eles como sinal forte de frustração. É a mesma disciplina sobre a qual a análise de rage clicks é construída.

Quais causas estão por trás de cada sinal?

Os dois sinais apontam para partes diferentes da stack, que é a razão para manter eles separados em vez de fundir tudo numa única contagem de frustração.

Rage clicks vêm de:

• Latência. O handler funciona, a resposta leva dois segundos, o usuário clica de novo.
• Falta de feedback. O handler funciona na hora, nada visível confirma, o usuário clica de novo.
• Envio bloqueado. A validação no cliente falha em silêncio e o botão parece inerte.
• Repetição legítima. Paginação, seletores de quantidade, carrosséis, seleção de texto.

Dead clicks vêm de:

• Elementos sem vínculo. Texto, ícones e imagens estilizados para parecer interativos sem handler nenhum.
• Erros de handler. Uma exceção JavaScript antes da mudança de estado. A FullStory rastreia isso à parte como Error Clicks, que trazem à tona um clique imediatamente antes de um erro de JavaScript no cliente ou de console.
• Pontos cegos de detecção. Canvas, vídeo, downloads, novas abas, diálogos nativos.

Um cluster que mostra os dois sinais no mesmo seletor é o caso mais forte que você vai conseguir: o elemento parece clicável, não faz nada e os usuários continuam tentando. Um cluster de dead clicks sem rage clicks normalmente significa que o elemento parece clicável para uma máquina e não para uma pessoa, o que é prioridade menor.

Como interpretar um cluster de cliques

Rage clicks e dead clicks no mesmo seletor

• O elemento parece clicável
• Não produz nenhuma mudança
• Os usuários continuam tentando
• Prioridade máxima para investigar

Apenas dead clicks, sem rage clicks

• O elemento parece clicável para uma máquina
• Não parece clicável para uma pessoa
• Prioridade mais baixa para investigar

Como usar os dois juntos?

Ordene por sessões afetadas e posição no funil, depois assista ao replay antes de escrever o ticket.

Nenhuma das contagens significa algo isolada. Cem rage clicks numa seta de carrossel é artefato do detector. Doze dead clicks num botão de finalizar compra é incidente de receita. A diferença não é o número, é onde o elemento está e se a sessão se recuperou depois.

Uma ordem de operações que funciona:

1. Agrupe por seletor CSS ou por ID estável de elemento, nunca por coordenadas brutas.
2. Filtre para páginas que carregam peso de conversão.
3. Verifique se as sessões que contêm o cluster completaram a etapa.
4. Assista a três replays do cluster. Confirme o elemento, a expectativa e a falha.
5. Só então abra o ticket, com o seletor, a página, a contagem de sessões e um link de replay.

Essa é a mesma lógica de priorização que vale para todo outro sinal da família dos sinais de frustração, e é por isso que o session replay fica embaixo das duas métricas em vez de ao lado delas. As contagens acham os candidatos. A gravação decide.

Perguntas frequentes

Quais fornecedores publicam um limiar exato de rage click?

PostHog e Hotjar. O PostHog documenta três cliques, cada um dentro de 30 pixels e 1 segundo do anterior, expostos como click_count, threshold_px e timeout_ms. O Hotjar documenta cinco cliques no mesmo elemento dentro de 500ms um do outro. FullStory, LogRocket e Microsoft Clarity não publicam números para nenhum dos dois sinais.

Alguém publica um limiar numérico para dead click?

Não. A FullStory diz "within a few seconds", o Clarity diz "a reasonable amount of time", o LogRocket define como um clique sem mudança de DOM e o PostHog define como um clique não seguido de mudança na página. Nenhum dos cinco declara um valor em milissegundos.

Contagens de rage click são comparáveis entre ferramentas?

Não. Com os padrões do PostHog, uma rajada de três cliques dentro de um segundo conta. Pela regra do Hotjar não conta, porque o Hotjar exige cinco cliques dentro de 500ms em um elemento. Qualquer migração entre os dois muda a contagem sem mudança nenhuma no comportamento do usuário.

Um clique pode ser rage click e dead click ao mesmo tempo?

Sim, e essa combinação é o cluster de maior valor para investigar. O elemento recebeu cliques repetidos e não produziu mudança na página, o que remove as duas explicações comuns de falso positivo de uma vez.

Como impedir que um carrossel ou seletor de quantidade produza rage clicks?

Adicione a classe de exclusão do fornecedor ao elemento. O PostHog usa .ph-no-rageclick e também aceita rageclick.css_selector_ignorelist. A FullStory usa fs-ignore-rage-clicks. A FullStory observa que exclusões valem para sessões capturadas depois da mudança, então sessões históricas mantêm a classificação original.

Um dead click sempre significa que algo está quebrado?

Não. Cliques em elementos canvas, players de vídeo, links de download, ações de área de transferência e diálogos nativos produzem respostas reais que um detector de mutação de DOM não consegue ver. Confirme o cluster em um replay antes de tratar ele como defeito.

O que o sinal Error Click da FullStory captura?

A FullStory registra isso como um sinal separado chamado Error Clicks, distinto dos dead clicks. Ele marca um clique que acontece logo antes de um erro de JavaScript ou de console no lado do cliente, ligando a falha a uma interação concreta em vez de a um erro geral da página. Essa ligação chega mais perto de um relatório de bug do que um dead click jamais chega, já que um dead click só diz que o DOM não mudou.

Qual é o fluxo recomendado antes de transformar um cluster de cliques em ticket?

Agrupe primeiro por seletor CSS ou por um ID de elemento estável, depois filtre para páginas com peso na conversão. Verifique se as sessões do cluster completaram a etapa e assista a três replays para confirmar o elemento, a expectativa e a falha. Só depois disso você abre o ticket, com o seletor, a página, o número de sessões e um link do replay.

O que causa um rage click além de uma resposta lenta?

A latência é uma causa, mas um rage click também dispara quando o handler responde instantaneamente e nada visível confirma que algo aconteceu. Também dispara quando a validação do lado do cliente falha silenciosamente e o botão simplesmente parece inerte, e quando a interface convida legitimamente a cliques repetidos, como paginação, seletores de quantidade, carrosséis ou seleção de texto.

Por que agrupar por seletor CSS importa mais do que por coordenadas brutas?

O fluxo de trabalho prático começa agrupando os cliques por seletor CSS ou por um ID de elemento estável, nunca por coordenadas brutas. Coordenadas brutas descrevem um ponto na tela, não o elemento com o qual a pessoa interagiu, então agrupar por elas espalha os cliques do mesmo botão em vários grupos diferentes. Agrupar por seletor é o que permite classificar os clusters por sessões afetadas e posição no funil.