En qué se diferencian de verdad rage clicks vs dead clicks

¿Cuál es la diferencia entre rage clicks y dead clicks?

La diferencia entre rage clicks vs dead clicks es de causa: un rage click registra a un usuario repitiendo una acción, y un dead click registra un único clic al que la página nunca respondió. Uno es conductual, el otro estructural. Se solapan constantemente, y por eso las herramientas los listan juntos, pero el arreglo de cada uno es distinto.

Un rage click te dice que una persona siguió intentándolo. Eso pasa cuando el objetivo es lento, cuando la respuesta es invisible, y también cuando la interfaz invita legítimamente a hacer clic repetido. Un dead click te dice que un elemento recibió un clic y no produjo ningún cambio. Eso pasa cuando el elemento no está conectado, cuando un handler lanzó una excepción, y también cuando el cambio fue real pero el detector no pudo verlo.

¿Qué umbrales publica cada proveedor?

Dos de los cinco publican números. Tres describen el comportamiento en prosa y ahí se quedan.

Proveedor	Regla de rage click	Regla de dead click
PostHog	$rageclick se dispara con "three clicks that are each within 30 pixels and 1 second of the previous one". Configurable como click_count: 3, threshold_px: 30, timeout_ms: 1000	$dead_click es "a click which isn't followed by a change to the page". No publica ventana numérica
Hotjar	"when a user clicks on the same element five times within 500ms of one another"	El filtro de dead click encuentra sesiones donde los usuarios "clicked on a button, link, or a specific element of your site but didn't get any reaction". Sin números
FullStory	"clicking or tapping multiple times, rapidly, in the same area". Sin 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". Sin números
LogRocket	"a series of rapid, repeated clicks on the same element". Sin números	"a click that did not result in a DOM change". Sin números
Microsoft Clarity	"the user clicks multiple times in a clustered area in rapid succession". Sin 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". Sin números

Las dos reglas publicadas no coinciden, y no están cerca. PostHog necesita tres clics dentro de una ventana de un segundo y permite que el puntero se desplace 30 píxeles entre ellos. Hotjar necesita cinco clics dentro de 500 milisegundos y los exige sobre el mismo elemento. Un usuario que hace tres clics en 800 milisegundos está rabioso en PostHog e invisible en Hotjar. Un usuario que hace cinco clics a lo largo de cuatro segundos sobre un botón no está rabioso en ninguno.

Eso importa más que los números en sí. Los recuentos de rage clicks no son comparables entre herramientas, y una migración de un proveedor a otro cambiará el número sin que nada cambie en tu sitio.

¿Qué cuenta como cambio de página para un dead click?

Ningún proveedor se compromete con una respuesta en público, que es el punto más débil de toda la señal.

LogRocket es el más concreto, y sigue siendo una categoría y no un umbral: un dead click es "a click that did not result in a DOM change". Clarity añade dos condiciones en prosa, que el estado visual no cambie y que no haya navegación fuera de la página, sin decir cuánto espera. FullStory dice "within a few seconds". PostHog dice solo "a change to the page".

Todo lo ambiguo cae en ese hueco:

• Un clic que dispara una petición de red cuya respuesta llega después de la ventana de detección.
• Un clic que cambia un canvas, una escena WebGL o un elemento de vídeo, ninguno de los cuales muta el DOM.
• Un clic que abre un diálogo nativo, lanza una descarga o copia al portapapeles.
• Un clic que alterna una clase CSS sin efecto visible en el breakpoint actual.

Cada uno de estos produce un dead click en al menos una herramienta y nada en otra. Trata un recuento bruto de dead clicks como un índice de búsqueda sobre sesiones y no como un recuento de defectos, y confirma cada grupo contra la grabación antes de que se convierta en un ticket. El flujo práctico es el descrito en análisis de dead clicks.

¿Por qué se disparan rage clicks en interfaces que funcionan?

Porque el detector mide la cadencia, no la intención, y hay muchas interfaces correctas que piden clics rápidos y repetidos.

FullStory plantea el problema en su propia documentación, bajo el título "Why don't Rage Clicks work for me?": algunos componentes de UI, como los botones Next y Previous, invitan de forma natural a hacer clic repetido, lo que dispara la heurística aunque el comportamiento sea el buscado. PostHog llega a la misma conclusión y trae valores por defecto para compensar. Con defaults: '2026-05-30' o posterior, PostHog ignora automáticamente los controles de navegación con texto como next, previous, > y <, los selectores de cantidad marcados con + y -, y los clics repetidos sobre superficies de selección de texto como inputs, textareas y elementos contenteditable, ya que hacer triple clic para seleccionar una línea no es rabia.

Ambos proveedores traen una vía de escape en el marcado:

Proveedor	Suprimir rage clicks	Suprimir dead clicks
PostHog	Clase .ph-no-rageclick, o rageclick.css_selector_ignorelist	Clase .ph-no-deadclick, o capture_dead_clicks.css_selector_ignorelist
FullStory	Clase fs-ignore-rage-clicks, o ajustes de la cuenta	Clase fs-ignore-dead-clicks, o ajustes de la cuenta

FullStory añade un detalle que conviene planificar: la supresión solo se aplica a sesiones nuevas, y las sesiones existentes no se reclasifican retroactivamente.

La documentación de PostHog cierra el círculo con la instrucción correcta: confirma los rage clicks contra las grabaciones de sesión antes de tratarlos como señal firme de frustración. Es la misma disciplina sobre la que se construye el análisis de rage clicks.

¿Qué causas hay detrás de cada señal?

Las dos señales apuntan a partes distintas del stack, que es la razón para mantenerlas separadas en lugar de fundirlas en un único recuento de frustración.

Los rage clicks vienen de:

• Latencia. El handler funciona, la respuesta tarda dos segundos, el usuario vuelve a hacer clic.
• Falta de feedback. El handler funciona al instante, nada visible lo confirma, el usuario vuelve a hacer clic.
• Envío bloqueado. La validación en cliente falla en silencio y el botón parece inerte.
• Repetición legítima. Paginación, selectores de cantidad, carruseles, selección de texto.

Los dead clicks vienen de:

• Elementos sin enlazar. Texto, iconos e imágenes con estilo de interactivos y sin handler.
• Errores de handler. Una excepción de JavaScript antes del cambio de estado. FullStory lo sigue por separado como Error Clicks, que muestran un clic inmediatamente anterior a un error de JavaScript en cliente o de consola.
• Puntos ciegos de detección. Canvas, vídeo, descargas, pestañas nuevas, diálogos nativos.

Un grupo que muestra ambas señales sobre el mismo selector es el caso más fuerte que vas a encontrar: el elemento parece pulsable, no hace nada, y los usuarios siguen intentándolo. Un grupo de dead clicks sin rage clicks suele significar que el elemento parece pulsable para una máquina y no para una persona, lo que es de menor prioridad.

Cómo interpretar un clúster de clics

Rage clicks y dead clicks en el mismo selector

• El elemento parece clicable
• No produce ningún cambio
• Los usuarios siguen intentándolo
• Máxima prioridad para investigar

Solo dead clicks, sin rage clicks

• El elemento parece clicable para una máquina
• No parece clicable para una persona
• Prioridad más baja para investigar

¿Cómo deberías usar las dos juntas?

Ordena por sesiones afectadas y posición en el embudo, y luego mira la grabación antes de escribir el ticket.

Ningún recuento significa nada por sí solo. Cien rage clicks en la flecha de un carrusel son un artefacto del detector. Doce dead clicks en el botón de envío del checkout son un incidente de ingresos. La diferencia no es el número, es dónde está el elemento y si la sesión se recuperó después.

Un orden de operaciones que funciona:

1. Agrupa por selector CSS o ID estable de elemento, nunca por coordenadas brutas.
2. Filtra a páginas que tengan peso en la conversión.
3. Comprueba si las sesiones que contienen el grupo completaron el paso.
4. Mira tres grabaciones del grupo. Confirma el elemento, la expectativa y el fallo.
5. Solo entonces abre el ticket, con el selector, la página, el número de sesiones y un enlace a la grabación.

Es la misma lógica de priorización que se aplica a cualquier otra señal de la familia de señales de frustración, y es la razón de que session replay esté debajo de ambas métricas y no al lado. Los recuentos encuentran a los candidatos. La grabación decide.

Preguntas frecuentes

¿Qué proveedores publican un umbral exacto de rage click?

PostHog y Hotjar. PostHog documenta tres clics, cada uno dentro de 30 píxeles y 1 segundo del anterior, expuestos como click_count, threshold_px y timeout_ms. Hotjar documenta cinco clics sobre el mismo elemento en un intervalo de 500 ms. FullStory, LogRocket y Microsoft Clarity no publican números para ninguna de las dos señales.

¿Publica alguien un umbral numérico de dead click?

No. FullStory dice "within a few seconds", Clarity dice "a reasonable amount of time", LogRocket lo define como un clic sin cambio en el DOM, y PostHog lo define como un clic al que no sigue un cambio en la página. Ninguno de los cinco da un valor en milisegundos.

¿Son comparables los recuentos de rage clicks entre herramientas?

No. Con los valores por defecto de PostHog, una ráfaga de tres clics en un segundo cuenta. Bajo la regla de Hotjar no cuenta, porque Hotjar exige cinco clics en 500 ms sobre un elemento. Cualquier migración entre las dos cambia el recuento sin ningún cambio en el comportamiento del usuario.

¿Puede un clic ser a la vez rage click y dead click?

Sí, y esa combinación es el grupo con más valor para investigar. El elemento recibió clics repetidos y no produjo ningún cambio de página, lo que elimina a la vez las dos explicaciones habituales de falso positivo.

¿Cómo evitas que un carrusel o un selector de cantidad produzca rage clicks?

Añade al elemento la clase de exclusión del proveedor. PostHog usa .ph-no-rageclick y también acepta rageclick.css_selector_ignorelist. FullStory usa fs-ignore-rage-clicks. FullStory señala que las exclusiones se aplican a las sesiones capturadas después del cambio, así que las sesiones históricas conservan su clasificación original.

¿Un dead click significa siempre que algo está roto?

No. Los clics sobre elementos canvas, reproductores de vídeo, enlaces de descarga, acciones de portapapeles y diálogos nativos producen respuestas reales que un detector de mutaciones del DOM no puede ver. Confirma el grupo en una grabación antes de tratarlo como un defecto.

¿Qué captura la señal Error Click de FullStory?

FullStory registra esto como una señal separada llamada Error Clicks, distinta de los dead clicks. Marca un clic que ocurre justo antes de un error de JavaScript o de consola en el cliente, vinculando el fallo a una interacción concreta en lugar de a un error general de la página. Ese vínculo se acerca más a un reporte de bug de lo que un dead click puede llegar a estar, porque un dead click solo indica que el DOM no cambió.

¿Cuál es el flujo recomendado antes de convertir un clúster de clics en un ticket?

Agrupa primero por selector CSS o por un ID de elemento estable, y luego filtra a las páginas con peso en la conversión. Comprueba si las sesiones del clúster completaron el paso y mira tres repeticiones para confirmar el elemento, la expectativa y el fallo. Solo entonces abres el ticket, con el selector, la página, el número de sesiones y un enlace a la repetición.

¿Qué causa un rage click además de una respuesta lenta?

La latencia es una causa, pero un rage click también se dispara cuando el manejador responde al instante y nada visible confirma que ocurrió algo. También se dispara cuando la validación del lado del cliente falla en silencio y el botón simplemente parece inerte, y cuando la interfaz invita legítimamente a clics repetidos, como en la paginación, los selectores de cantidad, los carruseles o la selección de texto.

¿Por qué importa más agrupar por selector CSS que por coordenadas en bruto?

El flujo de trabajo práctico empieza agrupando los clics por selector CSS o por un ID de elemento estable, nunca por coordenadas en bruto. Las coordenadas en bruto describen un punto en la pantalla, no el elemento con el que interactuó una persona, así que agrupar por ellas dispersa los clics del mismo botón en muchos grupos distintos. Agrupar por selector es lo que permite clasificar los clústeres por sesiones afectadas y posición en el embudo.