Quando um usuário clica no botão de relatório, acontece muita coisa que ele nunca vê. Aqui está tudo, e o motivo de cada parte estar ali.
Logs do console, incluindo o passado
O óbvio, com um detalhe que não é óbvio: o widget captura os logs de antes de ser aberto.
Isso importa mais do que parece. A sequência num relatório de bug real quase nunca é «o erro acontece, o usuário reporta na hora». É: o erro acontece, a página entra num estado sutilmente quebrado, o usuário tenta mais três coisas, fica confuso e reporta quatro minutos depois.
Um coletor que começa no momento do relatório captura esses quatro minutos de confusão e perde o erro que os causou. O SDK instala o coletor do console na inicialização, então o erro original ainda está lá quando o relatório finalmente é enviado.
Requisições de rede
Método, URL, status, tempo. É aqui que a maioria dos bugs realmente mora — não no código do seu frontend, mas na resposta que o seu frontend recebeu.
Os corpos de requisição e de resposta ficam disponíveis com a opção captureNetworkBodies, e vêm desligados por padrão. Esse padrão é proposital. Os corpos são o lugar mais provável para aparecerem tokens de autenticação, dados pessoais e dados de pagamento. Ligar isso deve ser uma decisão sua, não um padrão que você herda.
Mesmo sem os corpos, códigos de status e tempos resolvem a maioria dos bugs. Um 500 logo antes de o usuário desistir é o seu bug. Um 200 que levou nove segundos também é o seu bug, e esse o seu rastreador de erros nunca reportou.
Capturas de tela e a ferramenta de desfoque
As capturas de tela funcionam de dois modos, e vale entender o que se ganha e o que se perde em cada um.
screen-capture usa getDisplayMedia. O resultado é fiel pixel a pixel — canvas, vídeo, iframes de outras origens, selects nativos, tudo capturado exatamente como foi renderizado. O custo é um diálogo de permissão do navegador.
dom renderiza a partir do DOM com html2canvas. Sem pedido de permissão, portanto sem atrito, mas o conteúdo de canvas e os iframes de outras origens podem não sobreviver.
O padrão é screen-capture, e o widget passa automaticamente para dom quando o usuário nega a permissão. Um pedido negado deve piorar a captura de tela, não fazer o relatório se perder.
Depois vem a anotação: seta, retângulo, desenho livre, texto e desfoque. A ferramenta de desfoque é a que merece destaque, porque é um controle de privacidade disfarçado de ferramenta de desenho. A ocultação acontece no navegador — uma área desfocada nunca é enviada. Usuários que, de outra forma, não mandariam uma captura de tela de uma página com dados de clientes agora conseguem mandar.
Replay de sessão
Uma gravação do DOM ao longo do tempo, feita com rrweb. Não é um vídeo — é um replay do documento real, que você pode inspecionar.
O replay se paga na classe de bugs em que o console está limpo, a rede está limpa e o usuário tem certeza absoluta de que algo quebrou. Normalmente ele tem razão, e normalmente o que ele fez não é o que ele descreveu. O replay mostra a diferença.
Ações
Cliques, entradas de texto e navegação, em ordem.
É o sinal mais modesto e um dos mais úteis, porque são os seus passos para reproduzir — gravados, e não lembrados. «Passos para reproduzir» é o campo que os usuários preenchem pior, e é o campo de que você mais precisa. Por isso parei de perguntar e passei a gravar.
Notas de voz
Alguns usuários não escrevem três frases, mas falam de bom grado por vinte segundos. A frustração também carrega uma informação que o texto achata — dá para ouvir qual parte do fluxo realmente acabou com a paciência deles.
Tempos de performance
Carregamento da página e tempos dos recursos, para os relatórios que na verdade são sobre lentidão. «O app está lento» é um relatório de bug real e, sem os tempos, é um relatório impossível de confirmar ou refutar.
Metadados
Navegador, sistema operacional, tamanho da viewport, URL da página, timestamp.
A viewport é o azarão da lista. Uma parcela surpreendente dos relatórios de «o botão não funciona» são bugs de layout numa largura que ninguém testou. Os usuários quase nunca pensam em mencionar o tamanho da janela. É um número, é capturado automaticamente e fecha uma categoria de bugs que, de outra forma, é bem difícil de reproduzir.
O que deixei de fora de propósito
Não exijo a identidade de quem reporta. Nome e e-mail ficam numa seção recolhida. Um relatório sem nome continua sendo um relatório; um formulário que exige identificação recebe menos deles.
Não exijo título, categoria, severidade nem prioridade. São campos de triagem fantasiados de campos de relato. Os usuários chutam, chutam errado, e você refaz a triagem de qualquer jeito. O único campo obrigatório é a descrição.
Nada vaza para a sua página. O widget é renderizado num Shadow DOM. O seu CSS não o alcança, e o CSS dele não alcança você.
O princípio por trás
Todo sinal aqui segue uma regra: se o navegador já sabe, o usuário não deveria ter que dizer.
O trabalho do usuário é uma frase sobre o que ele esperava. Todo o resto é trabalho do BugDump, e o navegador já fez a maior parte dele.
Leia também
Modelo de relatório de bug que funciona (e como automatizar a maior parte) — um modelo para copiar e o argumento para tirar dele todo campo que o navegador consegue preencher.
Como capturar logs do console e requisições de rede do navegador do usuário — a instrumentação por trás desses sinais e as armadilhas que quebram a página monitorada.
Replay de sessão sem vigilância — como o replay fica limitado a um relatório, com desfoque feito no navegador e desligável com uma linha.