You open Events Manager, click your Lead or Purchase event, and see something like this next to it:
Event Match Quality: 4.1 out of 10 (OK)
Then you search what to do about it and find ten articles that each give you a different target, a different "points per parameter" table and a different tool to buy.
This guide sticks to what Meta actually documents, and it says clearly when a number comes from a vendor instead. That matters, because most of the confident numbers you'll find about Event Match Quality (EMQ) don't come from Meta at all.
The short answer
| Question | Answer |
|---|---|
| What is Event Match Quality? | A score from 0 to 10 that Meta gives each event (Lead, Purchase, Schedule and so on). It shows how well the customer details sent with that event let Meta match it to a real Facebook or Instagram account. |
| Where do I see it? | Events Manager, then Data sources, then your dataset (pixel), then the event. Each event name has its own score. |
| What does Meta call the score bands? | Poor, OK, Good and Great. |
| Is there an official target, like 6 or 8? | Meta doesn't publish one. "Aim for 6+" is a vendor rule of thumb, not a Meta requirement. |
| What raises it most? | Sending more correctly formatted customer details with each server event: email, phone, name, city, state, zip, country, your own customer ID, plus the click ID (fbc), browser ID (fbp), IP address and user agent. |
| What's the most common mistake? | Details that are hashed but not normalised first, for example an email with a capital letter or a phone number without the country code. The hash then never matches anyone. |
| Does a high score mean my tracking is right? | No. You can have a high score and still double count conversions if deduplication is broken. EMQ measures matching, not accuracy. |
What Event Match Quality actually measures
When your website, CRM or server sends an event to Meta through the Conversions API, it can attach customer information: the person's email, phone number, name, location and so on. Meta uses those details to work out which account the event belongs to.
Event Match Quality is Meta's grade for how useful those details are for that matching. A Lead event sent with only an IP address and a browser string is hard to match. A Lead event sent with a hashed email, a hashed phone number with country code, a name, a city and the Meta click ID is easy to match.
Three things follow from that:
- The score is per event, not per pixel. Your Purchase event can be Great while your PageView event is Poor. That's normal. A page view rarely knows who the visitor is.
- The score is about the details you send, not about your ads. It doesn't measure creative, targeting or attribution.
- Matched events are what Meta can learn from. An event Meta can't match to a person can't teach the delivery system much about who converts. That's why a low score on your optimisation event (Lead, Purchase) is worth fixing, and a low score on PageView usually isn't.
The four labels and the numbers people quote
Meta shows each score with one of four labels: Poor, OK, Good or Great.
Here's where you need to be careful. You'll see exact cutoffs online, such as "Poor is below 4" or "Poor is 0 to 2.9". Different sites give different cutoffs, and none of them link to a Meta page that states them. Treat the label in your own Events Manager as the answer and ignore any cutoff table.
The same goes for these common claims:
| Claim you'll see | Where it comes from |
|---|---|
| "Meta recommends an EMQ of 6 or higher" | Vendor and agency guides. Meta's own EMQ page doesn't set a target. |
| "Adding email adds about 4 points" | Vendor blogs. No Meta source. |
| "An EMQ of 8 means 80% of your buyers are matched" | Vendor estimate. The score is not a percentage, and different vendors map it differently. |
| "Server-side tracking gets you 15 to 30% more data" | A single vendor's customer case study. |
None of these are necessarily wrong for the accounts they came from. They just aren't Meta's numbers, and you shouldn't plan a project around them.
The one benchmark Meta does push in the product is about a different metric, event coverage. Meta's in-app prompts ask advertisers to bring the share of browser events that are also sent through the Conversions API up to 75%. More on that below.
Where to find your score
- Open Events Manager (business.facebook.com/events_manager).
- Choose Data sources and select your dataset. Older accounts call it a pixel.
- On the Overview tab, click an event, for example Lead.
- Open the event details. You'll see the Event Match Quality score, its label, and which customer information parameters Meta is receiving for that event and how often.
That last list is the useful part. It tells you, for example, that email is arriving on 95% of your Lead events but phone only on 20%. That's your to-do list.
Scores don't move the moment you change something. Give it several days of normal traffic after a fix before you judge it.
The customer details Meta can use, and how to format them
This is the part most guides skip. Meta's Conversions API documentation lists the customer information parameters and how each must be formatted. If you get the format wrong, the parameter still arrives, still counts as "sent", and still matches nobody.
Hash these with SHA-256, after normalising them:
| Parameter | What it is | How to format it before hashing |
|---|---|---|
| em | Trim spaces, make it all lowercase. | |
| ph | Phone | Digits only, with country code, no leading zeros, no plus sign or spaces. A US number looks like 16505551212. |
| fn | First name | Lowercase, no punctuation. |
| ln | Last name | Lowercase, no punctuation. |
| db | Date of birth | YYYYMMDD, for example 19970216. |
| ge | Gender | One lowercase letter: f or m. |
| ct | City | Lowercase, no spaces or punctuation. |
| st | State | For the US, the two-letter code in lowercase, for example ca. |
| zp | Zip or postal code | Lowercase, no spaces or dashes. For the US, the first five digits only. |
| country | Country | The two-letter ISO code in lowercase, for example us or gb. |
| external_id | Your own customer or lead ID | Any stable ID you assign. Hashing is recommended. |
Send these as they are, without hashing:
| Parameter | What it is |
|---|---|
| client_ip_address | The visitor's real IP address. |
| client_user_agent | The visitor's browser string. |
| fbc | The Meta click ID cookie, set when someone arrives from a Meta ad. |
| fbp | The Meta browser ID cookie. |
| lead_id | The ID Meta gives a lead from a lead form. |
Two rules from Meta's documentation are easy to miss:
- Always include country, even if all your customers are in one country.
- Server events need the IP address and user agent added by you. The browser pixel adds them automatically. Your server doesn't know them unless you pass them along from the visitor's request.
What fbc and fbp look like
Both cookies follow the same pattern: fb.1.1712345678901.AbCdEf...
- The first number after "fb." is the domain level the cookie was set on.
- The long number is the time it was created, in milliseconds.
- The last part is the ad click ID (fbclid) for fbc, or a random number for fbp.
If someone lands on your site with ?fbclid=... in the URL and you don't have the cookie, you can build fbc yourself in that format from the URL value. Don't change the fbclid itself: Meta uses it as it was sent.
Why your score is low: the usual causes
In rough order of how often they cause it:
- Server events with no personal details at all. Only IP, user agent and cookies. Common when a plugin sends server events for page views and add to cart, where nobody has typed an email yet. Expected for those events. A problem for Lead or Purchase.
- Hashing without normalising. "John@Example.com " and "john@example.com" produce completely different hashes. So does a phone number with and without the country code.
- The cookies never reach the server. The pixel sets
_fbcand_fbpin the browser, but the form or checkout that sends the server event doesn't read them and pass them on. - Missing IP and user agent on server events. See above.
- Only half the details are sent. The form asks for name, email, phone and zip, but the integration only forwards email.
- Expired click IDs. An fbc value from months ago will trigger warnings and match poorly. Refresh it when a new fbclid arrives.
- Third-party lead sources. If leads come from an affiliate or partner and you never see the person's details, there's a ceiling on how high the score can go. That's structural, not a bug.
How to raise it, step by step
- Pick the event that matters. Usually the one your campaigns optimise for: Lead, Schedule or Purchase. Don't spend a week on PageView.
- Look at the parameter list for that event in Events Manager. Note which details arrive rarely or never.
- Make sure you send every detail you already collect. If your form asks for phone, it should go with the event. Many setups send only email.
- Normalise before hashing, using the table above. Lowercase, trimmed, phone with country code.
- Add the IP address and user agent to every server event, taken from the visitor's original request.
- Pass the fbc and fbp cookies from the browser to your server event. On a form, read them when the form is submitted.
- Add your own customer ID as external_id. It's stable across visits and helps Meta connect events from the same person.
- Fix deduplication (next section) so the browser and server versions of the same event merge instead of competing.
- Wait and recheck. Give it about a week of normal traffic.
Event coverage, deduplication and the other numbers next to EMQ
Meta groups Event Match Quality with a few related signals. Its Dataset Quality API reports them together: event match quality, event coverage, deduplication, data freshness, and additional conversions reported.
Event coverage is the share of your browser (pixel) events that also arrive through the Conversions API with a matching deduplication key. Meta prompts advertisers to reach 75%. Low coverage means the server side is missing events the browser saw.
Deduplication is how Meta avoids counting the same conversion twice when the pixel and the server both send it. Per Meta's documentation:
- Send the same event_name and the same event_id from the browser and the server. That's the reliable match.
- Without a shared event_id, Meta can fall back to fbp or external_id plus the event name, but this generally only works when the browser event arrives first.
- Meta deduplicates within 48 hours, counted from when it first receives the event.
Broken deduplication doesn't always lower your EMQ, but it inflates your conversions. That's how you end up with a "Great" score and a cost per lead that's suspiciously low.
Additional conversions reported is Meta's estimate of how many extra conversions your Conversions API setup surfaced that the pixel alone would have missed. It's the clearest answer to "is server-side tracking worth it for this account".
Is a perfect 10 worth chasing?
No. Past a certain point you're polishing a number. Practical rules:
- For your optimisation event, the goal is that most events carry email or phone, correctly formatted, plus the click and browser IDs. If that's true, you're in good shape whatever the exact score says.
- For upper-funnel events like PageView and ViewContent, a low score is expected. Don't ask visitors for details just to raise it.
- If your score is decent and results are still poor, the problem is probably elsewhere: the offer, the form, follow-up speed, or optimising for the wrong event.
How Inflowave sends these details for you
If your forms, calendars and payments run through Inflowave, most of the list above is handled once you add your pixel ID and Conversions API access token in Settings.
- Form submissions send a Lead event with every detail the form collected that Meta can use: email, phone, first and last name, city, state, zip, country, date of birth and gender where asked, plus your Inflowave lead ID as external_id. They also send the visitor's IP address and browser, and the fbc and fbp cookies read at the moment of submission.
- Bookings send a Schedule event, and a paid booking deposit sends a Purchase event.
- Paid invoices through Stripe send a Purchase event.
- Phone calls that connect and last past a minimum length (30 seconds by default) send a Contact event.
- Personal details are normalised and SHA-256 hashed to Meta's rules before they leave Inflowave. The click ID, browser ID, IP address and user agent are sent unhashed, as Meta requires.
- Every event carries an event_id that matches the browser pixel event for the same action, so Meta deduplicates them.
- Form leads also keep the click ID and UTM tags on the lead record, so you can see in the CRM which campaign each one came from.
For anything else, a workflow step called Send CAPI Event can fire one of Meta's standard events (Lead, Purchase, Contact, SubmitApplication and others) when something happens in the CRM, for example a deal moving to a pipeline stage.
Inflowave doesn't show the Event Match Quality score itself. Check it in Events Manager as described above.
Related guides: Facebook Conversions API setup, Meta conversion leads explained, How to connect Facebook lead ads to your CRM and Meta Pixel Helper and Meta Ads Data Advisor.
Questions people ask
What is a good Event Match Quality score?
Meta labels scores Poor, OK, Good and Great but doesn't publish an official target. For the event you optimise for (Lead or Purchase), aim for Good or Great. For page views, a lower score is normal.
Is Event Match Quality out of 10?
Yes. Meta shows it as a score out of 10 for each event, with a label next to it.
Does Event Match Quality affect ad performance?
Indirectly. Events Meta can match to real people give its delivery system better information about who converts, which can improve optimisation and reporting. The score itself isn't a ranking factor you're graded on.
Why is my Event Match Quality low on PageView?
Because a page view usually happens before the visitor has told you anything about themselves. Only the IP address, browser and cookies are available. That's expected, and not worth fixing at the cost of extra friction.
Do I need the Conversions API to improve Event Match Quality?
For most setups, yes. The score is reported for events sent with customer information, and the Conversions API is how your server or CRM sends details like a hashed email or phone number reliably, without depending on the browser.
Should I hash the IP address, fbc or fbp?
No. Meta asks for those unhashed. Hash personal details like email, phone, name and address, after normalising them.
Why did my score drop after I changed nothing?
Usually because the mix of events changed: more traffic from a source where people don't fill in a form, a form that stopped passing the phone field, or a plugin update that stopped forwarding the cookies. Check the parameter list for the event in Events Manager to see which detail fell.
What's the difference between Event Match Quality and event coverage?
Event Match Quality grades the customer details sent with your events. Event coverage measures how many of your browser events also arrive through the Conversions API. Meta prompts advertisers to reach 75% coverage.
Can a high Event Match Quality score hide broken tracking?
Yes. If the pixel and server send the same conversion without a shared event_id, Meta may count it twice. The score can look Great while your reported conversions are inflated.
What is aggregated event measurement and is it the same thing?
No. Aggregated event measurement is Meta's privacy-limited reporting for people who opt out of tracking on iOS. Event Match Quality is about matching individual events to accounts. They're related but separate systems.

