Meta Event Match Quality improvement guide
Event Match Quality scores how well Meta can attach your events to real people, and it responds to a small number of parameters rather than to all of them. Email and phone carry most of the weight, then external ID, then the click and browser cookies. Sending more fields badly moves the score less than sending five properly — and normalization before hashing is where nearly every implementation loses its points, because a malformed value produces a perfectly valid hash that matches nothing and errors nowhere.
Free30 minutesNo obligation
Meta EMQ · what breaks
Where teams get this wrong — Meta EMQ
- 01
Hashing before normalizing
An email with a capital letter hashes to a valid, useless string. Nothing reports a problem.
- 02
Adding parameters instead of fixing them
Five correct fields beat ten sloppy ones. Coverage isn't the same as quality.
- 03
Reading the overall score
It's per event. A healthy average can hide a Purchase at 3, which is the one that matters.
Meta EMQ · the fix
What a correct implementation looks like — Meta EMQ
Values normalized then hashed at the server
Lowercase, trimmed, phone in E.164 without punctuation.
External ID included
A stable customer or order identifier. The most under-used field available.
fbc and fbp captured in the browser and forwarded
Not regenerated server-side.
Score read per event, over a week
Not overall, not on one day.
Meta EMQ · architecture
The parameters that move the score — Meta EMQ
Meta's documentation defines the current normalization rules and the full field list. These are the ones that carry the weight in practice.
- 1
Email
Lowercase, trimmed, then hashed. Carries the most weight of any single field.
- 2
Phone
E.164 format, digits only, no brackets or spaces, then hashed. The second heaviest.
- 3
External ID
A stable customer or order identifier, hashed. Materially useful and routinely omitted.
- 4
fbc
The click cookie, derived from fbclid. Only exists if fbclid was captured on landing — a very common gap.
- 5
fbp
The browser cookie. Set by the Pixel, forwarded with server events.
- 6
Name, city, postcode
Contribute less individually. Worth sending when you have them clean, not worth chasing.
Meta EMQ · diagnose
Common mistakes and how to validate each — Meta EMQ
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Case or whitespace left in before hashing
Read the raw value on a live conversion before it's hashed. This is where most points are lost.
- 02
Double hashing
The browser hashes, the server hashes again. Compare raw and dispatched values on one real conversion.
- 03
fbc missing
Click your own ad and check whether fbclid is captured on landing and persisted.
- 04
External ID never sent
Check the payload. Most implementations don't include it and it's free to add.
- 05
Overall score read instead of per event
Open the per-event view. Purchase is the one that matters.
Meta EMQ · prove
How to prove your implementation is right — Meta EMQ
Against your own records and a live payload, not against a preview screen.
Source of truth
Meta Events Manager match quality per event, over seven days
- EMQ at 8 or above on the primary conversion event.
- Parameter coverage read from a real payload, per event.
- Normalization verified against Meta's current specification.
- fbc and fbp confirmed present on server events.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
Meta EMQ · free audit
What we check in the free audit
- Case or whitespace left in before hashing
- Double hashing
- fbc missing
- External ID never sent
- Overall score read instead of per event
Checked against
Meta Events Manager match quality per event, over seven days
Free30 minutesNo obligation
Meta EMQ · when not to buy
What this reference deliberately leaves out — Meta EMQ
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Meta doesn't publish the exact weighting of each parameter, so the ordering here is from what we observe across accounts rather than from documentation.
- Normalization rules are Meta's and change. Verify against current documentation before building.
- The score is computed over a rolling window whose exact length Meta doesn't publish; give changes several days before judging them.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
Meta EMQ · what we deliver
The checklist — Meta EMQ
EMQ read per event, not overall
Purchase specifically.
Email lowercased and trimmed before hashing
The single most common fix.
Phone in E.164 with no punctuation
The second most common.
External ID present
Hashed, from a stable identifier.
fbc and fbp forwarded from the browser
fbc only exists if fbclid was captured on landing.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Meta EMQ questions, answered
8 or above on your primary conversion. Below 5 means Meta is matching a minority of your events and your attribution is materially understated.
No. A malformed parameter contributes nothing. Five correct fields beat ten sloppy ones, and normalization is usually the whole problem.
The server, from raw values. Browser hashing risks double hashing and hides normalization errors.
Because the values are malformed. A hash of an unnormalized email is valid and matches nothing, and no system reports it.
WhatsApp