Un replay es una reconstrucción, no un vídeo
El malentendido más común sobre el session replay es que graba la pantalla. No lo hace. Un replay captura el DOM — la estructura de la página — junto con cada cambio en ella, además de clics, scrolls, eventos de entrada, tiempos de red y errores de consola. La reproducción reconstruye la página a partir de esos datos en tu navegador.
Esa distinción lo es todo. Como un replay es dato estructurado y no píxeles, puedes buscarlo, saltar al instante exacto en que se lanzó un error y leer el estado del DOM en ese momento. Una grabación de pantalla no te da nada de eso, y consume mucho más ancho de banda.
Lo que aporta y un stack trace no
Un rastreador de errores te dice que se lanzó un TypeError en la línea 214. No te dice que el usuario ya había enviado el formulario dos veces, que el segundo intento fue con una conexión lenta, ni que el botón se quedó deshabilitado después. El replay aporta la secuencia de eventos que produjo el estado con el que tu código se atragantó.
En la práctica esto elimina la parte más lenta de depurar: la reproducción. En lugar de adivinar los pasos a partir de un informe de una línea, ves el camino que el usuario recorrió de verdad.
Cómo usarlo cuando entra un error
Trabaja hacia atrás desde el fallo, no hacia delante desde el inicio de la sesión. Localiza el error en tu monitorización, abre el replay enlazado y salta a la marca de tiempo. Luego retrocede treinta segundos: la causa casi siempre está en el medio minuto anterior al síntoma, no al principio de la sesión.
Comprueba tres cosas en orden: qué pulsó el usuario justo antes, si alguna petición falló o se quedó colgada, y si lo que vio en pantalla coincidía con lo que esperabas renderizar. La mayoría de los errores se resuelven en una de esas tres.
Lo que no va a resolver
El replay te muestra qué pasó, nunca por qué esa persona lo hizo. Si un usuario abandona un formulario, la grabación te dice en qué campo se detuvo, pero no si la pregunta le resultó confusa, intrusiva o simplemente demasiado larga. Esa respuesta se obtiene preguntando.
También es malo para preguntas agregadas. Una grabación es una anécdota. Si necesitas saber con qué frecuencia ocurre algo, eso es un embudo o una consulta de eventos; usa el replay para explicar la caída, no para medirla.
Cómo elegir uno pensando en depurar
Si el trabajo es depurar, pesa tres cosas por encima del resto. Captura de consola y de red: sin ellas estás viendo cine mudo. Enlace de error a replay, para que una excepción te lleve directamente a la sesión que la produjo y no a una lista que hay que rebuscar. Y controles de privacidad lo bastante granulares para que la herramienta siga sirviendo: enmascarar todos los campos protege a los usuarios, pero puede ocultar justo el valor que provocó el error, así que busca reglas por campo en lugar de un interruptor de todo o nada.