Event Match Quality (EMQ) is Meta’s score, out of 10, for how well the customer information on your Conversions API web events can match each event to a Meta account. Meta recommends aiming for 6.0 or higher. Lead gen starts ahead: the form collects the email and the ad click carries the click ID, the two identifiers Meta ranks highest.
The score matters because of what Meta does with an event it can’t match. Its Conversions API best practices put it plainly: only matched events can be used for ads attribution and ad delivery optimisation, and unmatched events stay useful for basic measurement only. A Lead that doesn’t match is a lead the delivery system never learns from.
What is Event Match Quality?
Meta’s help center article about Event Match Quality sets out the mechanics. The score runs from 0 to 10 and combines two things: the quality of the customer information you send with a specific server event, and the share of those events Meta matched to an account. It’s available for website events sent through the Conversions API with action_source set to website, standard or custom, and it’s calculated on the last 48 hours of data.
Three consequences that get missed:
- Every event has its own score. A weak PageView tells you nothing about your Lead, and the Lead is the event your campaigns optimise for.
- The window is short and rolling. After a fix, you need up to 48 hours of fresh events before the score reflects it. An event that fires a few times a day moves slowly.
- It describes server events. Meta’s breakdowns of server event details are built for Conversions API website events and may not be available for events sent through the Meta Pixel.
Does the Meta Pixel get an Event Match Quality score?
Not on its own. The pixel can send the same customer information through advanced matching (Meta’s EMQ article lists the parameters as shareable from the Meta Pixel or the Conversions API), and that helps matching. The number you read in Events Manager, though, belongs to your server events. A pixel-only setup has no EMQ to read, which is one more reason to send the Lead from the server.
What is a good Event Match Quality score?
Meta’s target is in its developer guide to verifying a setup: “Where possible, we typically recommend that you aim for an Event Match Quality score of 6.0 or higher.”
You’ll find blog posts with tidy bands (Poor, OK, Good, Great), each with its own cut-offs. They don’t agree with each other, and Meta’s EMQ documentation doesn’t define them. Treat 6.0 as the floor Meta asks for and ignore thresholds someone else invented.
The better question is asked per event: am I sending everything I legitimately collect? Meta warns that sending a parameter doesn’t guarantee a match. One parameter alone may not be enough, or the person may not have a Meta account, so a high share of events carrying data can still come with a low score. On leads from your own Meta ads the visitor clicked one of your ads, so a missing account is an unlikely explanation. The email typed into a form isn’t always the one on the person’s Meta account, though, which is why the phone and the click ID are worth sending next to it.
Which parameters count toward the score?
Meta ranks the parameters in the same EMQ article:
| Priority | Parameters, as Meta labels them |
|---|---|
| High | Email, Click ID |
| Medium | Facebook Login ID, Birthdate, Country, Phone number, External ID, Browser ID |
| Low | Lead, First name, Last name, City, Zip or Postal Code |
Here’s the same list read from a lead-gen landing page: the Conversions API key, where you get the value, and whether it gets hashed. The hashing rules come from Meta’s reference of customer information parameters.
Parameter (user_data key) | Meta priority | Where a lead-gen landing page gets it | Hashed? |
|---|---|---|---|
Email (em) | High | the form’s email field | yes, SHA-256 after trimming and lowercasing |
Click ID (fbc) | High | the _fbc cookie, or built on your server from the fbclid in the landing page URL | no |
Phone (ph) | Medium | the form’s phone field | yes, SHA-256 of digits only, country code included |
External ID (external_id) | Medium | your own ID for the lead or the click | recommended |
Browser ID (fbp) | Medium | the _fbp cookie set by the Meta Pixel | no |
Country (country) | Medium | a form field, or the country code of the phone number | yes, lowercase two-letter ISO code (it) |
First and last name (fn, ln) | Low | the form’s name fields | yes, lowercase, no punctuation |
City, zip (ct, zp) | Low | only if the form asks for them | yes |
Birthdate (db) | Medium | rarely on a lead form, and not worth a new field | yes, YYYYMMDD |
Facebook Login ID (fb_login_id) | Medium | only if visitors log in with Facebook | no |
Lead ID (lead_id) | Low (listed as “Lead”) | only for Instant Forms leads | no |
IP address (client_ip_address) | not ranked | the request that submits the form | never |
User agent (client_user_agent) | not ranked, required for website events | the same request’s headers | never |
The last two rows aren’t in Meta’s priority list. Don’t read that as optional: client_user_agent is required for website events sent through the Conversions API, and the developer best practices name the IP address among the high-quality parameters. Both are also free, because your server already has them in the request.
Add it up and a form with email and phone, plus the click ID from the URL and your own external ID, covers both High parameters and two Medium ones. A PageView can’t, because nobody has typed anything yet.
How to normalise and hash customer information
Meta’s systems are designed not to accept unhashed contact information such as names, email addresses and phone numbers. Normalise first, then hash with SHA-256. Meta’s reference shows the expected SHA-256 output for its examples, so you can test your own code against them.
Example values, normalised:
| Field | Raw input | Normalised | Rule |
|---|---|---|---|
[email protected] | [email protected] | trim spaces, lowercase | |
| Phone | +39 347 123 4567 | 393471234567 | digits only, country code, no leading zeros |
| Country | Italy | it | lowercase ISO 3166-1 alpha-2 |
| First name | Mario | mario | lowercase, no punctuation |
The same in Node.js, with the resulting hashes:
import { createHash } from "node:crypto";
const sha256 = (value) => createHash("sha256").update(value).digest("hex");
sha256(" [email protected] ".trim().toLowerCase());
// 10928b45363b7d849e040470c3277657f8177ef5a953a092b4302f149757a02e
sha256("+39 347 123 4567".replace(/\D/g, "").replace(/^0+/, ""));
// 75565655f639ba28fbb0a88254e0d01fad0a351049bde96a286e336219a33e5fWhere it goes wrong in practice:
- No country code. Meta wants it on every number, “even if all of your data is from the same country”. If your form accepts
347 123 4567, add39before hashing. Without the prefix it’s a different string, so a different hash. - Hashing twice, or hashing the wrong fields. A double-hashed email is a valid-looking string that matches nobody.
fbc,fbp, the IP address and the user agent are never hashed. - Placeholders. If the phone field is optional and empty, leave
phout. A dummy number or a default email is worse than nothing, and Meta now flags it (see the diagnostics below).
How to improve Event Match Quality on lead events
Start with what you already collect. In order:
- Send the Lead from your server, with the form data. The score is calculated on Conversions API events, so that’s where the gains happen; server-side tracking is the general pattern. Hash
emandphas above. - Capture
fbcandfbpfrom the landing page visit. Thefbclidis in the URL when the visitor arrives. If there’s no_fbccookie, buildfbcon the server and keep it with the click; read_fbpfrom the cookie when the form is submitted. Format and code are in _fbc and _fbp cookies, explained. - Pass the visitor’s real IP and user agent. Take both from the request that submits the form, never your own server’s or proxy’s address. If your landing page domain only answers over IPv4, add IPv6 support.
- Add an
external_id. Your own lead or click ID, hashed. If the pixel sends one too, use the same format on both sides. - Leave empty fields out instead of filling them with defaults.
- Wait 48 hours, then read the score of the Lead event specifically.
DropCPL sends the Lead event to Meta from the server, with an event_id for deduplication plus fbc and fbp. Your CPL is still computed on the leads your server received, per creative and per landing page. Start free →
Where to find the score in Events Manager
The steps, from the same Meta article on server event details:
- Open Events Manager and select your dataset (the pixel) by name and ID.
- Find the event, Lead for instance, and click View details.
- Open the Event Matching tab (Meta’s article also calls it Event Quality).
There you’ll find the score, the share of events carrying each customer information parameter, and Meta’s recommendations. The neighbouring tabs cover Event Coverage, Event Deduplication and Data Freshness. Deduplication has its own guide: Meta Pixel and CAPI deduplication.
Why is my EMQ score low?
Meta’s Dataset Quality API reports EMQ diagnostics per match key, and in September 2026 Meta added six issue types to them. Together with the mismatched-IP warning, they map neatly onto lead-gen mistakes:
| Diagnostic | What Meta says | Usual cause on a lead-gen setup |
|---|---|---|
| Empty IP | events are sent with no client_ip_address | the server never copies the visitor’s IP into the event |
| Server sending mismatched IP addresses | server IPs don’t match those from the Meta Pixel | your own server’s or proxy’s address sent instead of the visitor’s |
| Relay IP | the IP belongs to a privacy relay rather than the customer | visitors browsing through a relay; make sure the rest of the event is complete |
| IPv4 | IPv4 sent where IPv6 is available and would match better | a landing page domain reachable over IPv4 only; Meta’s suggested fix is IPv6 support on your web server and DNS |
| FBC coverage | fbc is present on too small a share of events | fbc taken only from the pixel’s cookie, never built from fbclid |
| Email placeholder | many events share the same placeholder email | a default value filled in when the field is empty |
| Phone placeholder | many events share the same placeholder phone number | the same, on the phone field |
A wrongly normalised value won’t show up in any of these: its hash is a valid-looking string that simply doesn’t match. Test a few values against the expected outputs in Meta’s reference before blaming your audience.
What the score doesn’t tell you
EMQ measures whether Meta can recognise the person behind an event. It says nothing about whether the lead was any good, and a perfect score wouldn’t make Meta’s reported lead count equal to the leads you received. Keep sending Meta a well-matched, deduplicated Lead, and keep making budget decisions on your own count. That’s the argument of real CPL vs platform CPL, and the reason first-party tracking logs the click on your own domain.