Event Match Quality: What It Is and How to Improve It in Meta Events Manager

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 offline events 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.

If you mostly send purchases made off the website (from a spreadsheet or phone orders), do not chase an EMQ score. Make sure every event carries the customer's email or phone and a stable event_id, as covered in offline conversions from Google Sheets to 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.

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

How this works in Basketly

Basketly 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 fbp and fbc only after consent from your CMP. It reuses an existing _fbp or creates its own identifier, and takes fbc only from a real fbclid; 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_id reaches Meta as a hashed external_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

1. Pick the events that matter. Usually Purchase, AddToCart and InitiateCheckout on your website. PageView normally carries little customer data and is not worth forcing.
2. Record a baseline. The score and the coverage of each parameter from Events Manager, so you have something to compare against.
3. 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.
4. Add browser identifiers (fbp, fbc, IP, user agent) after cookie consent.
5. Add external_id if customers have accounts in your shop.
6. Cut the delay: send each event right after the order.
7. 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 whether your event counts are right. A perfect 10 on a Purchase event that fires twice for one order still means inflated purchases.
• EMQ does not apply to offline events. There, data quality depends on email, phone and sending regularly.
• Basketly sends email, phone, external_id and 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.