Qué es Session Replay y cómo mejora la experiencia del usuario en entornos IT

Esto es lo que descubre enseguida cualquiera dedicado a la tecnología: Que el usuario la utilizará de la forma más inesperada y estrambótica posible… y que cuando algo falla, él nunca «ha tocado nada». Entre cómo se diseña algo y cómo se utiliza finalmente hay un océano de distancia y muchos bugs que pescar en él. Pero podemos optimizar esos procesos usando session replay.
Gracias a esta técnica de captura y reproducción de eventos, podemos alinear tecnología y experiencia de usuario, aumentando la satisfacción y productividad del usuario y el servicio técnico. Por eso, veremos en qué consiste session replay, cómo se diferencia de otras alternativas y cómo aplicarla para tener usuarios felices y técnicos que no quieran estrangularlos.

La mejora de experiencia de usuario mediante su monitorización

La tecnología alcanza su verdadero sentido cuando el usuario se beneficia de ella aumentando su productividad, comodidad, etc. Esa experiencia positiva es clave para que una tecnología se adopte y triunfe. Por eso, observar lo que hace el usuario con ella, a fin de prevenir errores y mejorarla, ya no es opcional.
A menudo se intenta mejorar dicha experiencia con encuestas, sugerencias… Pero muchas veces, el técnico está desconectado del proceso final que trata de mejorar (porque no lo usa cada día) y el usuario no tiene capacidad de verbalizar cómo optimizarla o lo ocurrido durante un error, al no comprender capacidades o limitaciones técnicas.
Session replay elimina esos obstáculos.

¿Qué es session replay y en qué se diferencia de otras técnicas UX?

Session replay es una tecnología que registra las interacciones de un usuario en una web o aplicación, capturando eventos (clics, scroll, inputs…) y cambios en el DOM (Document Object Model). Así, reconstruimos la sesión del usuario usando esos datos técnicos, lo que permite observar comportamientos y reproducirlos paso a paso.
Session replay no es la única manera de hacerlo y otras opciones son:

• Session recording. En forma de grabaciones en vídeo de lo que hace el usuario, mientras que replay usa datos estructurados para recrear la sesión.
• Mapas de calor. Que muestran patrones agregados (como zonas con mayor clic), pero no permiten analizar sesiones individuales o su secuencia temporal.
• Analítica tradicional. Que proporciona métricas cuantitativas (rebote, tiempo en página…), pero sin contexto visual ni detalle de los flujos de trabajo.

¿Cómo funciona técnicamente session replay?

Capturando datos de lo que ocurre en la página o aplicación, conseguidos de:

• Cambios en el árbol del documento (DOM), incluyendo actualizaciones dinámicas como las realizadas con AJAX.
• Eventos e inputs de usuario. Recogiendo clics, pulsaciones de teclas, envío de formularios…
• Capturas de pantalla o visuales. Detectando con esos snapshots cosas como fuentes personalizadas o CSS complejo.

Esos datos se guardan (por ejemplo, en formato JSON) y permiten reproducir la sesión de usuario con Websocket o motores de renderizado, como WEBGL.
Así, tendremos una reconstrucción de los hechos, además de datos que un vídeo de session recording no puede proporcionar, ni extraer, a partir de imágenes en movimiento.
Sin embargo, como todo en la vida, session replay no está exento de limitaciones.
Por ejemplo, en un teléfono dependeremos del SDK para acceder a eventos del sistema, o elementos como Canvas y WebGL pueden no capturarse fácilmente. Si, por ejemplo, un usuario paranoico concienciado con la privacidad (no miro a nadie, pero me miro a mí), usa Firefox con protección mejorada de tracking y bloquea Canvas para evitar fingerprinting, una session replay no registrará las interacciones de webs que usen ese Canvas. Del mismo modo, el extendido bloqueador de anuncios uBlock Origin puede bloquear scripts de grabación si los detecta como trackers.
Esto limita la efectividad de session replay para reproducir fielmente lo que ha hecho el usuario.

Casos de uso de session replay

Poder mirar por encima del hombro del usuario y disponer de datos que agregar y analizar es enormemente útil, porque el objetivo no es hacer realidad Gran Hermano, sino analizar su experiencia para mejorarla y solventar los fallos que surjan más rápidamente.
Así, casos de uso habituales son:

• En UX. Para reducir fricciones en el uso de la app, web o tecnología, mejorar su utilización, hacerla más eficiente y que la herramienta trabaje para el usuario y no contra él.
• En producto. Para analizar su uso real (que nunca será el previsto inicialmente), comprobar si se utilizan las nuevas características desplegadas, cuáles son más populares… El objetivo es alinear el producto con las necesidades del usuario.
• En negocio y marketing. Para mejorar la conversión (reduciendo de nuevo la fricción, viendo dónde se abandona más un proceso de compra o embudo de venta y por qué…).
• En soporte técnico. Para reducir incidencias, tickets y, sobre todo, comprobar qué hay realmente detrás de la frase favorita del usuario ante un fallo: «Yo no he tocado nada».

Retos técnicos y limitaciones de session replay

Aunque session replay ofrece datos fundamentales con los que podemos trabajar mucho mejor que con imágenes grabadas (de las que no podremos extraer mucho, a menos que pasemos horas mirando aburridas sesiones y anotando a mano), hay varios retos con esta tecnología.
Por ejemplo, podemos sobrecargar con demasiados datos que no aporten, o reducir el rendimiento de equipos, contribuyendo a aquello que queremos eliminar.
Del mismo modo, puede que tengamos mucha información de sesiones poco representativas para nuestro objetivo, con lo que da igual lo sesudo que sea el análisis, si la materia prima no es buena, las conclusiones serán irrelevantes.
Además, esto implica desplegar una especie de «estado policial» que recoge todo lo que hace el usuario. Y eso puede tener implicaciones no deseadas si cometemos ciertos errores y omitimos buenas prácticas.

Errores comunes y buenas prácticas con session replay

Para evitarnos problemas técnicos o legales, lo primero es no tropezar con piedras más habituales en este camino y que son:

• Grabarlo todo. Mucha información no significa mucho conocimiento. Si no ponemos filtros para lo que queremos saber según nuestros objetivos, solo lastraremos el rendimiento y llenaremos discos duros de datos inútiles.
• No anonimizar. La privacidad es fundamental y sus leyes vienen con multas bajo el brazo, así que hemos de tenerlas en cuenta. Además, session replay analiza para mejorar aspectos clave, no es una tecnología de vigilancia.
• No contextualizar. Los datos no tienen sentido en el vacío. Imaginemos una sesión lenta para el usuario, si no «vemos» más que eso, poco podremos conocer sobre el motivo, pero si contextualizamos con otros datos, como la carga de la CPU u otros programas ejecutados a la vez, puede que encontremos la clave.

Una vez evitado lo anterior, ¿qué buenas prácticas son recomendables?

• Poner objetivos claros. Debemos establecer nuestra meta concreta, qué necesitamos saber para cumplirla y recoger eso y ni una cosa más, en nombre de la eficiencia.
• Segmentar sesiones y datos. Así, podemos hacerla respecto a cuántos abandonaron el carro de compra en la web, cuántos usaron la nueva prestación en la aplicación de trabajo…
• Cruzar con otros datos cuantitativos, como analíticas tradicionales, para una perspectiva más amplia. Ante un cambio en la web, cruzar datos de session replay junto a Analytics de Google puede dar una imagen más completa del impacto del rediseño.

Herramientas populares de session replay

Si se nos enciende una bombilla con todo esto, tenemos bastantes opciones en cuanto a session replay. Esta es una comparativa de las herramientas más populares.

Herramienta	Tipo	Fortalezas	Limitaciones	Ideal para
Mixpanel	SaaS (Propietario)	Integración con analítica de producto. Filtros avanzados por eventos. Puedes empezar gratis.	Costo elevado para sesiones ilimitadas. Menos detalle técnico (enfocado a producto y marketing).	Equipos de producto y marketing (embudos), con énfasis en decisiones basadas en datos para mejorar el negocio.
Amplitude	SaaS (Propietario)	Correlación entre sesiones y métricas de negocio. Soporte para A/B testing. Puedes empezar gratis.	Complejidad en configuración. Precio elevado por volumen de datos.	Empresas enfocadas en conversión y retención.
Datadog	SaaS (Propietario)	Integración con logs, APM y métricas de infra. Enfoque full-stack. Machine learning y detección de riesgos.	Menos énfasis en UX. Costo elevado para equipos pequeños con muchos hosts.	Equipos DevOps.
PostHog	Open Source / SaaS	Autohospedaje. Suite completa (grabación + analítica).	Requiere mantenimiento técnico en versión self-hosted.	Startups o equipos técnicos con presupuesto ajustado.
OpenReplay	Open Source /SaaS	Gratuito y autohospedable. Enmascaramiento de datos sensible integrado.	Menos integraciones nativas que herramientas SaaS.	Empresas con restricciones de privacidad.

Cómo elegir y configurar la herramienta adecuada

Qué escoger dependerá de la organización, sus objetivos… y su presupuesto, porque la vida real es así.
Si necesitamos control total y anonimización, podemos optar por OpenReplay alojado en nuestros servidores, pero si estamos enfocados en negocio y queremos conocer el «viaje del cliente» por nuestro producto o web, Amplitude y Mixpanel se especializan en eso.
Para elegir bien debemos valorar:

• Qué es capaz de recoger la herramienta y los filtros que realiza a esos datos.
• La retención de los mismos.
• La escalabilidad, en caso de implementarse en más sistemas o tener un aumento de usuarios.
• La integración con el resto de la infraestructura, y si juega bien en equipo con otras analíticas o datos.

Como recomendaciones generales para una configuración segura y útil, deberíamos considerar:

• Empezar recogiendo los datos mínimos críticos (siempre podremos ir añadiendo).
• Monitorizar esa recogida para ver qué información obtenemos de esos datos.
• Comprobar cómo afecta session replay al rendimiento de equipos o almacenaje.
• Configurar la privacidad de la herramienta, algo fundamental que merece profundizarse.

La privacidad de session replay, anonimización y cumplimiento normativo

En estos tiempos de vigilancia de cada paso tecnológico, conviene insistir en que session replay sirve para obtener insights que mejoren la experiencia de usuario y el arreglo de fallos a partir de datos globales, no es para vigilar comportamientos individuales. Sin embargo, recoger eventos como teclas pulsadas o visitas a webs implica cuestiones importantes de privacidad.
Esas keypresses pueden incluir contraseñas si se capturan de manera indiscriminada, o visitas a páginas que revelen datos de la esfera íntima del usuario.
Por eso, hemos de considerar siempre la legislación de privacidad de datos a las que estemos sometidos. Por ejemplo:

• El RGPD europeo. Que insta a recoger solamente la información mínima necesaria, pedir consentimiento explícito si se recogen datos personales (como emails o IPs) y garantizar el derecho al olvido.
• PCI-DSS. El estándar de seguridad para tarjetas de pago impide grabar números de tarjetas, CVV, pins…

Muchas herramientas prevén esto y enmascaran campos en tiempo real (sustituyéndolos por asteriscos) o no recogerlos para selectores determinados (como los tipo password en HTML). Igualmente, se pueden eliminar o hashear IPs, pero debemos ajustar siempre las técnicas y herramientas a nuestra situación concreta.

Análisis de sesiones: metodología y patrones

La mejor herramienta es inútil si no adoptamos las mejores prácticas. Por eso, sin importar la aplicación elegida, la metodología básica de uso sería:

• Definir exactamente nuestros objetivos. No implementamos session replay por moda o para presumir, por eso, lo primero es clarificar bien el objetivo. ¿Es mejorar la experiencia de usuario? ¿Aumentar las ventas de la tienda online? ¿La productividad del trabajador?
• Traducir objetivos en indicadores clave. ¿Cómo medimos si lo anterior se cumple? Aquí entra la selección de KPIs. Pueden ser porcentajes de conversión, de abandono del carro de compra, registros introducidos en un software de trabajo, tiempos medios de introducción de esos registros…
• Comprobar si session replay ofrece los datos necesarios para los KPIs e integrar con otras fuentes si es necesario (como analíticas tradicionales).
• Buscar patrones y anomalías. Session replay dará mucha información, pero en primer lugar debemos detectar patrones comunes y anomalías. ¿Por qué los usuarios que llegan de un email comercial abandonan más una compra que quienes llegan por Google? Quizá indique que los mensajes de los correos promocionales no están alineados con la landing page. ¿Por qué aparecen clics donde no deberían al introducir clientes en el CRM?
• Proponer mejoras basadas en lo anterior.
• Repetir los pasos anteriores, implementando una mejora continua basada en datos.

Ejemplo práctico de aplicación de session replay para enmendar errores

Una de las aplicaciones habituales de esta tecnología es solventar errores en apps y herramientas. Cuando ocurre dicho error, session replay sustituye la poco productiva conversación entre técnico y usuario, que solo suele decir: «No entiendo tu idioma y no sé qué son todas esas cosas que me preguntas».
Sin embargo, cuando llegan informes de fallo, podemos acudir al session replay para ver qué pasó realmente y no necesitar paciencia ni el traductor universal de Star Trek para el idioma técnico-usuario.
Así, la herramienta muestra qué ocurrió, qué se pinchó en la aplicación y comprobar que el usuario siempre miente cuando dice que no ha tocado nada.
Imaginemos un error en el pago de una tienda online. Los usuarios reportan que, tras introducir la tarjeta, el botón «Comprar» no funciona. Con session replay, el técnico ve que, el 90% de los casos, los usuarios hacen clic en un elemento fantasma: un overlay CSS que se carga mal en iOS 16, por ejemplo. Así, el evento click no llega al botón. Además, la consola JavaScript registra un error de CORS al cargar la pasarela de pago.
Sin session replay se habría achacado a una posible mala conexión del cliente, perdiendo más ventas. Pero con ella, el técnico ve que el usuario hizo clic 17 veces en un botón inexistente por un CSS roto, pudiendo ir a gritarle a los de front-end, a los que no considera ingenieros de verdad.

Cómo implementa Pandora FMS la grabación de sesiones reales

Dada la enorme utilidad de lo visto, Pandora FMS permite grabar, reproducir y analizar sesiones de usuario (en web y Windows). Aunque no lo hace al «estilo vídeo» como otras herramientas de session replay, ofrece una monitorización estructurada y automatizada de la experiencia del usuario, basada en scripts grabados, tiempos por fase, capturas de pantalla y alertas.
Cuando se trata de web, combina su módulo WUX (Web User Experience), el motor de automatización PWRD (Pandora Web Robot Daemon) y el IDE Selenium, permitiendo:

• Grabar interacciones en el navegador.
• Crear scripts que reproduzcan automáticamente esas sesiones.
• Dividirlas en fases para un mejor análisis.
• Obtener capturas de pantalla en caso de fallo.
• Recoger las métricas clave y configurar alertas.

Cuando se trata de Windows, Pandora usa su módulo PDR (Pandora Desktop Recorder) para:

• Grabar lo que hace el usuario (escritura, cambios de ventanas…).
• Automatizar procesos de escritorio simulando a un usuario real.
• Ejecutar esos scripts grabados para monitorizar continuamente.
• Capturar pantalla en caso de error.
• Segmentar por fases para obtener métricas detalladas.

Qué diferencia a Pandora FMS de otras herramientas de session replay

La forma en que Pandora captura e implementa las prestaciones session replay permite ir más allá de lo habitual en estas herramientas. Así, su grabación estructurada permite:

• Monitorización continua y detección proactiva de fallos. De modo que podamos solventar muchos antes de que causen efectos en producción.
• Visualización de errores y trazabilidad completa de lo ocurrido, con capturas de pantalla y tiempos detallados por paso o fase.

La clave es que, mientras el resto de herramientas session replay observan pasivamente lo ocurrido, Pandora FMS ayuda a actuar y prevenir. Reproduce programáticamente lo que debe ocurrir, detectando desviaciones funcionales antes de que los usuarios reales las sufran y pasando de una grabación inerte, para diagnósticos a posteriori, a una prevención proactiva.
Eso permite reducir fallos y mejorar la experiencia de usuario, convirtiéndolo en alguien feliz y productivo que no quiere estrellar el teclado contra la pantalla. Mientras, nuestros técnicos no estarán repasando sesiones y buscando la aguja del fallo en el pajar de las acciones del usuario, consiguiendo que tampoco quieran estrellar el teclado contra dicho usuario.