Qualidade de correspondência do Meta: o que move a nota de verdade
A nota de correspondência não sobe mexendo em configuração do Meta. Ela é consequência de quanto você captura e de quanto disso sobrevive até o envio — e as duas coisas são medíveis do seu lado, hoje.
A qualidade de correspondência — Event Match Quality, ou EMQ — é uma nota de 0 a 10 que o Meta dá a cada evento que você envia pela API de Conversões. Ela responde a uma pergunta só: com os dados que vieram nesse evento, o Meta consegue dizer de quem ele é?
Quase toda discussão sobre EMQ começa no lugar errado, procurando um ajuste dentro do Gerenciador de Eventos. Não existe esse ajuste. A nota é um espelho: mede o que você capturou e o que você mandou. As duas pontas ficam do seu lado.
O que cada parâmetro pesa
Os campos de user_data não valem a mesma coisa. Vale saber onde investir esforço de captura antes de sair pedindo mais dado ao visitante.
| Parâmetro | O que resolve | Efeito prático |
|---|---|---|
| em (e-mail) | Identificação direta da conta | O mais determinante. Sozinho costuma colocar a nota na faixa de 5 a 6 |
| ph (telefone) | Segunda identidade forte, e no Brasil quase universal | Somado ao e-mail, empurra a nota para 7 ou mais |
| fbc | O clique no anúncio, vindo do fbclid da URL | Quando existe, é atribuição direta — não é palpite |
| fbp | O navegador, para costurar sessões da mesma pessoa | Médio. Liga a visita anônima à visita identificada |
| external_id | O seu identificador estável da pessoa | Médio, e é o que dá consistência entre eventos |
| fn, ln | Nome e sobrenome | Baixo isolado, relevante somado |
| ct, st, zp, country | Localização | Baixo isolado. Em conjunto, desempata |
Repare no que a tabela não diz: não existe parâmetro mágico. O e-mail é o primeiro degrau, e depois dele o ganho vem de somar sinais fracos — que é exatamente o trabalho que ninguém quer fazer.
Nota baixa quase nunca é problema de configuração. É problema de captura: ou o dado não existe, ou existe no seu banco e não chegou ao envio.
A medição que encerra a discussão em dez minutos
O Gerenciador de Eventos mostra a nota agregada, com atraso de horas e sem dizer o que faltou. Existe um sinal muito mais útil, e ele está do seu lado: nos eventos que você entregou nos últimos sete dias, que porcentagem levou cada parâmetro.
-- Cobertura de parâmetro nos eventos que você REALMENTE entregou.
-- Não é o que o payload poderia levar: é o que saiu.
SELECT
event_name,
count() AS enviados,
round(100 * countIf(tem_email), 1) AS pct_email,
round(100 * countIf(tem_telefone), 1) AS pct_telefone,
round(100 * countIf(tem_fbc), 1) AS pct_fbc,
round(100 * countIf(tem_external_id), 1) AS pct_external_id
FROM entregas
WHERE enviado_em >= now() - INTERVAL 7 DAY
GROUP BY event_name
ORDER BY enviados DESCEssa consulta muda a conversa. Se o e-mail aparece em 30% dos envios, nenhum ajuste do lado do Meta vai salvar o pareamento, e não adianta discutir hash nem formato: faltam 70% dos e-mails.
Um resultado real que ilustra o ponto
Numa conta que auditamos, o mesmo pixel, na mesma semana, produziu dois números completamente diferentes: o evento de visita de página saiu com e-mail em 11,4% e telefone em 10,3%, enquanto o evento de carrinho abandonado da mesma conta saiu com os dois em 100%.
Não é contradição. É o momento da captura: no carrinho a pessoa já se identificou, na visita ainda não. A leitura correta é que EMQ é por evento — comparar a nota de eventos diferentes não significa nada.
Os três erros que anulam o esforço de captura
1. Normalizar depois de hashear, ou não normalizar
O sha256 é do texto exato. Um e-mail com maiúscula ou com espaço sobrando produz um hash diferente do mesmo e-mail limpo, e só o limpo casa. Antes de hashear: minúsculas e sem espaço nas pontas. Telefone: só dígitos, com o código do país na frente — no Brasil, 55.
2. Mandar só o que veio no payload do evento
Este é o mais caro e o mais comum. O e-mail da pessoa quase sempre já existe no seu banco, ligado a ela por uma compra anterior ou por um formulário de dois meses atrás. Se a montagem do user_data lê apenas a requisição que chegou agora, você joga fora o que já sabia. O user_data deveria sair do grafo de identidade, não do corpo do evento.
3. Inventar o que falta
A tentação de completar gênero ou cidade por inferência é grande, e o efeito é o oposto do esperado: palpite errado não é neutro, é ruído que o Meta usa para tentar casar a pessoa errada.
Vimos isso medido. Um dicionário de nomes usado para inferir gênero cobria 87,7% do tráfego brasileiro e não conhecia nomes comuníssimos aqui — e o acento quebrava a busca nos dois sentidos. O resultado é que o parâmetro de gênero saía em cerca de metade dos eventos em que o nome existia. O conserto não foi chutar melhor: foi deixar o campo vazio quando o nome é ambíguo.
Parâmetro ausente custa um sinal. Parâmetro errado custa o pareamento inteiro daquele evento.
O teto que ninguém conta
Vale dizer o que a nota alta não resolve. EMQ mede reconhecimento de pessoa, não qualidade de conversão. Um evento com nota 9 apontando para um PIX que expirou continua ensinando a campanha a procurar quem gera PIX e não paga.
Por isso as duas frentes andam juntas, e nesta ordem: primeiro o filtro do que sobe, depois a cobertura de quem é. Subir a nota de um evento que não deveria estar sendo enviado só faz a campanha errar com mais confiança.
No CrazyLeads o user_data é montado a partir do grafo de identidade — o e-mail que a pessoa deixou em qualquer fonte viaja junto com a compra —, normalização e hash são o comportamento padrão, e a cobertura por parâmetro é uma tela, não uma consulta que você precisa escrever.