How Do You Get a 9+ Event Match Quality Score?

Reaching a 9+ Event Match Quality (EMQ) score requires sending both hashed email and hashed phone on every conversion event, plus the _fbp and _fbc cookies, the IP address, and the user agent. Most accounts cap at 6–7 for a reason that has nothing to do with their tracking configuration: their form only collects an email address.

That’s the thing almost nobody says out loud. You can only transmit what you collect. Your EMQ ceiling is set by your form, not your pixel — and no amount of server-side tooling raises a ceiling that was decided the day someone designed the signup form.

What counts as a good EMQ score?

Meta publishes four EMQ bands, and the practical implications differ sharply between them:

Most guidance stops at “aim for 8.” That’s the floor of acceptable, not the target. The gap between 8 and 9.5 is smaller in raw score than the gap between 5 and 8, but it compounds differently: at 9+, Meta is matching effectively all of your conversions, so every optimisation decision the algorithm makes is based on the full picture rather than a sample. On a mature account spending real money, that difference shows up as steadier scaling and less erratic cost per result.

The practical target is therefore 9+ on your primary conversion event — Purchase or Lead, whichever you optimise toward. Upper-funnel events like ViewContent will always score lower for everyone, because anonymous browsers simply carry fewer identifiers.

Why is your EMQ stuck at 6 or 7?

Almost always because you’re sending an email and not much else — and that isn’t a bug in your tracking, it’s a consequence of your form.

Meta weights match parameters unequally. Hashed email carries the most weight; hashed phone is second. Everything after those two — names, location fields, browser cookies, IP, user agent — adds meaningful but smaller increments. Which produces a fairly predictable arithmetic:

Look at where the jump happens. Adding phone is the single largest step available to most accounts — bigger than any amount of server-side re-plumbing. An account running a flawless Conversions API integration on an email-only form is operating at its ceiling at 7. The integration isn’t underperforming; the form is.

This is why “improve your EMQ” advice so often disappoints. It’s written as a tracking problem — check your hashing, verify your event IDs, confirm your cookies — and those things genuinely matter. But if the email field is the only identifier your form ever collects, every one of those fixes lands you at the top of a band you can’t escape.

The ceiling is upstream. It’s a form-design decision, made before a single event fires.

Doesn’t requiring a phone number hurt conversion rate?

Yes — and pretending otherwise would be dishonest. Every additional required field costs some completion rate, and phone is among the more sensitive asks. A form that requires phone will typically convert a bit lower than one that doesn’t.

So the real question isn’t “does it cost anything” but “what does it buy, and can the cost be offset?”

What it buys: a jump from roughly 7 to 9+ on your primary conversion event, which means the bidding algorithm trains on matched conversions rather than a partial subset. For accounts where paid acquisition is the growth engine, better optimisation signal compounds over every future dollar spent. A slightly smaller number of leads, each of which teaches the algorithm properly, frequently outperforms a larger number it can’t match.

How the cost gets offset: by not losing the people who started. Conventional tracking only ever sees a phone number if the visitor completes and submits the form. Capture-as-they-type changes that arithmetic — a visitor who fills in email and phone and then abandons at the next field has already handed over the two highest-weight identifiers. Their event still carries full match data.

That reframes the trade-off. The conversion-rate cost of a phone field is real, but it’s calculated against completed submissions. When abandoned forms also produce usable, high-match events, the field earns its keep across a much larger share of traffic than the completion rate alone suggests.

Practical guidance: put email first and phone second, before any qualifying questions. If someone abandons, they abandon after the identifiers rather than before.

What else has to be right?

Collecting email and phone sets the ceiling. Four technical details determine whether you actually reach it:

1. Normalise before hashing. Email must be lowercased and trimmed before SHA-256; phone must be reduced to E.164 digits only. +1 (415) 555-1234 and 14155551234 hash to completely different values, and a mis-normalised hash is accepted by the API while silently failing to match. This is the most common way a full-PII payload still scores badly.
2. Never hash what shouldn’t be hashed. _fbp, _fbc, client_ip_address, and client_user_agent are sent as plain text. Hashing them doesn’t just fail to help — it removes signal the matcher would otherwise have used.
3. Send _fbc in Meta’s format. When someone arrives from a Meta ad, the fbclid in the URL has to be wrapped as fb.1.<timestamp>.<fbclid>. The raw click ID on its own doesn’t match.
4. Include external_id. A stable identifier for the person across events gives Meta an additional handle, particularly for repeat conversions. Get the collection right and these four wrong, and you’ll sit in the 6s wondering why. Get both right and 9+ is the expected outcome, not a lucky one.

How does PartialLeads deliver 9+ consistently?

When a form requires both email and phone, PartialLeads customers consistently land at EMQ 9 or higher. That’s an observed outcome across customer accounts, and it isn’t luck — it’s what happens when the collection problem and the technical problem are both solved in the same pipeline.

Both high-weight identifiers get captured — including from people who never submit. The tag records email and phone field by field as the visitor types, with a final flush before the page unloads. Completed submissions carry full PII, and so do abandoned ones, which means the share of your traffic producing a high-match event is substantially larger than your form’s completion rate.

Normalisation and hashing happen server-side, to Meta’s specification. Email lowercased and trimmed, phone reduced to E.164 digits, names lowercased — then SHA-256. The silent mis-hashing failure mode doesn’t occur, because the customer never writes the hashing.

The unhashed parameters are sent unhashed. _fbp and _fbc as cookie values, client_ip_address and client_user_agent from the actual session. When the _fbc cookie is missing but a fbclid was in the landing URL, it’s reconstructed in Meta’s required format server-side.

The visitor identity survives long enough to matter. The visitor ID is set by the server rather than by JavaScript, so Safari’s tracking prevention doesn’t sever it after seven days — which matters whenever the conversion happens days after the click.

And external_id ships on every event, giving Meta a stable handle across a person’s repeat conversions.

The result is a payload carrying the complete high-weight set — em, ph, fn, ln, fbp, fbc, client_ip_address, client_user_agent, external_id — on every dispatched event. That’s the configuration Meta scores in the 9–10 band.

The honest conditions. The 9+ outcome depends on the form requiring both email and phone — that’s the load-bearing precondition, and it’s why this article spends so long on form design. Beyond the payload, EMQ also has a platform-side component: Meta has to be able to resolve those people in its own graph. An audience of work email addresses with no consumer footprint can score lower even with a flawless payload. And keep a base Meta Pixel installed — the _fbp cookie it sets is a match input your server events reuse.

The path to 9+, in one view:

Setup is one tag. The free tier is enough to watch your EMQ move in Meta’s Events Manager before paying anything — and because the score refreshes roughly every 48 hours on a rolling seven-day window, you’ll know inside a week.

Sources

1. Meta Business Help — About Event Match Quality: https://www.facebook.com/business/help/765081237991954
2. Meta for Developers — Customer information parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
3. Meta for Developers — Conversions API best practices: https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices
4. Meta for Developers — fbp and fbc parameters: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
5. Meta for Developers — Test Events tool: https://developers.facebook.com/docs/marketing-api/conversions-api/payload-helper