Hashing de PII na prática: normalizar e-mail, telefone e nome antes de enviar

Quando um evento de conversão sai do seu servidor rumo a uma plataforma de anúncios, ele carrega uma pergunta implícita: "quem é a pessoa por trás desta compra?". As plataformas precisam responder a isso para atribuir a conversão à campanha certa, mas você não quer — e, em muitos regimes, não pode — entregar o e-mail e o telefone dos seus clientes em texto puro para um terceiro. O hashing de dados pessoais (PII, do inglês personally identifiable information) resolve essa tensão: em vez do dado bruto, você envia uma impressão digital criptográfica dele. A plataforma faz o mesmo com a base própria e compara impressões, nunca os valores originais.

O detalhe que separa uma integração que funciona de uma que desperdiça metade das conversões é aparentemente banal: a impressão digital só bate se os dois lados partirem exatamente do mesmo texto. E é aí que mora a disciplina deste guia — não basta hashear, é preciso normalizar antes de hashear, seguindo à risca a mesma receita que a plataforma usa do outro lado. Este artigo cobre o que é o SHA-256, por que a ordem das operações importa, como normalizar cada campo (e-mail, telefone, nome, cidade, estado, CEP) e quais são os erros que silenciosamente derrubam sua taxa de correspondência.

Por que a identidade nunca trafega em texto puro#

A ideia central de um canal de mensuração moderno é a correspondência por identificadores hasheados. Você tem um cliente que comprou; a plataforma tem uma base de usuários logados. Ambos os lados aplicam a mesma função de hash sobre os mesmos campos normalizados. Se o resultado é idêntico, a plataforma conclui — com alta probabilidade — que se trata da mesma pessoa e credita a conversão. O valor original nunca é compartilhado nesse processo; o que viaja é uma sequência hexadecimal de tamanho fixo que não revela o dado de origem.

Isso atende a dois objetivos ao mesmo tempo. Do lado da privacidade e conformidade, você minimiza a exposição de dados pessoais: o terceiro recebe um derivado, não o e-mail em si. Do lado da mensuração, você amplia a correspondência para além de cookies e identificadores de clique, que são cada vez mais frágeis. É a combinação dos dois que faz o hashing de PII virar prática padrão em rastreamento server-side.

O que é SHA-256 (e por que "mão única")#

SHA-256 é uma função de hash criptográfica que recebe qualquer texto e produz uma saída de 256 bits, representada como 64 caracteres hexadecimais. Três propriedades importam aqui:

• Determinística: a mesma entrada produz sempre a mesma saída. É isso que permite a correspondência — os dois lados chegam ao mesmo resultado partindo do mesmo texto.
• Irreversível (mão única): a partir do hash não é viável recuperar a entrada original. Não existe "des-hashear".
• Sensível a qualquer diferença: trocar uma única letra, um espaço ou o caso de um caractere gera um hash completamente diferente. Não há "quase igual" — ou bate por inteiro, ou não bate.

É a terceira propriedade que impõe a normalização. Joao@Gmail.com (com espaço no fim e maiúsculas) e joao@gmail.com são, para o SHA-256, dois universos distintos. Se você hashear um e a plataforma hashear o outro, a correspondência falha por um detalhe cosmético que não muda quem a pessoa é.

A regra de ouro: normalizar ANTES de hashear#

Guarde esta sequência como um mantra: coletar → normalizar → hashear → enviar. Inverter os dois passos do meio é o defeito número um em integrações de conversão. Como o hash não tolera diferença nenhuma, toda a variação humana precisa ser eliminada antes de a função de hash entrar em cena. Depois de hashear já é tarde: o hash de joao@gmail.com e o hash de JOAO@gmail.com não têm relação alguma entre si, e não há como "consertar" isso no lado do hash.

Normalizar é aplicar um conjunto de regras que colapsam todas as variações válidas de um mesmo dado em uma única forma canônica. Cada plataforma publica a sua receita, e elas são muito parecidas entre si porque todas convergiram para o mesmo bom senso: caixa baixa, sem espaços nas bordas, formato único por tipo de campo. O trabalho é seguir essa receita exatamente, campo a campo.

Normalização de e-mail#

O e-mail é, de longe, o identificador de maior valor de correspondência, porque as pessoas costumam usar o mesmo endereço em vários serviços. As regras básicas:

• Remover espaços no início e no fim (trim).
• Converter tudo para minúsculas. E-mails são tratados como case-insensitive na prática.
• Remover espaços internos, que às vezes entram por colagem ou por preenchimento automático malfeito.

``text " Joao.Silva@Gmail.COM " → "joao.silva@gmail.com" ``

A nuance dos pontos e do "+" no Gmail#

Existe uma otimização adicional que gera muita confusão: no Gmail, pontos antes do @ são ignorados pelo provedor (joao.silva@gmail.com e joaosilva@gmail.com chegam à mesma caixa), e tudo depois de um + é um sufixo de rótulo (joao+lojas@gmail.com também chega em joao@gmail.com). Algumas plataformas de anúncios fazem essa canonização adicional apenas para domínios do Gmail para elevar a correspondência.

O ponto delicado é: só aplique essa regra se a plataforma de destino também aplicar, e apenas aos domínios que ela especifica. Se você remover os pontos e a plataforma não remover, os hashes deixam de bater — você teria piorado, não melhorado. Além disso, esse comportamento é característico do Gmail; aplicá-lo cegamente a outros provedores quebra endereços em que o ponto é significativo. Na dúvida, faça o básico (trim + minúsculas) e trate a canonização de Gmail como um passo opcional, condicionado ao que a documentação do destino determina.

Normalização de telefone#

Telefone é o segundo identificador mais valioso, mas também o mais bagunçado, porque cada pessoa digita de um jeito: com parênteses, com traços, com espaços, com ou sem código de país. A forma canônica universal é o E.164: sinal de mais opcional (muitas plataformas pedem só os dígitos), código do país, e o número nacional, sem nenhum separador.

As regras:

• Remover todos os caracteres não numéricos — parênteses, traços, espaços, pontos.
• Incluir o código do país. No Brasil, 55.
• Remover o zero de tronco e quaisquer prefixos de operadora que não fazem parte do número internacional.

``text "(11) 98765-4321" → "5511987654321" "+55 11 98765 4321" → "5511987654321" ``

O caso do nono dígito no Brasil#

Celulares brasileiros ganharam um nono dígito (o 9 inicial no número local). Isso cria uma armadilha de correspondência: se a sua base tem números antigos gravados sem o nono dígito e a base do outro lado tem com o nono dígito, os hashes não batem. A canonização precisa ser consistente: decida por incluir sempre o nono dígito para celulares e aplique isso a toda a base antes de hashear. O objetivo é que o mesmo telefone físico sempre produza a mesma string E.164, independentemente de como foi capturado. Números fixos não têm o nono dígito; a regra vale para móveis.

Um detalhe operacional: se você não tem o código do país gravado, precisa inferi-lo por contexto (país da loja, DDI do formulário). Enviar um número nacional "pelado", sem DDI, é uma causa comum de correspondência baixa, porque a plataforma não sabe a qual país aquele número pertence.

Normalização de nome, endereço e outros campos#

E-mail e telefone carregam a maior parte do peso, mas nome, cidade, estado e CEP funcionam como sinais complementares que ajudam a plataforma a compor uma correspondência mais confiável. As regras gerais são as mesmas: caixa baixa, sem espaços nas bordas, formato consistente. Algumas particularidades por campo:

• Nome e sobrenome: minúsculas, sem espaços nas pontas. Muitas receitas pedem remover acentuação (joão → joao) e caracteres especiais, ficando só letras a-z. Envie nome e sobrenome em campos separados quando a plataforma oferecer os dois.
• Cidade: minúsculas, sem espaços internos e sem pontuação. São Paulo costuma virar saopaulo.
• Estado: o padrão mais comum é a sigla de duas letras em minúsculas para os EUA; para o Brasil, siga a orientação do destino (sigla da UF em minúsculas, como sp, quando aceito).
• CEP / código postal: apenas os dígitos, sem traço. Algumas receitas pedem só os cinco primeiros dígitos (padrão dos EUA); para o Brasil, o CEP completo sem hífen é o caminho seguro, conforme o destino especificar.
• País: código ISO de duas letras em minúsculas (br).

A regra de ouro se mantém: use exatamente a normalização que a plataforma de destino documenta para cada campo. Divergir da receita não é "quase certo" — é errado, porque o hash amplifica qualquer diferença.

Exemplo de pipeline: normalizar e hashear#

Abaixo, um pipeline mínimo que normaliza e hasheia um e-mail e um telefone. Note que a normalização vem primeiro e o hash vem por último, sempre sobre a string já canônica.

```python import hashlib import re import unicodedata

def sha256(valor: str) -> str: # Hash SHA-256 de uma string ja normalizada, codificada em UTF-8. return hashlib.sha256(valor.encode("utf-8")).hexdigest()

def normalizar_email(email: str) -> str: # trim + minusculas; remove espacos internos. return email.strip().lower().replace(" ", "")

def normalizar_telefone(tel: str, ddi_padrao: str = "55") -> str: # Mantem so digitos; garante o codigo de pais na frente. digitos = re.sub(r"\D", "", tel) if not digitos.startswith(ddi_padrao): digitos = ddi_padrao + digitos return digitos

def normalizar_nome(nome: str) -> str: # Minusculas, sem acento, so letras a-z. sem_acento = unicodedata.normalize("NFKD", nome) sem_acento = sem_acento.encode("ascii", "ignore").decode("ascii") return re.sub(r"[^a-z]", "", sem_acento.lower())

email_hash = sha256(normalizar_email(" Joao.Silva@Gmail.COM ")) tel_hash = sha256(normalizar_telefone("(11) 98765-4321"))

print(email_hash) # hash de "joao.silva@gmail.com" print(tel_hash) # hash de "5511987654321" ```

O equivalente em JavaScript no servidor (Node.js), útil quando a sua camada de conversão roda em ambiente JS:

```js import { createHash } from "node:crypto";

// Hash SHA-256 hexadecimal de uma string ja normalizada. const sha256 = (v) => createHash("sha256").update(v, "utf8").digest("hex");

// trim + minusculas, sem espacos internos. const normalizarEmail = (e) => e.trim().toLowerCase().replace(/\s+/g, "");

// So digitos, com DDI garantido na frente. const normalizarTelefone = (t, ddi = "55") => { const d = t.replace(/\D/g, ""); return d.startsWith(ddi) ? d : ddi + d; };

const emailHash = sha256(normalizarEmail(" Joao.Silva@Gmail.COM ")); const telHash = sha256(normalizarTelefone("(11) 98765-4321")); ```

O que NÃO hashear#

Nem tudo que identifica o usuário deve ser hasheado. Um conjunto importante de campos precisa viajar em texto puro, porque a plataforma os usa como chave direta de correspondência ou de deduplicação:

• Identificadores de navegador/cookie da própria plataforma (por exemplo, o par cookie do navegador + cookie de clique que o pixel grava). Eles já são pseudônimos e devem ir crus.
• Identificadores de clique capturados da URL (os parâmetros que a plataforma anexa ao anúncio) vão em texto puro.
• IDs externos que você usa para casar com a base da plataforma (quando o campo é definido para receber um identificador opaco, e não um dado pessoal).
• O event_id de deduplicação, o endereço IP e o user agent também não são hasheados.

A regra mental é simples: hasheia-se o que é dado pessoal legível (e-mail, telefone, nome, endereço); não se hasheia o que já é um identificador técnico opaco. Hashear um identificador de clique, por exemplo, o torna inútil, porque a plataforma esperava o valor cru para casar com o registro do próprio clique.

Testes de consistência#

Como o hash é uma caixa-preta — você não "lê" o resultado —, o único jeito de ter confiança é testar contra valores esperados. Duas técnicas:

• Vetores de teste fixos. Escolha entradas conhecidas e compare a saída do seu pipeline com o hash esperado. Por exemplo, joao.silva@gmail.com em SHA-256 sempre produz o mesmo hexadecimal; grave esse valor no seu conjunto de testes e faça o pipeline reproduzi-lo. Se um dia parar de bater, algo mudou na normalização.
• Comparação com a ferramenta de diagnóstico do destino. As plataformas oferecem painéis que mostram a qualidade e a taxa de correspondência dos parâmetros recebidos. Se um campo que você jura ter enviado aparece com correspondência zero, quase sempre a causa é normalização divergente — não falta do dado.

Escreva o teste de forma que ele force uma falha conhecida: inclua um caso em que a entrada não-normalizada produz um hash diferente do esperado, garantindo que o teste realmente detecta o problema em vez de passar por vacuidade.

Erros comuns que derrubam a correspondência#

Vale enumerar os defeitos recorrentes, porque quase toda queda de match rate cai em um destes:

• Hashear sem normalizar. O clássico. João@Gmail.com hasheado cru nunca vai bater com a base do destino, que normalizou para joão@gmail.com... perdão, joao@gmail.com.
• Dupla hashificação / hashear já-hasheado. Enviar o hash de um valor que já era um hash. Acontece quando uma camada normaliza-e-hasheia e outra camada, sem saber, hasheia de novo. O resultado é um hash de 64 caracteres que não corresponde a nada.
• Enviar o hash de string vazia. Se o campo veio vazio, o correto é omitir o campo, não enviar o hash de "". O hash da string vazia é um valor fixo e conhecido; mandá-lo faz a plataforma tentar casar milhares de usuários pelo "mesmo" hash de nada, o que polui a correspondência e pode ser rejeitado.
• Encoding errado. Hashear os bytes em uma codificação diferente de UTF-8 (por exemplo, Latin-1) muda o resultado para qualquer caractere acentuado. Padronize UTF-8 dos dois lados.
• Formato de saída inconsistente. Misturar hexadecimal com Base64, ou maiúsculas com minúsculas no hex. A maioria das plataformas espera hexadecimal em caixa baixa; confira a documentação.
• Normalização parcial. Fazer trim mas esquecer o lower, ou vice-versa. Meia normalização não é normalização — o hash exige a receita completa.

Impacto direto em match rate e EMQ#

Tudo isso não é preciosismo: converte-se diretamente em resultado de mensuração. A taxa de correspondência (match rate) — a fração de eventos que a plataforma consegue casar com um usuário — sobe quando você envia mais campos, bem normalizados. Cada identificador correto é uma chance a mais de casar; cada identificador malformado é uma chance desperdiçada e, no limite, ruído que atrapalha.

No ecossistema da Meta, essa qualidade é resumida em uma nota conhecida como EMQ (Event Match Quality), que avalia quão bem os parâmetros de identidade enviados permitem a correspondência. Normalizar corretamente e-mail e telefone, incluir campos complementares como nome e localização, e não poluir com hashes vazios ou duplos: é essa higiene que empurra o EMQ para cima. E um EMQ melhor significa atribuição mais precisa, otimização de campanha mais eficiente e menos conversões perdidas por um simples descuido de formatação.

Síntese#

O hashing de PII é a ponte que permite mensurar conversões sem entregar dados pessoais em texto puro: cada lado transforma o mesmo dado na mesma impressão digital SHA-256 e compara impressões, não valores. A engenharia inteira gira em torno de uma disciplina de uma frase — normalizar antes de hashear, seguindo exatamente a receita do destino, porque o hash não perdoa nem um espaço ou uma maiúscula fora do lugar. Normalize e-mail (trim, minúsculas, e a canonização de Gmail só quando o destino a fizer), telefone (E.164 com DDI e nono dígito consistente) e os campos complementares (nome sem acento, cidade sem espaço, CEP só dígitos); mantenha em texto puro o que é identificador técnico opaco; jamais envie hash de string vazia nem hasheie duas vezes; e teste contra vetores fixos para garantir consistência. Feito isso, a recompensa é concreta: correspondência mais alta, EMQ melhor e atribuição em que se pode confiar.