Guia de Integração de Consentimento de Cookie de Gravação de Sessão do Microsoft Clarity para 2026
O Microsoft Clarity foi lançado em 2020 como uma alternativa gratuita e sem cotas ao Hotjar e ao Smartlook para gravação de sessões, mapas de calor e análise de interações. Cinco anos depois, ele ocupa uma parcela significativa de sites de médio porte e pequenas empresas em todo o mundo, em parte porque é genuinamente útil e em parte porque a instalação é uma linha de JavaScript que a maioria dos operadores cola sem pensar mais. Do ponto de vista de privacidade, essa facilidade de instalação é exatamente o problema. O Clarity registra movimentos do mouse, comportamento de rolagem, cliques, teclas pressionadas, interações com formulários e capturas de tela completas do DOM da página — a carga comportamental mais densa de qualquer ferramenta de análise comumente implantada — e encaminha tudo para os servidores da Microsoft no momento em que o script é carregado. Para qualquer implantação que toque o tráfego da EU, UK, EEA, Brasil ou Califórnia, a instalação padrão não está em conformidade, e os reguladores mais ativos na aplicação de gravação de sessões — o CNIL, o Garante italiano, o ICO do Reino Unido — foram explícitos de que a análise se aplica independentemente do nível de preço ou fornecedor da ferramenta. Este guia percorre o que o Clarity registra, como funciona o limite de consentimento e o padrão de integração que sobrevive a uma auditoria.
O que o Clarity realmente registra
O Clarity SDK (carregado de www.clarity.ms/tag/{project_id}) inicializa um objeto global clarity e identifica visitantes com um cookie da Microsoft chamado _clck, além de um cookie de sessão _clsk. A partir desse momento, o script captura um fluxo comportamental denso:
- Entrada de mouse e toque — cada movimento, clique, toque, rolagem e gesto é registrado com carimbo de data/hora e coordenadas.
- Interações com formulários — eventos de foco, desfoque e entrada em cada campo de formulário, além do texto de campos não sensíveis se o mascaramento não estiver configurado.
- Capturas de tela do DOM — capturas de tela completas periódicas do DOM da página para que a reprodução da sessão possa reconstruir o estado visual exato em qualquer momento.
- Eventos personalizados — quaisquer eventos que o aplicativo emite explicitamente por meio de chamadas clarity("event", "name").
- Dados de desempenho e erros — erros de JavaScript, falhas de rede e tempos de core web vitals.
- Dados de identificador — o cookie do Clarity mais geolocalização derivada de IP e impressão digital do agente do usuário.
A combinação — particularmente as capturas de tela do DOM e a captura de campos de formulário — torna o Clarity funcionalmente equivalente a uma gravação de vídeo da sessão do visitante. A classificação regulatória sob o GDPR é direta: isso é processamento de dados pessoais, os cookies não são essenciais, os dados cruzam fronteiras para a infraestrutura americana da Microsoft, e a base legal necessária é o consentimento. A orientação do CNIL de 2024 sobre gravação de sessões é inequívoca neste ponto e nomeia explicitamente ferramentas na categoria do Clarity.
O risco de dados sensíveis
As ferramentas de gravação de sessão têm um perigo de privacidade específico que outras ferramentas de análise não têm: elas podem capturar acidentalmente dados pessoais sensíveis. Um usuário digitando um número de cartão de crédito, uma condição de saúde, uma afiliação religiosa ou um identificador nacional em qualquer campo de formulário é gravado pelo Clarity se o campo não estiver explicitamente mascarado. Sob o GDPR, isso é processamento de dados pessoais sensíveis do Article 9, que requer consentimento explícito de opt-in e raramente é coberto por uma decisão geral de consentimento de marketing.
O Clarity suporta uma configuração de mascaramento de conteúdo que oculta campos específicos da gravação, mas o comportamento padrão captura tudo. A abordagem defensável em auditoria é mascarar de forma agressiva — assumir que cada campo de formulário é sensível até que seja provado o contrário — e documentar explicitamente as decisões de mascaramento.
Controles de privacidade nativos do Clarity
A Microsoft investiu nos controles de privacidade do Clarity nos últimos dois anos. A plataforma agora expõe vários primitivos que uma integração de CMP pode aproveitar.
O atributo de máscara
Adicionar data-clarity-mask="true" a um elemento DOM oculta seu conteúdo da gravação de sessão. Adicionar data-clarity-unmask="true" a um elemento filho substitui a máscara para essa subárvore. O padrão correto para qualquer campo de formulário que possa conter dados pessoais é mascarar e, em seguida, desmascarar explicitamente onde for seguro.
A API de consentimento
O Clarity expõe uma chamada clarity("consent") que, quando invocada, sinaliza que o consentimento foi concedido e o SDK deve prosseguir. Sem essa chamada, o SDK pode ser configurado para parar após o carregamento inicial. Este é o primitivo correto para integração de CMP no lado da ativação.
Mascaramento de IP e tratamento de identificadores
As configurações do projeto Clarity expõem opções para truncamento de IP e mascaramento de identificadores. Habilitar essas opções é uma medida de defesa em profundidade além do controle de CMP; não substitui o consentimento.
Mascaramento automático de conteúdo sensível
As versões recentes do Clarity tentam detectar automaticamente campos sensíveis (padrões de cartão de crédito, campos de senha, campos chamados "ssn" ou similares) e mascará-los por padrão. A detecção é heurística e incompleta; não confie nela como única linha de defesa.
Integração CMP passo a passo
A arquitetura confiável é adiar completamente o Clarity SDK até que o consentimento seja concedido, depois ativá-lo explicitamente por meio da API de consentimento.
1. Remova a tag padrão do cabeçalho do documento
O trecho de instalação do Clarity é um único script inline que inicializa o SDK no carregamento da página. Substitua-o por um elemento de script de espaço reservado cujo type seja text/plain e cujo data-category seja analytics ou marketing dependendo de como seu CMP categoriza ferramentas de gravação de sessões.
2. Decida sobre o mapeamento de categorias
A gravação de sessões é uma categoria contestada. O CNIL a tratou variadamente como análise (quando os dados são usados para pesquisa interna de UX) e como marketing (quando os dados alimentam decisões de personalização ou compartilhamento externo). O mapeamento conservador é marketing; a posição defensável em auditoria exige que você seja específico sobre como as gravações são realmente usadas.
3. Configure o mascaramento agressivo antes da ativação
Adicione data-clarity-mask="true" a cada elemento de formulário, cada campo de entrada, cada contêiner que possa conter dados pessoais. A política padrão é mascarar por padrão com exceções explícitas de desmascaramento para elementos conhecidos como seguros (títulos de páginas, rótulos de navegação, blocos de conteúdo público).
4. Ative o Clarity a partir do callback de consentimento
Quando o CMP disparar o evento de categoria aceita relevante, reescreva a tag do script de espaço reservado e chame clarity("consent") para conceder ao SDK permissão para prosseguir. Os eventos na fila que foram armazenados em buffer durante o período de pré-consentimento serão então liberados.
5. Trate a revogação explicitamente
Se o usuário revogar o consentimento, o Clarity SDK não tem uma chamada limpa de "parar gravação" equivalente à API de ativação. O padrão prático é chamar clarity("consent", false) se suportado na sua versão do SDK, e adicionalmente limpar os cookies do Clarity no lado do cliente. Para exclusão completa de gravações históricas, use o fluxo de trabalho de exclusão de dados na interface de administração do Clarity ou a API de exclusão.
Armadilhas comuns
Quatro erros de integração respondem pela maioria das descobertas de auditoria em implantações do Clarity.
Instalando o Clarity "só para ver o que os visitantes fazem"
O padrão mais comum: um gerente de produto instala o Clarity para pesquisar um problema de UX, nunca habilita o controle de consentimento, nunca configura o mascaramento e esquece o script. A superfície de gravação continua acumulando. A correção é remover completamente o Clarity ou colocá-lo sob a mesma arquitetura de consentimento que qualquer outro rastreador.
Confiar no mascaramento automático
A detecção heurística de campos sensíveis do Clarity captura casos óbvios, mas perde os específicos do domínio — uma área de texto "sintomas" em um site de saúde, um campo "número de conta" em um site financeiro com um nome idiossincrático. Mascare explicitamente; não confie na detecção.
Tratar a gravação de sessões como análise
O CNIL foi explícito de que a categoria de gravação de sessões está mais próxima do marketing do que da análise first-party do ponto de vista do consentimento. Restringir o Clarity apenas ao consentimento de análise é defensável somente se as gravações forem usadas exclusivamente para pesquisa interna de UX e nunca compartilhadas fora da organização.
Esquecer payloads de eventos personalizados
O código do aplicativo que chama clarity("event", "name", customProperties) pode vazar dados pessoais para o fluxo do Clarity por meio do payload de customProperties. Audite cada local de chamada e evite passar identificadores de usuário, endereços de e-mail ou quaisquer dados pessoais nas propriedades de eventos.
Lista de verificação de auditoria
Seis perguntas concretas para responder em qualquer implantação do Clarity que toque o tráfego da EU, UK, Brasil ou Califórnia.
- O Clarity aguarda o consentimento? Abra a página em uma janela privada e confirme que nenhuma solicitação clarity.ms é disparada antes que o banner seja aceito.
- O mascaramento é agressivo? Confirme que cada campo de formulário e cada contêiner com conteúdo potencialmente pessoal tem data-clarity-mask aplicado.
- O mapeamento de categorias está documentado? Confirme que há um registro escrito sobre se o Clarity está restrito a análise ou marketing, com o raciocínio.
- A API de consentimento está conectada? Confirme que o callback do CMP chama clarity("consent") na concessão e o equivalente na revogação.
- Os eventos personalizados são auditados? Confirme que as chamadas clarity("event", ...) não passam dados identificadores ou sensíveis em seus payloads de propriedade.
- A exclusão é automatizada? Confirme que as solicitações DSAR acionam o fluxo de trabalho de exclusão do Clarity, não um ticket de suporte manual.
Onde o Clarity se encaixa em uma pilha de consentimento prioritário
A gravação de sessões é a superfície de rastreamento comportamental com maior densidade de informações em implantação comum, e o Clarity é a ferramenta que mais agressivamente a democratizou. O nível de preço gratuito e a instalação sem atrito tornam-na o caminho de menor resistência para qualquer equipe que queira visibilidade no comportamento de UX. Essa mesma instalação sem atrito é o que torna o Clarity a ferramenta de análise mais comumente mal configurada nas auditorias de 2026. A arquitetura correta trata o Clarity como qualquer outro rastreador identificador: coloque-o atrás de consentimento explícito, mascare campos de formulário de forma agressiva por padrão, documente o mapeamento de categorias e conecte a API de consentimento para que os primitivos próprios do SDK apliquem o que o CMP registrou. Feito corretamente, o valor de pesquisa de UX para o qual a ferramenta foi adquirida é preservado enquanto a exposição regulatória cai para uma fração do que uma instalação padrão carrega.