Glosario

Las cuatro señales de frustración y qué significa cada una

Taras Shynkarenko
Taras Shynkarenko
•Actualizado: •8 min de lectura
Las cuatro señales de frustración y qué significa cada unaLas cuatro señales de frustración y qué significa cada una

TL;DR, Respuesta rápida

8 min de lectura

Las 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ñalQué hizo el usuarioA qué apuntaQué revisar primero
Rage clickHizo clic varias veces seguidas y rápido en el mismo puntoUn control que respondió demasiado lento o no respondióEl tiempo desde el clic hasta el primer cambio visible en ese elemento
Dead clickHizo un solo clic sobre algo que no produjo ninguna respuestaTexto no interactivo, un icono sin handler, un estado deshabilitado sin explicaciónSi el elemento tiene un handler de clic y si parece un botón
Error clickHizo clic y justo después saltó un error de JavaScriptUn handler roto, una petición fallida, una referencia nula en la ruta del clicEl stack trace y la llamada de red asociados a ese clic
Thrashed cursorMovió el puntero de un lado a otro rápido sin hacer clicBúsqueda de un control que falta, está mal etiquetado o queda bajo el pliegueSi 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.

Una persona hace clic varias veces rápido en el trackpad del portátil, el patrón que una regla de rage click está hecha para detectar.

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

Un analista observa gráficos en un monitor, el tipo de datos de sesión que se revisan para ordenar señales según cuántos usuarios afectan.

¿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

Flowsery
Flowsery

Empieza tu prueba gratis de 14 días

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.

Una semana, 8.300 sesiones
Sesiones totales 8.300
Sesiones con una señal 412
Botón de pago 280
Resto del sitio 132
En esa semana, un solo botón de pago generó más sesiones marcadas que el resto del sitio combinado.

¿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

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 clicksEn qué se diferencian de verdad rage clicks vs dead clicks
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.

•9 min de lectura
Qué cubre la analítica de experiencia digital que la analítica web no veQué cubre la analítica de experiencia digital que la analítica web no ve
Glosario

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.

•8 min de lectura
Qué exige de verdad el RGPD en session replayQué exige de verdad el RGPD en session replay
Glosario

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.

•10 min de lectura
Dónde los valores por defecto de la redacción de PII en session replay dejan datos expuestosDónde los valores por defecto de la redacción de PII en session replay dejan datos expuestos
Glosario

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.

•10 min de lectura
¿Cuánto ralentiza el session replay la velocidad de un sitio web?¿Cuánto ralentiza el session replay la velocidad de un sitio web?
Glosario

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

•9 min de lectura
Lo que una demanda de escuchas por session replay tiene que probar ante un tribunalLo que una demanda de escuchas por session replay tiene que probar ante un tribunal
Glosario

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.

•10 min de lectura

Artículos relacionados