Meta CAPI Match Quality: What ‘Good’ Actually Looks Like

Almost every business we work with has Meta Conversions API implemented at this point. Far fewer have actually checked whether their match quality improved as a result – which means most CAPI implementations are running without anyone confirming they’re doing what they were built to do.

What match quality actually measures

Meta scores how confidently it can match an incoming conversion event to a real, known Facebook/Instagram user – based on the customer information parameters you send alongside the event. Higher match quality means better campaign optimisation, because Meta’s algorithm has more confidence in the signal it’s acting on. This is a score you can and should check, not something to assume is fine because the integration “is live.”

The parameters that actually move the needle

Not all customer information parameters carry equal weight. In rough order of impact:

• em (hashed email) – typically the single highest-impact parameter, when available and correctly hashed (lowercase, trimmed, SHA-256)
• ph (hashed phone) – a strong secondary signal, especially valuable for markets where phone is more reliably collected than email
• fbp and fbc – the Facebook browser cookie and click ID, when available client-side and passed through to the server-side event
• external_id – a hashed customer ID from your own system, useful when you can reliably tie it to the same user across sessions
• client_ip_address and client_user_agent – lower-impact individually, but consistently including them provides small, cumulative improvement

What “good” actually looks like

Meta’s Events Manager shows a match quality score directly against each event source. There’s no single universal “good” number since it varies by event volume and available customer data, but as a practical benchmark: if your score sits meaningfully below what your best-performing event source achieves, or if it dropped noticeably after a recent change, that’s worth investigating rather than assuming it’s simply “as good as it gets.”

Common implementation mistakes that quietly cap match quality

Hashing errors. Email must be lowercased and trimmed of whitespace before hashing – a capitalised email or trailing space produces a completely different hash, silently failing to match even though the underlying email is correct.

Missing fbp/fbc entirely. If your server-side implementation doesn’t capture and forward these browser-set values, you’re leaving a genuinely high-value signal unused – this is one of the most common gaps we find.

No deduplication between Pixel and CAPI. If you’re running both client-side Pixel and server-side CAPI for the same conversion without a shared event_id for deduplication, Meta may either double-count the conversion or, in some cases, discard both as conflicting signals.

Sending events too late. Server-side events sent significantly after the actual user action (batched processing, delayed CRM sync) can reduce match quality, since some of the signal Meta uses is time-sensitive.

How to actually check this yourself

1. Meta Events Manager → your Pixel/dataset → Overview tab
2. Look at the Event Match Quality column for each event, not just whether the event count looks reasonable
3. Compare match quality between your client-side Pixel events and server-side CAPI events for the same conversion type – a large gap between the two often points to a missing parameter in the server-side payload specifically
4. Check the diagnostics tab for specific parameter-level warnings Meta surfaces directly

Implementing CAPI is the first step. Checking whether it’s actually improving match quality is the step most implementations skip – and it’s the one that tells you whether the work actually paid off.