Event match quality: what Meta's EMQ score means

You can have the Conversions API running, events flowing, and still hand Meta a signal it cannot use. If a purchase event arrives without enough information to tie it to a real person, Meta cannot attribute it to an ad or learn from it. Event match quality (EMQ) is the score that tells you how often that is happening.

Here is what the score measures, which parameters move it, how hashing and the browser IDs fit in, and how to find the actual problem in Events Manager.

What event match quality measures

Event match quality is a score from 0 to 10 that Meta shows for events sent through the Conversions API. Per Meta's documentation, it reflects three things:

1. Which customer information parameters your server sends with the event.
2. The quality of that information: whether it is formatted and hashed correctly.
3. The share of events that Meta successfully matches to a Meta account.

The score is per event, per dataset. Your Purchase event can score well while PageView scores poorly, and that is often fine. Events Manager groups scores into labels (Poor, OK, Good, Great), and the label is more useful than chasing a decimal.

A higher score means more of your conversions can be connected to the people who saw or clicked your ads. That improves attribution, which shapes what Ads Manager reports, and optimization, which shapes who Meta shows your ads to next.

What a good score looks like

There is no official universal target, and it depends on the event. Practitioners generally treat these as reasonable expectations:

The point of this table: a low score on an event where the visitor is anonymous is expected. A low score on Purchase, where you literally have their email, means something is broken.

Parameters that raise the score

Meta calls these customer information parameters, sent in the user_data object. They fall into two groups.

Hashed parameters

These must be normalized, then hashed with SHA-256 before sending:

• Email (em): trim whitespace, lowercase.
• Phone (ph): digits only, including the country code (a US number starts with 1).
• First and last name (fn, ln): lowercase, no punctuation.
• City (ct), state (st), zip (zp), country (country): lowercase; US states as two-letter codes; US zip as the first 5 digits; country as a two-letter ISO code such as us.
• Date of birth (db) and gender (ge): if you genuinely collect them.
• External ID (external_id): your own customer or user ID. Hashing is recommended, not required. Use the same value consistently across pixel and server.

Parameters that must not be hashed

• fbp: the browser ID from the _fbp cookie, set by the pixel.
• fbc: the click ID from the _fbc cookie, or built from the fbclid URL parameter when someone arrives from an ad.
• client_ip_address: the visitor's IP, IPv4 or IPv6.
• client_user_agent: the visitor's browser user agent string.

In practice, email and the click ID tend to do the most work, because email is the identifier people most reliably use across devices and fbc ties the event to the exact ad click. Phone and external ID add coverage on top.

Getting fbp and fbc right

These two are where most setups leak. The server does not see browser cookies unless your code reads them from the incoming request and forwards them.

1. Read _fbp and _fbc from the request cookies on the page or checkout request that triggers the event, and pass them as fbp and fbc.
2. If _fbc is missing but the URL has fbclid, construct fbc in Meta's documented format (fb.1.<timestamp>.<fbclid>). Do not alter the fbclid value itself.
3. Persist them through checkout. If checkout lives on another domain or a hosted payment page, the cookies may not survive. Store them with the cart or order so the server purchase event can include them.
4. Capture the visitor's IP and user agent from their request, not your server's. A proxy or CDN in front of your app may put the real IP in a forwarded header; use that.

The IP detail has a known trap: if the browser reports an IPv6 address and your server sends IPv4 (or the reverse), Meta flags a mismatch. Meta's own diagnostics call this out specifically.

Diagnosing low scores in Events Manager

Open Events Manager, select your dataset, and go to the event you care about. What to look at:

1. Event match quality on the event's details: the score, plus the list of customer information parameters Meta is receiving and what share of events include each one.
2. Diagnostics tab: Meta flags specific integration problems here, such as badly formatted phone numbers, unhashed emails, or IP mismatches, with affected event counts.
3. Event coverage: how many of your pixel events also arrive through the Conversions API with matching deduplication keys. Low coverage means the server is missing events.
4. Additional conversions reported: Meta's estimate of the conversions your Conversions API setup adds, and how much more a given parameter could add.
5. Test events: send a test event with a test code and inspect the payload Meta received, parameter by parameter.

Then work down this list:

• Parameter missing entirely. The data exists in your system but the integration is not sending it. Fix the mapping.
• Parameter present on few events. Often a logged-in versus guest split, or an event that fires before the email is captured. Move the event later or attach the data where you have it.
• Formatting errors. Phone numbers without country codes and emails with capitals or spaces before hashing are the classics. Normalize first, then hash.
• Double hashing. Some partner integrations hash for you. If you hash again, the value no longer matches anything.

After a fix, scores update over the following days, not instantly. Resist changing several things at once, or you will not know which one helped. And keep perspective: better matching helps the system learn, but it will not rescue an ad set starved of budget. Check the learning phase math and the attribution settings you judge results on as well.

Frequently asked questions

What is a good event match quality score?

For events where you collect customer details, such as Purchase and Lead, aim for Meta's Good or Great labels. For top-of-funnel events like PageView and ViewContent, where visitors are usually anonymous, OK is normal and not a sign of a broken setup.

Why is my event match quality low?

The usual causes are missing customer information parameters (especially email, phone, and fbc), parameters formatted incorrectly before hashing, double hashing, and sending your server's IP address instead of the visitor's. The Diagnostics tab in Events Manager names the specific problem.

Does event match quality apply to the Meta pixel?

The score is shown for events sent through the Conversions API. Pixel events can carry customer information through advanced matching, which also helps Meta match events, but EMQ in Events Manager is reported on your server events.

Should fbp and fbc be hashed?

No. fbp, fbc, client_ip_address, and client_user_agent must be sent unhashed. Email, phone, names, and address fields must be normalized and SHA-256 hashed.

---

Once your signal is clean, results depend on the creative you feed it. upload.ad gives your team one library for creatives, reviews, and launches, and sends approved work straight into Meta and TikTok. Start free.