LGPD e consentimento no rastreamento: como mensurar conversão sem violar a lei

Existe uma crença perigosa circulando entre times de marketing e dados: a de que mover o rastreamento para o servidor "resolve a parte da privacidade". Não resolve. Server-side muda onde o dado é processado, não se você tem base legal para processá-lo. Confundir uma coisa com a outra é o tipo de erro que passa despercebido por meses e vira problema no dia em que um titular reclama ou a autoridade pergunta.

Este texto é um guia de engenharia e operação — não é aconselhamento jurídico. Para casos concretos, envolva o DPO e o jurídico da sua empresa. O objetivo aqui é dar ao time técnico e de tráfego o vocabulário e os princípios para construir uma mensuração de conversão que respeite a Lei Geral de Proteção de Dados (Lei nº 13.709/2018) desde o desenho, em vez de tentar remendar depois.

O básico da LGPD que todo time de dados precisa dominar

A LGPD regula o tratamento de dados pessoais de pessoas no Brasil. "Tratamento" é praticamente qualquer operação: coletar, armazenar, usar, compartilhar, enviar para uma plataforma de anúncios. Se você faz qualquer uma dessas coisas com dado pessoal, está sob a lei.

Dado pessoal é qualquer informação relacionada a uma pessoa natural identificada ou identificável. Isso é mais amplo do que muita gente imagina. Nome e e-mail são óbvios. Mas endereço IP, identificadores de cookie, IDs de dispositivo e IDs de publicidade também podem ser dado pessoal, porque permitem, direta ou indiretamente, identificar alguém. Um "ID anônimo" que consegue reconhecer o mesmo usuário entre sessões geralmente não é anônimo de fato — é pseudonimizado, e pseudonimizado continua sendo dado pessoal sob a lei.

A fiscalização no Brasil cabe à ANPD (Autoridade Nacional de Proteção de Dados), que edita regulamentos, orienta e aplica sanções. Não é uma lei sem dente.

Bases legais: consentimento não é a única, mas para tracking de marketing costuma ser

Todo tratamento precisa de uma base legal — uma justificativa prevista na lei. A LGPD lista dez bases. As que mais interessam ao contexto de mensuração são duas:

• Consentimento: manifestação livre, informada e inequívoca do titular. Precisa ser específico para a finalidade, dado por ação afirmativa (nada de caixa pré-marcada), e revogável com a mesma facilidade com que foi concedido.
• Legítimo interesse: permite tratar dados quando há um interesse legítimo do controlador que não se sobreponha aos direitos do titular. Exige um teste de balanceamento documentado e não vale para dados sensíveis.

Aqui está o ponto que gera mais discussão: para rastreamento de marketing e publicidade direcionada — cookies não essenciais, envio de dados para plataformas de anúncio, construção de públicos —, a base tende fortemente para o consentimento, e não legítimo interesse. Rastreamento essencial para o funcionamento do serviço (um cookie de sessão de carrinho, por exemplo) é outra história. A régua prática: cookie/tracking que serve à sua estratégia de mídia quase sempre precisa de consentimento; cookie que faz o site funcionar, geralmente não. Na dúvida sobre um caso específico, é decisão do jurídico, não do time de mídia.

Consentimento para rastreamento na prática

Consentimento válido não é um banner com um botão "OK" que aparece uma vez e some. Na prática, um mecanismo de consentimento que se sustenta tem algumas características:

• Granular: o usuário pode aceitar analytics e recusar marketing separadamente, em vez de um "aceitar tudo ou sair".
• Informado: deixa claro quais finalidades, quais categorias de dado e quais terceiros recebem o dado.
• Ativo: nada é tratado antes do "sim". Sem caixas pré-marcadas, sem tratamento "por padrão".
• Revogável e registrado: o usuário pode mudar de ideia, e você guarda prova de qual consentimento foi dado, quando e para quê. Consentimento que você não consegue comprovar, para efeitos práticos, é como se não existisse.

O ponto operacional crítico: o estado do consentimento precisa chegar até a camada que dispara os eventos de conversão. De nada adianta um banner bonito na frente se, atrás, o evento é enviado para o Meta ou o Google independentemente da escolha do usuário. O consentimento precisa ser um sinal que atravessa toda a arquitetura de mensuração e efetivamente bloqueia ou libera o disparo.

O conceito de Consent Mode

A ideia por trás do que o Google chama de Consent Mode — e que vale como padrão de arquitetura mesmo fora do ecossistema Google — é fazer as tags de mensuração respeitarem o estado do consentimento em vez de ignorá-lo. Quando o usuário não consente com marketing, as ferramentas ajustam seu comportamento: não gravam identificadores, não enviam dados pessoais, e no máximo transmitem sinais agregados e sem identificação.

O valor conceitual aqui é tratar o consentimento como variável de primeira classe da mensuração, e não como um obstáculo a contornar. Um sistema bem desenhado sabe, no momento de cada evento, se pode ou não anexar dado pessoal àquele disparo — e age conforme.

Hashing e pseudonimização de PII para CAPI

As APIs de conversão modernas — como a Conversions API do Meta — melhoram a correspondência de eventos recebendo dados do cliente, como e-mail e telefone. Enviar esses dados em texto puro para uma plataforma seria um compartilhamento de dado pessoal identificável de altíssimo risco. A prática padrão, e a que você deve exigir da sua implementação, é o hashing.

Antes de sair do seu servidor, o e-mail e o telefone passam por SHA-256, uma função de hash unidirecional. joao@exemplo.com vira uma string de 64 caracteres hexadecimais da qual não se recupera o e-mail original. A plataforma compara hashes com hashes; nunca recebe o dado em claro. Alguns pontos técnicos que não são detalhe:

• Normalize antes de aplicar o hash. E-mail em minúsculas e sem espaços; telefone no formato internacional só com dígitos. Sem normalização consistente, o mesmo usuário gera hashes diferentes e a correspondência falha — você perde a mensuração e processa dado à toa.
• Hashing reduz o risco, mas não isenta da lei. Um hash de e-mail ainda é usado para identificar e reconhecer uma pessoa numa plataforma de anúncio. Para efeitos de LGPD, tratar isso como "dado anônimo" é ingênuo. É pseudonimização — uma medida de segurança valiosa e frequentemente exigida —, não anonimização que faz a lei deixar de valer.
• Nunca dependa de hashing feito no cliente por terceiros que você não controla. O ponto de hashing tem que ser um lugar de confiança na sua arquitetura, tipicamente o seu servidor.

Minimização de dados: colete o mínimo necessário

Um dos princípios centrais da LGPD é a minimização: trate apenas os dados estritamente necessários para a finalidade declarada. Aplicado à mensuração, isso é tanto lei quanto boa engenharia.

Você precisa mesmo enviar CEP completo, ou a região já resolve? Precisa do nome completo para atribuir uma conversão, ou o hash do e-mail basta para a correspondência? Cada campo de dado pessoal a mais no seu fluxo de eventos é mais risco, mais superfície de exposição e mais coisa para justificar. A pergunta correta antes de adicionar um campo ao payload de conversão não é "isso pode ajudar a mensuração?" — quase tudo ajuda um pouco — e sim "a finalidade declarada exige este campo?". Se não exige, ele não deveria estar ali.

Server-side NÃO isenta do consentimento

Este é o mito que abre o artigo, e ele merece ser dito de novo com todas as letras: mover o rastreamento para o servidor não cria uma base legal que você não tinha.

O rastreamento server-side traz vantagens reais de confiabilidade, resiliência a bloqueadores e qualidade de sinal. Mas ele processa os mesmos dados pessoais, para as mesmas finalidades, apenas num lugar diferente da arquitetura. Se enviar um evento de compra para o Meta a partir do navegador exige consentimento, enviar o mesmo evento a partir do seu servidor exige o mesmo consentimento. A lei se importa com a finalidade e a natureza do dado, não com o hostname que fez a requisição HTTP.

O risco, aliás, é que o server-side seja usado justamente para esconder o tratamento do usuário — coletar e compartilhar sem que o banner de consentimento tenha qualquer efeito, porque o disparo acontece longe do navegador onde as ferramentas de auditoria olham. Isso não é uma zona cinzenta esperta; é tratamento sem base legal com uma camada a mais de opacidade. A arquitetura correta faz o oposto: o sinal de consentimento chega até o servidor e o servidor respeita esse sinal, disparando o evento com dado pessoal apenas quando há consentimento, e degradando para sinal agregado ou nenhum disparo quando não há.

Como conciliar mensuração e privacidade

A boa notícia é que privacidade e mensuração de qualidade não são inimigas — na maior parte do tempo, apontam na mesma direção. Um sistema que respeita consentimento, minimiza dados e trabalha com sinal confiável é, ao mesmo tempo, mais conforme e menos ruidoso. Alguns pilares práticos:

• Consentimento como sinal que atravessa a stack. Do banner ao servidor ao disparo do evento. O estado de consentimento é lido em cada disparo e efetivamente libera ou bloqueia.
• Server-side com sinal confiável, disparando só na conversão real. Emitir o evento a partir de uma fonte de verdade — o pedido pago, o negócio fechado — em vez de sinais frágeis do navegador. Isso melhora a mensuração e reduz o volume de dado tratado especulativamente, porque você para de disparar eventos que não correspondem a nada.
• Hashing e minimização por padrão. PII sempre pseudonimizada antes de sair; só os campos que a finalidade exige.
• Reconciliar com privacidade em mente faz parte de um movimento maior de medir bem num mundo com menos cookies de terceiros. Se você ainda está entendendo o impacto dessa mudança, vale ler como o fim dos cookies de terceiros muda a mensuração de conversão antes de redesenhar sua stack.

Retenção, contratos e o papel de operador

Dois pontos operacionais que fecham o desenho e que times técnicos costumam esquecer:

Retenção. Dado pessoal não pode ser guardado para sempre "por via das dúvidas". A LGPD exige que você trate os dados apenas pelo tempo necessário à finalidade e depois elimine ou anonimize. Defina políticas de retenção explícitas para os dados de mensuração, com prazos, e implemente a expiração de verdade — não deixe payloads de eventos com PII acumulando indefinidamente num data lake sem dono. Retenção indefinida é passivo, não ativo.

Controlador, operador e contratos. Quando você envia dados para uma plataforma de anúncio, um provedor de tag server-side ou uma ferramenta de mensuração, está compartilhando dado pessoal com um terceiro. Você é, tipicamente, o controlador (decide as finalidades) e esse terceiro atua muitas vezes como operador (trata em seu nome). Essa relação precisa estar coberta por contrato — um acordo de tratamento de dados que defina finalidades, obrigações de segurança, sub-operadores e o que acontece no encerramento. Compartilhar dado pessoal com um fornecedor sem esse instrumento é uma lacuna de conformidade, por melhor que seja a ferramenta.

Fechando: privacidade por desenho é engenharia, não burocracia

A forma errada de encarar a LGPD é como um checklist jurídico que se resolve depois, com um banner colado por cima de uma arquitetura que trata dados como sempre tratou. A forma certa é privacidade por desenho: consentimento como variável de primeira classe, dados minimizados, PII pseudonimizada, retenção com prazo, contratos com operadores, e a consciência de que o servidor não é um esconderijo da lei.

O ganho não é só evitar multa. Um sistema desenhado assim tende a ser mais confiável, mais auditável e mais alinhado com um futuro em que menos dado individual estará disponível de qualquer forma. Medir bem e respeitar o titular são, cada vez mais, o mesmo trabalho — e o time que internaliza isso agora chega mais preparado do que o que trata a conformidade como um problema para o ano que vem. Reforçando o aviso do começo: isto é orientação de engenharia e operação; a decisão jurídica final é sempre do seu DPO e do seu jurídico.