When a client asks whether their Conversions API setup is working, the first number they point to is Event Match Quality. It is a useful number, but it is often treated as a grade for the whole tracking setup, which it is not. I have written about why server-side CAPI reduces signal loss and how it compares with the pixel. This piece is narrower: what EMQ is, which customer information parameters move it, and a checklist I run through field by field.
What EMQ is, and what it is not
Event Match Quality is a score from 0 to 10 that Meta shows in Events Manager for each event, for example Purchase or Lead. It estimates how effectively the customer information parameters sent with that event can be matched to a Meta account. Meta's documentation on customer information parameters describes the fields it accepts and the formatting it expects; Events Manager then shows the score and which parameters it would like more of. Third-party guides, including Usercentrics and Elevar, describe bands where roughly 8 and above is great and 6 to 8 is good, though Meta's own wording in your account is the reference. What EMQ does not measure matters just as much. It does not tell you whether events are deduplicated, whether a Lead is a real lead, or whether the value is correct. A setup can score 9 while double counting every purchase. A fake but well-formatted email matches no account but will not necessarily alert you either. So I read EMQ as a measure of match keys, and check deduplication and event accuracy separately.
The parameters that carry the most weight
Not every field is equal. Email (em) and phone (ph) are the strongest identifiers because they are unique to a person and most Meta accounts carry them. Both must be normalised then hashed with SHA-256: email lowercased and trimmed, phone in international format with country code and no symbols, so an Indian number starts with 91. The external_id, your own customer or lead ID, helps Meta link events from the same person across sessions; it should be consistent across browser and server events. The fbp cookie and fbc click ID come from the browser. fbc is especially valuable because it ties the event to a specific ad click, and it is often missing when the fbclid in the landing page URL is not captured and stored. client_ip_address and client_user_agent are sent unhashed and must be the user's, not your server's. A common mistake in server-side setups is sending the IP of the hosting server, which adds nothing. Name, city, state, zip and country add incremental lift once the main keys are present.
Field checklist I run on every setup
For each important event, I check the payload in Events Manager's test events tool and the event details view. Email: present when the user gave one, lowercased, trimmed, hashed once (not hashed twice). Phone: present, with country code, digits only before hashing. external_id: present and identical in browser and server versions of the same event. fbp: present on browser and forwarded to server. fbc: present when the session started from an ad click, built from the fbclid captured on landing and stored in a cookie. client_ip_address: the user's IP, IPv6 preferred where available. client_user_agent: the user's browser string, required for website events sent from a server. First and last name, city, state, zip, country: lowercased and hashed according to Meta's formatting rules. event_id: present and identical across browser and server for deduplication. Finally, check timing: Meta's docs expect events to be sent close to when they happen, and very delayed events lose value. Every missing field on this list is usually a fix of an hour or two, not a rebuild.
Where the missing data usually is
Low EMQ is rarely a CAPI problem. It is usually a data capture problem upstream. On ecommerce sites, guest checkout means you only get the email at the last step, so earlier events like AddToCart and InitiateCheckout carry very little. You can improve this for returning visitors by reading stored identifiers for logged-in customers, but you should not expect top-of-funnel events to score like Purchase. On lead generation sites, forms that ask only for a phone number limit you to one identifier, and a phone field without a country selector produces numbers that cannot be normalised correctly. Third-party checkouts are another gap, because the payment or checkout provider holds the customer data, not your site; I cover that case for Indian stores in the piece on Shiprocket and GoKwik checkout tracking. And consent matters: if a user declines tracking, you should not send their data, so EMQ is capped by your consent rate, which is correct.
How much to chase the score
Higher EMQ generally means Meta can attribute more conversions and has better data to optimise on, which is why it is worth fixing the basics. But past a point it becomes vanity. I aim for the main optimisation event, Purchase or Lead, to sit in the upper bands Meta labels as good or great, with email, phone, external_id, fbc, IP and user agent all present at high coverage. Beyond that I would rather spend the time on deduplication, correct values and moving the optimisation event closer to real revenue, for example confirmed rather than placed orders for COD stores. EMQ also moves slowly, because it is calculated over recent events, so give a change a few days before judging it. And never inflate it by sending data users did not provide or did not consent to share. That is a compliance risk, and Meta's terms require that you have the right to share the data.
Sources
Meta for Developers, Conversions API customer information parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters . Usercentrics, Improve Meta Event Match Quality score: https://usercentrics.com/knowledge-hub/improve-meta-event-match-quality-score/ . Elevar, What is Event Match Quality score: https://docs.getelevar.com/docs/what-is-event-match-quality-score-in-facebook
FAQ
Meta shows EMQ on a 0 to 10 scale with descriptive bands. Third-party guides such as Usercentrics describe 8 and above as great and 6 to 8 as good. I aim for the main optimisation event to sit in Meta's good or great band.
Events Manager shows match quality for events that carry customer information, and in practice the score is most useful for Conversions API events, where you control which parameters are sent. Check the event details view in your own account for what it reports.
No. Meta's customer information parameters documentation lists client_ip_address and client_user_agent as fields sent without hashing. Email, phone, names and location fields are normalised and hashed with SHA-256.
Usually a field stopped arriving: a checkout or theme update removed a data layer value, a consent change reduced coverage, or a server change started sending the server IP. Compare parameter coverage in Events Manager before and after the drop.