Cómo funciona el session replay y qué no puede ver

¿Qué es el session replay?

En analítica web, el session replay es una técnica que reconstruye la visita de un usuario como una reproducción visualizable registrando cambios del DOM y eventos de entrada en lugar de filmar la pantalla. El grabador serializa el DOM de la página una vez al cargar y después transmite cada mutación, clic, scroll, pulsación de tecla y cambio de viewport como un evento con marca de tiempo. Un reproductor aplica más tarde ese flujo de eventos a una copia reconstruida de la página dentro de un iframe aislado, y por eso la reproducción parece vídeo pero pesa una fracción de uno.

Esa distinción determina todo lo demás, desde lo que demuestra un replay hasta lo que cuesta almacenarlo.

¿Cómo graba el session replay una página sin vídeo?

Un grabador de session replay captura estado, no píxeles. Al cargar la página recorre el árbol del DOM y serializa cada nodo en una estructura JSON, asignando a cada nodo un id numérico estable. Esa primera carga es la instantánea completa del DOM, y todo lo que viene después es un diff.

A partir de ahí el grabador conecta un MutationObserver y un conjunto de escuchadores de eventos. Cada cambio se convierte en un registro pequeño: el nodo 412 ganó un hijo, al nodo 205 le reemplazaron el texto, la ventana hizo scroll hasta y=1,200 en el milisegundo 8,431. La biblioteca de código abierto rrweb estableció el formato que sigue la mayoría de proveedores, incluidos el modelo de un id por nodo y la separación entre instantánea e incrementos.

La reproducción invierte el proceso. El reproductor construye un documento a partir de la instantánea, lo monta en un iframe con los scripts desactivados y luego aplica las mutaciones en el orden grabado contra un reloj virtual. Nada de la página reproducida se ejecuta, y el cursor que se ve es una capa dibujada, no un puntero capturado.

¿Qué puede capturar un session replay y qué se le escapa?

Un session replay captura todo lo que está expresado en el DOM de la página grabada, y nada de lo que vive fuera de él. Como el grabador lee el mismo DOM que renderiza el navegador, el contenido inyectado por una extensión del navegador aparece en el replay exactamente como lo vio el visitante, lo que explica los informes de error que nadie del equipo puede reproducir.

Las lagunas son concretas:

• Las superficies de canvas y WebGL se renderizan como cajas en blanco salvo que el grabador esté configurado para capturarlas, porque su contenido no son nodos del DOM.
• El contenido de <video> y de <iframe> de otro origen no se puede leer, así que el replay muestra el marco del elemento sin nada dentro.
• La interfaz nativa del navegador nunca aparece: menús de autocompletado, diálogos alert(), la hoja de impresión, la barra de descargas, las devtools.
• Todo lo que ocurre en otra pestaña, otra ventana o el sistema operativo queda fuera de alcance.
• El estado del servidor sigue invisible. El replay muestra que un formulario devolvió un error, no qué restricción de la base de datos lo rechazó.

Hay un fallo que sorprende a los equipos meses después. Las imágenes, las fuentes y las hojas de estilo se guardan como URLs, no como bytes, así que un despliegue que cambia una hoja de estilo hace que los replays antiguos se rendericen con los estilos nuevos. Un replay de hace seis meses es un registro de estructura y comportamiento, no de apariencia exacta.

¿Cómo protege el enmascaramiento los datos personales en un session replay?

El enmascaramiento sustituye los valores sensibles dentro del navegador antes de enviar ningún evento, así que el servidor nunca recibe el texto original. Un grabador aplica reglas mientras serializa cada nodo: los campos de contraseña se descartan por defecto, los elementos con una clase como .mask cambian su texto por asteriscos, y los elementos bloqueados se convierten en una caja vacía de marcador de posición que conserva el diseño.

Dos políticas se comportan de forma distinta bajo presión. Una lista de bloqueo enmascara los campos que alguien se acordó de marcar, y filtra el campo que un desarrollador añade en el siguiente sprint. Una lista de permitidos enmascara todo por defecto y desenmascara los elementos que se nombran, lo que produce replays más feos y ninguna sorpresa. Elija la lista de permitidos para cualquier superficie que toque datos de pago, salud, cuenta o soporte.

Flowsery no usa cookies, está alojado en la UE, es GDPR by design y entrega un único script de menos de 10 KB.

Lista de bloqueo frente a lista de permitidos en el enmascaramiento

Lista de bloqueo

• Enmascara solo los campos marcados hoy
• Deja pasar el campo que un desarrollador añade el próximo sprint

Lista de permitidos

• Enmascara todo por defecto
• Solo revela los elementos indicados por su nombre
• Replays menos vistosos, sin sorpresas

¿Cuánto almacenamiento necesita un session replay?

El almacenamiento escala con el volumen de eventos, no con la duración de la sesión en tiempo real. Un visitante que lee un artículo durante diez minutos produce casi ninguna mutación; un visitante que arrastra elementos por una app de canvas durante noventa segundos produce decenas de miles. La estimación es:

monthly bytes = sessions recorded x events per session x compressed bytes per event

Un ejemplo concreto. Suponga 50,000 sesiones grabadas al mes, 4,000 eventos por sesión y 200 bytes comprimidos por evento:

4,000 x 200 = 800,000 bytes, es decir, unos 800 KB por sesión. 800 KB x 50,000 = 40,000,000 KB, es decir, unos 40 GB al mes.

Esas mismas 50,000 sesiones capturadas como vídeo 720p llegarían a los terabytes. Esa proporción es la razón por la que las herramientas de replay cobran por número de sesiones y ventanas de retención en lugar de por gigabytes, y Flowsery fija los límites de plan como cuotas que cubren sesiones de analítica, grabaciones de sesión, sesiones analizadas por IA y retención de replay en meses.

¿Conviene muestrear sesiones o grabarlas todas?

El muestreo cambia cobertura diagnóstica por coste, y falla justo en las sesiones que hacen falta. Si un fallo de checkout afecta a un visitante de cada 400 y se graba el 10 por ciento del tráfico, el fallo se captura una vez cada 4,000 sesiones y no se puede confirmar una corrección sin esperar semanas. Los eventos raros son la razón de que exista el replay, y los eventos raros son lo que el muestreo borra.

Flowsery graba cada sesión de usuario sin muestreo de datos y se conecta a replays ya grabados en PostHog o Amplitude sin reinstrumentar nada. Si un presupuesto obliga de todos modos a decidir un muestreo, conserve el 100 por ciento de las sesiones que tocan checkout, registro y cualquier flujo que haya emitido un error de JavaScript.

¿En qué se diferencia el session replay de una grabación de pantalla y de un heatmap?

El session replay, la grabación de pantalla y los heatmaps responden a tres preguntas desde tres fuentes de datos. La grabación de pantalla captura píxeles codificados de lo que vea una API de captura. Un heatmap agrega coordenadas de muchos visitantes en una sola imagen y no conserva ningún recorrido individual.

Pregunta	Session replay	Grabación de pantalla	Heatmap
Qué se almacena	Mutaciones del DOM y eventos de entrada como JSON	Fotogramas de vídeo codificados	Coordenadas y recuentos agregados
Tamaño por sesión	Kilobytes	Megabytes	Sin artefacto por sesión
Texto tras la captura	Texto real del DOM, seleccionable	Solo píxeles	No se conserva
Quién lo inicia	El script de la página, automáticamente	Una persona, deliberadamente	El script de la página, automáticamente
Alcance	Solo la página grabada	Toda la pantalla o la ventana	Solo la página grabada
Muestra el recorrido de una persona	Sí	Sí	No, fusiona a todos
Responde	Por qué falló esta visita	Qué dijo esta persona mientras lo hacía	Dónde hace clic todo el mundo

Use un heatmap para decidir dónde mirar, y un replay para averiguar qué pasó ahí. Un heatmap muestra un CTA frío; solo una grabación de sesión de un visitante que pasó de largo revela que el botón quedaba detrás de una cabecera fija en ese breakpoint.

¿Dónde usan los equipos el session replay en la práctica?

Los equipos usan el replay para cerrar la distancia entre un informe de error y una reproducción. Una traza de pila nombra la línea que lanzó el error; el replay que la precede muestra los once clics que dejaron la aplicación en ese estado. Lo mismo vale para los fallos silenciosos, donde nada lanza un error y la única evidencia es un visitante que hace clic seis veces en un botón desactivado.

Ver replays uno a uno deja de funcionar pasadas unas pocas centenas de sesiones al día, así que la detección importa más que la reproducción. El session replay con IA de Flowsery detecta rage clicks, dead clicks, errores de JavaScript, abandonos y flujos rotos de forma automática, agrupa las sesiones coincidentes en un solo problema y ordena los problemas según cuántos usuarios los sufren. Cada problema llega a Slack, Linear o Jira con el replay y los pasos de reproducción adjuntos, y etiquetar a @flowsery en Slack abre un pull request en borrador en su repositorio de GitHub. Esas señales de frustración convierten las grabaciones en una cola priorizada.

Preguntas frecuentes

¿El session replay es lo mismo que una grabación de pantalla?

No. La grabación de pantalla almacena fotogramas de vídeo codificados de una pantalla o ventana, mientras que el session replay almacena mutaciones del DOM y eventos de entrada y reconstruye la página a partir de ellos. Las consecuencias son el tamaño, kilobytes frente a megabytes, y el alcance, ya que el replay solo ve la página grabada.

¿El session replay graba las contraseñas?

Los grabadores descartan por defecto los valores de los campos de contraseña, así que el campo aparece enmascarado y el valor real nunca sale del navegador. Otros campos sensibles quedan desprotegidos salvo que se marquen, y por eso una lista de permitidos que enmascara todo y desenmascara los elementos nombrados supera al marcado campo por campo.

¿Por qué los replays antiguos se ven rotos?

Los replays referencian hojas de estilo, fuentes e imágenes por URL en lugar de guardar sus bytes. Un despliegue de CSS o un recurso de CDN eliminado hacen que los replays antiguos se rendericen con los estilos nuevos o con imágenes que faltan. La estructura del DOM y la línea de tiempo de interacción siguen siendo exactas.

¿Puede el session replay ver dentro de un iframe?

Un grabador puede capturar iframes del mismo origen instrumentándolos junto con el documento principal. El modelo de seguridad del navegador bloquea los iframes de origen cruzado, así que un formulario de pago incrustado o un widget de terceros de otro dominio aparece como un marco vacío en la reproducción.

¿Cuánto tiempo hay que conservar los replays?

La retención debe coincidir con la ventana más corta en la que se actúa sobre los datos, ya que cada mes extra suma coste y exposición de privacidad. Flowsery expresa la retención de replay en meses como parte de la cuota del plan.

¿El session replay ralentiza una página?

El coste del grabador viene de serializar el DOM inicial y de observar las mutaciones después, así que las aplicaciones de página única pesadas con árboles grandes pagan más que las páginas estáticas. El peso del script es la parte que se controla al instalar: Flowsery entrega un único script de menos de 10 KB.

¿Flowsery usa cookies para grabar sesiones?

Flowsery graba sesiones sin cookies, funciona sobre infraestructura alojada en la UE y está construido GDPR by design. El script que captura la instantánea del DOM y el flujo de mutaciones pesa menos de 10 KB, así que el propio proceso de grabación no depende de cookies.

¿Puede aparecer una extensión del navegador en un session replay?

Sí, porque el recorder lee el mismo DOM que renderiza el navegador, y el contenido que inyecta una extensión pasa a formar parte de ese DOM. Eso explica los reportes de errores que nadie en el equipo logra reproducir, porque la extensión solo existe en el navegador de esa persona.

¿El session replay se conecta con herramientas como PostHog o Amplitude?

Flowsery se conecta con los replays ya grabados en PostHog o Amplitude, así que un equipo no necesita volver a instrumentar un sitio que ya envía eventos a alguna de esas plataformas. Graba cada sesión sin muestreo, lo que conserva los fallos raros de checkout o registro que una captura parcial pasaría por alto.

¿Puede el session replay señalar problemas automáticamente sin ver cada grabación?

El AI session replay de Flowsery detecta rage clicks, dead clicks, errores de JavaScript, abandonos y flujos rotos, agrupa las sesiones parecidas en un solo issue y las ordena según cuántos usuarios las sufren. Cada issue llega a Slack, Linear o Jira con el replay y los pasos para reproducirlo, y mencionar a @flowsery en Slack abre un draft pull request en el repositorio de GitHub conectado.