TL;DR, Respuesta rápida
8 min de lecturaLas señales de frustración son comportamientos que un detector etiqueta automáticamente cuando un usuario choca con fricción: rage clicks, dead clicks, error clicks y thrashed cursors. Cada una salta en un umbral hecho de un recuento, una distancia y una ventana de tiempo, y cada proveedor elige sus propios números. Una señal nombra el momento, no la causa, así que solo vale la pena cuando abre una sesión que puedes ver.
¿Qué son las señales de frustración en UX?
El término señales de frustración cubre comportamientos detectados automáticamente que muestran que un usuario chocó con fricción, y el conjunto estándar es rage clicks (varios clics rápidos en el mismo punto), dead clicks (un clic que no produce ninguna respuesta), error clicks (un clic al que le sigue un error de JavaScript) y thrashed cursors (el puntero moviéndose de un lado a otro sin clic), cada uno definido por un umbral y no por una suposición. Un detector lee el flujo de eventos que sale de la página, aplica una regla con números dentro y etiqueta la sesión cuando la regla coincide. Nadie etiqueta esto a mano. Ese es el punto. Una regla puede revisar cien mil sesiones en una noche, y un investigador no.
La palabra señal hace trabajo real ahí. Una señal no es un diagnóstico. Marca uno o dos segundos en los que el usuario y la interfaz no estuvieron de acuerdo sobre qué debía pasar a continuación, y te entrega una marca de tiempo. Averiguar qué se rompió de verdad sigue siendo tu trabajo.
¿Cuáles son las cuatro señales estándar?
Cuatro comportamientos forman el conjunto que trae la mayoría de las herramientas de replay, y cubren modos de fallo distintos. Los rage clicks atrapan un control que no responde. Los dead clicks atrapan algo que parece clicable y no lo es. Los error clicks atrapan una acción que lanzó una excepción de JavaScript. Los thrashed cursors atrapan a un usuario que no encuentra aquello por lo que vino.
| Señal | Qué hizo el usuario | A qué apunta | Qué revisar primero |
|---|---|---|---|
| Rage click | Hizo clic varias veces seguidas y rápido en el mismo punto | Un control que respondió demasiado lento o no respondió | El tiempo desde el clic hasta el primer cambio visible en ese elemento |
| Dead click | Hizo un solo clic sobre algo que no produjo ninguna respuesta | Texto no interactivo, un icono sin handler, un estado deshabilitado sin explicación | Si el elemento tiene un handler de clic y si parece un botón |
| Error click | Hizo clic y justo después saltó un error de JavaScript | Un handler roto, una petición fallida, una referencia nula en la ruta del clic | El stack trace y la llamada de red asociados a ese clic |
| Thrashed cursor | Movió el puntero de un lado a otro rápido sin hacer clic | Búsqueda de un control que falta, está mal etiquetado o queda bajo el pliegue | Si el objetivo de esa sección de la página se ve a ese ancho de viewport |
Lee la tercera columna de arriba abajo y verás por qué las cuatro existen como conjunto. Son cuatro tipos distintos de fricción del usuario, y meterlas en un único número de "frustración" tira a la basura la parte que te dice dónde mirar.

¿Cómo decide un detector que algo es un rage click?
Toda regla de rage click se construye con tres números: cuántos clics, dentro de qué radio, dentro de qué ventana de tiempo. Una serie de clics que supera los tres a la vez queda etiquetada. Digamos que tu herramienta está configurada para tres clics dentro de un radio de veinte píxeles en un segundo. Cuatro clics en el mismo botón en 700 milisegundos encajan. Cuatro clics repartidos en cinco segundos no, porque la ventana se cerró. Dos clics en cualquier sitio no, porque el recuento nunca llegó.
Las otras tres señales usan el mismo estilo de regla con entradas distintas. Un detector de dead click vigila un clic seguido de ningún cambio en el DOM, ninguna navegación y ninguna petición de red antes de que expire una ventana de espera. Un detector de error click enlaza un clic con cualquier error de JavaScript lanzado dentro de una ventana corta después de él. Un detector de thrashed cursor mide la distancia del puntero y los cambios de dirección a lo largo de una ventana sin ningún clic dentro.
¿Son esos umbrales iguales en todas las herramientas?
No. No hay un organismo de normalización para esto, y cada proveedor elige su propio recuento, radio y ventana, y luego los entrega como valores por defecto que a veces puedes editar. Los tres clics en un segundo de una herramienta son los cuatro clics en dos segundos de otra.
De ahí salen dos consecuencias. Los recuentos de rage clicks no se transfieren entre herramientas, así que una migración puede mover el número sin que cambie ni una sola cosa en tu interfaz. Y un benchmark que leas en el blog de otra persona mide los umbrales de esa persona, no los tuyos. Abre los ajustes de tu herramienta, anota los valores reales y ponlos junto a cualquier número que reportes.
¿Por qué dos rage clicks idénticos necesitan arreglos distintos?
Porque el detector no puede ver la intención, solo los clics. Un usuario aporreando un botón Guardar que tarda cuatro segundos en responder y un usuario aporreando un div que nunca se conectó a nada producen el mismo patrón de eventos. Mismo recuento, mismo radio, misma ventana, misma etiqueta en la sesión.
Los arreglos no tienen nada en común. El botón lento necesita un estado optimista, un spinner o un endpoint más rápido, y el handler del clic ya funciona. El elemento muerto necesita un handler, o necesita dejar de parecer un botón. Lanza el spinner de carga en el segundo caso y habrás hecho que un control roto parezca ocupado.
Este es el límite honesto de toda señal de frustración, y por eso el recuento por sí solo es casi inútil. Una tasa que pasó del 2 por ciento al 5 por ciento te dice que algo cambió. No te dice qué, y no lo hará hasta que alguien vea una de las sesiones.

¿Cómo se ordenan las señales por impacto?
Ordena por la proporción de sesiones afectadas, no por el recuento bruto de señales, porque un solo usuario furioso que hace cuarenta clics puede pesar más que un problema que golpea en silencio a mil personas.
tasa de frustración = sesiones con al menos una señal / sesiones totales
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Toma una semana con 8.300 sesiones donde 412 contenían al menos una señal. Eso es 412 / 8.300 = 0,0496, una tasa de frustración del 4,96 por ciento. Luego divide el mismo cálculo por elemento. Si 280 de esas 412 sesiones saltaron todas en un mismo botón de checkout, ese único elemento explica por sí solo el 3,37 por ciento de todas las sesiones, y las 132 sesiones restantes están repartidas por el resto del sitio. Ya sabes qué arreglo programar primero.
Agrupa antes de contar. Cuarenta rage clicks de una persona en un botón son un bug, no cuarenta, y un ranking que lo trate como cuarenta te mandará detrás del usuario más ruidoso en vez del problema más amplio.
¿Qué hace que una señal de frustración sea realmente útil?
Una señal es útil cuando puedes hacer clic en ella y aterrizar en el segundo exacto en que saltó. Ese es todo el bucle. La regla encuentra el momento, la grabación muestra la causa, y la causa te dice qué cambiar.
Sin ese salto, tienes un gráfico que dice que los usuarios están descontentos en algún sitio. Con él, ves el botón de checkout tardar cuatro segundos, ves el tercer clic aterrizar antes de la primera respuesta y sabes que el arreglo es un estado deshabilitado durante la petición. Flowsery detecta rage clicks, dead clicks, errores de JavaScript y abandonos de forma automática, agrupa las sesiones coincidentes en un único problema y ordena los problemas por cuántos usuarios los sufren, así que la señal llega ya enganchada a la grabación que necesitas ver.
Preguntas frecuentes
¿Existe una lista oficial de señales de frustración?
Ningún organismo de normalización define el conjunto. Rage clicks, dead clicks, error clicks y thrashed cursors son las cuatro en las que convergieron la mayoría de los productos de session replay, así que trátalas como una convención y no como una especificación. Algunas herramientas añaden las suyas, como envíos repetidos de formulario o ir y volver entre dos páginas.
¿Cuál es la diferencia entre un rage click y un dead click?
Un rage click son varios clics rápidos en la misma zona pequeña, lo que significa que el usuario lo intentó otra vez porque no pasó nada. Un dead click es un solo clic que no produjo ninguna respuesta. El mismo elemento roto puede generar los dos, según si el usuario se rindió tras un intento o siguió insistiendo.
¿Puede una señal de frustración ser un falso positivo?
Sí, y esto es lo principal que hay que prever. Un rage click en un botón lento pero funcional se ve idéntico a un rage click en un elemento realmente muerto, y hacer doble clic por costumbre en una app de escritorio que se comporta como una web dispara la misma regla. La etiqueta te dice dónde mirar, no qué está mal.
¿Funcionan las señales de frustración en móvil?
Los rage clicks, dead clicks y error clicks se traducen directamente a toques, ya que la regla de fondo va de recuento, distancia y tiempo. Los thrashed cursors no, porque los dispositivos táctiles no tienen un puntero flotante que seguir. En móvil, las herramientas sustituyen esa señal por otras de movimiento, como inversiones rápidas de scroll.
¿Debería poner una alerta sobre mi tasa de frustración?
Alerta sobre un cambio repentino y no sobre un número absoluto, ya que el número absoluto depende de umbrales que no estandarizaste. Un salto justo después de un deploy merece despertar a alguien. Una tasa que lleva seis meses en el 4 por ciento es un elemento del backlog, no un incidente.
¿Cuántas sesiones necesito para que los números signifiquen algo?
Las suficientes para que un solo usuario no pueda mover la tasa, lo que significa agrupar primero por usuario y después por elemento. Si un elemento explica la mayoría de tus sesiones etiquetadas a lo largo de muchos usuarios distintos, eso se sostiene con volúmenes pequeños. Una tasa calculada a partir de un puñado de sesiones se mueve varios puntos cada vez que una persona aporrea un botón.
¿Cómo se calcula una tasa de frustración?
Divide las sesiones con al menos una señal entre el total de sesiones del período. Una semana con 8.300 sesiones y 412 sesiones marcadas da 412 / 8.300, una tasa de frustración del 4,96 por ciento. Divide el mismo cálculo por elemento para saber qué páginas o botones están impulsando el número.
¿Por qué un botón lento activa un rage click?
El detector solo ve clics, no el motivo detrás de ellos. Un botón de Guardar que tarda cuatro segundos en responder recibe varios clics antes de que llegue la primera respuesta, y ese patrón coincide con el mismo conteo, radio y ventana que un botón sin ningún controlador. La solución es un estado optimista, un spinner o un endpoint más rápido, no un nuevo controlador de clic.
¿Qué suele causar un dead click?
Un dead click se dispara sobre texto no interactivo, un icono sin controlador o un estado deshabilitado sin explicación, cualquier cosa que parezca clicable pero no produzca cambio en el DOM, navegación ni solicitud de red antes de que expire la ventana de espera. Revisa si el elemento tiene un controlador de clic y si parece un botón.
¿Por qué agrupar las señales de frustración por usuario antes de ordenarlas?
Una persona que golpea un botón cuarenta veces genera cuarenta eventos de rage click para un solo error, y una clasificación que cuenta señales en bruto persigue ese ruido en lugar del problema que afecta a más gente. Agrupa primero por usuario y luego por elemento, para que un usuario furioso no pese más que una solución que afecta en silencio a mil sesiones.
¿Te resultó útil este artículo?
¡Cuéntanos qué opinas!
Vernos más en Google
Un clic marca Flowsery como fuente preferida y nuestros artículos aparecen más arriba en tus Noticias destacadas, el modo IA y los resúmenes con IA.
Antes de irte...
Flowsery
Analítica orientada a ingresos para tu sitio web
Rastrea cada visitante, fuente y conversión en tiempo real. Simple, potente y sin cookies.
Panel en tiempo real
Seguimiento de objetivos
Rastreo sin cookies
Términos relacionados del glosario


En qué se diferencian de verdad rage clicks vs dead clicks
La distinción rage clicks vs dead clicks va de causa, no de gravedad. Umbrales publicados por PostHog, Hotjar, FullStory, LogRocket y Clarity.


Qué cubre la analítica de experiencia digital que la analítica web no ve
En vez de contar eventos, la analítica de experiencia digital reconstruye la visita: session replay, heatmaps, detección de fricción y análisis de recorrido.


Qué exige de verdad el RGPD en session replay
Revisar el RGPD en session replay depende de cuatro cosas: base legal del artículo 6, datos del artículo 9, consentimiento ePrivacy 5(3) y una EIPD.


Dónde los valores por defecto de la redacción de PII en session replay dejan datos expuestos
Los valores por defecto de la redacción de PII en session replay varían: rrweb solo enmascara contraseñas, Sentry todo el texto, Clarity números y correos.


¿Cuánto ralentiza el session replay la velocidad de un sitio web?
La respuesta real a si el session replay ralentiza un sitio web, con cifras publicadas de rrweb y Sentry sobre script, CPU y ancho de banda de subida.


Lo que una demanda de escuchas por session replay tiene que probar ante un tribunal
Toda demanda de escuchas por session replay se apoya en CIPA 631, la WESCA de Pensilvania o la Wiretap Act federal. Qué alegan los demandantes y qué fallaron.
Artículos relacionados


Leer bien una curva de retención empieza con el análisis de cohortes
Una curva de retención solo tiene sentido cuando el análisis de cohortes agrupa usuarios por una misma fecha de inicio, ya que un promedio oculta el patrón.


Dos números se esconden detrás de una sola tasa de drop-off
Todo embudo produce dos cifras de tasa de drop-off, una por paso y otra de extremo a extremo, y los equipos las citan indistintamente. Una tabla las separa.


De quién es el dwell time, del buscador o de tu analítica
Los buscadores son dueños del dwell time y tu analítica no lo ve. Dónde cae la línea frente al tiempo en página y la duración de sesión, y qué documenta Google.

