Meta Event Match Quality: como aumentar a sua pontuação

A Event Match Quality (EMQ) é uma nota de 10 que o Meta dá a cada evento de site que você envia pela Conversions API. Ela mostra o quanto as informações do cliente nesse evento conseguem associá-lo a uma conta do Meta. Você a aumenta enviando mais dos identificadores certos, formatados e com hash do jeito que o Meta espera.

Este guia explica o que a nota mede, quais parâmetros de informações do cliente mais contam, as regras de hash e normalização, por que as compras a partir dos dados de pedidos carregam mais identificadores do que as visualizações de página, qual nota buscar e onde conferi-la.

O que a Event Match Quality mede?

O Meta calcula a nota a partir de duas coisas: a qualidade das informações do cliente que você envia com um evento de servidor e a parcela desses eventos que o Meta associa a uma conta. Um evento associado diz ao Meta qual pessoa comprou. O Meta pode então creditar a compra ao anúncio que essa pessoa viu ou clicou e mostrar os seus anúncios a pessoas com mais chance de comprar.

Alguns fatos da documentação do Meta moldam a forma como você lê a nota:

• Ela é por evento. Purchase, AddToCart e PageView recebem, cada um, a própria nota, tanto para eventos padrão quanto para personalizados.
• Ela cobre apenas eventos de servidor. A nota está disponível para eventos de site enviados pela Conversions API com action_source definido como website. Eventos enviados apenas pelo pixel do navegador não têm nota.
• Ela usa as últimas 48 horas. Envie eventos de forma contínua, ou a nota fica desatualizada.

O Meta também observa que uma associação melhor pode aumentar as conversões adicionais que ele informa para a sua configuração da Conversions API. Uma compra que o Meta não consegue associar é uma compra pela qual os seus anúncios não recebem crédito.

Quais parâmetros de informações do cliente aumentam a pontuação?

O Meta publica uma prioridade para cada tipo de informação do cliente. Envie todos os parâmetros que você tem para um evento, começando pelos de prioridade alta.

O endereço IP e o user agent não estão na lista de prioridades do Meta, mas a documentação para desenvolvedores do Meta diz que enviar client_ip_address e client_user_agent pode ajudar na associação. O user agent é exigido para eventos de site de qualquer forma. Os dois precisam ser os valores do comprador, não os do seu servidor.

Como aplicar hash e normalizar os dados do cliente?

O Meta exige que as informações de contato passem por hash SHA-256 antes de serem enviadas. O hash só funciona se todo sistema escreve o mesmo valor do mesmo jeito, então o Meta define uma forma normal para cada campo. Normalize primeiro e aplique o hash depois.

No código, o que importa é a ordem das etapas:

import { createHash } from 'node:crypto';
const sha256 = (s) => createHash('sha256').update(s).digest('hex');

// Normalize first, then hash.
const em = sha256(' Anna.Berg@Example.com '.trim().toLowerCase());
// hashes "anna.berg@example.com"

const ph = sha256('+1 (415) 555-0134'.replace(/\D/g, ''));
// hashes "14155550134"

const ct = sha256('San Francisco'.toLowerCase().replace(/[^a-z]/g, ''));
// hashes "sanfrancisco"

// Sent as they are, never hashed:
// fbp, fbc, client_ip_address, client_user_agent

Atenção com números de telefone que têm o zero do prefixo nacional. Um número holandês escrito como +31 (0)6 1234 5678 vira 310612345678 se você só remover os símbolos. A forma correta é 31612345678. Valores de preenchimento são outra armadilha: um e-mail como noemail@example.com que uma loja preenche em pedidos feitos como visitante é compartilhado por muitos clientes, então não identifica uma única pessoa. Deixe o campo de fora.

Por que os eventos de servidor a partir dos dados de pedidos carregam mais identificadores?

Uma visualização de página acontece antes de o visitante ter informado qualquer coisa. O navegador conhece um ID de cookie, talvez um ID de clique, um endereço IP e um user agent. Um pedido pago é diferente: o comprador digitou um endereço de e-mail, muitas vezes um telefone, um nome e um endereço.

É por isso que um evento Purchase enviado do seu servidor pode ter uma pontuação maior do que PageView ou ViewContent. Um evento de compra que vem apenas da página de agradecimento tem os identificadores do navegador, mas nem sempre o e-mail e o telefone do pedido.

Nem todo parâmetro consegue chegar a 100% dos eventos, e isso é normal. No exemplo abaixo, o ID de clique está em 38% das compras, porque só quem chegou por um clique em um anúncio do Meta tem um.

Qual é uma meta realista de Event Match Quality?

A documentação para desenvolvedores do Meta diz que costuma recomendar uma pontuação de 6.0 ou mais, sempre que possível. Trate isso como a meta para os eventos que carregam dados de contato, principalmente o Purchase. Um Purchase montado a partir dos dados do pedido traz o e-mail, um dos dois parâmetros de alta prioridade, e a maioria dos de média prioridade, então é o evento em que a meta é mais realista. Meça em vez de presumir: a pontuação também depende dos seus clientes.

Não espere a mesma pontuação em todos os eventos. PageView, ViewContent e AddToCart muitas vezes não têm dados de contato, porque a maioria dos visitantes é anônima até o checkout. Uma pontuação mais baixa neles é esperada e não é motivo para coletar e-mails antes do que os seus visitantes querem fornecer.

Também não persiga o 10. A pontuação depende ainda da proporção de eventos que o Meta consegue associar, e parte disso está fora do seu controle: alguns dos seus compradores não têm conta no Meta ou usaram outro e-mail nela. O consentimento também conta. No ROASaurus, com Respect visitor consent ativado, um visitante que recusa os cookies de marketing não tem ID de clique nem ID de visitante armazenado, então o pedido pago sai com os dados do pedido em hash e com o endereço IP e o user agent do pedido, mas sem fbc e fbp. Quanto mais recusas, menos identificadores por evento. Nossa página de ajuda sobre consentimento explica a configuração.

A pergunta útil não é se a sua pontuação é alta, mas se ela mudou. Compare cada evento com o próprio histórico depois de toda mudança no tema, no checkout ou no rastreamento.

Como conferir a Event Match Quality no Events Manager?

1. Abra o seu conjunto de dados

   Vá ao Events Manager e selecione o nome e o ID do seu pixel ou conjunto de dados.

2. Abra os detalhes do evento

   Encontre o evento, por exemplo Purchase, e clique em View details.

3. Leia a aba Event matching

   Ela mostra a pontuação, a proporção de eventos que trazem informações do cliente e dicas para melhorar a correspondência.

4. Confira o Diagnostics

   A aba Diagnostics do Events Manager lista problemas com os seus eventos e recomendações de como corrigi-los.

5. Confira de novo depois de dois dias

   A pontuação usa as últimas 48 horas de eventos, então uma correção só aparece por completo cerca de dois dias depois.

As outras abas da mesma página também ajudam. Event coverage compara os seus eventos de servidor com os eventos do pixel, Event deduplication mostra a proporção de eventos que trazem uma chave de deduplicação, como o ID do evento, e Data freshness mostra a rapidez com que os seus eventos de servidor chegam. Se você ainda está configurando o lado do servidor, comece pelo nosso guia da Conversions API do Meta.

Por que a minha Event Match Quality está baixa?

Quando um evento tem uma pontuação mais baixa do que você esperava, estas são as causas mais comuns:

• O servidor envia o próprio endereço IP. Se os eventos passam pelo seu servidor ou por um servidor de tags, ele precisa repassar o endereço IP e o user agent que registrou do comprador, não os dele.
• O fbclid se perde. O ID de clique só aparece na URL da página de entrada. Se nada o salva ali, ele já se perdeu quando chega o checkout. Mantenha-o exatamente como chega, porque ele diferencia maiúsculas de minúsculas.
• Os dados de contato passam por hash sem normalização, ou são enviados sem hash.
• Os identificadores do navegador passam por hash. Um fbp ou fbc com hash não consegue ser associado.
• As compras vêm só do navegador. Um evento da página de agradecimento muitas vezes não tem o e-mail e o telefone que o pedido tem. Enviar a compra a partir do pedido resolve isso.

Como o ROASaurus envia as informações do cliente

O ROASaurus monta o evento Purchase a partir do pedido na sua loja, então ele traz os dados de contato do pedido. E-mail, telefone, nome e sobrenome, cidade, estado, CEP e país são normalizados e passam por hash SHA-256. O ID de cliente da loja e o ID de visitante do ROASaurus entram com hash como external_id. O endereço IP, o user agent, a URL da página e o fbp são associados a partir da visita do comprador, e o fbc é montado a partir do fbclid que o script da loja salva quando o visitante chega.

Um evento sem fbc, fbp, e-mail, telefone ou endereço IP é descartado, porque o Meta não consegue associá-lo. A página de integração com o Meta lista todos os campos enviados, e o rastreamento server-side explica como os pedidos são associados ao clique no anúncio. Para acompanhar a pontuação, a página Tracking health lê todos os dias a Event Match Quality de cada pixel do Meta e emite um alerta quando a pontuação de Purchase cai abaixo do seu mínimo, 6.0 por padrão.

Fontes

1. Meta Business Help Center: About Event Match Quality
2. Meta for Developers: Customer Information Parameters
3. Meta for Developers: Verifying Your Setup
4. Meta Business Help Center: View server event details in Meta Events Manager
5. Meta for Developers: Best Practices - Conversions API

No ROASaurus

• Integração com o Meta
• Rastreamento server-side
• Ajuda: conectar o Meta

Continue lendo