Como funciona o session replay e o que ele não vê

O que é session replay?

Em web analytics, session replay é uma técnica que reconstrói a visita de um usuário como uma reprodução assistível gravando mudanças do DOM e eventos de entrada em vez de filmar a tela. O gravador serializa o DOM da página uma vez no carregamento e depois transmite cada mutação, clique, rolagem, tecla pressionada e mudança de viewport como um evento com marca de tempo. Um player aplica depois esse fluxo de eventos a uma cópia reconstruída da página dentro de um iframe isolado, e é por isso que a reprodução parece vídeo mas pesa uma fração de um.

Essa distinção determina todo o resto, do que um replay comprova ao que custa armazená-lo.

Como o session replay grava uma página sem vídeo?

Um gravador de session replay captura estado, não pixels. No carregamento da página ele percorre a árvore do DOM e serializa cada nó em uma estrutura JSON, atribuindo a cada nó um id numérico estável. Essa primeira carga é o snapshot completo do DOM, e tudo depois dela é um diff.

A partir daí o gravador anexa um MutationObserver e um conjunto de listeners de eventos. Cada mudança vira um registro pequeno: o nó 412 ganhou um filho, o nó 205 teve o texto substituído, a janela rolou até y=1,200 no milissegundo 8,431. A biblioteca de código aberto rrweb estabeleceu o formato que a maioria dos fornecedores segue, incluindo o modelo de um id por nó e a divisão entre snapshot e incrementos.

A reprodução inverte o processo. O player monta um documento a partir do snapshot, coloca esse documento em um iframe com scripts desativados e então aplica as mutações na ordem gravada contra um relógio virtual. Nada na página reproduzida é executado, e o cursor que você vê é uma camada desenhada, não um ponteiro capturado.

O que um session replay captura e o que escapa dele?

Um session replay captura tudo o que está expresso no DOM da página gravada, e nada do que vive fora dele. Como o gravador lê o mesmo DOM que o navegador renderiza, o conteúdo injetado por uma extensão de navegador aparece no replay exatamente como o visitante viu, o que explica relatos de bug que ninguém da equipe consegue reproduzir.

As lacunas são específicas:

• Superfícies canvas e WebGL aparecem como caixas em branco a menos que o gravador esteja configurado para capturá-las, porque o conteúdo delas não são nós do DOM.
• Conteúdo de <video> e de <iframe> de outra origem não pode ser lido, então o replay mostra a moldura do elemento sem nada dentro.
• A interface nativa do navegador nunca aparece: menus de preenchimento automático, caixas alert(), a folha de impressão, a barra de downloads, as devtools.
• Qualquer coisa em outra aba, outra janela ou no sistema operacional está fora do escopo.
• O estado do servidor continua invisível. O replay mostra que um formulário retornou um erro, não qual restrição do banco de dados o rejeitou.

Um modo de falha surpreende as equipes meses depois. Imagens, fontes e folhas de estilo são guardadas como URLs, não como bytes, então um deploy que muda uma folha de estilo faz replays antigos renderizarem com os estilos novos. Um replay de seis meses atrás é um registro de estrutura e comportamento, não de aparência exata.

Como o mascaramento protege dados pessoais em um session replay?

O mascaramento substitui valores sensíveis dentro do navegador antes de qualquer evento ser enviado, então o servidor nunca recebe o texto original. Um gravador aplica regras enquanto serializa cada nó: campos de senha são descartados por padrão, elementos com uma classe como .mask têm o texto trocado por asteriscos, e elementos bloqueados viram uma caixa vazia de espaço reservado que preserva o layout.

Duas políticas se comportam de forma diferente sob pressão. Uma lista de bloqueio mascara os campos que você lembrou de marcar, e vaza o campo que um desenvolvedor adiciona na próxima sprint. Uma lista de permissão mascara tudo por padrão e desmascara os elementos que você nomeia, o que produz replays mais feios e nenhuma surpresa. Escolha a lista de permissão para qualquer superfície que toque dados de pagamento, saúde, conta ou suporte.

A Flowsery é livre de cookies, hospedada na UE e GDPR by design, e entrega um único script com menos de 10 KB.

Lista de bloqueio x lista de permissões na mascaração

Lista de bloqueio

• Mascara só os campos marcados hoje
• Deixa passar o campo que um desenvolvedor adiciona no próximo sprint

Lista de permissões

• Mascara tudo por padrão
• Revela só os elementos indicados
• Replays menos bonitos, mas sem surpresas

Quanto armazenamento um session replay precisa?

O armazenamento escala com o volume de eventos, não com a duração da sessão em tempo de relógio. Um visitante que lê um artigo por dez minutos produz quase nenhuma mutação; um visitante que arrasta itens por um app de canvas durante noventa segundos produz dezenas de milhares. A estimativa é:

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

Vamos a um exemplo. Suponha 50,000 sessões gravadas por mês, 4,000 eventos por sessão e 200 bytes comprimidos por evento:

4,000 x 200 = 800,000 bytes, ou seja, cerca de 800 KB por sessão. 800 KB x 50,000 = 40,000,000 KB, ou seja, cerca de 40 GB por mês.

As mesmas 50,000 sessões capturadas como vídeo 720p chegariam a terabytes. Essa proporção é o motivo de as ferramentas de replay cobrarem por contagem de sessões e janelas de retenção em vez de gigabytes, e a Flowsery define os limites de plano como cotas que cobrem sessões de analytics, gravações de sessão, sessões analisadas por IA e retenção de replay em meses.

Vale amostrar sessões ou gravar todas elas?

A amostragem troca cobertura de diagnóstico por custo, e falha exatamente nas sessões de que você precisa. Se um bug de checkout afeta um visitante em 400 e você grava 10 por cento do tráfego, você captura o bug uma vez a cada 4,000 sessões e não consegue confirmar uma correção sem esperar semanas. Eventos raros são a razão de o replay existir, e eventos raros são o que a amostragem apaga.

A Flowsery grava cada sessão de usuário sem amostragem de dados e se conecta a replays já gravados no PostHog ou no Amplitude sem reinstrumentação. Se um orçamento forçar mesmo assim uma decisão de amostragem, mantenha 100 por cento das sessões que passam por checkout, cadastro e qualquer fluxo que tenha emitido um erro de JavaScript.

Qual a diferença entre session replay, gravação de tela e um heatmap?

Session replay, gravação de tela e heatmaps respondem a três perguntas a partir de três fontes de dados. A gravação de tela captura pixels codificados de tudo o que uma API de captura enxerga. Um heatmap agrega coordenadas de muitos visitantes em uma imagem só e não guarda nenhum caminho individual.

Pergunta	Session replay	Gravação de tela	Heatmap
O que é armazenado	Mutações do DOM e eventos de entrada como JSON	Quadros de vídeo codificados	Coordenadas e contagens agregadas
Tamanho por sessão	Kilobytes	Megabytes	Nenhum artefato por sessão
Texto após a captura	Texto real do DOM, selecionável	Só pixels	Não é mantido
Quem inicia	O script da página, automaticamente	Uma pessoa, deliberadamente	O script da página, automaticamente
Escopo	Só a página gravada	A tela ou a janela inteira	Só a página gravada
Mostra o caminho de uma pessoa	Sim	Sim	Não, ele funde todo mundo
Responde	Por que esta visita falhou	O que esta pessoa disse enquanto fazia	Onde todo mundo clica

Use um heatmap para decidir onde olhar, e um replay para descobrir o que aconteceu ali. Um heatmap mostra um CTA frio; só uma gravação de sessão de um visitante que passou rolando por ele revela que o botão ficava atrás de um cabeçalho fixo naquele breakpoint.

Onde as equipes usam session replay na prática?

As equipes usam replay para fechar a distância entre um relato de erro e uma reprodução. Um stack trace aponta a linha que lançou o erro; o replay que a antecede mostra os onze cliques que colocaram o app naquele estado. O mesmo vale para falhas silenciosas, em que nada é lançado e a única evidência é um visitante clicando seis vezes em um botão desativado.

Assistir replays um a um deixa de funcionar depois de algumas centenas de sessões por dia, então detecção importa mais do que reprodução. O session replay com IA da Flowsery detecta rage clicks, dead clicks, erros de JavaScript, abandonos e fluxos quebrados automaticamente, agrupa sessões equivalentes em um único problema e ordena os problemas por quantos usuários foram atingidos. Cada problema chega no Slack, Linear ou Jira com o replay e os passos de reprodução anexados, e marcar @flowsery no Slack abre um pull request em rascunho no seu repositório do GitHub. Esses sinais de frustração transformam gravações em uma fila priorizada.

Perguntas frequentes

Session replay é a mesma coisa que gravação de tela?

Não. A gravação de tela armazena quadros de vídeo codificados de uma tela ou janela, enquanto o session replay armazena mutações do DOM e eventos de entrada e reconstrói a página a partir deles. As consequências são o tamanho, kilobytes contra megabytes, e o escopo, já que o replay enxerga apenas a página gravada.

O session replay grava senhas?

Os gravadores descartam por padrão os valores dos campos de senha, então o campo aparece mascarado e o valor real nunca sai do navegador. Outros campos sensíveis ficam desprotegidos a menos que você os marque, e é por isso que uma lista de permissão que mascara tudo e desmascara elementos nomeados ganha de marcar campo por campo.

Por que replays antigos parecem quebrados?

Os replays referenciam folhas de estilo, fontes e imagens por URL em vez de guardar os bytes delas. Um deploy de CSS ou um arquivo de CDN apagado faz replays antigos renderizarem com os estilos novos ou com imagens faltando. A estrutura do DOM e a linha do tempo de interação continuam corretas.

O session replay consegue ver dentro de um iframe?

Um gravador consegue capturar iframes de mesma origem instrumentando-os junto com o documento principal. Iframes de origem cruzada são bloqueados pelo modelo de segurança do navegador, então um formulário de pagamento incorporado ou um widget de terceiros de outro domínio aparece como uma moldura vazia na reprodução.

Por quanto tempo os replays devem ser guardados?

A retenção deve coincidir com a menor janela em que você age sobre os dados, já que cada mês extra soma custo e exposição de privacidade. A Flowsery expressa a retenção de replay em meses como parte da cota do plano.

O session replay deixa a página mais lenta?

O custo do gravador vem de serializar o DOM inicial e de observar as mutações depois, então aplicações de página única pesadas com árvores grandes pagam mais do que páginas estáticas. O peso do script é a parte que você controla na instalação: a Flowsery entrega um único script com menos de 10 KB.

O Flowsery usa cookies para gravar sessões?

O Flowsery grava sessões sem cookies, roda em infraestrutura hospedada na UE e é construído GDPR by design. O script que captura o snapshot do DOM e o fluxo de mutações pesa menos de 10 KB, então o próprio pipeline de gravação não depende de cookies.

Uma extensão do navegador pode aparecer em um session replay?

Sim, porque o recorder lê o mesmo DOM que o navegador renderiza, e o conteúdo injetado por uma extensão passa a fazer parte desse DOM. Isso explica relatos de bug que ninguém no time consegue reproduzir, porque a extensão só existe no navegador daquele visitante.

O session replay se conecta com ferramentas como PostHog ou Amplitude?

O Flowsery se conecta a replays já gravados no PostHog ou na Amplitude, então um time não precisa reinstrumentar um site que já envia eventos para uma dessas plataformas. Ele grava todas as sessões sem amostragem, o que preserva as falhas raras de checkout ou cadastro que uma captura parcial deixaria passar.

O session replay consegue sinalizar problemas automaticamente sem que alguém veja cada gravação?

O AI session replay do Flowsery detecta rage clicks, dead clicks, erros de JavaScript, abandonos e fluxos quebrados, agrupa sessões parecidas em um único issue e ordena os issues pelo número de usuários afetados. Cada issue chega ao Slack, Linear ou Jira com o replay e os passos de reprodução, e marcar @flowsery no Slack abre um draft pull request no repositório GitHub conectado.