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

A Event Match Quality (EMQ) é uma pontuação em 10 que a Meta atribui a cada evento de website que envia através da Conversions API. Mostra em que medida a informação do cliente nesse evento permite associá-lo a uma conta da Meta. Aumenta-a ao enviar mais dos identificadores certos, formatados e com hash da forma que a Meta espera.

Este guia explica o que a pontuação mede, que parâmetros de informação do cliente contam mais, as regras de hash e de normalização, porque é que as compras a partir dos dados da encomenda trazem mais identificadores do que as visualizações de página, que pontuação procurar atingir e onde a verificar.

O que mede a Event Match Quality?

A Meta calcula a pontuação a partir de duas coisas: a qualidade da informação do cliente que envia com um evento do servidor e a percentagem desses eventos que a Meta associa a uma conta. Um evento associado diz à Meta que pessoa comprou. A Meta pode então atribuir a compra ao anúncio que essa pessoa viu ou em que clicou, e mostrar os seus anúncios a pessoas com maior probabilidade de comprar.

Alguns factos da documentação da Meta condicionam a forma como lê a pontuação:

• É por evento. O Purchase, o AddToCart e o PageView têm cada um a sua pontuação, tanto nos eventos padrão como nos personalizados.
• Abrange apenas eventos do servidor. A pontuação está disponível para eventos de website enviados através da Conversions API com action_source definido como website. Os eventos enviados apenas pelo pixel do navegador não têm pontuação.
• Usa as últimas 48 horas. Envie eventos de forma regular, ou a pontuação fica desatualizada.

A Meta refere também que uma melhor associação pode aumentar as conversões adicionais que reporta para a sua configuração da Conversions API. Uma compra que a Meta não consegue associar é uma compra pela qual os seus anúncios não recebem mérito.

Que parâmetros de informação do cliente aumentam a pontuação?

A Meta publica uma prioridade para cada tipo de informação do cliente. Envie todos os parâmetros que tiver para um evento e comece pelos de prioridade alta.

O endereço IP e o user agent não constam da lista de prioridades da Meta, mas a documentação para programadores da Meta diz que enviar client_ip_address e client_user_agent pode ajudar na associação. O user agent é, de qualquer forma, obrigatório nos eventos de website. Ambos têm de ser os valores do comprador, não os do seu servidor.

Como se aplica hash e se normalizam os dados do cliente?

A Meta exige que os dados de contacto tenham hash SHA-256 antes de serem enviados. O hash só funciona se todos os sistemas escreverem o mesmo valor da mesma forma, por isso a Meta define uma forma normal para cada campo. Primeiro normalize, depois aplique o hash.

Em código, o que importa é a ordem dos passos:

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 aos números de telefone com o zero do prefixo nacional. Um número neerlandês escrito como +31 (0)6 1234 5678 passa a 310612345678 se retirar apenas os símbolos. A forma correta é 31612345678. Os valores de preenchimento são outra armadilha: um email como noemail@example.com, que uma loja preenche nas encomendas de convidados, é partilhado por muitos clientes, por isso não identifica uma só pessoa. Deixe antes o campo de fora.

Porque é que os eventos do servidor criados a partir dos dados da encomenda trazem mais identificadores?

Uma visualização de página acontece antes de o visitante ter dito alguma coisa. O navegador conhece um ID de cookie, talvez um ID de clique, um endereço IP e um user agent. Uma encomenda paga é diferente: o comprador escreveu um endereço de email, muitas vezes um número de telefone, um nome e uma morada.

É por isso que um evento Purchase enviado a partir do seu servidor pode ter uma pontuação mais alta 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 email e o telefone da encomenda.

Nem todos os parâmetros conseguem chegar a 100% dos eventos, e isso é normal. No exemplo abaixo, o ID de clique está em 38% das compras, porque só os compradores que chegaram através de um clique num anúncio da Meta o têm.

Qual é um objetivo realista de Event Match Quality?

A documentação para programadores da Meta indica que, em regra, recomenda uma pontuação de 6.0 ou superior, sempre que possível. Encare-a como a meta para os eventos que trazem dados de contacto, sobretudo o Purchase. Um Purchase criado a partir dos dados da encomenda traz o email, um dos dois parâmetros de prioridade alta, e a maioria dos de prioridade média, por isso é o evento em que a meta é mais realista. Meça-a em vez de a assumir: a pontuação depende também dos seus clientes.

Não espere a mesma pontuação em todos os eventos. O PageView, o ViewContent e o AddToCart muitas vezes não têm dados de contacto, porque a maioria dos visitantes é anónima até ao checkout. Uma pontuação mais baixa nesses eventos é esperada e não é motivo para recolher endereços de email mais cedo do que os seus visitantes querem dá-los.

Também não persiga um 10. A pontuação depende ainda da percentagem de eventos que a Meta consegue associar, e parte disso está fora do seu controlo: alguns dos seus compradores não têm conta na Meta ou usaram nela outro endereço de email. O consentimento também conta. Na ROASaurus, com Respect visitor consent ativado, um visitante que recuse os cookies de marketing não tem ID de clique nem ID de visitante guardados, por isso a encomenda paga sai com os dados da encomenda com hash e com o endereço IP e o user agent da encomenda, mas sem fbc e fbp. Quanto mais recusas, menos identificadores por evento. A nossa página de ajuda sobre consentimento explica a opção.

A pergunta útil não é se a sua pontuação é alta, mas se mudou. Compare cada evento com o seu próprio histórico depois de cada alteração ao tema, ao checkout ou ao tracking.

Como verificar a Event Match Quality no Events Manager?

1. Abra o seu dataset

   Vá ao Events Manager e selecione o nome e o ID do seu pixel ou dataset.

2. Abra os detalhes do evento

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

3. Leia o separador Event matching

   Mostra a pontuação, a percentagem de eventos que trazem informação do cliente e sugestões para melhorar a correspondência.

4. Verifique o Diagnostics

   O separador Diagnostics no Events Manager lista os problemas dos seus eventos e recomendações para os corrigir.

5. Volte a verificar passados dois dias

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

Os outros separadores da mesma página também ajudam. O separador Event coverage compara os seus eventos do servidor com os eventos do pixel, o Event deduplication mostra a percentagem de eventos que trazem uma chave de eliminação de duplicados, como o ID de evento, e o Data freshness mostra a rapidez com que os seus eventos do servidor chegam. Se ainda está a configurar o lado do servidor, comece pelo nosso guia da Conversions API da Meta.

Porque é que a minha Event Match Quality está baixa?

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

• O servidor envia o seu próprio endereço IP. Se os eventos passam pelo seu servidor ou por um servidor de tags, este tem de reencaminhar o endereço IP e o user agent que registou do comprador, não os seus.
• O fbclid perde-se. O ID de clique só está no URL da página de entrada. Se nada o guardar aí, já se perdeu quando chega ao checkout. Mantenha-o exatamente como chega, porque distingue maiúsculas de minúsculas.
• Os dados de contacto recebem hash sem serem normalizados, ou são enviados sem hash.
• Os identificadores do navegador recebem hash. Um fbp ou fbc com hash não pode ser associado.
• As compras vêm apenas do navegador. Um evento da página de agradecimento muitas vezes não tem o email e o telefone que a encomenda tem. Enviar a compra a partir da encomenda resolve isso.

Como a ROASaurus envia a informação do cliente

A ROASaurus cria o evento Purchase a partir da encomenda na sua loja, por isso ele traz os dados de contacto da encomenda. O email, o telefone, o nome próprio e o apelido, a cidade, o estado, o código postal e o país são normalizados e recebem hash SHA-256. O ID de cliente da loja e o ID de visitante da ROASaurus seguem com hash como external_id. O endereço IP, o user agent, o URL da página e o fbp são associados a partir da visita do comprador, e o fbc é criado a partir do fbclid que o script da loja guarda quando o visitante chega.

Um evento sem fbc, fbp, email, telefone nem endereço IP é ignorado, porque a Meta não o consegue associar. A página da integração com a Meta lista todos os campos que são enviados, e o tracking server-side explica como as encomendas são associadas 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 da Meta e emite um alerta quando a pontuação de Purchase desce abaixo do seu mínimo, 6.0 por predefiniçã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

Na ROASaurus

• Integração com a Meta
• Tracking server-side
• Ajuda: ligar a Meta

Continue a ler