EMQ score stuck low — how to raise Meta event match quality

Event match quality (EMQ) is a score out of 10 that Meta calculates for each server event from three things: which customer information parameters arrived, how clean their formatting was, and what share of event instances Meta could tie back to a real account. Meta's recommended floor is 6.0, events below 3.0 are excluded from conversion lift studies entirely, and a Purchase event stuck at 6 or 7 almost always means the same thing — the hashed email and phone that carry most of the matching weight never left your store.

The score is not a health check on your pixel, and it is not an attribution number. It only exists for events delivered through the Conversions API, it only answers "can Meta tell who this was", and on a Shopify store running the stock Facebook & Instagram channel it tends to sit at exactly the value that looks fine and is not. The fix order below is the one that moves it.

What the score actually measures

Meta documents the calculation in one sentence: the score is based on which customer information parameters are received, the quality of the information received, and the percentage of event instances matched to Meta accounts. It is computed per event type — Purchase gets its own score, PageView gets its own — from the last 48 hours of data, so a store that sends events in bursts will see the number swing. The Help Center describes the scale as 0 to 10 and the developer documentation says 1 to 10; either way you are reading one number out of ten, refreshed roughly daily.

Two consequences fall straight out of that definition:

• Only matched events are usable. Meta states it plainly: you can use only matched events for attribution and ad delivery optimization, and unmatched events can still be used for basic measurement but nothing else. A store at EMQ 5 is not merely under-optimised — roughly half its purchase signal is inert.
• It is weighted, not counted. Sending fifteen parameters does not beat sending four good ones. Meta publishes the priority ranking, and it is top-heavy: a handful of fields do most of the matching, the rest add incremental confidence.

Data table+

Meta rates email and the click ID as High — the name and address fields a Shopify checkout can supply are Low — source: Meta Business Help Center, About event match quality, accessed 2026-10-15 — priority tiers mapped High=3, Medium=2, Low=1

Category	Value
Email	3
Click ID (fbc)	3
Phone number	2
External ID	2
Browser ID (fbp)	2
First + last name	1
City	1
ZIP / postal	1

Source: Meta Business Help Center, About event match quality, accessed 2026-10-15 — priority tiers mapped High=3, Medium=2, Low=1

Worth knowing before you trust any article on this topic, this one included: Meta's own two documents disagree about the click ID, listing it as High in the Help Center and Medium in the EMQ fact sheet. Email is the only parameter every Meta document puts at or near the top, which is why it is always the first thing to check.

Why a Shopify store stalls at six or seven

Because the parameters that score are the ones a browser-side integration never has. Shopify's stock channel passes the browser identifiers reliably — fbp, fbc, client IP and user agent — and typically omits hashed email, phone and address, because the pixel fires on the page while the contact data only exists once the order does. Those are precisely the high- and medium-weight fields, so the score climbs to the mid-range and stops.

Four quieter causes sit underneath that, in the order we hit them:

The click ID never arrives. fbc is one of the strongest matching parameters, and a share of your Meta traffic reaches you without one: Safari's link tracking protection strips fbclid from URLs in Private Browsing, in Mail and Messages, and inside the Instagram in-app browser. That traffic cannot be given a click ID you never received.

The browser cookies are not forwarded. Even when fbp and fbc exist in the browser, a server event only carries them if the implementation reads them and includes them in the payload. Setups bolted together quickly after Shopify's checkout extensibility migration commonly do not, which is why a server event can arrive with an email attached and nothing else.

Formatting errors are silent. Email hashed without lowercasing and trimming first, phone numbers without a country code, a birthdate not in YYYYMMDD before hashing — none of these throw an error. The event lands, is counted, and fails to match. Meta's own guidance is explicit that formatting and content of the value matter, not just the presence of the field.

Two integrations are racing. A Shopify app and a tag-manager setup both sending Purchase, each with a partial version of the same event, produces duplicate pairs that fail to deduplicate. Meta's baseline rules also reject events carrying only broad combinations of geography — the score punishes padding, not just absence.

What each path puts on a Purchase event Source: Meta Conversions API parameter documentation; AdBeacon and WeltPixel Shopify EMQ guides, 2026 — typical behaviour of the stock channel, checked 2026-10-15

Parameter Meta scores	Stock Shopify channelbrowser-side	Server-side from order dataHeadless
The fields that carry the score
Hashed email (em)	Not sent (does not offer this)	Sent (wins this row)
Hashed phone (ph)	Not sent (does not offer this)	Sent (wins this row)
Address fields (ct, st, zp)	Not sent (does not offer this)	Sent (wins this row)
Stable ID for guests	None (does not offer this)	Derived from order (wins this row)
The fields both paths can send
Click ID (fbc)	Sent if present	Forwarded from browser
Browser ID (fbp)	Sent	Forwarded from browser
Client IP + user agent	Sent	Sent

Source: Meta Conversions API parameter documentation; AdBeacon and WeltPixel Shopify EMQ guides, 2026 — typical behaviour of the stock channel, checked 2026-10-15

Read your own score before you change anything

Events Manager → Data sources → your dataset → Overview, pick the event you care about, open View details and find the event matching panel. Two things are shown there: which customer information parameters actually arrived, and the percentage of events received. That panel is the diagnosis — if hashed email does not appear, no amount of campaign-side work will move the number.

Three checks worth doing in the same sitting:

1. Confirm you have a score at all. EMQ exists only for website events sent through the Conversions API. No server events means no score; a number that will not appear is a delivery problem, not a quality problem.
2. Run one checkout through Test Events. Place a real order and read the payload: is em there, is ph there, are fbp and fbc carried through, is the email lowercased and hashed?
3. Count your integrations. If a Shopify app and a tag manager are both sending Purchase, you are scoring two partial payloads against each other. One of them should go.

Data table+

At 6 to 7 roughly 60% of purchases are identifiable — every point above it is about ten points of matched events — source: Niblin EMQ diagnostic guide, 2026, as cited by AdBeacon — midpoints of that guide's stated match-rate bands; Meta does not publish this mapping

Category	Value (%)
4–5 (partial)	40
6–7 (native)	60
8–9 (server)	80

Source: Niblin EMQ diagnostic guide, 2026, as cited by AdBeacon — midpoints of that guide's stated match-rate bands; Meta does not publish this mapping

The fix, in the order it pays

1. Hashed email on every Purchase, sourced from the order. Lowercase and trim, then SHA-256. This is the single highest-priority parameter in every Meta document, and on most stores it is the first hour of work.

2. Phone, in E.164 with the country code. Adding phone to an email-only setup is routinely the largest single jump available.

3. A stable external_id, including for guests. Derive it from the order so a guest purchase does not lose a medium-weight identifier just because nobody logged in.

4. Forward fbp and fbc from the browser into the server payload. Capture the click ID at landing where you can, accept that Safari will strip it for some traffic, and refresh both values rather than caching them.

5. Make the two copies deduplicable. Identical event_name, plus event_id on both sides — Meta advises also including external_id and fbp. The rules are shorter than they sound and the deduplication explainer walks through them.

6. Remove the duplicate integration. One sender, not two.

7. Wait out the window. The score is built from the last 48 hours; judge the change a day or two later, not the same afternoon.

What a higher score still does not fix

EMQ answers "can Meta identify this person", not "did the ad cause this". The Events Manager purchase gap is still mostly attribution-window arithmetic even after your score climbs, modelled conversions still fill in some of what the browser could not observe, and a perfect score will not deduplicate two integrations sending the same event. If your pixel-side events are thin to begin with, that is a separate diagnosis — the 12-cause pixel checklist covers it, and the 2026 state of Meta tracking report shows how common the underlying gaps are across ad-running Shopify stores.

Getting there without building it yourself

Everything above is order-data work: email and phone from the order, a stable guest identifier, browser cookies carried into the server payload, one sender that deduplicates against the pixel. That is what Headless does — server-side Meta Conversions API delivery with first-party enrichment on every Purchase, alongside CNAME masking and 39 metrics Shopify will not show you, from $34 a month on founding pricing for the first 25 stores.

If you would rather see your store's own data first: install Headless and watch your checkout's server events land in the dashboard alongside your revenue, from $34 a month on founding pricing.