Cómo funciona la tasa de muestreo de session replay en Sentry, PostHog y otros

¿Qué es la tasa de muestreo de session replay?

La proporción de sesiones de usuario que graba una herramienta de repetición es su tasa de muestreo de session replay, que suele escribirse como una fracción entre 0 y 1 o como un porcentaje entre 0 y 100. Con una tasa de 0.1, más o menos una sesión de cada diez se graba entera y las otras nueve no. La documentación de Sentry lo resume en una línea: "Sampling controls how much traffic results in a Session Replay."

La tasa se decide una sola vez, cuando empieza la sesión, así que un visitante que queda fuera de la muestra sigue fuera durante toda la visita. Eso importa porque una session replay solo tiene sentido completa: una grabación a la que le falta su primer snapshot completo del DOM no se puede reproducir.

Los proveedores no coinciden en la unidad, en el valor por defecto ni en dónde se configura. Las secciones de abajo citan la documentación de cada proveedor.

¿En qué se diferencia el muestreo por sesión del muestreo por evento?

El muestreo por sesión decide si una sesión se graba o no. El muestreo por evento graba la sesión pero descarta o limita algunos eventos dentro de ella. El primero controla cuántas repeticiones guardas. El segundo controla cuánto pesa cada repetición.

El grabador open source rrweb muestra con claridad el muestreo por evento. Su opción sampling acepta claves como mousemove, scroll, media e input, y su receta de almacenamiento fija scroll: 150 con el comentario "do not emit twice in 150ms" e input: 'last' para que solo se guarde el valor final de una secuencia tecleada. Todas las sesiones se siguen grabando, solo que con menos eventos.

Ninguno de los dos es el muestreo que aplica un informe de analítica cuando estima totales a partir de un subconjunto de filas. Ese tipo se trata en cuándo empieza el muestreo de datos en un informe.

¿Cómo usa Sentry replaysSessionSampleRate y replaysOnErrorSampleRate?

Sentry usa dos tasas, que se fijan en Sentry.init(). Su referencia de configuración las define así:

• replaysSessionSampleRate, tipo number, por defecto 0: "The sample rate for replays that begin recording immediately and last the entirety of the user's session. 1.0 collects all replays, and 0 collects none."
• replaysOnErrorSampleRate, tipo number, por defecto 0: "The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends."

La página de configuración de Sentry explica el orden. Primero se comprueba replaysSessionSampleRate. Si la sesión entra en la muestra, "Full session recording starts and is sent to Sentry in real-time." Si no entra, la grabación queda "buffered in memory only (last 60 seconds kept)". Cuando ocurre un error en una sesión fuera de la muestra, se comprueba replaysOnErrorSampleRate, y si acierta se envía el "Buffered 60 seconds + rest of session". Si falla, se descarta el buffer y no se envía nada.

Sentry publica dos valores por defecto distintos para las mismas opciones. La referencia de configuración indica 0 para las dos, así que una instalación del SDK que no fije ninguna no graba nada. El fragmento del Loader Script en la página de configuración dice que "will initialize Replay with the default config: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". Qué valor por defecto recibes depende de cómo instalaste Sentry, y merece la pena comprobar cuál está usando tu proyecto.

Sentry es además el único proveedor de esta lista que publica una tabla de tasas recomendadas, titulada "Recommended Production Sample Rates":

Su consejo sobre la tasa de error es tajante: "Keep replaysOnErrorSampleRate at 1.0 - error sessions provide the most debugging value." Para las pruebas recomienda replaysSessionSampleRate: 1.0.

¿Cómo muestrea PostHog las grabaciones de sesiones?

PostHog fija su tasa de muestreo en los ajustes de ingesta de replay, no en el código del SDK. Cada "trigger group" tiene sus propias condiciones (disparadores por URL, disparadores por evento, un feature flag) más "its own sample rate, minimum duration, and match type". Una sesión se graba si coincide con cualquier grupo.

El muestreo de PostHog es determinista. Su documentación dice: "When a new session starts, PostHog converts the session ID into a number between 0 and 1 using a hash function. This number is then compared to your configured sample rate (for example, 0.1 for 10% or 0.2 for 20%)." El mismo ID de sesión recibe siempre la misma respuesta, "even across page refreshes". La documentación también dice a qué renuncias: "You can't choose which sessions are sampled."

La tasa se aplica después de las condiciones de un grupo, no junto a ellas. El ejemplo de PostHog es "a group with an exception event trigger and a 20% sample rate records 20% of the sessions that threw an exception", no el 20% de todas las sesiones más cada excepción. Si borras tu último grupo de disparadores, PostHog lo sustituye por un grupo por defecto "Record all sessions" con un muestreo del 100%. Su recomendación publicada va en sentido contrario a la tabla de Sentry: "Our recommendation is to start with capturing 100% of sessions and decrease it as needed."

¿Cómo gestiona LogRocket el muestreo?

LogRocket fija las tasas de muestreo dentro de Conditional Recording, que su documentación etiqueta como "Available as a separate add on for Pro and Enterprise customers". Creas una condición de grabación, como un clic en un botón de checkout o un error de red, y "set the sampling rate" para ella. La documentación pone como ejemplo "record 20% of users who visit our checkout page". Varias condiciones "will be considered separately, not cumulatively, so a session needs to meet only one condition in order to be recorded."

Como una condición puede dispararse a mitad de una visita, LogRocket guarda un historial previo: "All recordings record up to 10MB of activity prior to the recording condition being met." Es un límite en bytes, no en tiempo, así que la duración de ese historial varía de una sesión a otra.

Sin el complemento, los controles de la página Recording Settings de LogRocket son límites y filtros, no tasas: pausar la grabación, un límite mensual o diario de sesiones y bloqueos por ubicación, dirección IP, versión de la app o user agent. La documentación pública de LogRocket no describe ningún parámetro del SDK para una tasa de muestreo ni publica ninguna tasa recomendada.

¿Microsoft Clarity muestrea las grabaciones de sesiones?

Las FAQ de Clarity dicen que no, y luego enumeran un tope. Bajo "Why should I use Clarity?" promete "No sampling (that is, tracking only a portion of your site's traffic)" y "there are no traffic limits on these sites." Más abajo, la misma página responde a "How many sessions can Clarity record?" con "Clarity records up to 100,000 sessions per project per day." Una tercera respuesta añade: "Clarity tracks all sessions, but recordings might not be available for all sessions."

Leído todo junto, Clarity sigue todas las sesiones pero limita las grabaciones, y no documenta cómo elige qué sesiones graba una vez superado el tope. Clarity no ofrece ningún ajuste de tasa de muestreo.

¿Cómo funciona el sessionReplaySampleRate de Datadog?

Datadog anida dos porcentajes. sessionSampleRate "controls the percentage of overall sessions being tracked" y vale 100 por defecto. sessionReplaySampleRate "is applied after the overall sample rate, and controls the percentage of sessions tracked as Browser RUM & Session Replay." Los dos aceptan valores de 0 a 100, no de 0 a 1.

La guía de muestreo de Datadog resuelve un ejemplo: "If you set sessionSampleRate to 60 and sessionReplaySampleRate to 50, 40% of sessions are dropped, 30% of sessions are collected as Browser RUM, and 30% of sessions are collected as Browser RUM & Session Replay." El valor por defecto cambió en una versión mayor: desde el Browser SDK v5.0.0, "the sessionReplaySampleRate initialization parameter default value is 0. Previous versions of the SDK use 100."

¿Cómo se comparan los proveedores en la tasa de muestreo de session replay?

¿Qué tasa de muestreo de session replay deberías elegir?

Parte del problema más raro que necesitas ver, no del presupuesto. La aritmética es sencilla: si un bug afecta a una sesión de cada 400 y grabas el 10% de las sesiones, lo capturas más o menos una vez cada 4,000 sesiones. Baja la tasa y la espera crece en proporción. La tasa de error de Sentry existe porque una tasa plana juega en contra de los eventos raros, y los grupos de disparadores de PostHog y las condiciones de LogRocket te permiten mantener el 100% en el checkout o el registro mientras muestreas todo lo demás.

Dos comprobaciones antes de poner una tasa en producción. Primero, confirma el valor por defecto que usa de verdad tu instalación, ya que Sentry y Datadog publican un 0 que significa "no grabar nada". Segundo, cuenta los dos lados: sesiones por tasa da las grabaciones, que es lo que factura un plan por grabación y lo que tiene que cubrir tu revisión de privacidad. El muestreo reduce la exposición además del coste, algo que nuestra comparativa de herramientas de session replay analiza proveedor por proveedor.

Las instrucciones de instalación del script de grabación de Flowsery dicen: "Recording and AI sampling are both 100% unless explicitly changed." Cada sesión se graba y la revisa la IA en la AI session replay de Flowsery salvo que la bajes.

Preguntas frecuentes

¿Qué significa replaysSessionSampleRate 0.1 en Sentry?

Significa que Sentry graba alrededor del 10% de las sesiones enteras desde el momento en que empiezan. La documentación de Sentry describe 1.0 como recoger todas las repeticiones y 0 como no recoger ninguna.

¿Cuál es la tasa de muestreo de session replay por defecto en Sentry?

La referencia de configuración del SDK indica 0 tanto para replaysSessionSampleRate como para replaysOnErrorSampleRate. El Loader Script de Sentry usa en cambio 0.1 y 1 como configuración por defecto.

¿replaysOnErrorSampleRate graba lo que pasó antes del error?

Sí. Sentry guarda en memoria los últimos 60 segundos de las sesiones fuera de la muestra, y un error que entra en la muestra envía ese buffer más el resto de la sesión.

¿Puedo elegir qué sesiones muestrea PostHog?

No. PostHog convierte el ID de sesión con un hash en un número entre 0 y 1 y graba la sesión si ese número está por debajo de tu tasa. Su documentación afirma que "You can't choose which sessions are sampled."

¿El sessionReplaySampleRate de Datadog es un porcentaje de todas las sesiones?

No. Es un porcentaje de las sesiones que ya ha conservado sessionSampleRate. Con 60 y 50, el propio ejemplo de Datadog recoge repeticiones del 30% de todas las sesiones.

¿Microsoft Clarity graba todas las sesiones?

Las FAQ de Clarity dicen que no muestrea, pero también dicen que Clarity graba hasta 100,000 sesiones por proyecto al día y que las grabaciones "might not be available for all sessions."

¿Qué pasa con las sesiones que Sentry no muestrea?

Sentry almacena la sesión en memoria en lugar de descartarla por completo. La página de configuración describe este búfer como los últimos 60 segundos guardados, así que avanza de forma continua durante toda la visita. Cuando ocurre un error, se comprueba replaysOnErrorSampleRate: un acierto envía el búfer más el resto de la sesión, y un fallo descarta el búfer. Una sesión sin errores no envía nada a Sentry.

¿Qué tasa de muestreo recomienda PostHog para empezar?

La documentación de PostHog recomienda empezar capturando el 100% de las sesiones y reducir la tasa solo si hace falta. Eso va en dirección contraria a la tabla de Sentry, que recomienda bajar al 1% con tráfico alto. También coincide con el grupo de reserva que PostHog crea cuando borras tu último grupo de disparadores: un grupo "Record all sessions" con un muestreo del 100% y sin condiciones.

¿El muestreo condicional de LogRocket viene incluido en todos los planes?

LogRocket vende Conditional Recording, la función que fija una tasa de muestreo por condición, como complemento aparte para clientes Pro y Enterprise. Los planes sin ese complemento reciben límites y filtros en su lugar: pausar la grabación, un límite de sesiones mensual o diario, y bloqueos por ubicación, dirección IP, versión de la app o user agent. Ninguna de esas opciones funciona como una tasa de muestreo.

¿Cómo reduce rrweb los datos dentro de una sesión grabada?

rrweb recorta los datos dentro de cada grabación mediante su opción sampling, en lugar de saltarse sesiones completas. Su receta de almacenamiento limita los eventos de scroll a uno cada 150 milisegundos y conserva solo el último valor de una secuencia de entrada escrita. Cada sesión se sigue grabando, solo se reduce el volumen de eventos dentro de ella.