«¿Qué hiciste justo antes de que fallara?» es la pregunta que hace todo desarrollador y que casi ningún usuario sabe responder con precisión. La gente no recuerda qué botón pulsó en segundo lugar, si la página había terminado de cargar o que pulsó «atrás» en mitad de un formulario. La repetición de sesión responde a la pregunta sin hacerla: una grabación de lo que de verdad pasó en el navegador del usuario, que puedes adelantar y retroceder, adjunta al reporte de bug.
Cómo funciona de verdad la repetición de sesión
La repetición de sesión moderna no es video. Grabar píxeles ocuparía muchísimo, sería lento y no sabría nada de la estructura de la página. En su lugar, herramientas como rrweb (el motor de código abierto sobre el que está construida la repetición de BugDump) toman una instantánea del DOM y luego registran las mutaciones: nodos añadidos y eliminados, cambios de atributos, valores de los campos, scrolls, movimientos del cursor, clics.
La reproducción reconstruye la página a partir de esos datos, como reproducir una partida de ajedrez a partir de la notación en lugar de filmar el tablero. El resultado ocupa poco y, como es estructural y no visual, puedes recorrerlo y ver exactamente con qué elemento interactuó el usuario, no solo dónde estaba su cursor en la pantalla.
La consecuencia práctica: la repetición es lo bastante barata como para ejecutarse en segundo plano todo el tiempo, así que los momentos anteriores a que el usuario decida reportar un bug ya están capturados cuando pulsa el botón de reporte. Esa es la parte que los flujos tipo video de «graba tu pantalla ahora» nunca te pueden dar: cuando alguien empieza a grabar, el bug ya ocurrió.
Lo que la repetición te dice y los logs no
Los logs de consola y de red te dicen qué hizo el código. La repetición te dice qué hizo el usuario. Los bugs viven en el hueco entre ambos, y algunas categorías son casi imposibles de diagnosticar sin la parte del usuario:
Bugs de secuencia: el modal solo se rompe al abrirlo, cerrarlo y volver a abrirlo. Ninguna línea de log lo dice; la repetición lo muestra en diez segundos.
Condiciones de carrera: el usuario hizo clic antes de que terminara una solicitud. La repetición marca la hora del clic; el log de red marca la hora de la respuesta; juntos son el diagnóstico.
Datos «incorrectos» que no lo son: el usuario pegó un valor con un espacio al final, o el autocompletado rellenó un campo que no esperabas. La repetición muestra el estado real del formulario.
Confusión con el estado de la interfaz: el usuario estaba en una vista filtrada, en una pestaña desactualizada o a mitad de una edición sin guardar. El estado del DOM en cada momento está ahí.
Lo contrario también es cierto: la repetición sin logs te muestra que la página se rompió, pero no por qué. La excepción no capturada está en la consola; el 500, en la pestaña de red. Por eso la repetición es más útil como un panel de un reporte completo que como herramienta aislada.
La repetición en un flujo de reporte de bugs
Tradicionalmente, la repetición de sesión pertenece a la analítica: grabar a todo el mundo y luego tomar muestras de sesiones para estudiar la UX. Ese modelo da mucho de sí, pero es pesado: guardas miles de sesiones para mirar una de vez en cuando.
El reporte de bugs le da la vuelta. BugDump recoge la repetición en segundo plano y la adjunta cuando un usuario envía un reporte, junto con el búfer de consola (hasta 300 entradas, 2000 durante una grabación), el búfer de red (150 solicitudes, 1000 durante una grabación, con las fallidas marcadas), los detalles del entorno y las métricas de rendimiento. Tienes repeticiones justo de las sesiones en las que algo salió mal y una persona lo dijo, las sesiones con más señal que existen.
El reporte llega como un expediente completo: lees la descripción de una frase del usuario, recorres la repetición para ver la acción, buscas en la consola la excepción que provocó y encuentras la solicitud fallida en el log de red. Para muchos bugs, esa secuencia sustituye toda la conversación de «pasos para reproducir».
Privacidad
Una grabación del DOM puede contener todo lo que muestra una página, incluido lo que escriben los usuarios. Tómatelo en serio:
Decide qué se graba. La repetición debería ser un interruptor deliberado por proyecto, no un valor por defecto invisible del que te olvidaste. BugDump la expone como un feature flag (
features.sessionReplay) que controlas tú.Filtra el tráfico sensible. Si capturas datos de red, usa filtros para dejar fuera de los búferes los endpoints de terceros o sensibles: se descartan antes de guardarse, no se censuran después.
Deja que quien reporta oculte lo visual. La anotación de capturas con una herramienta de desenfoque permite al usuario ocultar su propio número de cuenta antes de enviar. Que oculte los datos la persona que sabe qué es sensible funciona mejor que hacerlo con una regex.
Avísalo. Tu política de privacidad debería decir que los reportes de bugs pueden incluir una grabación de la sesión de quien reporta. Quien envía un reporte de bug suele alegrarse de que los datos vayan con él, pero debería saberlo.
Cuándo la repetición sobra
No todos los proyectos necesitan repetición desde el primer día. Un sitio de contenido sin estado interactivo obtiene casi todo su valor de las capturas de pantalla y los logs de consola. La repetición se gana su sitio cuando tu app tiene flujos (formularios de varios pasos, editores, checkouts, dashboards) en los que el camino importa tanto como el destino. Si tus últimas cinco conversaciones sobre bugs incluyeron la frase «de acuerdo, pero ¿qué pulsaste antes de eso?», la repetición se paga sola de inmediato.
También conviene saber qué tipo de «grabación» obtienes. El widget de BugDump ofrece tanto la grabación de pantalla explícita (el usuario explica un problema mientras graba su pantalla) como la repetición de sesión en segundo plano (automática, adjunta a los reportes). La primera es una herramienta de comunicación; la segunda, una herramienta forense. Se complementan, no se sustituyen.
En resumen
La repetición de sesión cierra el hueco más antiguo del reporte de bugs: la diferencia entre lo que los usuarios dicen que pasó y lo que pasó. Junto con los logs de consola, los datos de red y los detalles del entorno, y recogida automáticamente en el momento en que un usuario real se topa con un problema real, hace que «no se puede reproducir» pase de ser una forma habitual de cerrar un bug a ser una rareza.
Te puede interesar
Repetición de sesión sin vigilancia — cómo uso la repetición de sesión: limitada a un reporte, con datos que el usuario puede ocultar y desactivable con una línea.
Cómo ver los errores de consola de tus usuarios sin DevTools — cómo funciona la captura en el cliente (búferes circulares, hooks de red, filtros) y cómo tenerla con una etiqueta script.
Qué hacer con un reporte de bug que no puedes reproducir — las causas habituales, el contexto que las resuelve y cómo evitar que se repitan.