«O que você fez logo antes de quebrar?» é a pergunta que todo desenvolvedor faz e que quase nenhum usuário consegue responder com precisão. As pessoas não lembram qual botão clicaram em segundo lugar, se a página já tinha terminado de carregar ou que apertaram o botão de voltar no meio de um formulário. O replay de sessão responde à pergunta sem precisar fazê-la: uma gravação, que você percorre como quiser, do que de fato aconteceu no navegador do usuário, anexada ao relatório de bug.
Como o replay de sessão funciona de verdade
O replay de sessão moderno não é vídeo. Gravar pixels geraria arquivos enormes, seria lento e cego à estrutura da página. Em vez disso, ferramentas como o rrweb, o motor open source sobre o qual o replay do BugDump é construído, tiram um snapshot do DOM e depois registram as mutações: nós adicionados e removidos, mudanças de atributos, valores de campos, rolagens, movimento do mouse, cliques.
A reprodução reconstrói a página a partir desses dados, como rever uma partida de xadrez pela notação em vez de filmar o tabuleiro. O resultado é compacto e, como é estrutural e não visual, você pode avançar e voltar nele e ver exatamente com qual elemento o usuário interagiu, e não só onde estava o cursor na tela.
A consequência prática: o replay é barato o bastante para rodar o tempo todo em segundo plano, então os momentos antes de o usuário decidir relatar um bug já estão capturados quando ele clica no botão de relatório. É isso que fluxos no estilo vídeo, de «grave sua tela agora», nunca conseguem dar: o bug já aconteceu quando alguém começa a gravar.
O que o replay conta e os logs não
Os logs de console e de rede contam o que o código fez. O replay conta o que o usuário fez. Os bugs vivem no espaço entre os dois, e algumas categorias são quase impossíveis de diagnosticar sem o lado do usuário:
Bugs de sequência: o modal só quebra quando é aberto, fechado e aberto de novo. Nenhuma linha de log diz isso; o replay mostra em dez segundos.
Condições de corrida: o usuário clicou antes de uma requisição terminar. O replay marca o horário do clique; o log de rede marca o horário da resposta; juntos, eles são o diagnóstico.
Entrada «errada» que não é: o usuário colou um valor com um espaço no final, ou o preenchimento automático completou um campo que você não esperava. O replay mostra o estado real do formulário.
Confusão de estado da interface: o usuário estava numa visualização filtrada, numa aba desatualizada ou no meio de uma edição não salva. O estado do DOM em cada momento está ali.
O inverso também vale: replay sem logs mostra que a página quebrou, mas não por quê. A exceção não tratada está no console; o 500 está na aba de rede. Por isso o replay é mais útil como um painel de um relatório completo do que como ferramenta isolada.
Replay num fluxo de relatórios de bug
O uso tradicional do replay de sessão é em analytics: gravar todo mundo e depois pegar amostras de sessões para estudar a UX. Esse modelo rende muito, mas é pesado: você guarda milhares de sessões para, de vez em quando, olhar uma.
O relato de bugs inverte isso. O BugDump coleta o replay em segundo plano e o anexa quando um usuário envia um relatório, junto com o buffer do console (até 300 registros, 2.000 durante uma gravação), o buffer de rede (150 requisições, 1.000 durante uma gravação, falhas marcadas), os detalhes do ambiente e as métricas de desempenho. Você recebe replays exatamente das sessões em que algo deu errado e uma pessoa disse isso, as sessões com mais sinal que existem.
O relatório chega como um dossiê completo: leia a descrição de uma frase do usuário, percorra o replay para ver a ação, confira no console a exceção que ela disparou e encontre a requisição que falhou no log de rede. Para muitos bugs, essa sequência substitui toda a conversa de «passos para reproduzir».
Privacidade
Uma gravação do DOM pode conter tudo o que a página mostra, inclusive o que o usuário digita. Leve isso a sério:
Decida o que é gravado. O replay deveria ser uma opção ligada de propósito em cada projeto, e não um padrão invisível que você esqueceu. O BugDump o expõe como uma feature flag (
features.sessionReplay) que você controla.Filtre o tráfego sensível. Se você captura dados de rede, use filtros para manter endpoints de terceiros ou sensíveis totalmente fora dos buffers: descartados antes de serem guardados, não mascarados depois.
Deixe quem relata esconder o que aparece na tela. Com a ferramenta de desfoque na anotação da captura de tela, o usuário esconde o próprio número de conta antes de enviar. O mascaramento feito por quem sabe o que é sensível é melhor que o feito por regex.
Avise. Sua política de privacidade deveria dizer que os relatórios de bug podem incluir uma gravação da sessão de quem relatou. Quem envia um relatório de bug costuma ficar contente que os dados vão junto, mas precisa saber.
Quando o replay é exagero
Nem todo projeto precisa de replay no primeiro dia. Um site de conteúdo sem estado interativo tira a maior parte do valor de capturas de tela e logs do console. O replay merece o lugar quando o seu app tem fluxos (formulários de várias etapas, editores, checkouts, dashboards), em que o caminho importa tanto quanto o destino. Se as suas últimas cinco conversas sobre bugs incluíram a frase «tá, mas o que você clicou antes disso?», o replay se paga na hora.
Também vale saber que tipo de «gravação» você está recebendo. O widget do BugDump oferece tanto a gravação de tela explícita (o usuário narra o problema enquanto grava a tela) quanto o replay de sessão em segundo plano (automático, anexado aos relatórios). A primeira é uma ferramenta de comunicação; o segundo, uma ferramenta de perícia. Um complementa o outro, em vez de substituí-lo.
O que o replay de sessão resolve
O replay de sessão fecha a lacuna mais antiga dos relatórios de bug: a diferença entre o que o usuário diz que aconteceu e o que aconteceu. Junto com os logs do console, os dados de rede e os detalhes do ambiente, e coletado automaticamente no momento em que um usuário real esbarra num problema real, ele faz de «não foi possível reproduzir» uma raridade, e não um desfecho.
Leia também
Replay de sessão sem vigilância — como uso o replay só dentro de um relatório, com mascaramento pelo próprio usuário e desligável com uma linha.
Como capturar logs do console e requisições de rede do navegador do usuário — como instrumentar console, erros, fetch e XHR sem quebrar a página que você está monitorando.
Na minha máquina funciona: guia prático de bugs que não se reproduzem — as cerca de oito diferenças entre duas máquinas e a marca que cada uma deixa no bug.