Event Match Quality (EMQ): como medir e melhorar a nota de correspondência passo a passo

Quando um evento sai do seu servidor rumo à plataforma de anúncios, ele carrega um punhado de sinais sobre quem realizou a ação. O Event Match Quality (EMQ) é a nota que resume o quanto esses sinais permitiram identificar a pessoa por trás do evento com confiança. Em outras palavras, o EMQ não mede se o evento chegou — mede se o evento foi casado a um indivíduo real do outro lado. Essa distinção é a raiz de quase todo mal-entendido sobre o tema: você pode ter cem por cento dos eventos entregues e, ainda assim, uma correspondência sofrível, porque os campos que identificam a pessoa chegaram vazios, malformados ou hasheados de forma errada.

Este é um guia técnico passo a passo. Vamos cobrir o que a nota representa, por que ela afeta diretamente otimização, atribuição e alcance, quais parâmetros de user_data pesam mais, como normalizar e hashear os dados sem zerar o match, como diagnosticar uma nota baixa de forma sistemática e, por fim, montar um plano de melhoria priorizado — separando o que dá ganho imediato do que exige mudança estrutural.

O que a nota de EMQ realmente representa#

O EMQ é uma estimativa de qualidade de correspondência, normalmente expressa numa escala de zero a dez. Cada evento server-side traz um bloco user_data com identificadores da pessoa — alguns diretos (email, telefone), outros indiretos (endereço IP, user agent, identificadores de clique). A plataforma tenta encontrar, na sua base, o indivíduo que corresponde àquele conjunto de sinais. Quanto mais sinais válidos e corretos chegam, maior a probabilidade de o casamento acontecer, e maior a nota.

É importante entender que a nota é agregada e probabilística. Ela reflete a média de qualidade dos eventos de um tipo (um Purchase, um Lead) ao longo de uma janela. Uma nota alta não garante que todo evento foi casado; ela indica que, na maioria deles, chegaram identificadores fortes e bem formados. Por isso, olhar apenas o número final engana: o diagnóstico útil vem de decompor a nota em cobertura por campo, como veremos adiante.

Por que EMQ alto importa#

Uma correspondência boa não é vaidade de dashboard. Ela alimenta três funções centrais da campanha:

• Otimização. O algoritmo aprende com quem converteu. Se ele não consegue casar a conversão a um perfil, o sinal de aprendizado se perde ou fica ruidoso. EMQ alto entrega exemplos limpos de "esta pessoa converteu", e o modelo passa a buscar semelhantes com mais precisão.
• Atribuição. Sem casar o evento a uma pessoa que viu ou clicou no anúncio, a conversão não é creditada à campanha. Isso subestima o retorno, distorce o custo por resultado e leva a decisões de verba equivocadas — cortando o que na verdade funciona.
• Alcance e reengajamento. Correspondência é o que permite deduplicar eventos entre navegador e servidor, remontar públicos de retargeting e excluir quem já comprou. Match fraco infla frequência sobre gente errada e desperdiça impressão.

Em resumo: EMQ é a ponte entre o que aconteceu no seu domínio e o que a plataforma consegue usar. Ponte estreita, aprendizado pobre.

Quais parâmetros de user_data pesam#

Nem todo identificador tem o mesmo poder de correspondência. Campos que são únicos e estáveis por pessoa casam melhor do que campos amplos e compartilhados. A tabela abaixo ordena os principais parâmetros por impacto relativo típico na correspondência. Trate os pesos como ordem de grandeza, não como constantes exatas — o efeito real depende de cobertura e qualidade.

| Parâmetro | Campo comum | Impacto relativo | Observação | |---|---|---|---| | Email | em | Muito alto | Identificador forte; aceita múltiplos por pessoa. Hashear normalizado. | | Telefone | ph | Muito alto | Forte quando em E.164 (com código do país). | | External ID | external_id | Alto | Seu ID interno estável de usuário; ótimo para deduplicar. | | Click ID (fbc) | fbc | Alto | Captura o clique específico; determinístico quando presente. | | Browser ID (fbp) | fbp | Alto | Cookie de primeira parte do pixel; liga sessões. | | Nome e sobrenome | fn, ln | Médio | Reforça o match combinado; fraco isolado. | | Cidade / Estado / CEP | ct, st, zp | Médio | Reduz ambiguidade junto de nome; sozinho é amplo. | | País | country | Médio-baixo | Amplo demais isolado; útil como reforço. | | Endereço IP | client_ip_address | Baixo-médio | Compartilhado e volátil; reforço, não âncora. | | User agent | client_user_agent | Baixo-médio | Essencial junto de fbc/fbp para deduplicação. |

A leitura prática: priorize os identificadores fortes e estáveis (email, telefone, external_id, click IDs) e use os demais como reforço. Um evento com apenas país e IP tende a casar mal; um evento com email normalizado, telefone em E.164, external_id e fbc/fbp casa quase sempre.

O efeito de enviar mais campos — e de enviá-los corretamente#

Há dois ganhos distintos, e vale não confundi-los. O primeiro é de cobertura: enviar mais campos aumenta as chances de que algum identificador forte esteja presente para cada pessoa. Nem todo visitante tem cookie de clique; nem todo lead informou telefone. Quanto mais campos você tenta preencher, menor a fatia de eventos que chega "cega".

O segundo ganho é de corretude: cada campo enviado precisa estar normalizado e hasheado do jeito esperado, senão ele não só deixa de ajudar como consome esforço à toa. Um telefone sem código de país, um email com espaço no fim, um nome com acento não normalizado — todos produzem um hash que não bate com nada. O campo aparenta estar preenchido, mas contribui zero para a nota. Por isso mais campos só elevam o EMQ quando cada um deles está correto; volume malformado é peso morto.

Normalização antes do hashing — e por que hash errado zera o match#

Identificadores pessoais são enviados hasheados (SHA-256) para não trafegar em texto claro. O ponto crítico: a plataforma hasheia os dados dela com uma normalização específica e compara hash contra hash. Hash é determinístico e sem tolerância — joao@exemplo.com (com espaço) e joao@exemplo.com produzem digests completamente diferentes. Se você normalizar de um jeito e a plataforma de outro, os hashes nunca coincidem, e aquele campo forte vira ruído. Um erro de normalização não degrada o match: ele o zera para aquele campo.

As regras de normalização mais importantes:

• Email: remover espaços das pontas, converter para minúsculas. Não altere o conteúdo interno (pontos, sinais de mais) — normalize só caixa e espaços.
• Telefone: formato E.164 — apenas dígitos, com código do país, sem +, sem espaços, parênteses, traços ou zeros de tronco. Um número nacional sem o código do país casa mal.
• Nome, cidade, estado: minúsculas, sem espaços nas pontas. Muitas implementações também removem acentos e pontuação — siga a especificação vigente da plataforma para cada campo.
• CEP: minúsculas, sem espaços; em alguns países, só a primeira parte.
• Estado/País: frequentemente em código de duas letras minúsculas.
• fbc, fbp, external_id, IP, user agent: NÃO hasheie. Estes vão em texto claro. Hashear um destes é um erro comum que os anula.

O exemplo abaixo mostra a normalização de email e telefone antes do hash. Note que a ordem importa: normaliza-se primeiro, hasheia-se depois.

```javascript import { createHash } from "crypto";

// Aplica SHA-256 e devolve o digest em hexadecimal minúsculo. function sha256(value) { return createHash("sha256").update(value, "utf8").digest("hex"); }

// Normaliza e hasheia um email: apara espaços e força minúsculas. function hashEmail(raw) { if (!raw) return undefined; const normalized = raw.trim().toLowerCase(); if (!normalized.includes("@")) return undefined; // malformado: não envie return sha256(normalized); }

// Normaliza para E.164 (só dígitos, com código do país) e hasheia. // defaultCountry é o código discado do país quando o número vem local. function hashPhone(raw, defaultCountry = "55") { if (!raw) return undefined; let digits = raw.replace(/\D+/g, ""); // remove +, espaços, ( ) e - if (!digits) return undefined; // Remove zero de tronco inicial antes de prefixar o país. digits = digits.replace(/^0+/, ""); if (!digits.startsWith(defaultCountry)) { digits = defaultCountry + digits; } return sha256(digits); }

// Exemplos: hashEmail(" Joao@Exemplo.COM "); // hash de "joao@exemplo.com" hashPhone("(11) 98888-7777"); // hash de "5511988887777" ```

E aqui, um objeto user_data com vários campos preenchidos — os identificadores pessoais hasheados, os técnicos em texto claro:

```javascript // Monta o bloco user_data de um evento server-side. // Campos hasheados: em, ph, fn, ln, ct, st, zp, country, external_id // Campos em texto claro: client_ip_address, client_user_agent, fbc, fbp const userData = { em: [hashEmail("joao@exemplo.com")], // array aceita múltiplos emails ph: [hashPhone("11988887777")], fn: sha256("joao"), ln: sha256("silva"), ct: sha256("saopaulo"), // cidade sem espaço/acento st: sha256("sp"), zp: sha256("01310100"), country: sha256("br"), external_id: sha256("user_000123"), // seu ID interno estável client_ip_address: "203.0.113.42", // texto claro client_user_agent: "Mozilla/5.0 (...)", // texto claro fbc: "fb.1.1700000000000.IwAR0abc123", // click ID, texto claro fbp: "fb.1.1700000000000.987654321", // browser ID, texto claro };

// Remove chaves indefinidas para não enviar campos vazios. Object.keys(userData).forEach((k) => userData[k] == null && delete userData[k]); ```

Repare no cuidado final: campos indefinidos são removidos antes do envio. Mandar uma string vazia ou um hash de string vazia não é neutro — pode ser lido como valor válido e sujar a correspondência.

Como diagnosticar EMQ baixo, passo a passo#

Nota baixa não se resolve no chute. Siga uma investigação estruturada:

1. Audite quais campos realmente chegam#

Inspecione o payload como ele sai do seu servidor, não como você acha que está montando. Logue (com mascaramento, sem PII em claro) a lista de chaves presentes em user_data por evento. É comum descobrir que um campo que "deveria estar lá" some por uma condição de código, por um dado ausente na origem ou por uma serialização que o descarta.

2. Meça cobertura por campo#

Para cada identificador, calcule a fração de eventos que o traz preenchido: qual porcentagem dos Purchase tem email? Telefone? fbc? external_id? Um campo forte com cobertura de dez por cento tem impacto pequeno no agregado, por mais bem formado que esteja. Cobertura é onde a maior parte do ganho costuma se esconder.

3. Cace campos vazios ou malformados#

Cobertura alta não basta se o conteúdo está quebrado. Procure: emails sem @, telefones sem código de país ou com dígitos de mais, hashes de string vazia, nomes ainda com acento quando a spec pede sem, campos técnicos (fbc/fbp/IP) hasheados por engano. Cada um desses é um campo que parece presente e casa zero.

4. Verifique a captura dos IDs de clique#

fbc e fbp merecem atenção própria porque se perdem com facilidade. O fbp depende do cookie de primeira parte existir e ser lido no servidor. O fbc depende de capturar o parâmetro de clique da URL de entrada e persisti-lo até a conversão — se ele só existe na landing e some no checkout, você perde o identificador mais determinístico que tinha. Confirme que ambos atravessam toda a jornada, inclusive entre subdomínios.

5. Confronte com a ferramenta de diagnóstico da plataforma#

A maioria das plataformas expõe, por evento recente, quais parâmetros foram recebidos e reconhecidos. Use isso para fechar o ciclo: o campo que você acha que mandou foi de fato aceito? A normalização bateu? Essa checagem transforma suspeita em fato.

Plano de melhoria priorizado#

Com o diagnóstico em mãos, ataque em ordem de esforço versus retorno.

Quick wins (baixo esforço, ganho rápido):

• Corrigir a normalização de email e telefone. É a causa mais frequente de match zerado e costuma ser uma mudança de poucas linhas.
• Parar de hashear campos que vão em texto claro (fbc, fbp, external_id, IP, user agent).
• Remover campos vazios e hashes de string vazia do payload.
• Garantir E.164 com código do país no telefone.
• Corrigir a ordem: normalizar antes de hashear, sempre.

Ganho estrutural (mais esforço, teto mais alto):

• Elevar a cobertura dos campos fortes: coletar email/telefone mais cedo e em mais pontos da jornada; propagar o external_id do usuário logado para todos os eventos.
• Persistir fbc e fbp de ponta a ponta — capturar o click ID na entrada, guardar em armazenamento de primeira parte e reanexar na conversão, inclusive cruzando subdomínios.
• Unificar identidade no backend: quando o usuário é conhecido, enriquecer o evento com os dados de cadastro já normalizados, em vez de depender só do que o navegador enviou.
• Instrumentar monitoramento contínuo de cobertura por campo, para que uma regressão (um deploy que derruba a captura de um campo) seja detectada por alerta, não meses depois pela queda da nota.

A sequência importa: arrume a corretude primeiro — ela é barata e destrava o valor dos campos que você já manda. Depois invista em cobertura e persistência de identidade, que têm o maior teto mas exigem mudança de arquitetura de coleta.

Fechamento#

O Event Match Quality recompensa uma disciplina simples de dados: enviar identificadores fortes, para o máximo de eventos possível, normalizados exatamente como a plataforma espera e hasheados apenas onde deve. A nota é só o termômetro; o que ela mede é se o seu evento conseguiu encontrar a pessoa do outro lado. Trate cada campo como um contrato — normalização certa, formato certo, texto claro onde é texto claro — e o EMQ deixa de ser um número misterioso no painel para virar consequência direta de uma coleta bem-feita. Meça a cobertura, corrija os malformados, persista os IDs de clique, e a otimização, a atribuição e o alcance melhoram juntos, porque todos bebem da mesma fonte: uma correspondência que de fato acontece.