Gravação de sessão mostra tudo o que aparece na tela. Inclusive o CPF, o cartão e o saldo do cliente. Veja como mascarar dados sensíveis em cada ferramenta e como revisar antes de publicar.
Índice do artigo
- Por que mascaramento vem antes da instalação
- Mapeando o que é sensível
- Como cada ferramenta mascara
- Estratégia: mascarar tudo e liberar, ou liberar tudo e mascarar?
- Eventos, atributos e URLs também vazam
- Checklist de revisão
- Os erros que mais aparecem
- Perguntas frequentes
Por que mascaramento vem antes da instalação
Uma ferramenta de session replay reconstrói a tela do usuário. Se o dado aparece na tela, ele pode aparecer na gravação. Por isso o mascaramento não é ajuste fino: é pré-requisito. Instalar primeiro e mascarar depois significa que as sessões gravadas nesse intervalo já contêm dados que não deveriam estar lá.
Em uma frase: em session replay, o que não foi mascarado foi gravado.
Mapeando o que é sensível
Antes de configurar qualquer ferramenta, faça o inventário por tipo de página:
- Cadastro e perfil: nome, CPF, e-mail, telefone, data de nascimento, endereço.
- Checkout e pagamento: dados de cartão, chave Pix, endereço de entrega.
- Área logada: saldo, extrato, pedidos, dados de saúde, documentos.
- Formulários de contato e atendimento: campos de texto livre (onde o usuário escreve qualquer coisa).
- Mensagens na tela: “Olá, Maria” no cabeçalho também é dado pessoal.
Campos de texto livre merecem atenção especial: o usuário pode digitar dado sensível onde você não espera.
Como cada ferramenta mascara
Microsoft Clarity
- Atributo HTML data-clarity-mask=”true” oculta um elemento; data-clarity-unmask=”true” revela.
- Aplique no contêiner de blocos inteiros (formulário de checkout, área de conta) em vez de campo a campo.
UXCam
- O mascaramento se chama occlusion e é configurado na inicialização do SDK, por tela ou por elemento.
- No SDK Web, campos como senha e e-mail são mascarados automaticamente, e há mascaramento configurável de inputs e URLs.
- A documentação alerta para não armazenar dado pessoal sem um acordo de processamento de dados em vigor.
Fullstory
- As regras de privacidade definem o que é excluído, mascarado ou capturado só com consentimento.
- Elementos marcados como “capturar com consentimento” só são gravados após FS(‘setIdentity’, { consent: true }).
Hotjar
- Tem supressão de dados em gravações configurável; além disso, a documentação proíbe dado pessoal em nomes de evento e restringe e-mail ao atributo reservado da Identify API.
Consulte sempre a documentação oficial de cada ferramenta para a sintaxe atual, que muda com as versões.
Estratégia: mascarar tudo e liberar, ou liberar tudo e mascarar?
Para páginas de alto risco (checkout, conta, formulários com texto livre), a estratégia mais segura é mascarar o bloco inteiro e liberar elementos específicos que você precisa analisar (botões, mensagens de erro, textos fixos). No Clarity, isso é feito combinando data-clarity-mask no contêiner com data-clarity-unmask nos elementos liberados.
Para páginas de baixo risco (home, categoria, conteúdo), o padrão da ferramenta com mascaramento pontual costuma bastar.
O ponto de equilíbrio: mascarar demais torna a gravação inútil para CRO; mascarar de menos cria risco jurídico. A decisão sobre o que é aceitável é do DPO.
Eventos, atributos e URLs também vazam
Mascarar a tela não resolve se o dado sai por outro caminho:
- URLs: parâmetros como ?email= ou tokens de redefinição de senha aparecem nas gravações e nos relatórios. A Croct, por exemplo, oferece uma função para sanitizar URLs antes do envio; o GTM permite limpar parâmetros antes de disparar tags.
- Nomes de evento: nunca com dado pessoal.
- Atributos de usuário: use um User ID interno e estável, não e-mail.
- Textos de erro: mensagens como “CPF 123.456.789-00 já cadastrado” precisam ser mascaradas.
Checklist de revisão
- Inventário de páginas e campos sensíveis aprovado pelo DPO.
- Mascaramento aplicado em ambiente de homologação.
- Gravações de teste revisadas página a página, incluindo estados de erro.
- Teste em mobile e desktop (layouts diferentes expõem elementos diferentes).
- URLs e parâmetros verificados nas gravações.
- Eventos e atributos revisados no dicionário de eventos.
- Processo de revisão agendado para cada release que altere páginas sensíveis.
Os erros que mais aparecem
- Instalar a ferramenta antes de configurar o mascaramento.
- Mascarar campo a campo e esquecer um novo campo adicionado depois.
- Não revisar estados de erro e mensagens dinâmicas.
- Deixar dado pessoal em parâmetros de URL.
- Não repetir a revisão após redesign.
Perguntas frequentes
Session replay grava senhas?
Ferramentas como UXCam mascaram campos de senha automaticamente, mas cada implementação deve ser validada.
Como esconder dados sensíveis no Clarity?
Com o atributo data-clarity-mask=”true” nos elementos ou blocos que devem ser ocultados.
O que é occlusion na UXCam?
É o recurso de mascaramento de telas e elementos, configurado na inicialização do SDK.
Mascaramento resolve a LGPD?
É uma das medidas técnicas, mas a conformidade envolve base legal, consentimento, retenção e direitos do titular, definidos com o jurídico.
Devo mascarar a página inteira de checkout?
Em geral, sim: mascare o bloco e libere apenas o que precisa ser analisado, como botões e mensagens de erro.
URLs aparecem nas gravações?
Sim. Remova parâmetros com dados pessoais ou tokens antes do envio.
