How to Improve Meta Event Match Quality (EMQ) Score

You connected the Conversions API, Events Manager shows server events arriving, and next to each one sits a number out of 10 called Event Match Quality, often with a yellow or red indicator. That number decides whether the conversions you worked to send actually count. This guide explains what EMQ measures, which parameters carry the most weight, and the practical fixes that move the score, in the order we apply them. For background on the API itself, see Facebook Pixel vs Conversions API.

What Event Match Quality measures

When your server sends a conversion, Meta has to work out which Meta account performed it so the event can be attributed to the ad that person saw and used to optimise delivery. It does this by comparing the customer information parameters in the event (hashed email, hashed phone, browser identifiers, IP, and so on) against its accounts. Event Match Quality is Meta's score, per event type, for how good that comparison is: how many high-quality parameters you send, how often each one is present, and how well they match. It is updated continuously from the last 48 hours of events, and it applies only to server events; Pixel events have their own matching via cookies and are not scored.

A low score does not mean events were rejected. It means a large share of them arrived with too little information to be tied to a person, so they are counted in your totals but cannot be attributed or learned from. That is why advertisers with a working CAPI setup and a poor EMQ still see under-reporting.

Which parameters matter most

Meta's documentation ranks customer information parameters by their contribution to matching. Email and phone are the strongest. The browser identifiers fbp (Meta's first-party cookie) and fbc (the click ID from the ad) are next, because they tie the event directly to a known browser or click. IP address and user agent are weak alone but required for several match paths and should always be present. The rest add incremental lift.

Fix 1: send email and phone on every event that has them

A Purchase or Lead event almost always happens after the visitor typed an email address, and often a phone number. If those are not in the server event, you are leaving the two strongest signals on the table. Capture them at submission, normalise (lowercase, trim, remove formatting from phone numbers and prepend the country code), hash with SHA-256, and include both em and ph. For events earlier in the funnel, send them whenever the visitor is logged in or has previously identified themselves on your domain.

Fix 2: forward fbp and fbc from the browser

The Pixel sets a _fbp cookie on your domain, and when a visitor arrives from a Meta ad with an fbclid in the URL it stores a _fbc value as well. Your server event should read both cookies and pass them in user_data. If the Pixel is blocked or has not loaded by the time the event fires, you can construct fbc yourself from the fbclid parameter using Meta's documented format (fb.1.timestamp.fbclid), which is exactly what a first-party collector that captures the landing URL on arrival makes easy. Missing fbc is the most common gap we see on server events that otherwise carry good data, and adding it typically produces the single biggest jump in EMQ for paid traffic.

Fix 3: include the visitor's IP and user agent, not your server's

Both parameters are required for website events, and they must be the visitor's values. A common mistake in backend integrations is to send the IP address and user agent of the server making the request, which matches nobody. Capture them from the original browser request (checking forwarded-for headers behind a proxy or CDN) and pass them through unchanged.

Fix 4: add external_id

If you have a stable identifier for the visitor, such as a customer ID, user ID, or the first-party visitor ID your tracker assigns, send it as external_id on both the Pixel (via Advanced Matching) and the server event. Meta uses it to link events from the same person across sessions and devices, which lifts match rates for returning visitors in particular. Hash it unless you have a reason not to.

Fix 5: keep the Pixel running alongside CAPI

It sounds counter-intuitive when the whole point of the server event is to work when the Pixel does not, but the Pixel is what collects fbp and fbc in the first place and what runs Advanced Matching in the browser. Removing it lowers the information available to your server events. The recommended setup is both channels with a shared event_id for deduplication; our guide to Meta CAPI event deduplication covers the mechanics, and the pixel inspector confirms the Pixel is actually loading on your pages.

Fix 6: check normalisation and hashing

A correctly hashed but badly normalised email will not match. Lowercase the address, strip leading and trailing whitespace, then hash. For phone numbers remove spaces, dashes, parentheses, and leading zeros, prepend the country code without a plus sign, then hash. Names are lowercased with no punctuation. The Events Manager test events tool lets you send a sample event and see which parameters Meta recognised; if a parameter you are sending does not appear, normalisation is the first thing to check.

Reading the score after each change

1. 1In Events Manager, select the dataset, open the event (for example Purchase), and click the Event Match Quality value to see the list of parameters received and how often each is present.
2. 2Make one change at a time. Because the score is based on the trailing 48 hours of events, wait two days before judging the effect.
3. 3Prioritise the events that drive optimisation: Purchase, Lead, CompleteRegistration. A PageView EMQ of 5 is normal and not worth chasing.
4. 4Watch the deduplication rate in the same view. A rising EMQ with a falling deduplication rate means your event_id handling broke while you were adding parameters.

What a good setup looks like

The pattern behind every fix above is the same: capture identifiers once, as early as possible, on your own domain, and attach them to every conversion the server sends. A first-party collector records the fbclid, the fbp cookie, the visitor's IP and user agent, and a stable visitor ID at the first page view. When a form is submitted or an order is placed, the email and phone are added to the same record. The server event to Meta then carries all of it, hashed where required, with an event_id shared with the browser Pixel. This is how EndFrame builds Conversions API events, and it is why EMQ for purchase and lead events in that setup sits at the top of the scale without per-site tuning. For the wider implementation, see our guide to the Meta Conversions API without server-side GTM.