Understanding Event Match Quality (EMQ)

When Prism (or any tracking source) sends a conversion event to Meta, Meta tries to match the customer details on that event to a real Meta account. Event Match Quality (EMQ) is Meta's own score, out of 10, of how well that matching worked, shown per event in Events Manager — higher is better. A higher score means more of the events you're sending get tied back to an actual person Meta can act on.

It's a match rate, not a data-quality grade

EMQ isn't judging whether your data is "clean" in the abstract — it's measuring how many identifying parameters (email, phone, name, location, click IDs, IP/user agent) were present and matched a Meta account. Sending more of the right fields raises the score; sending fields that don't match anything doesn't help.

Why it matters

Meta can only optimize delivery and count a conversion toward a campaign if it can attribute that event to someone. An event that arrives at Meta but doesn't match anyone is delivered successfully and still wasted — it doesn't inform bidding, doesn't show up as an attributed conversion, and doesn't help the algorithm learn who converts. That's the quiet cost of low EMQ: nothing errors, nothing alerts you, campaigns just optimize on a thinner signal than they should, and reported conversions undercount what actually happened.

The inverse is also true — improving EMQ on an existing campaign, with no other change, typically improves both reported conversion volume and optimization quality, because Meta is working from a more complete picture of who actually converted.

What raises EMQ

• Send more identifying parameters per event. Hashed email and phone are the strongest matchers; name, city, state, and zip add incremental match strength. See Customer data & privacy for the full list of fields Prism recognizes and how each one is normalized before hashing.
• Capture at least one strong identifier on every form. A lead form with only a name field gives Meta far less to match against than one that also collects email or phone — worth checking on any conversion event that currently sends little beyond the page URL.
• Pass click IDs. fbclid (and Meta's own _fbp browser identifier) let Meta match an event back to the specific ad click that led to it, independent of the customer-data fields. See Customer data & privacy for how these are captured and their lifetimes.
• Deliver server-side rather than relying on the browser alone. Browser-side pixel events are blocked by ad blockers and some browser privacy features; server-side delivery via Meta's Conversions API isn't. See Meta (Facebook) CAPI.

Hashing and privacy

None of this requires sending raw customer data anywhere. Fields like email and phone are normalized and SHA-256 hashed in the visitor's browser before anything leaves it — Prism's servers, and Meta, only ever see the hash. See Customer data & privacy for the full field list and normalization rules.

How Adsidian helps

Prism sends full customer-data parameters and click IDs with every event automatically once you're passing them on the prism('track', ...) call, and it mints Meta's _fbp browser ID itself so match quality doesn't depend on a Meta pixel being present. The client page's Integration Health and Event delivery cards, described in Meta CAPI, surface Event Match Quality when Meta reports it, alongside the delivery reconciliation that shows whether events sent match events received.

Identity coverage

Match quality is only as good as the identifiers each event carries, and different install paths carry different ones. The site snippet, a Shopify pixel, an order webhook, and Prism's own derived events (cart and checkout abandonment) are separate sources, and one of them can quietly fall behind while the others look fine.

Prism's Identity coverage check, on the client's Health page, measures the last 7 days per source: the share of events carrying _fbp, a click ID, an email, a phone, an address, and the visitor's IP and user agent. It raises a warning when:

• a browser source carries _fbp on fewer than half its events;
• fewer than half of a source's purchase or lead events carry an email;
• events reach Meta without an IP address or user agent, which Meta scores as low-quality website events;
• one browser source carries _fbp at less than half the rate of another, which usually means the pixel or snippet on that path is outdated or blocked.

What to do about each:

• Low _fbp on the site snippet: events are firing before prism.js has loaded, or a consent gate is holding the snippet back. Load the snippet early in <head>, and confirm the consent configuration matches your policy.
• Low _fbp or no address on the Shopify pixel: the store is still running an older pasted pixel. Re-paste the loader from your Prism setup once; after that the pixel updates itself. See Install on Shopify.
• Low email on lead events: pass email (and phone, name, and address where you have them) on the prism('track', ...) call. See Customer data & privacy.
• Missing IP and user agent: the events come from a server-side source such as an order webhook. They still count, but they match better when the same purchase also fires from the browser, so keep the pixel or snippet installed alongside the webhook.

FAQ

What's a "good" EMQ score? Meta doesn't publish a fixed threshold, and it isn't the same for every event type or industry. Treat it as a number to trend upward, not a pass/fail line — the fields you add and the identifiers your forms capture are what move it, and Meta surfaces the current score per event right in Events Manager.

Does a low EMQ mean events aren't being delivered? No — delivery and match quality are separate. An event can arrive at Meta successfully (200 response, counted in delivery reconciliation) and still fail to match a real account. That's exactly the silent-waste case EMQ exists to catch.

Do I need a customer's email and phone to get a good score? Not both, but more helps. Even one strong identifier — email or phone — matches far better than name and location alone. If your intake form only asks for a name, adding an email or phone field is usually the single highest-leverage change.

Does raising EMQ mean sending more raw customer data to Meta? No. The parameters that raise EMQ are hashed in the browser before they ever leave it — Meta receives hashes, never the raw email or phone number. See Customer data & privacy.

Will removing a duplicate Meta pixel affect my EMQ? No — it doesn't hurt match quality. Prism generates the _fbp identifier itself and sends full customer information server-side, so EMQ doesn't depend on a browser pixel being installed. See Meta (Facebook) CAPI.