The short answer. Event match quality (EMQ) is Meta’s score, out of 10, for how well the customer information sent with a server event can match it to a Meta account. It is scored per event type. Raise it by sending more identifiers: the click ID and hashed email carry the most weight, and the browser ID, IP address and user agent cost nothing to add.
Ahrefs puts the US search volume for “event match quality” at about 50 a month, and every one of those searchers is looking at a number in Events Manager and wondering whether it is bad. The top result is Meta’s own help page. Below it sit Reddit threads asking what a good score is, and a handful of vendor guides that list the same parameters in the same order.
Most of those guides treat the score as a grade to maximize. It is better read as a diagnostic: a coverage report on the identifiers your server sends. Once you read it that way, the fix list gets short and most of the work is free.
What event match quality measures
Meta defines EMQ in its Dataset Quality API documentation as “a score (out of 10) that indicates how effective the customer information sent from your server may be at matching event instances to a Meta account.” Three details in that sentence matter.
It is about your server events. The score reflects the customer information you send with Conversions API events. A pixel-only setup gets little out of it, which is one reason it appears in the same conversations as the Meta CAPI setup guide.
It is per event, not per account. Meta’s Dataset Quality API returns a composite score for each event type, plus coverage per identifier. A Purchase event with a hashed email can score well while your PageView events sit much lower, because a page view usually carries only the IP address, user agent and browser cookie. Stape’s guide says PageView events without user parameters score around 4. Judging one number for the whole account hides this.
It measures matching, not tracking. A score of 9 says nothing about whether you captured every conversion. It says the ones you sent carried useful identifiers. That is a different failure from the one covered in our piece on conversion tracking accuracy, where the loss happens before any event is built.
What a good score is, and why chasing 10 is a mistake
Triple Whale’s write-up reports that Meta treats roughly 6 out of 10 as healthy for ad optimization, and gives rough targets by funnel stage: 4.5 to 7 for top-of-funnel events, 6 to 8 for add to cart and checkout, and 7.5 to 9.3 for purchase and registration. Those are one vendor’s benchmarks, not Meta guarantees, but the shape is right. The further down the funnel, the more identifying data you have, so the higher the score should be.
Our take: the number deserves attention in two situations and not otherwise. First, when a purchase or lead event is below about 6, because it means you are sending too little to match. Second, when the score drops suddenly, because that nearly always means a code change broke an identifier. In between, a purchase event at 7.5 and one at 9 are both fine. Triple Whale’s own framing is that Meta would rather see 1,010 conversions at a 6 than 1,000 at a 9, and we agree. Missing events cost you more than imperfect ones.
The identifiers, in the order they are worth fixing
Meta’s customer information parameters split into two groups, and the split is the most useful thing to know. One group needs no hashing and no personal data from your customer. The other needs both.
| Parameter | Hash it? | Where it comes from |
|---|---|---|
fbc (click ID cookie) | No | Built from the fbclid on the landing page URL |
fbp (browser ID) | No | Set by the Meta pixel in the browser |
client_ip_address | No | The request that triggered the event |
client_user_agent | No | The same request |
em (email) | Yes | Form field or account |
ph (phone) | Yes | Form field or account |
fn, ln, ct, st, zp, country | Yes | Billing or shipping details |
external_id | Hashing recommended | Your own customer or user ID |
That table suggests an order of work.
1. The free four: fbc, fbp, IP address and user agent. Meta’s documentation marks all four “do not hash.” None needs a form field, so you are not asking the customer for anything new. They are usually missing or wrong for a mundane reason: the event is built on a server that never saw the browser. A webhook from your payment processor, for instance, arrives with the processor’s IP address and user agent, not your customer’s. Capture these values in the browser at the time of the click and pass them along with the order.
fbc is the one that decays. It comes from fbclid in the landing page URL, which exists only on the first page of the visit and only if something reads it. Stape ranks the email and click ID as the highest-priority identifiers, and Triple Whale says the same: click IDs and email carry the most weight, while city and state add less. A click ID that is stored for the full attribution window and sent with the eventual purchase is the cheapest large improvement most accounts have. Safari makes this harder; the iOS tracking recovery guide covers why a script-set cookie often does not survive.
2. Email, at the point you collect it. Hashed email is the strongest customer-supplied identifier. Collect it at the form and attach it to every later event for that person: lead, purchase and subscription alike. The common mistake is sending it on the purchase and nowhere else.
3. Phone, then address fields. Phone adds real matching power when email fails, since people use different emails across sites. City, state and zip add less. Send them if you hold them, but do not build a form to collect them.
4. external_id. Your own stable customer ID helps Meta link events from the same person across sessions and devices. It costs nothing and is rarely sent.
The hashing mistakes that silently zero a parameter
Meta’s documentation spells out the normalization for each field, and most low scores that are not a coverage problem are a formatting problem. Hashing a differently formatted value produces a different hash, which matches nothing and raises no error.
- Email: trim leading and trailing spaces and convert to lowercase before hashing.
- Phone: remove symbols, letters and leading zeros, and include the country code.
- State: the two-character code in lowercase; outside the US, lowercase with no punctuation or spaces.
- Zip: lowercase, no spaces or dashes, and only the first 5 digits for US zip codes.
- Country: the lowercase two-letter ISO 3166-1 code.
- Names: lowercase, no punctuation, UTF-8 for special characters.
- City: lowercase, no punctuation, no special characters and no spaces, so New York becomes
newyork.
The reverse mistake happens as often. Hashing client_ip_address, client_user_agent, fbc or fbp makes them unusable, because Meta expects them in the clear.
Here is the email and phone normalization in a few lines of module JavaScript:
import { createHash } from 'node:crypto';
const sha256 = (value) => createHash('sha256').update(value).digest('hex');
export function hashEmail(email) {
if (!email) return undefined;
return sha256(email.trim().toLowerCase());
}
export function hashPhone(phone, defaultCountryCode = '1') {
if (!phone) return undefined;
const digits = phone.replace(/\D/g, '').replace(/^0+/, '');
return sha256(digits.startsWith(defaultCountryCode) ? digits : defaultCountryCode + digits);
}
The phone helper above is deliberately naive: it assumes one default country and will mangle numbers from elsewhere. Use a proper phone-parsing library before you trust it with international traffic.
How to check your score without staring at the dashboard
Events Manager shows the score and a list of parameters, but it is a snapshot. For anything you want to track over time, Meta’s Dataset Quality API returns the composite score per event, a match_key_feedback array with coverage for each identifier, and a diagnostics array describing integration problems. The coverage figure is the useful one: if fbc coverage on Purchase is 12 percent, you have found your problem, and no amount of tweaking email formatting will fix it.
A weekly check is enough. Pull the score for Purchase and Lead only, compare coverage for fbc, email and ip_address (the API’s names for those identifiers), and treat a drop of a full point as a bug report.
Where Convultra fits
Convultra’s tag captures fbclid alongside gclid, gbraid, wbraid and msclkid at first touch with a 90-day retention window, and persists fbclid, gclid and msclkid server-side, so the click ID is still there when the conversion happens weeks later. That covers the identifier that decays fastest and is the hardest to rebuild after the fact. To be straight about the rest: automatic delivery today is Google Ads and OpenAI Ads, with Meta, Microsoft Ads and TikTok coming soon. For Meta, the capture layer is described on the server-side tracking page, and the conversion API explained guide covers how the server-to-server handshake works.
A short checklist
- Pull per-event scores from Events Manager or the Dataset Quality API. Look at Purchase and Lead first.
- Check coverage for
fbc,fbp, IP address and user agent. Fix any that are well short of complete before touching anything else. - Attach hashed email (and phone, if collected) to every event after the visitor identifies themselves.
- Verify normalization: trim, lowercase, country code on phone, no spaces in city, 5-digit zip.
- Send
external_id. - Stop when Purchase sits at 7 or above and coverage is stable. More effort belongs on capturing missing conversions.
FAQ
What is event match quality?
Event match quality is a score out of 10 that Meta gives each server event type, indicating how effective the customer information you send may be at matching the event to a Meta account.
What is a good event match quality score?
It depends on the event. Purchase and lead events should land in the high 6s to 9s because they carry the most identifying data, while PageView events often score far lower. A sudden drop matters more than the absolute number.
How do I improve event match quality?
Send more identifiers with each server event. Start with the click ID (fbc), browser ID (fbp), IP address and user agent, then add hashed email, phone and external_id.
Which customer information parameters should not be hashed?
Meta’s documentation says not to hash client_ip_address, client_user_agent, fbc or fbp. Email, phone, name and address fields must be normalized and hashed.
Does event match quality affect ad performance?
Better matching lets Meta attribute more conversions to ad clicks and optimize on them, but missing conversions hurt more than imperfect matches. Fix capture first, then match quality.
Capture the click before you score the match
Match quality only works on the events you actually capture, and capturing the click ID on landing is where most accounts lose it. Convultra does that with one line of JavaScript. Start your free trial.