La repetición de sesión tiene un problema de reputación, y en gran parte merecido.
La categoría la definieron herramientas de analítica que graban todas las sesiones de todos los usuarios, sin parar y para siempre, para que un equipo de growth pueda revisar el proceso de pago de alguien el trimestre que viene. Eso es vigilancia con una función de depuración pegada, y los usuarios tienen razón en que les incomode.
Aun así, uso la repetición de sesión, porque para un tipo de bug no funciona nada más. Pero la uso de otra manera.
Cuándo la repetición es la única herramienta
La mayoría de los bugs se resuelven con la consola y el registro de red. Un error, un 500, listo.
Luego está el otro tipo. Consola limpia. Red limpia. Todas las peticiones devolvieron 200. Y el usuario está completamente seguro de que algo se rompió.
Casi siempre tiene razón. Lo que se rompió fue la interacción: un clic que cayó en el elemento equivocado, un formulario que se reinició sin avisar, un modal que se abrió detrás de una capa, una transición de estado que dejó la interfaz de una forma que nunca previste. Nada de eso produce un error, porque desde el punto de vista del código no salió nada mal.
En esos casos, la repetición es toda la investigación. Ves los doce segundos anteriores al reporte y lo que el usuario hizo de verdad, que muchas veces no es lo que describió.
Limitada a un reporte, no a un usuario
La diferencia de fondo: en BugDump, la repetición va unida a un reporte de bug, no al perfil de un usuario.
La grabación existe para explicar un reporte concreto que alguien envió. No construye un historial a largo plazo del comportamiento de nadie. No hay navegador de sesiones, ni «ver a un usuario al azar», ni análisis de embudos. Si nadie reportó un bug, nadie está mirando nada.
Es una función más pequeña que la repetición de las herramientas de analítica. De eso se trata. La versión acotada resuelve el problema de depuración sin la parte que incomoda a la gente.
La herramienta para ocultar datos la tiene el usuario
El anotador de capturas de pantalla incluye una herramienta para difuminar, y funciona como debe: los datos se ocultan en el navegador antes de subir nada. Una zona difuminada no se difumina en los servidores de BugDump: nunca llega a ellos.
Esto invierte lo habitual. Normalmente la privacidad es una promesa del proveedor: dice que tratará tus datos con responsabilidad, y tú decides si le crees. Ocultar datos en el navegador no es una promesa. Los píxeles no salen de la máquina.
En la práctica, significa que un usuario que está viendo una página llena de nombres de clientes puede enviarte la captura que necesitas. Sin esto, los más cuidadosos no envían nada.
Desactivado por defecto, donde importa
captureNetworkBodies es false salvo que lo actives.
Los cuerpos son útiles: a veces el payload de la respuesta es todo el bug. También son donde viven los tokens, los datos personales y los datos de pago. El valor por defecto seguro es aquel en el que activarlo es una decisión que alguien tomó a propósito.
La repetición en sí se desactiva con una línea, ya sea de forma global o en las rutas que no deben grabarse:
Bugdump.init({
apiKey: 'your-api-key',
features: {
sessionReplay: false,
},
});Todas las funciones de captura funcionan así: capturas de pantalla, grabación, repetición y adjuntos se activan y desactivan cada uno por su lado. Puedes usar BugDump solo con una descripción y un log de consola si es lo que exige tu política de cumplimiento.
El aviso de permisos que decidí mantener
Por defecto, las capturas de pantalla y las grabaciones usan getDisplayMedia, que muestra el diálogo de permisos del propio navegador. Podría haberlo evitado del todo usando por defecto el renderizado del DOM.
Lo mantuve, por dos razones.
La fidelidad es real: canvas, video, iframes de otros orígenes y controles nativos se capturan exactamente como se ven, no de forma aproximada. Y el aviso es honesto. Es el navegador, no BugDump, quien le dice al usuario que van a capturar su pantalla. Puede rechazarlo, y si lo rechaza se recurre a la captura del DOM en lugar de perder el reporte.
Un diálogo de permisos es fricción. También es consentimiento, y lo entrega alguien a quien no controlamos ni tú ni yo.
Mi postura
La industria de la analítica enseñó a la gente a desconfiar de la repetición de sesión, una herramienta potente. La desconfianza es razonable, y aun así la herramienta vale la pena.
Mi respuesta: limitarla a reportes y no a sesiones, poner la herramienta para ocultar datos en manos del usuario y aplicarla antes de subir nada, desactivar por defecto la captura más arriesgada y hacer que cada función se pueda desactivar con una línea.
Tú recibes los doce segundos que explican el bug. No recibes un sistema de vigilancia, y yo tampoco.
Te puede interesar
Repetición de sesión para depurar: mira qué hizo el usuario antes del bug — qué graba una repetición de sesión y por qué, junto a la consola y la red, vuelve diagnosticable un reporte vago.
Anatomía de un reporte de bug: qué captura BugDump y por qué — cada señal que recoge el widget, por qué se gana su sitio y cuáles resuelven bugs de verdad.
Cómo capturar logs de consola y peticiones de red del navegador del usuario — qué parchear y en qué orden, y por qué los cuerpos de red y los datos sensibles se filtran antes de salir del navegador.