Replay de sessão sem vigilância

replay de sessãoDenis Povarov20 de agosto de 2026

O replay de sessão tem um problema de reputação, e em grande parte merecido.

A categoria foi definida por ferramentas de analytics que gravam todas as sessões de todos os usuários, sem parar e para sempre, para que um time de growth possa assistir ao checkout de alguém no trimestre seguinte. Isso é vigilância com um recurso de depuração acoplado, e os usuários têm razão em se incomodar.

Eu uso replay mesmo assim, porque para uma classe de bugs nada mais funciona. Mas uso de outro jeito.

Onde o replay é a única ferramenta

A maioria dos bugs se resolve com o console e o log de rede. Um erro, um 500, pronto.

E há o outro tipo. Console limpo. Rede limpa. Todas as requisições retornaram 200. E o usuário tem certeza absoluta de que algo quebrou.

Ele quase sempre tem razão. O que quebrou foi a interação — um clique que caiu no elemento errado, um formulário que se reiniciou em silêncio, um modal que abriu atrás de um overlay, uma transição de estado que deixou a interface num formato que você nunca previu. Nada disso gera erro, porque, do ponto de vista do código, nada deu errado.

Nesses casos, o replay é a investigação inteira. Você assiste aos doze segundos antes do relatório e vê o que o usuário fez de fato, o que muitas vezes não é o que ele descreveu.

Limitado a um relatório, não a um usuário

A diferença central: o replay do BugDump fica anexado a um relatório de bug, não a um perfil de usuário.

A gravação existe para explicar um relatório específico que foi enviado. Ela não monta um histórico do comportamento de ninguém ao longo do tempo. Não há explorador de sessões, nem «assistir a um usuário aleatório», nem análise de funil. Se ninguém reportou um bug, ninguém está assistindo a nada.

É um recurso menor que o replay das ferramentas de analytics. E é essa a ideia. A versão mais restrita resolve o problema de depuração sem a parte que deixa as pessoas desconfortáveis.

A ferramenta de ocultação fica com o usuário

O anotador de capturas de tela tem uma ferramenta de desfoque, e ela funciona como deveria: a ocultação acontece no navegador, antes do upload. Uma área desfocada não é desfocada nos servidores do BugDump — ela nunca chega até eles.

Isso inverte a lógica habitual. Normalmente, privacidade é uma promessa do fornecedor: ele diz que vai tratar os seus dados com responsabilidade, e você decide se acredita. A ocultação no navegador não é uma promessa. Os pixels não saem da máquina.

Na prática, isso significa que um usuário olhando para uma página cheia de nomes de clientes consegue mandar a captura de tela de que você precisa. Sem isso, os mais cuidadosos não mandam nada.

Desligado por padrão, onde importa

captureNetworkBodies é false, a menos que você o ative.

Os corpos são úteis — às vezes o payload da resposta é o bug inteiro. Também é neles que ficam tokens, dados pessoais e dados de pagamento. O padrão seguro é aquele em que ativar é uma decisão que alguém tomou de propósito.

O próprio replay se desativa com uma linha, globalmente ou nas rotas que não devem ser gravadas:

Bugdump.init({
  apiKey: 'your-api-key',
  features: {
    sessionReplay: false,
  },
});

Todo recurso de captura funciona assim — capturas de tela, gravação de tela, replay e anexos se ligam e desligam de forma independente. Você pode rodar o BugDump só com uma descrição e um log de console, se é isso que as suas exigências de compliance pedem.

O pedido de permissão que decidi manter

Por padrão, capturas e gravações de tela usam getDisplayMedia, que mostra o diálogo de permissão do próprio navegador. Eu poderia evitá-lo por completo usando a renderização do DOM como padrão.

Mantive, por dois motivos.

A fidelidade é real — canvas, vídeo, iframes de outras origens e controles nativos são capturados exatamente como foram renderizados, e não aproximados. E o pedido é honesto. Quem avisa o usuário de que a tela dele vai ser capturada é o navegador, não eu. Ele pode recusar e, nesse caso, o BugDump recorre à captura via DOM em vez de perder o relatório.

Um diálogo de permissão é atrito. Também é consentimento, entregue por uma parte que nenhum de nós dois controla.

Onde cheguei

O replay é uma ferramenta poderosa da qual a indústria de analytics ensinou as pessoas a desconfiar. A desconfiança é razoável, e a ferramenta continua valendo a pena.

Minha resposta: limitar o replay a relatórios, e não a sessões; colocar a ferramenta de ocultação nas mãos do usuário e executá-la antes do upload; deixar a captura mais arriscada desligada por padrão; e fazer com que cada recurso possa ser desativado com uma linha.

Você recebe os doze segundos que explicam o bug. Você não recebe um sistema de vigilância, e eu também não.