Advanced Matching: normalizar antes de hashear

O campo está preenchido, o hash está sendo enviado, e o casamento continua zero. Quase sempre a causa é a mesma: o valor foi hasheado antes de ser limpo, e a Meta não desfaz isso.

Atualizado em 8 de setembro de 2026 · por WYB Trackers

Por que dado preenchido pode não casar

A Meta não re-normaliza um valor que já chegou hasheado. Hash é função de via única: um telefone hasheado com parênteses, traço e espaço produz um hash daquele texto formatado, que nunca vai coincidir com o hash do número limpo do outro lado.

A ordem é obrigatória e não tem exceção. Normalizar primeiro, hashear depois. Invertida, ela transforma um campo válido em um hash inútil, e o painel não indica o motivo em lugar nenhum.

Telefone brasileiro: a regra que quebra números legítimos

A normalização correta tem três passos, e o terceiro é onde o mercado erra.

  1. 1Manter apenas dígitos. Remover parênteses, traço, espaço e sinal de mais.
  2. 2Remover zeros à esquerda, incluindo o zero de operadora quando presente.
  3. 3Decidir o código do país 55 PELO COMPRIMENTO: 10 ou 11 dígitos indica número nacional e recebe o prefixo 55.

Nunca decidir o DDI por prefixo

A heurística comum é olhar se o número já começa com 55 e, em caso positivo, não prefixar. Ela corrompe números legítimos, porque o DDD 55 existe: é o de Santa Maria, no Rio Grande do Sul. Um celular de Santa Maria começa com 55 e continua sendo um número nacional de 11 dígitos que precisa do prefixo. Quem decide por prefixo transforma o número em algo que não casa e não percebe, porque o efeito fica restrito a uma região.

Cidade e demais campos de endereço

A normalização de cidade remove acento e espaço e deixa apenas letras minúsculas de a a z. Na prática: decomposição Unicode, remoção dos sinais diacríticos, conversão para minúsculas e remoção dos espaços.

CampoEntrada típicaDepois da normalização
CidadeSão José dos Campossaojosedoscampos
E-mailJoao@Email.com (com espaço no fim)joao@email.com
Telefone(12) 99662-35455512996623545
EstadoSPsp
PaísBRbr
Só depois dessa etapa o valor é hasheado. Hashear a coluna do meio produz um hash que não casa com nada.

Hash duplo: a falha que não aparece em lugar nenhum

Algumas tags aplicam SHA-256 em hexadecimal por conta própria. Se a variável que alimenta a tag também hashear, o valor chega hasheado duas vezes e o casamento é zero. O sintoma é cruel: todos os campos aparecem preenchidos, o volume de eventos está normal, e a nota de casamento fica baixa sem explicação visível.

A regra da WYB Trackers

Decidir uma camada de hash e registrar por escrito qual é. Não é preciosismo de documentação: essa falha é invisível no painel e reaparece toda vez que alguém mexe no contêiner meses depois, sem saber que a tag já hasheia.

Os campos que mais faltam em auditoria de conta real

Em ordem de frequência observada nas auditorias da WYB Trackers:

Dado pessoal em texto puro: tirar, não somar

Integrações nativas de checkout às vezes enviam nome, e-mail, telefone e endereço completo em parâmetros customizados, como cd[user] e cd[address], em texto puro, além do dado hasheado no lugar correto. Isso não melhora a nota de casamento e é exposição de dado pessoal sem contrapartida. A recomendação é remover.

O que normalizar bem não resolve

Perguntas relacionadas

Por que preciso normalizar antes de hashear?

Porque a Meta não re-normaliza um valor que já chegou hasheado. Hash é uma função de via única: se você hasheia o telefone com parênteses, traço e espaço, o resultado é um hash daquele texto formatado, e ele nunca vai coincidir com o hash do número limpo que a Meta tem do outro lado. O casamento simplesmente não acontece, e nada no painel indica o motivo.

Como normalizar telefone brasileiro corretamente?

Mantenha apenas dígitos, remova zeros à esquerda e decida a inclusão do código do país 55 pelo comprimento do número: 10 ou 11 dígitos indica número nacional e recebe o prefixo 55. Nunca decida por prefixo, porque o DDD 55 existe, é o de Santa Maria no Rio Grande do Sul, e a heurística de prefixo corrompe números legítimos dessa região.

O que é hash duplo e como percebo?

É quando o valor é hasheado duas vezes antes de chegar à plataforma, normalmente porque a tag já aplica hash sozinha e a variável que a alimenta também aplica. O resultado é um hash de um hash, que não casa com nada. O sintoma é Event Match Quality baixo mesmo com todos os campos aparentemente preenchidos. A regra é decidir uma única camada de hash e documentar por escrito onde ela acontece.

Aumentar o Event Match Quality garante melhora nos resultados?

Não. EMQ é meio, não fim. Um EMQ alto no evento errado é pior que um EMQ médio no evento certo, porque você estará casando com precisão uma conversão que não representa o que a campanha deveria otimizar. Trate o score como termômetro do dado enviado, não como métrica de sucesso da conta.

Meu fbc está vazio. É defeito?

Não necessariamente. O fbc deriva do fbclid, que só existe quando a pessoa chegou por um clique em anúncio da Meta. Se a sessão auditada veio de tráfego orgânico, direto ou de outro canal, não existe fbclid e portanto não existe fbc. Confirme a origem do tráfego da sessão testada antes de abrir um chamado de bug.

Enviar mais dados sempre melhora o casamento?

Não, e pode piorar. Advanced Matching com normalização errada substitui um campo válido por um hash inútil. Além disso, algumas integrações nativas enviam nome, e-mail, telefone e endereço em texto puro em parâmetros customizados, além do dado hasheado. Isso não melhora o casamento e expõe dado pessoal sem necessidade.

Continuar lendo

Nota de casamento baixa com os campos todos preenchidos?

No diagnóstico gratuito olhamos o payload real e identificamos se o problema é normalização, hash duplo ou campo ausente.

Agendar diagnostico gratuito