Meta CAPI Event Match Quality: what actually moves EMQ from 5 to 9

Meta Event Match Quality (EMQ) is the score, from 0 to 10, that Meta uses internally to judge whether a Conversions API event can be tied to a known Meta user. Higher EMQ means better ad optimisation, more accurate attribution, lower cost per action. Most CAPI deployments sit between 4 and 6; the delta between 6 and 9 is almost all revenue.

This post walks through the identity parameters Meta uses for matching, in roughly the order of contribution to EMQ, and shows what sending a complete set looks like.

The parameters that actually matter

In our experience with production CAPI pipelines, these are the identity fields that move EMQ, roughly ranked by marginal contribution:

• email (em) — SHA-256 hashed, lowercased. Single biggest lift. Even one hashed email in an event typically moves EMQ from 3-4 up to 6-7.
• phone (ph) — SHA-256 hashed, E.164 format, no spaces or punctuation.
• external_id — your own stable user ID (user_id from identify calls). Accepts hashed or raw; hashed is preferred.
• _fbp — the Meta browser cookie. Auto-generated on first visit. Must persist across sessions.
• _fbc — Meta’s click ID cookie, captured from fbclid URL params. Required for click-attributed conversions.
• first_name (fn) / last_name (ln) — SHA-256 hashed, lowercased. Moderate lift for identify-tied events.
• city (ct) / state (st) / zip (zp) / country (country) — SHA-256 hashed, lowercased. Small individual lift but they compound.
• client_ip_address + client_user_agent — included automatically by Signal’s server-side delivery. Required by Meta for match quality scoring.
• dob (db) / gender (ge) — SHA-256 hashed. Marginal lift for tightly targeted audiences.

Sending all of the above where you have them typically gets EMQ to 8-9. 10 is effectively reserved for events where Meta has independently verified every parameter.

What "sending" actually means

Meta’s CAPI spec accepts these parameters inside user_data on every event. The hash format is strict: SHA-256, hex-encoded, lowercased with whitespace trimmed before hashing. A single byte difference (e.g. [email protected] vs [email protected]) yields a completely different hash and Meta will treat it as unmatched.

If you are sending CAPI today via a vendor tag or plugin, inspect one of your events in the Meta Events Manager. You will almost always find 3-4 fields populated and 6+ missing.

Why client-side deployments struggle with EMQ

The Meta Pixel in the browser can only see the parameters your page exposes to it — usually _fbp, _fbc, and whatever you pass to fbq('track', 'Event', { ... }). It has no structured access to the authenticated user’s email, phone, or address book data unless you pass it explicitly at every fbq call, which few teams do consistently.

A server-side CAPI pipeline solves this differently: the server already knows who the user is (from your auth system, CRM, or identify calls on the collector), so it can attach every identity parameter to every event without needing the browser to pass anything.

A complete CAPI event with Datafly Signal

Here is what a purchase event looks like after Signal’s Meta CAPI blueprint has enriched it:

event_name: Purchase
event_time: 1713355200
event_id: ord_A9F3B2
action_source: website
event_source_url: https://shop.example.com/thank-you
user_data:
  em: [<sha256 of lowercased email>]
  ph: [<sha256 of E.164 phone>]
  fn: [<sha256 of first_name>]
  ln: [<sha256 of last_name>]
  ct: [<sha256 of lowercased city>]
  zp: [<sha256 of postcode>]
  country: [<sha256 of country>]
  external_id: [<sha256 of customer_id>]
  fbp: fb.1.1713355000.1234567890
  fbc: fb.1.1713355000.abc123def456
  client_ip_address: 203.0.113.42
  client_user_agent: "Mozilla/5.0 ..."
custom_data:
  currency: GBP
  value: 142.50
  content_ids: ["sku-1234", "sku-5678"]
  content_type: product

Every _ga-adjacent field hashed correctly, _fbp and _fbc present, IP and User-Agent captured server-side. EMQ on a production site running this pattern sits between 8 and 9.

Common traps

• Trimming matters. Lowercase and strip leading/trailing whitespace before hashing. We have seen EMQ drop by 2 from a single trailing space.
• Phone formatting. E.164 with the leading +, no spaces, no hyphens, no parentheses. +447700900123 hashes differently from 07700 900 123.
• Do not hash already-hashed fields. Meta expects raw hashes; some pipelines accidentally hash them again when they re-enter the pipeline.
• Check event_id uniqueness. Meta uses event_id to deduplicate between browser Pixel and server CAPI. If you have both running during migration, the event_id must be identical on both paths. Signal handles this automatically with the messageId field.

For a full server-side CAPI walkthrough including the Datafly Signal blueprint, see the Meta Conversions API solution page.