Event Match Quality: What It Is and How to Improve It in Meta Events Manager
What Event Match Quality in Meta Events Manager measures, which customer parameters actually help matching, how to prepare them, and when EMQ does not appear at all.
On this page
Event Match Quality is Meta's hint about how many of your events it can attribute to real people. An event Meta cannot match to an account will not help optimisation or attribution, even if it was accepted without errors. Treat EMQ like a thermometer: it does not cure anything, but it shows where your data is too thin. This guide explains what the score measures, which parameters matter, how to prepare them, and why you will not see it for CRM leads at all.
What is Event Match Quality?
According to the Dataset Quality API documentation, EMQ is a score out of 10 that indicates how effective the customer information sent from your server may be at matching an event to a Meta account. Meta considers:
- which customer information parameters it receives through the Conversions API,
- the quality of those parameters,
- the share of events matched to an account.
The score is calculated in real time and shown separately for each event, such as Purchase or AddToCart. Alongside it, Meta shows diagnostics (specific integration issues with suggested fixes) and data freshness, the delay between an event happening and Meta receiving it.
Why it matters: Meta's Conversions API best practices say plainly that only matched events can be used for ad attribution and delivery optimisation. Unmatched events are useful for basic measurement at most.
Which events does Meta calculate EMQ for?
Website events only. Meta notes that EMQ is not available for offline and physical store events, app events, or the CRM integration for leads (conversion leads). This matters because many teams look for a score where none exists.
| Event type | Example | EMQ? | Main matching key |
|---|---|---|---|
Website (action_source: website) | Purchase from an online shop | yes | email, phone, IP, user agent, fbp, fbc, external_id |
CRM lead stage (system_generated) | QualifiedLead for a Meta form lead | no | lead_id, with email and phone as backup |
| Offline or spreadsheet | a status from Google Sheets | no | email, phone, lead_id if available |
If you mostly send stages for form leads, do not chase an EMQ score. Make sure every event carries the original lead_id and that your stages are well designed, as covered in CRM lead stages for Meta.
Which customer parameters actually help?
Meta gives email, IP address, first and last name, and phone as examples of high-quality parameters, and recommends sending external_id and event_id with every event. The full list of fields and preparation rules is in the customer information parameters reference.
| Parameter | Where it comes from | How to prepare it | Hashing |
|---|---|---|---|
Email (em) | checkout form, customer account | trim spaces, lowercase | SHA-256 |
Phone (ph) | checkout form | digits only with country code, e.g. 447700900123 | SHA-256 |
IP address (client_ip_address) | the customer's browser request | the customer's real address, not your server's | never |
User agent (client_user_agent) | the customer's browser | unchanged; required for website events | no |
fbp | the _fbp cookie | unchanged | no |
fbc | the _fbc cookie or fbclid from the click | only from a real ad click | no |
external_id | your customer ID | the same for one person across all channels | recommended |
First, last name (fn, ln) | form | lowercase, no punctuation | SHA-256 |
Two rules that are easy to overlook:
- Overly broad events are rejected. If an event carries only fields such as gender, city, state and country, Meta treats it as invalid. City or postcode only help as extras.
- Send test events with your own data. Meta says test events that do not match an account may be discarded, so test with your own email and phone, not
test@test.com.
Common causes of a low EMQ
| Symptom | Cause | Fix |
|---|---|---|
| Email is sent, but few matches | capitals or spaces before hashing | normalise before SHA-256 |
| Phone adds almost nothing | number without country code or with a leading zero | store numbers in international format |
| No fbp or fbc on orders | browser identifiers never reach the order | pass them from the page to the order after cookie consent |
| IP is always the same address | your server or proxy address is being sent | pass the customer's IP; trust proxy headers only when the proxy overwrites them |
| Diagnostics flag delays | events sent in a nightly batch | send each event right after the order |
| Score drops after a site change | a new form no longer passes email or phone | check parameter coverage after every release |
How this works in Convs
Convs does not "boost" the score with tricks. It makes sure data is complete and correct before it leaves for Meta:
- Email and phone are normalised and hashed on the server. An invalid email or a phone number without a country code stops the event with a clear error rather than sending a hash that will never match.
- The shop collector gathers
fbpandfbconly after consent from your CMP. It reuses an existing_fbpor creates its own identifier, and takesfbconly from a realfbclid; it never invents one without a click. It also records the customer's real IP and user agent, skipping private addresses. - A shop order is sent as a website event with a stable
event_id, the customer's user agent and a page URL on the same domain as the source. Query parameters are stripped before sending. - Your own customer ID passed as
user_idreaches Meta as a hashedexternal_id. - Events leave from a durable queue checked every minute, so data reaches Meta close to the time of the event.
How to carry the collector's identifier into the order and avoid double counting with the Pixel is covered in server-side purchase events for online shops and Pixel and CAPI event deduplication. The Meta Conversions API feature page describes delivery in general.
How does EMQ relate to the Pixel and deduplication?
EMQ rates events sent from your server, but in most shops the browser Pixel also reports the same order. If both send Purchase, Meta has to know it is one transaction. The best practices require either an event_id or a combination of external_id and fbp on both events; in practice, the simplest route is the same event name and the same event_id on both sides.
That is good news for EMQ: the identifiers that let Meta remove the duplicate also help it match. A server event carrying the customer's fbp, fbc, IP and user agent is both better matched and easier to deduplicate. The reverse holds too: a server event with no browser identifiers gives Meta less to work with on both counts.
One warning: do not invent an fbc to "fill the gap". Meta expects a value from a real ad click, and a fabricated one can distort attribution.
A step-by-step plan to improve EMQ
- Pick the events that matter. Usually Purchase and Lead on your website. PageView normally carries little customer data and is not worth forcing.
- Record a baseline. The score and the coverage of each parameter from Events Manager, so you have something to compare against.
- Fix the format first, before adding new fields. A badly normalised email is worse than none, because it looks as though data is being sent.
- Add browser identifiers (
fbp,fbc, IP, user agent) after cookie consent. - Add
external_idif customers have accounts in your shop. - Cut the delay: send each event right after the order.
- Check the score after a few days of traffic and compare it with your baseline.
Only collect data you need to fulfil the order. Adding form fields purely to lift EMQ conflicts with the data minimisation principle. More in GDPR and the Conversions API.
Limits: what EMQ does not tell you
- EMQ does not measure lead quality or whether your event counts are right. A perfect 10 on a Lead event that fires for every spam submission still means optimising for spam.
- EMQ does not apply to CRM lead stages. There, data quality depends on
lead_idand sending stages regularly. - Convs sends email, phone,
external_id,lead_idand browser data from the collector. It does not send first or last name, city, postcode or date of birth. If your approach depends on those fields, you need a different setup. - A higher score does not guarantee better campaigns. It gives Meta more matched events to learn from; Ads Manager shows the effect.
If you are new to server-side events, start with what the Meta Conversions API is. Plans and limits are on the pricing page.
Frequently asked questions
Where do I find Event Match Quality?
In Events Manager, in the details of a website event for the relevant data source. Meta shows the score there along with which customer parameters arrive and at what coverage. The same score is available through the Dataset Quality API.
What is a good EMQ score?
Meta's developer documentation gives a scale out of 10 and recommends monitoring the score per event together with the parameters you send, but no single threshold. Targets like 'at least 6' usually come from tool vendors. Compare against your own score before changes.
Why is there no EMQ for my lead form leads?
Because Meta only calculates EMQ for website events. Offline events, app events and the CRM integration for leads (conversion leads) do not have it. For leads, the key is the lead_id, which ties each event to a specific submission.
Will sending date of birth or city raise EMQ much?
Meta lists email, IP address, first and last name and phone as examples of high-quality parameters. City, gender or country help less, and an event with only such fields is rejected as too broad. Do not collect extra data just to raise the score.
Does a higher EMQ mean better campaign results?
Not automatically. A higher EMQ means more events can be matched to accounts, and only matched events can be used for attribution and optimisation. That is better material for Meta, not a guarantee of a lower cost per conversion.
Does hashing lower EMQ?
No, as long as the data is normalised before hashing. The problem is hashing a badly formatted value, such as an email with a capital letter or a phone number without a country code: that hash will not match anything. IP address, user agent, fbp and fbc are not hashed.
