Existe um número dentro do Gerenciador de Eventos que quase ninguém abre, e que decide silenciosamente quanto você paga por venda. Ele se chama pontuação de qualidade da correspondência de eventos — em inglês, Event Match Quality, ou EMQ — e vai de 0 a 10.
A maior parte das contas que eu abro está entre 3 e 5. E quase sempre a conversa é a mesma: “mas eu já instalei a API de Conversões”. Instalar a API de Conversões e mandar dados bons por ela são duas coisas diferentes, e é exatamente essa diferença que a nota mede.
O que a nota realmente mede
Não é a qualidade do seu anúncio, nem do seu criativo, nem da sua página. A pontuação mede uma coisa só: o quanto a informação que você manda junto de cada conversão permite ao Meta descobrir qual pessoa fez aquela compra.
Pense no que acontece quando uma venda entra. O seu servidor avisa ao Meta: “houve uma compra de R$ 297”. Ótimo — mas de quem? O Meta precisa ligar esse evento a um perfil real para saber qual anúncio o gerou e, principalmente, para aprender com quem se parece o seu comprador. Se você mandou só o valor, ele não liga a ninguém. O evento entra na conta e não ensina nada.
É por isso que o nome tem a palavra correspondência. Você não manda a identidade de ninguém — manda pistas embaralhadas, e o Meta tenta casá-las com o que já sabe. Quanto mais pistas, maior a chance de casar. Uma pista sozinha pode falhar; seis, dificilmente.
Onde ver a sua
Gerenciador de Eventos → escolha o seu pixel → aba Visão geral. Clique no evento (normalmente Purchase) e procure o cartão de qualidade da correspondência. Ali também aparece a lista de parâmetros que você está mandando — e, mais útil que a nota, a lista dos que você não está.
A nota demora a se mexer, e isso é normal
O Meta recalcula a pontuação em uma janela de aproximadamente 48 horas, olhando só os eventos recentes. Duas consequências práticas: uma correção que você subir hoje não aparece hoje, e uma variação de 0,2 a 0,5 ponto de um dia para o outro é ruído, não é a sua implementação piorando. Compare semana com semana, não dia com dia.
Por que ela decide o seu custo
Aqui está o mecanismo, e vale entender porque ele explica por que a nota importa mais do que parece.
A entrega do Meta funciona por semelhança. Ele pega quem comprou de você e procura mais gente parecida. Esse é o motor inteiro. Agora: um evento que ele não conseguiu casar com nenhum perfil é um comprador que ele não sabe quem é — e de quem, portanto, não consegue extrair nenhuma semelhança.
Então a conta que costuma ficar invisível é esta: se metade das suas vendas não é casada, o algoritmo está aprendendo com metade dos dados que você pagou para gerar. Você comprou 100 conversões e ensinou 50. O anúncio não fica ruim por isso — ele fica lento, que é pior, porque parece só falta de sorte.
E tem o efeito na atribuição. Venda não casada é venda que o Gerenciador não credita ao anúncio que a fez. Aí o relatório mostra um ROAS menor que o real, você pausa uma campanha que estava lucrando, e a decisão errada nasce de um dado incompleto — não de um julgamento ruim.
Os parâmetros que você pode mandar
Esta é a lista que importa para evento de site. A coluna do hash é a que mais gera erro, então ela vem primeiro:
| Campo | O que é | SHA-256? | Como normalizar antes |
|---|---|---|---|
em | Sim | Minúsculas, sem espaço nas pontas | |
ph | Telefone | Sim | Só dígitos, com DDI, sem zero à esquerda |
fn | Nome | Sim | Minúsculas, sem pontuação |
ln | Sobrenome | Sim | Minúsculas, sem pontuação |
ct | Cidade | Sim | Minúsculas, sem espaço nem acento |
st | Estado | Sim | Sigla em minúsculas — sp, rj |
zp | CEP | Sim | Só dígitos, sem hífen |
country | País | Sim | ISO de 2 letras minúsculas — br |
external_id | Seu id do cliente | Recomendado | O mesmo id que o pixel manda |
fbc | Id do clique | Não | Texto puro, formato fb.1.<tempo>.<fbclid> |
fbp | Id do navegador | Não | Texto puro, do cookie _fbp |
client_ip_address | IP do visitante | Não | Texto puro, IPv4 ou IPv6 |
client_user_agent | User agent | Não | Texto puro, string completa |
Hashear o que não se hasheia derruba o evento
Os quatro últimos vão em texto puro. Mandar o IP ou o fbc hasheado não é “um pouco pior” — o Meta trata como valor inválido. E como a resposta da API costuma vir 200 mesmo assim, a implementação parece funcionando enquanto a nota não sobe.
Os dois que quase ninguém manda
Se a sua nota está travada entre 4 e 6 mesmo mandando e-mail e telefone, aposto nesses dois.
fbc — o identificador do clique
Quando alguém clica no seu anúncio, o Meta acrescenta um parâmetro fbclid na URL de destino. Esse código identifica aquele clique específico, e é a ligação mais direta que existe entre a venda e o anúncio — mais forte que e-mail, porque não depende de casar pessoa nenhuma: ele já é o clique.
O formato tem quatro partes separadas por ponto:
fb.1.1725360000000.IwAR2ZxK...
│ │ │ └── o fbclid inteiro, como veio na URL
│ │ └── quando você capturou, em milissegundos
│ └── nível do subdomínio (1 para utmizey.com.br)
└── prefixo fixoO detalhe que mata: o fbclid vive na URL da primeira página. Se a pessoa navega para o checkout e você só captura ali, o parâmetro já se perdeu. Ele precisa ser guardado no primeiro clique — cookie ou localStorage — e recuperado na hora da compra, que pode ser dias depois.
fbp — o identificador do navegador
É o cookie _fbp, que o pixel cria sozinho no primeiro carregamento. Formato parecido, e ele cobre um caso que o fbc não cobre: a pessoa que viu o anúncio, não clicou, procurou você no Google depois e comprou. Não há clique para rastrear, mas há o mesmo navegador.
Os dois são de graça e não dependem do cliente
E-mail e telefone dependem do que o comprador digita — nome abreviado, telefone sem DDD, e-mail descartável. O fbc e o fbp vêm do navegador, sempre no mesmo formato, sem ninguém precisar preencher nada. São a melhor relação entre esforço e ganho de nota que existe.
O external_id, que tem o maior alcance
Esse merece parágrafo próprio porque é o de maior cobertura. E-mail existe quando a pessoa comprou. O external_id pode existir para todo visitante, inclusive quem só passou pela página — basta você gerar um identificador anônimo e persistente por navegador.
Há uma regra que faz toda a diferença: o mesmo external_id tem que ir nos dois lados — no pixel do navegador e no envio do servidor. Se o pixel manda um e o servidor manda outro, você não reforçou a correspondência; criou duas pessoas diferentes na cabeça do Meta a partir de uma só.
Como hashear sem estragar
SHA-256, resultado em hexadecimal minúsculo. A normalização vem antes do hash, e é aí que quase todo erro acontece: hash é uma função exata, então Joao@Email.com e joao@email.com produzem resultados completamente diferentes e não casam com nada.
// Errado — o espaço e a maiúscula sobrevivem no hash
sha256(" Joao@Email.com ")
// 7f3c2a... não corresponde a ninguém
// Certo — normaliza, depois hasheia
sha256(" Joao@Email.com ".trim().toLowerCase())
// 4a1b8e... correspondeO telefone tem a sua própria armadilha, e é a mais comum no Brasil:
(11) 98765-4321 → errado: tem símbolos e falta o DDI
011987654321 → errado: zero à esquerda
5511987654321 → certo: DDI 55, DDD 11, só dígitosNão hasheie duas vezes
Se a sua plataforma de vendas já entrega o e-mail hasheado e você hasheia de novo antes de mandar, o valor final não corresponde a nada — e nada no retorno da API indica isso. Confira o que chega antes de transformar: um hash SHA-256 tem sempre 64 caracteres hexadecimais.
Deduplicação: o passo que dobra a venda
Quando você tem pixel e API de Conversões, a mesma compra é enviada duas vezes: uma pelo navegador, outra pelo servidor. Isso é intencional — se o navegador for bloqueado, o servidor salva o evento.
Mas o Meta precisa saber que são o mesmo evento. Isso se faz mandando o mesmo event_name e, principalmente, o mesmo event_id nos dois lados:
{
"event_name": "Purchase",
"event_id": "pedido-8842", ← idêntico no pixel e no servidor
"event_time": 1725360000,
"action_source": "website",
"user_data": { "em": ["4a1b8e..."], "fbc": "fb.1.1725360000000.IwAR2..." },
"custom_data": { "value": 297.00, "currency": "BRL" }
}Sem isso, uma venda vira duas. O faturamento no Gerenciador infla, o ROAS aparente sobe, e você escala uma campanha com base em um número que não existe. É o único erro desta lista que faz o painel parecer melhor — e por isso o que demora mais para ser descoberto.
O roteiro, em ordem de retorno
- 1. Ligue fbc e fbp. Não dependem do comprador digitar nada, e costumam ser o maior salto isolado da nota.
- 2. Confira o DDI do telefone. Praticamente toda conta brasileira que eu abro está mandando telefone sem o 55.
- 3. Mande external_id nos dois lados. Maior alcance de todos, e o único que cobre quem ainda não comprou.
- 4. Acrescente cidade, estado, CEP e país. Sozinhos valem pouco; somados aos outros, fecham o cerco.
- 5. Verifique a deduplicação. Antes de comemorar qualquer aumento de faturamento no Gerenciador.
- 6. Espere 48 horas. E compare semana com semana.
Como o UTMizey resolve isso
Esta parte é sobre o nosso produto, então vale ser exato sobre o que ele faz — e só sobre isso.
Toda venda aprovada que entra pelo webhook da sua plataforma volta ao Meta pela API de Conversões com os treze parâmetros da tabela acima, quando eles existem no que a plataforma enviou: em, ph, fn, ln, ct, st, zp, country, external_id, fbp, fbc, client_ip_address e client_user_agent.
O hash sai pronto do banco, já normalizado, e os quatro campos de texto puro seguem em texto puro. O event_id viaja junto para a deduplicação, e o external_id é o mesmo que o script manda pelo navegador — é o que impede a duplicação de identidade descrita acima.
Do seu lado são duas colagens: o script na página e a URL do webhook na plataforma de vendas. Não há servidor para manter, nem código para escrever.
Veja a sua pontuação subir
Crie a conta, conecte o seu pixel e ligue o webhook da sua plataforma. As próximas vendas já saem com o conjunto completo de parâmetros de correspondência — e em cerca de 48 horas o Gerenciador de Eventos mostra a diferença. O plano gratuito não pede cartão.