Como funciona a taxa de amostragem do session replay no Sentry, PostHog e outros

O que é uma taxa de amostragem do session replay?

Na prática, a taxa de amostragem do session replay é a fração das sessões de usuários que uma ferramenta de replay grava, normalmente escrita como uma fração entre 0 e 1 ou uma porcentagem entre 0 e 100. Com uma taxa de 0.1, mais ou menos uma sessão em cada dez é gravada por inteiro e as outras nove não. A documentação do Sentry resume em uma linha: "Sampling controls how much traffic results in a Session Replay."

A taxa é decidida uma única vez, quando a sessão começa, então um visitante que ficou fora da amostra continua fora durante toda a visita. Isso importa porque um session replay só faz sentido inteiro: uma gravação sem o primeiro snapshot completo do DOM não pode ser reproduzida.

Os fornecedores discordam sobre a unidade, o padrão e o lugar onde você a define. As seções abaixo citam a documentação de cada fornecedor.

Qual a diferença entre amostragem por sessão e amostragem por evento?

A amostragem por sessão decide se uma sessão é gravada ou não. A amostragem por evento grava a sessão mas descarta ou limita alguns eventos dentro dela. A primeira controla quantos replays você armazena. A segunda controla o peso de cada replay.

O gravador open source rrweb mostra bem a amostragem por evento. A opção sampling dele aceita chaves como mousemove, scroll, media e input, e a receita de armazenamento define scroll: 150 com o comentário "do not emit twice in 150ms" e input: 'last' para que só o valor final de uma sequência digitada seja mantido. Toda sessão continua sendo gravada, só que com menos eventos.

Nenhuma das duas é a mesma amostragem que um relatório de analytics aplica quando estima totais a partir de um subconjunto de linhas. Esse tipo está coberto em quando a amostragem de dados começa em um relatório.

Como o Sentry usa replaysSessionSampleRate e replaysOnErrorSampleRate?

O Sentry usa duas taxas, definidas em Sentry.init(). A referência de configuração dele as define assim:

• replaysSessionSampleRate, tipo number, padrão 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, padrão 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."

A página de configuração do Sentry explica a ordem. replaysSessionSampleRate é verificada primeiro. Se a sessão entra na amostra, "Full session recording starts and is sent to Sentry in real-time." Se não entra, a gravação fica "buffered in memory only (last 60 seconds kept)". Quando ocorre um erro em uma sessão fora da amostra, replaysOnErrorSampleRate é verificada, e um acerto envia o "Buffered 60 seconds + rest of session". Uma falha descarta o buffer e nada é enviado.

O Sentry publica dois padrões diferentes para as mesmas opções. A referência de configuração lista 0 para ambas, então uma instalação via SDK que não defina nenhuma das duas não grava nada. O snippet do Loader Script na página de configuração diz que ele "will initialize Replay with the default config: replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1". O padrão que você recebe depende de como você instalou o Sentry, e vale verificar qual deles o seu projeto está rodando.

O Sentry também é o único fornecedor aqui que publica uma tabela de taxas recomendadas, com o título "Recommended Production Sample Rates":

O conselho dele sobre a taxa de erro é direto: "Keep replaysOnErrorSampleRate at 1.0 - error sessions provide the most debugging value." Para testes, ele recomenda replaysSessionSampleRate: 1.0.

Como o PostHog faz amostragem das gravações de sessão?

O PostHog define a taxa de amostragem nas configurações de ingestão de replay, não no código do SDK. Cada "trigger group" tem as próprias condições (triggers de URL, triggers de evento, uma feature flag) mais "its own sample rate, minimum duration, and match type". Uma sessão é gravada se corresponder a qualquer grupo.

A amostragem do PostHog é determinística. A documentação diz: "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%)." O mesmo ID de sessão sempre recebe a mesma resposta, "even across page refreshes". A documentação também diz do que você abre mão: "You can't choose which sessions are sampled."

A taxa se aplica depois das condições de um grupo, não junto com elas. O exemplo do PostHog é "a group with an exception event trigger and a 20% sample rate records 20% of the sessions that threw an exception", e não 20% de todas as sessões mais toda exceção. Se você apagar o seu último trigger group, o PostHog o substitui por um grupo padrão "Record all sessions" com 100% de amostragem. A recomendação publicada dele vai no sentido oposto ao da tabela do Sentry: "Our recommendation is to start with capturing 100% of sessions and decrease it as needed."

Como o LogRocket lida com amostragem?

O LogRocket define taxas de amostragem dentro do Conditional Recording, que a documentação dele descreve como "Available as a separate add on for Pro and Enterprise customers". Você cria uma condição de gravação, como um clique em um botão de checkout ou um erro de rede, e "set the sampling rate" para ela. A documentação dá "record 20% of users who visit our checkout page" como exemplo. Várias condições "will be considered separately, not cumulatively, so a session needs to meet only one condition in order to be recorded."

Como uma condição pode disparar no meio de uma visita, o LogRocket mantém uma janela retroativa: "All recordings record up to 10MB of activity prior to the recording condition being met." Esse é um limite em bytes, não em tempo, então o tamanho da janela retroativa varia de sessão para sessão.

Sem o add-on, os controles da página Recording Settings do LogRocket são limites e filtros, não taxas: pausar a gravação, um limite mensal ou diário de sessões, e bloqueios por localização, endereço IP, versão do app ou user agent. A documentação pública do LogRocket não descreve nenhum parâmetro de SDK para taxa de amostragem e não publica nenhuma taxa recomendada.

O Microsoft Clarity faz amostragem das gravações de sessão?

O FAQ do Clarity diz que não, e depois lista um limite. Em "Why should I use Clarity?" ele promete "No sampling (that is, tracking only a portion of your site's traffic)" e "there are no traffic limits on these sites." Mais abaixo, a mesma página responde "How many sessions can Clarity record?" com "Clarity records up to 100,000 sessions per project per day." Uma terceira resposta acrescenta: "Clarity tracks all sessions, but recordings might not be available for all sessions."

Lido em conjunto, o Clarity rastreia todas as sessões mas limita as gravações, e não documenta como escolhe quais sessões gravar depois do limite. O Clarity não expõe nenhuma configuração de taxa de amostragem.

Como funciona o sessionReplaySampleRate da Datadog?

A Datadog aninha duas porcentagens. sessionSampleRate "controls the percentage of overall sessions being tracked" e tem padrão 100. sessionReplaySampleRate "is applied after the overall sample rate, and controls the percentage of sessions tracked as Browser RUM & Session Replay." Ambas aceitam valores de 0 a 100, não de 0 a 1.

O guia de amostragem da Datadog desenvolve um exemplo: "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." O padrão mudou em uma versão major: a partir do Browser SDK v5.0.0, "the sessionReplaySampleRate initialization parameter default value is 0. Previous versions of the SDK use 100."

Como os fornecedores se comparam em taxas de amostragem do session replay?

Qual taxa de amostragem do session replay você deve escolher?

Comece pelo problema mais raro que você precisa ver, não pelo orçamento. A conta é simples: se um bug atinge uma sessão em 400 e você grava 10% das sessões, você o captura mais ou menos uma vez a cada 4,000 sessões. Reduza a taxa e a espera cresce na mesma proporção. A taxa de erro do Sentry existe porque uma taxa fixa trabalha contra eventos raros, e os trigger groups do PostHog e as condições do LogRocket deixam você manter 100% no checkout ou no cadastro enquanto faz amostragem de todo o resto.

Duas verificações antes de colocar uma taxa em produção. Primeiro, confirme o padrão que a sua instalação realmente usa, já que o Sentry e a Datadog publicam um 0 que significa "não gravar nada". Segundo, conte os dois lados: sessões vezes taxa dá o número de gravações, que é o que um plano por gravação cobra e o que a sua revisão de privacidade precisa cobrir. A amostragem reduz a exposição além do custo, e nossa comparação de ferramentas de session replay analisa isso fornecedor por fornecedor.

As instruções de instalação do script de gravação do Flowsery afirmam: "Recording and AI sampling are both 100% unless explicitly changed." Toda sessão é gravada e revisada pela IA no AI session replay do Flowsery, a menos que você reduza a taxa.

Perguntas frequentes

O que significa replaysSessionSampleRate 0.1 no Sentry?

Significa que o Sentry grava cerca de 10% das sessões por inteiro desde o momento em que começam. A documentação do Sentry descreve 1.0 como coletar todos os replays e 0 como não coletar nenhum.

Qual é a taxa de amostragem do session replay padrão no Sentry?

A referência de configuração do SDK lista 0 tanto para replaysSessionSampleRate quanto para replaysOnErrorSampleRate. O Loader Script do Sentry usa 0.1 e 1 como configuração padrão.

O replaysOnErrorSampleRate grava o que aconteceu antes do erro?

Sim. O Sentry mantém em buffer na memória os últimos 60 segundos das sessões fora da amostra, e um erro amostrado envia esse buffer mais o resto da sessão.

Posso escolher quais sessões o PostHog amostra?

Não. O PostHog converte o ID da sessão, via hash, em um número entre 0 e 1 e grava a sessão se esse número estiver abaixo da sua taxa. A documentação afirma que "You can't choose which sessions are sampled."

O sessionReplaySampleRate da Datadog é uma porcentagem de todas as sessões?

Não. É uma porcentagem das sessões já mantidas pelo sessionSampleRate. Com 60 e 50, o próprio exemplo da Datadog coleta replays de 30% de todas as sessões.

O Microsoft Clarity grava todas as sessões?

O FAQ do Clarity diz que ele não faz amostragem, mas também diz que o Clarity grava até 100,000 sessões por projeto por dia e que as gravações "might not be available for all sessions."

O que acontece com as sessões que o Sentry não amostra?

O Sentry armazena a sessão em buffer na memória em vez de descartá-la por completo. A página de configuração descreve esse buffer como os últimos 60 segundos guardados, então ele avança junto com a visita inteira. Quando ocorre um erro, o replaysOnErrorSampleRate é verificado: um acerto envia o buffer mais o resto da sessão, e uma falha descarta o buffer. Uma sessão sem nenhum erro não envia nada ao Sentry.

Qual taxa de amostragem o PostHog recomenda para começar?

A documentação do PostHog recomenda começar capturando 100% das sessões e reduzir a taxa apenas quando necessário. Isso vai na direção oposta à tabela do Sentry, que recomenda cair para 1% em tráfego alto. Também combina com o grupo que o PostHog cria quando você apaga o seu último trigger group: um grupo "Record all sessions" com 100% de amostragem e sem condições.

A amostragem condicional do LogRocket vem incluída em todos os planos?

O LogRocket vende o Conditional Recording, o recurso que define uma taxa de amostragem por condição, como um complemento separado para clientes Pro e Enterprise. Planos sem esse complemento recebem limites e filtros no lugar: pausar a gravação, um limite mensal ou diário de sessões, e bloqueios por localização, endereço IP, versão do app ou user agent. Nenhuma dessas opções funciona como taxa de amostragem.

Como o rrweb reduz os dados dentro de uma sessão gravada?

O rrweb reduz os dados dentro de cada gravação por meio da opção sampling, em vez de pular sessões inteiras. Sua receita de armazenamento limita eventos de rolagem a um a cada 150 milissegundos e mantém apenas o último valor de uma sequência de entrada digitada. Cada sessão continua sendo gravada, apenas o volume de eventos dentro dela diminui.