Meta Event Match Quality: how to raise your score

Event Match Quality (EMQ) is a score out of 10 that Meta gives each website event you send through the Conversions API. It shows how well the customer information on that event can match it to a Meta account. You raise it by sending more of the right identifiers, formatted and hashed the way Meta expects.

This guide explains what the score measures, which customer information parameters count most, the hashing and normalization rules, why purchases from order data carry more identifiers than page views, what score to aim for, and where to check it.

What does Event Match Quality measure?

Meta calculates the score from two things: the quality of the customer information you send with a server event, and the share of those events that Meta matches to an account. A matched event tells Meta which person bought. Meta can then credit the purchase to the ad that person saw or clicked, and show your ads to people who are more likely to buy.

A few facts from Meta's documentation shape how you read the score:

• It is per event. Purchase, AddToCart and PageView each get their own score, for standard and custom events alike.
• It covers server events only. The score is available for website events sent through the Conversions API with action_source set to website. Events sent only by the browser pixel have no score.
• It uses the last 48 hours. Send events steadily, or the score goes stale.

Meta also notes that better matching may increase the additional conversions it reports for your Conversions API setup. A purchase that Meta cannot match is a purchase your ads do not get credit for.

Which customer information parameters raise the score?

Meta publishes a priority for each type of customer information. Send every parameter you have for an event, and start with the high-priority ones.

The IP address and the user agent are not in Meta's priority list, but Meta's developer documentation says that sending client_ip_address and client_user_agent may help matching. The user agent is required for website events anyway. Both must be the shopper's values, not the ones of your server.

How do you hash and normalize customer data?

Meta requires contact information to be hashed with SHA-256 before you send it. Hashing only works if every system writes the same value in the same way, so Meta defines a normal form for each field. Normalize first, then hash.

In code, the order of the steps is what matters:

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

Watch out for phone numbers with a trunk zero. A Dutch number written as +31 (0)6 1234 5678 becomes 310612345678 if you only strip the symbols. The correct form is 31612345678. Placeholder values are another trap: an email such as noemail@example.com that a shop fills in for guest orders is shared by many customers, so it cannot identify one person. Leave the field out instead.

Why do server events from order data carry more identifiers?

A page view happens before the visitor has told you anything. The browser knows a cookie id, perhaps a click id, an IP address and a user agent. A paid order is different: the shopper has typed in an email address, often a phone number, a name and an address.

That is why a Purchase event sent from your server can score higher than PageView or ViewContent. A purchase event that only comes from the thank-you page has the browser identifiers, but not always the email and phone from the order.

Not every parameter can reach 100% of events, and that is normal. In the example below, the click id is on 38% of purchases, because only buyers who arrived from a Meta ad click have one.

What is a realistic Event Match Quality target?

Meta's developer documentation says it typically recommends a score of 6.0 or higher, where possible. Treat that as the target for the events that carry contact data, above all Purchase. A Purchase built from order data carries email, one of the two high-priority parameters, and most of the medium-priority ones, so it is the event where the target is most realistic. Measure it rather than assume it: the score also depends on your customers.

Do not expect the same score on every event. PageView, ViewContent and AddToCart often have no contact data, because most visitors are anonymous until checkout. A lower score there is expected, and it is not a reason to collect email addresses earlier than your visitors want to give them.

Do not chase a 10 either. The score also depends on the share of events that Meta matches, and part of that is outside your control: some of your buyers have no Meta account, or used a different email address there. Consent matters too. In ROASaurus, with Respect visitor consent on, a visitor who declines marketing cookies has no stored click id or visitor id, so the paid order goes out with hashed order data and the order's IP address and user agent, but without fbc and fbp. More declines mean fewer identifiers per event. Our help page on consent explains the setting.

The useful question is not whether your score is high, but whether it changed. Compare each event with its own history after every change to your theme, checkout or tracking.

How do you check Event Match Quality in Events Manager?

1. Open your dataset

   Go to Events Manager and select the name and id of your pixel or dataset.

2. Open the event details

   Find the event, for example Purchase, and click View details.

3. Read the Event matching tab

   It shows the score, the share of events that carry customer information, and tips to improve matching.

4. Check Diagnostics

   The Diagnostics tab in Events Manager lists issues with your events and recommendations on how to fix them.

5. Recheck after two days

   The score uses the last 48 hours of events, so a fix shows up fully about two days later.

The other tabs on the same page help too. Event coverage compares your server events with your pixel events, Event deduplication shows the share of events that carry a deduplication key such as the event id, and Data freshness shows how quickly your server events arrive. If you are still setting up the server side, start with our Meta Conversions API guide.

Why is my Event Match Quality low?

When one event scores lower than you expect, these are the usual causes:

• The server sends its own IP address. If events pass through your server or a tag server, it must forward the IP address and user agent it recorded from the shopper, not its own.
• The fbclid is lost. The click id is only in the URL of the landing page. If nothing saves it there, it is gone by checkout. Keep it exactly as it arrives, because it is case sensitive.
• Contact data is hashed without normalizing, or sent unhashed.
• The browser identifiers are hashed. A hashed fbp or fbc cannot be matched.
• Purchases come only from the browser. A thank-you page event often lacks the email and phone that the order has. Sending the purchase from the order fixes that.

How ROASaurus sends customer information

ROASaurus builds the Purchase event from the order in your shop, so it carries the order's contact data. Email, phone, first and last name, city, state, zip and country are normalized and hashed with SHA-256. The shop's customer id and the ROASaurus visitor id go in hashed as external_id. The IP address, user agent, page URL and fbp are joined from the shopper's visit, and fbc is built from the fbclid that the storefront script saves when the visitor lands.

An event with no fbc, fbp, email, phone or IP address is skipped, because Meta cannot match it. The Meta integration page lists every field that is sent, and server-side tracking explains how orders are matched to the ad click. To follow the score, the Tracking health page reads each Meta pixel's Event Match Quality every day and raises an alert when the Purchase score falls below your minimum, 6.0 by default.

Sources

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

In ROASaurus

• Meta integration
• Server-side tracking
• Help: connect Meta

Keep reading