Meta Event Match Quality: what actually moves the score
Event Match Quality does not go up by changing a setting inside Meta. It is a consequence of how much you capture and how much of it survives to the send — and both are measurable on your side, today.
Event Match Quality — EMQ — is a 0 to 10 score Meta assigns to each event you send through the Conversions API. It answers a single question: with the data that arrived in this event, can Meta tell whose it is?
Most EMQ conversations start in the wrong place, hunting for a setting inside Events Manager. That setting does not exist. The score is a mirror: it measures what you captured and what you sent. Both ends are on your side.
What each parameter is worth
user_data fields are not equal. It pays to know where to spend capture effort before you start asking visitors for more.
| Parameter | What it resolves | Practical weight |
|---|---|---|
| em (email) | Direct account identification | The strongest single field. On its own it lands the score around 5 to 6 |
| ph (phone) | A second strong identity, near universal in some markets | Added to email, it pushes the score to 7 or above |
| fbc | The ad click, derived from the fbclid in the URL | When present it is direct attribution, not inference |
| fbp | The browser, used to stitch sessions of the same person | Medium. Connects the anonymous visit to the identified one |
| external_id | Your own stable identifier for the person | Medium, and it is what makes events consistent with each other |
| fn, ln | First and last name | Low alone, relevant in combination |
| ct, st, zp, country | Location | Low alone. Together they break ties |
Note what the table does not say: there is no magic parameter. Email is the first step, and everything after it comes from stacking weak signals — which is exactly the work nobody wants to do.
A low score is almost never a configuration problem. It is a capture problem: either the data does not exist, or it exists in your database and never made it into the send.
The measurement that settles the argument in ten minutes
Events Manager shows an aggregate score, hours late, without telling you what was missing. There is a far more useful signal, and it lives on your side: across the events you delivered in the last seven days, what percentage carried each parameter.
-- Parameter coverage over the events you ACTUALLY delivered.
-- Not what the payload could have carried: what left the building.
SELECT
event_name,
count() AS sent,
round(100 * countIf(has_email), 1) AS pct_email,
round(100 * countIf(has_phone), 1) AS pct_phone,
round(100 * countIf(has_fbc), 1) AS pct_fbc,
round(100 * countIf(has_external_id), 1) AS pct_external_id
FROM deliveries
WHERE sent_at >= now() - INTERVAL 7 DAY
GROUP BY event_name
ORDER BY sent DESCThat query changes the conversation. If email shows up in 30% of sends, no adjustment on Meta's side will save matching, and arguing about hashing or formatting is beside the point: 70% of the emails are missing.
A real result that makes the point
In one account we audited, the same pixel, in the same week, produced two completely different numbers: the page view event went out with email on 11.4% and phone on 10.3%, while the abandoned cart event from the same account went out with both at 100%.
That is not a contradiction. It is about when capture happens: at the cart the person has already identified themselves, on the visit they have not. The correct reading is that EMQ is per event — comparing the score of different events means nothing.
The three mistakes that cancel out your capture work
1. Normalizing after hashing, or not at all
sha256 is of the exact string. An email with a capital letter or a stray space produces a different hash from the same email cleaned up, and only the clean one matches. Before hashing: lowercase, trim. Phone: digits only, with the country code in front.
2. Sending only what arrived in the event payload
This is the most expensive and the most common. The person's email usually already exists in your database, tied to them by an earlier purchase or a form filled two months ago. If user_data is assembled from the request that just came in, you throw away what you already knew. user_data should come from the identity graph, not from the event body.
3. Inventing what is missing
The temptation to fill in gender or city by inference is strong, and the effect is the opposite of what you want: a wrong guess is not neutral, it is noise Meta uses to try to match the wrong person.
We measured this. A name dictionary used to infer gender covered 87.7% of Brazilian traffic and did not recognise extremely common local names — and accents broke the lookup in both directions. The result was that the gender parameter went out on roughly half of the events where a name existed. The fix was not to guess better: it was to leave the field empty when the name is ambiguous.
A missing parameter costs you one signal. A wrong parameter costs you the whole match for that event.
The ceiling nobody mentions
It is worth saying what a high score does not fix. EMQ measures person recognition, not conversion quality. An event scoring 9 that points at an expired payment still teaches the campaign to look for people who start checkouts and never pay.
That is why both fronts move together, in this order: first the filter on what goes up, then the coverage of who it is. Raising the score of an event that should not be sent at all only makes the campaign wrong with more confidence.
In CrazyLeads, user_data is assembled from the identity graph — the email someone left in any source travels with the purchase — normalisation and hashing are the default behaviour, and parameter coverage is a screen, not a query you have to write.