Alguien en tu sitio se topa con un error. Puede verlo: el diseño roto, el botón que no hace nada, el mensaje en rojo. Para cuando eso llega a un desarrollador se ha convertido en una frase. “El checkout está roto.” Todo lo que se podía ver se ha tirado a la basura, y el primer trabajo del desarrollador es reconstruirlo a base de preguntas.
El reporte visual de errores es la práctica de capturar lo que había en la pantalla, y lo que sabía el navegador, en el momento en que alguien decidió avisar de un problema. El informe es la evidencia, no una descripción de ella.
Qué lleva dentro en realidad
La palabra “visual” se queda corta. La imagen es la parte que uno nota; la mayor parte del valor está en lo que el navegador estaba haciendo detrás de la imagen.
Un informe visual de errores suele llevar algunas de estas cosas, o todas:
- Una captura de pantalla o una grabación de la página tal como la vio quien avisa, a menudo con algo dibujado encima para señalar el problema.
- El entorno: navegador y versión, sistema operativo, tamaño de pantalla. Los datos que deciden si un defecto es universal o pertenece a una sola configuración.
- La salida de la consola, incluido el error que se imprimió mientras nadie la estaba mirando.
- El registro de red: qué peticiones hizo la página, qué devolvieron, cuánto tardaron. Con frecuencia la respuesta es un 403 que nadie vio.
- Lo que hizo quien avisa: los clics, lo que escribió en los formularios y los cambios de página que llevaron hasta ahí, en orden.
Eso último es lo que convierte un informe en instrucciones. Unos pasos de reproducción escritos de memoria son una reconstrucción; una secuencia grabada es un registro.
En qué se diferencia del session replay
Los dos se confunden, también nosotros: nuestro producto se llama Session Replay, que es un nombre que elegimos y una categoría en la que no estamos.
El session replay, tal como se usa normalmente el término, es una práctica de analítica. Un script se ejecuta en cada página para cada visitante y graba las sesiones de forma continua para que alguien pueda verlas después, normalmente buscando patrones: dónde duda la gente, dónde abandona un formulario, qué rage click precede a qué abandono. Nadie pulsa nada. La grabación existe porque se graba a todo el mundo.
El reporte visual de errores empieza cuando una persona decide que algo está mal. No se graba nada hasta que actúa, y lo que produce va dirigido a un lector concreto con un defecto concreto en mente.
- Session replay
- Siempre encendido, todos los visitantes, visto después para encontrar problemas que nadie avisó
- Reporte visual de errores
- Empieza cuando alguien avisa, captura un incidente, se envía a quien puede arreglarlo
La diferencia importa por dos razones prácticas. La primera es la privacidad: una herramienta que graba a todo el mundo por defecto tiene que responder por lo que guardó sobre personas que nunca pidieron nada, y por eso las herramientas de session replay dedican tanta parte de su documentación al enmascaramiento. Un informe que solo existe porque alguien eligió enviarlo tiene una pregunta mucho más pequeña que responder.
La segunda es la recuperación. Encontrar entre miles la única sesión que contiene el error del que te han hablado es un trabajo en sí mismo. Un informe llega sabiendo ya de qué incidente trata.
Dónde es la herramienta equivocada
El reporte visual de errores solo ve lo que alguien decidió contar. No te dirá cuánta otra gente se topó con el mismo defecto y se marchó, y no sacará a la luz un problema del que nadie se quejó. Eso lo responde la analítica, y un informe de error no puede.
También es inútil para todo lo que el navegador no puede ver. Un trabajo que falló en una cola, una importación nocturna que escribió las filas equivocadas, una condición de carrera entre dos servicios: nada de eso está en una página, y ninguna cantidad de captura de pantalla lo va a encontrar. Para eso están los logs y el tracing.
La postura honesta es que son tres herramientas para tres preguntas distintas. Qué le salió mal a esta persona, ahora mismo, es la única que un informe visual de errores responde bien.
Qué aspecto tiene en la práctica
La versión que construimos nosotros es una extensión de Chrome. Alguien se topa con un error, hace clic en el icono y obtiene una captura de pantalla o una grabación con el entorno, la salida de la consola, el registro de red y la secuencia de lo que hizo adjuntos. Recibe un enlace para pegarlo donde se lleve el seguimiento del trabajo. No hace falta cuenta para enviar uno.
Session Replay
Extensión de Chrome gratuita. Un clic en la página que se está portando mal captura la captura de pantalla, la consola y el registro de red, y te da un enlace para pegar en el ticket.
Dos cosas que no hace, porque una explicación de categoría que solo enumera virtudes es un anuncio. No vigila a todo el mundo: no se graba nada hasta que alguien decide avisar de algo, así que nunca te hablará de la gente que se topó con el mismo defecto y se fue sin decir nada. Y no decide qué importa. El título, la gravedad y el juicio sobre si dos síntomas son un mismo defecto siguen siendo de la persona que estaba allí, que es de lo que trata cómo escribir un informe de error perfecto.
Si estás eligiendo entre los dos
Pregúntate qué pregunta intentas responder.
Si es “por qué abandona la gente este formulario”, quieres analítica, y el session replay es parte de esa familia. Si es “por qué se rompió esto para esta persona”, quieres el incidente capturado y enviado a alguien, y eso es reporte de errores. Los equipos que necesitan las dos cosas suelen usar las dos, y confundirlas es la forma de acabar viendo cuatrocientas grabaciones para encontrar una que alguien te podría haber dado en quince segundos.
Los informes en sí siguen teniendo que estar bien escritos: la captura quita la excusa de que falte contexto, no la necesidad de un título claro y de una explicación honesta de lo que esperabas. Los diez errores más comunes siguen al alcance de cualquiera que avise, por buenas que sean sus herramientas.