Event Match Quality: What It Is and How to Raise It

Every server event you send to Meta is only useful if Meta can work out who it happened to. Event Match Quality (EMQ) is the score, from 0 to 10, that Events Manager assigns to each event type to tell you how well that is going. A high score means your events are being matched to real Meta accounts and can be used for attribution and, crucially, for optimisation. A low score means you are sending events into the void. This guide explains what goes into the score and what to do about it.

What Event Match Quality measures

When a Conversions API event arrives, Meta looks at the customer information parameters in its user_data object and tries to match them to an account. EMQ reflects two things: how many useful parameters you are sending, and how often those parameters actually produce a match. It is calculated per event name (Purchase, AddToCart and so on) over a rolling window, and it is shown next to each server event in Events Manager's Overview and in the Data Sources diagnostics.

Meta's own guidance is that higher EMQ improves ad attribution and can reduce cost per result, because better-matched events give the delivery system more accurate feedback. The score is a diagnostic, not a target in itself: an EMQ of 10 does not make a bad campaign good, but an EMQ of 3 will make a good campaign look worse than it is and learn slower than it could.

The parameters that count

Meta ranks customer information parameters by how much they help matching. The strongest signals are those tied directly to an account:

• Email (em): the single most valuable parameter. Hashed.
• Phone (ph): close behind, especially for mobile-first audiences. Hashed.
• Click ID (fbc): derived from the fbclid Meta appends to ad clicks. Not hashed. Ties the event to a specific ad click.
• Browser ID (fbp): the first-party _fbp cookie value. Not hashed.
• External ID (external_id): your own customer id, hashed. Helps when the same person appears across events.
• IP address and user agent (client_ip_address, client_user_agent): weaker alone, but required for website events and useful in combination.
• Name, city, state, zip, country (fn, ln, ct, st, zp, country): each adds a little; together they add a lot when email is missing. Hashed.
• Date of birth, gender: rarely available to merchants and low incremental value.

The score rewards combinations. An event with email, phone, fbp, fbc, IP and user agent will nearly always outscore one with email alone, even though email is the strongest individual key.

Normalisation before hashing

Meta matches hashes, and a hash of Jane.Doe@Example.com is a completely different string from a hash of jane.doe@example.com. If you do not normalise exactly the way Meta does, your carefully hashed parameters match nothing. The rules, in short:

Then SHA-256, hex-encoded, lowercase. fbc, fbp, IP and user agent are sent unhashed. Getting a single field wrong (phone numbers without a country code are the classic) silently zeroes its contribution.

Why fbc deserves special attention

The click id is the only parameter that connects a conversion to a specific ad click rather than to a person. It is formed as fb.1.{timestamp}.{fbclid}. The Meta Pixel writes it into the _fbc cookie when a visitor lands with fbclid in the URL, but cookies are exactly what gets lost in the modern browser. Capture the fbclid at the first hop, store it server-side, and attach it to the eventual purchase yourself. This matters most when the purchase happens somewhere you do not run a pixel, such as Amazon: for those events fbc, fbp, IP and user agent captured at the redirect are the only match keys available, and a click id makes the difference between a matched purchase and an anonymous one.

How to raise your score, in order

1. Send email and phone on every purchase. If you sell on Shopify, this data is in the order, and Shopify includes it in order webhooks for apps it has approved for protected customer data (PixlBridge handles that; there is nothing for you to set up). PixlBridge's Shopify integration hashes and sends em, ph, name, address and external_id from the order.
2. Fix normalisation. Check one event in Test events: Events Manager shows which parameters were received. If ph is present but EMQ does not move, the format is wrong.
3. Add fbc and fbp. Recover them from cookies, checkout attributes or the landing page URL. For off-site destinations, capture them at the click.
4. Send IP and user agent for website events. They are required for action_source: website and contribute to matching.
5. Add address fields (ct, st, zp, country). Cheap to add when you have a shipping address.
6. Deduplicate properly. Duplicates do not lower EMQ directly, but a browser event with rich data and a server event with poor data for the same purchase confuse the picture. Use the same event_id and let Meta merge them.

What to expect (illustrative)

Meta does not publish a formula, so treat these as rough ranges seen in practice rather than guarantees:

• Purchase events from a checkout with email, phone, name, address, fbp/fbc and IP/UA typically land in the upper band (roughly 7 to 9 out of 10).
• Funnel events such as PageView or ViewContent, which by nature carry only browser identifiers, sit in the middle band and that is normal.
• Events with hashed email only, or with poorly normalised fields, often score in the low-to-mid band.
• Off-site purchases (Amazon) matched via fbc, fbp, IP and user agent score below checkout purchases because no PII is available; the click id is what keeps them in the useful range.

Reading the diagnostics

In Events Manager, open your dataset, choose an event and expand Event Match Quality. Meta lists the parameters it received, how often each was present, and recommendations such as "send phone number" or "fix formatting of email". These recommendations are specific to your data and are the fastest route to a better score. Re-check a week after any change; the score is computed over a window and moves slowly.

A ten-minute audit

• Open Events Manager, pick Purchase, and note the current EMQ and the parameter list Meta says it receives.
• Send one test purchase and compare the parameters received against what your order data contains. Anything present in the order but missing in the event is a pipeline gap.
• Check a hashed value by hand: normalise a known email exactly as described above, SHA-256 it, and compare with what your system sent. A mismatch means a normalisation bug.
• Confirm that fbc is present on purchases that came from Meta clicks. If it is missing while fbp is present, the click id is being lost between landing and checkout.
• Verify that browser and server purchases share event_id values and that the Deduplicated column in Events Manager is non-zero when both run.
• Re-check the score after seven days; write down the number so you can see the effect of each change.

Summary

EMQ is a measure of how much identity you attach to each event and how correctly you format it. Email and phone do most of the work, click and browser ids connect the event to the ad, and address fields fill in the rest. Normalise exactly, hash consistently, recover fbclid early, and check the diagnostics rather than guessing. PixlBridge applies all of these rules automatically for Shopify purchases today, and will for Amazon purchases once Amazon is available (coming soon); see the Conversions API overview for the full list of parameters sent per event.