Meta Event Match Quality: cómo subir tu puntuación

Event Match Quality (EMQ) es una puntuación sobre 10 que Meta da a cada evento del sitio web que envías a través de la Conversions API. Muestra lo bien que la información del cliente de ese evento permite vincularlo con una cuenta de Meta. La subes enviando más de los identificadores adecuados, con el formato y el hash que Meta espera.

Esta guía explica qué mide la puntuación, qué parámetros de información del cliente cuentan más, las reglas de hash y normalización, por qué las compras a partir de datos de pedido llevan más identificadores que las visualizaciones de página, qué puntuación buscar y dónde comprobarla.

¿Qué mide Event Match Quality?

Meta calcula la puntuación a partir de dos cosas: la calidad de la información del cliente que envías con un evento del servidor y la proporción de esos eventos que Meta vincula con una cuenta. Un evento vinculado le dice a Meta qué persona compró. Entonces Meta puede atribuir la compra al anuncio que esa persona vio o en el que hizo clic, y mostrar tus anuncios a personas con más probabilidades de comprar.

Algunos datos de la documentación de Meta determinan cómo interpretar la puntuación:

• Es por evento. Purchase, AddToCart y PageView reciben cada uno su propia puntuación, tanto en eventos estándar como personalizados.
• Solo cubre eventos del servidor. La puntuación está disponible para los eventos del sitio web enviados a través de la Conversions API con action_source establecido en website. Los eventos enviados solo por el píxel del navegador no tienen puntuación.
• Usa las últimas 48 horas. Envía eventos de forma constante, o la puntuación se queda obsoleta.

Meta señala también que una mejor vinculación puede aumentar las conversiones adicionales que informa para tu configuración de la Conversions API. Una compra que Meta no puede vincular es una compra por la que tus anuncios no reciben mérito.

¿Qué parámetros de información del cliente suben la puntuación?

Meta publica una prioridad para cada tipo de información del cliente. Envía todos los parámetros que tengas para un evento y empieza por los de prioridad alta.

La dirección IP y el user agent no están en la lista de prioridades de Meta, pero la documentación para desarrolladores de Meta dice que enviar client_ip_address y client_user_agent puede ayudar a la vinculación. El user agent es obligatorio de todos modos para los eventos del sitio web. Ambos deben ser los valores del comprador, no los de tu servidor.

¿Cómo se aplica el hash y se normalizan los datos del cliente?

Meta exige que la información de contacto lleve hash SHA-256 antes de enviarla. El hash solo funciona si todos los sistemas escriben el mismo valor de la misma manera, así que Meta define una forma normal para cada campo. Primero normaliza y luego aplica el hash.

En el código, lo que importa es el orden de los pasos:

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

Cuidado con los números de teléfono con un cero de troncal. Un número neerlandés escrito como +31 (0)6 1234 5678 se convierte en 310612345678 si solo quitas los símbolos. La forma correcta es 31612345678. Los valores de relleno son otra trampa: un email como noemail@example.com, que una tienda rellena en los pedidos de invitados, lo comparten muchos clientes, así que no identifica a una sola persona. Deja el campo sin enviar.

¿Por qué los eventos del servidor a partir de datos de pedido llevan más identificadores?

Una visualización de página ocurre antes de que el visitante te haya dado ningún dato. El navegador conoce un id de cookie, quizá un click id, una dirección IP y un user agent. Un pedido pagado es distinto: el comprador ha escrito una dirección de email, a menudo un teléfono, un nombre y una dirección.

Por eso un evento Purchase enviado desde tu servidor puede puntuar más que PageView o ViewContent. Un evento de compra que solo procede de la página de agradecimiento tiene los identificadores del navegador, pero no siempre el email y el teléfono del pedido.

No todos los parámetros pueden llegar al 100% de los eventos, y es normal. En el ejemplo de abajo, el click id está en el 38% de las compras, porque solo lo tienen los compradores que llegaron desde un clic en un anuncio de Meta.

¿Cuál es un objetivo realista de Event Match Quality?

La documentación para desarrolladores de Meta dice que, por lo general, recomienda una puntuación de 6.0 o superior, siempre que sea posible. Toma esa cifra como objetivo para los eventos que llevan datos de contacto, sobre todo Purchase. Un Purchase creado a partir de los datos del pedido lleva el email, uno de los dos parámetros de prioridad alta, y la mayoría de los de prioridad media, así que es el evento en el que el objetivo es más realista. Mídelo en lugar de darlo por hecho: la puntuación también depende de tus clientes.

No esperes la misma puntuación en todos los eventos. PageView, ViewContent y AddToCart suelen no tener datos de contacto, porque la mayoría de los visitantes son anónimos hasta el checkout. Allí se espera una puntuación más baja, y no es motivo para pedir las direcciones de email antes de lo que tus visitantes quieren darlas.

Tampoco persigas un 10. La puntuación también depende del porcentaje de eventos que Meta consigue vincular, y una parte de eso queda fuera de tu control: algunos de tus compradores no tienen cuenta de Meta o usaron otra dirección de email en ella. El consentimiento también cuenta. En ROASaurus, con Respect visitor consent activado, un visitante que rechaza las cookies de marketing no tiene click id ni id de visitante almacenados, así que el pedido pagado sale con los datos del pedido con hash y con la dirección IP y el user agent del pedido, pero sin fbc ni fbp. Cuantos más rechazos, menos identificadores por evento. Nuestra página de ayuda sobre consentimiento explica este ajuste.

La pregunta útil no es si tu puntuación es alta, sino si ha cambiado. Compara cada evento con su propio historial después de cada cambio en tu tema, tu checkout o tu tracking.

¿Cómo se comprueba Event Match Quality en Events Manager?

1. Abre tu conjunto de datos

   Ve a Events Manager y selecciona el nombre y el id de tu píxel o conjunto de datos.

2. Abre los detalles del evento

   Busca el evento, por ejemplo Purchase, y haz clic en View details.

3. Lee la pestaña Event matching

   Muestra la puntuación, el porcentaje de eventos que llevan información del cliente y consejos para mejorar la coincidencia.

4. Revisa Diagnostics

   La pestaña Diagnostics de Events Manager enumera los problemas de tus eventos y recomendaciones para solucionarlos.

5. Vuelve a comprobarlo a los dos días

   La puntuación usa las últimas 48 horas de eventos, así que una corrección se refleja por completo unos dos días después.

Las demás pestañas de la misma página también ayudan. Event coverage compara tus eventos del servidor con los eventos de tu píxel, Event deduplication muestra el porcentaje de eventos que llevan una clave de deduplicación, como el id de evento, y Data freshness muestra con qué rapidez llegan tus eventos del servidor. Si aún estás configurando la parte del servidor, empieza por nuestra guía de la Meta Conversions API.

¿Por qué es baja mi Event Match Quality?

Cuando un evento puntúa menos de lo que esperas, estas son las causas habituales:

• El servidor envía su propia dirección IP. Si los eventos pasan por tu servidor o por un servidor de etiquetas, este debe reenviar la dirección IP y el user agent que registró del comprador, no los suyos.
• Se pierde el fbclid. El click id solo está en la URL de la página de llegada. Si nada lo guarda ahí, se pierde antes del checkout. Consérvalo exactamente como llega, porque distingue entre mayúsculas y minúsculas.
• Se aplica el hash a los datos de contacto sin normalizarlos, o se envían sin hash.
• Se aplica el hash a los identificadores del navegador. Un fbp o un fbc con hash no puede vincularse.
• Las compras vienen solo del navegador. Un evento de la página de agradecimiento suele carecer del email y del teléfono que sí tiene el pedido. Enviar la compra desde el pedido lo soluciona.

Cómo envía ROASaurus la información del cliente

ROASaurus crea el evento Purchase a partir del pedido de tu tienda, así que lleva los datos de contacto del pedido. El email, el teléfono, el nombre y los apellidos, la ciudad, la provincia, el código postal y el país se normalizan y se les aplica un hash SHA-256. El id de cliente de la tienda y el id de visitante de ROASaurus entran con hash como external_id. La dirección IP, el user agent, la URL de la página y fbp se unen desde la visita del comprador, y fbc se construye a partir del fbclid que el script de la tienda guarda cuando el visitante llega.

Un evento sin fbc, fbp, email, teléfono ni dirección IP se omite, porque Meta no puede vincularlo. La página de la integración con Meta enumera todos los campos que se envían, y server-side tracking explica cómo se vinculan los pedidos con el clic en el anuncio. Para seguir la puntuación, la página Tracking health lee cada día la Event Match Quality de cada píxel de Meta y lanza una alerta cuando la puntuación de Purchase baja de tu mínimo, 6.0 por defecto.

Fuentes

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

En ROASaurus

• Integración con Meta
• Server-side tracking
• Ayuda: conectar Meta

Sigue leyendo