Event Match Quality is a score from 0 to 10 that Meta shows in Events Manager for each server event, estimating how reliably the customer information you send can be matched to a Facebook or Instagram account. Most accounts raise it by sending events through the Conversions API, adding a hashed email wherever they have one, and passing click and browser IDs cleanly.
This page covers what the score measures according to Meta's own documentation, which parameters move it, a fix order that avoids wasted work, and the two things a high score does not tell you.
What Event Match Quality measures
Meta's developer documentation describes EMQ as a score out of 10 that indicates how effective a server event's customer information may be at matching it to a Meta account. The Dataset Quality API documentation adds how it is built: from which customer information parameters are received from your server, the quality of that information, and the percent of event instances matched to a Meta account.
Three consequences follow from that definition.
- EMQ is a score about server events. It describes what your Conversions API integration sends. A browser-only pixel setup gives Meta far less to score.
- Quantity alone does not raise it. A parameter in the wrong format is not a partly counted parameter. It is a missing one.
- It is scored per event. Purchase and PageView are graded separately, and they should be read separately.
What counts as a good score
Events Manager shows the number with a rating label: Poor, OK, Good or Great. Meta does not publish a threshold table in its developer documentation. The mapping most often reported by tracking vendors is:
| Score | Label commonly reported | Practical reading |
|---|---|---|
| 0 to 3.9 | Poor | Most events are not being matched. Look for a broken integration first. |
| 4 to 5.9 | OK | Signal exists but is thin. Usually missing email or server events. |
| 6 to 7.9 | Good | Workable for most events. |
| 8 to 10 | Great | Typical of a full server setup with hashed email on most events. |
Mapping reported by LeadsBridge and CustomerLabs. Treat it as a reading guide, not a Meta specification.
Do not expect every event to reach the same score. An early event such as PageView usually fires before a visitor has given you an email, so it has fewer identifiers to send. A Purchase event happens after checkout, where you normally hold email, phone and address. A low PageView score next to a high Purchase score is expected.
| Event | Identifiers you usually hold | What to focus on |
|---|---|---|
| PageView, ViewContent | IP, user agent, fbp, fbc, sometimes external ID | Clean fbp and fbc; send external ID for logged-in visitors |
| AddToCart | The above, plus email if the visitor is logged in | Pass email for logged-in sessions |
| InitiateCheckout | Email, often phone | Send them as soon as they are entered |
| Purchase, Lead | Email, phone, name, address | Send every parameter you legitimately hold |
What moves the score, in order of typical effect
1. Sending server events through the Conversions API. Browser tracking loses events to ad blockers, browser restrictions and consent choices. No amount of parameter tuning recovers an event that never reached Meta. See Meta Pixel vs Conversions API for how the two work together.
2. Email on every event where you have it. Meta's Conversions API best practices list email, IP address, first and last name, and phone number as high-quality customer information. Once a person logs in or types an email at checkout, send it with every later event, not only Purchase.
3. Click ID and browser ID. The fbc and fbp values connect an event to a specific ad click and browser. Meta recommends refreshing their values regularly. Capture fbclid when the visitor lands and carry it through to the server event. If your store and checkout sit on different domains, this is where it most often breaks.
4. The required web fields. Website events sent through the Conversions API require client_user_agent, action_source and event_source_url. Missing them is a common, silent reason for weak scores.
5. More identifiers, where you legitimately hold them. Phone, name, city, state, postcode, country and external ID each add matching surface.
6. Speed. Meta recommends sending server events in real time or in batches close to real time. A nightly batch upload weakens the signal even when the parameters are perfect.
How to diagnose a low score
Start in Events Manager. Clicking the score beside an event opens a breakdown of which parameters are received and which are missing. For teams that want the same data programmatically, the Dataset Quality API returns six groups of fields:
| Field group | What it tells you |
|---|---|
| Event match quality (composite_score) | The 0 to 10 score, plus coverage for each identifier |
| Additional conversions reported (ACR) | Meta's estimate of extra conversions reported because of your server events, overall and per parameter |
| Event coverage | How many of your browser events have a matching server event, against a goal |
| Data freshness | Whether server events arrive in real time or hourly |
| Dedupe key feedback | Coverage of the keys used to match browser and server copies of the same event |
| Diagnostics | Named issues with a suggested fix and the share of events affected |
Most tracking guides stop at checking the Diagnostics tab. The coverage and freshness numbers are more useful, because they separate "we are not sending the event" from "we are sending it badly".
| Symptom | Likely cause |
|---|---|
| Purchase scores well, PageView scores poorly | Expected. Early events lack identifiers. Often not a problem. |
| Every event scores poorly | No server events, or the server integration is missing fields. |
| Score dropped with no deployment | A third-party app, a consent setting or a checkout change stopped passing a parameter. |
| Parameters show as sent but the score does not move | Formatting or hashing error. Emails must be trimmed and lowercased before hashing. |
A 7-step fix order that avoids wasted work
Each step can make a later one unnecessary, so the order matters.
- 1.Open the per-event breakdown in Events Manager and write down which parameters are missing for Purchase and your main lead or signup event.
- 2.Check formatting and hashing on the parameters you believe you already send. Fix these before adding anything new.
- 3.Send Purchase through the Conversions API first, then the rest of the funnel.
- 4.Add email to every event after the visitor identifies themselves.
- 5.Carry fbclid from landing to the server event, including across a checkout on another domain.
- 6.Deduplicate browser and server copies of the same event. Meta's rule: the same event_name, plus either the same event_id or a combination of external_id and fbp. Skipping this inflates event counts.
- 7.Wait before judging. Meta does not publish the scoring window. Practitioners report the displayed score reflects roughly the last 48 hours of events, so allow a few days of normal traffic before reading the result.
What a higher score does and does not prove
Tracking vendors publish before-and-after stories in which a higher EMQ arrives alongside lower cost per acquisition. Those are single-account observations without a control group, usually published by companies selling tracking products, and the account typically changed several things at once. We do not repeat their percentages here.
The defensible claim is narrower and still worth acting on: better identification means more of your real conversions are matched and reported, so the delivery system optimizes against a more complete picture of what happened. That is a signal-quality argument, not a promised return.
A high score does not mean your revenue figures are right. EMQ measures identification, not value. A Purchase event with a perfect score and the wrong currency, or a pre-discount value, is confidently reporting a wrong number.
A high score does not mean Meta's conversions equal your orders. They answer different questions, and 2026 widened the gap: click-through attribution now requires a link click, and the 7-day and 28-day view windows were removed from the Ads Insights API. See Meta's 2026 attribution changes. Keep your order ledger separate from Meta's reported conversions and compare them, rather than merging them.
Where AdRiseLab fits
AdRiseLab does not install or repair your Conversions API setup. What it does is read a connected Meta ad account and flag where performance data and delivery do not add up. A Meta ads audit is the fastest place to see whether a tracking problem is distorting the numbers you make decisions on. AdRiseLab is Meta-only and plans start at $39 a month; see pricing.
Sources
Meta for Developers: Conversions API best practices. Meta for Developers: Dataset Quality API. Meta for Developers: handling duplicate Pixel and Conversions API events. Meta Business Help Center: about Event Match Quality. Score mapping from third parties: LeadsBridge and CustomerLabs.
Related Reading
When reported results fall, why Meta ROAS drops splits the decline into CPM, click-through rate, conversion rate and order value. Account analytics shows the same numbers for a connected ad account.