Meta Conversions API · Ads Data Quality

Meta Conversions API Event Match Quality (EMQ): Why a "Successful" Event Can Still Score Low (2026)

Your server reports every event as delivered. Meta's own Events Manager still shows a mediocre score next to it. EMQ is the reason those two things are not the same thing.

Once a Conversions API (CAPI) integration is live, most teams check exactly one thing: did the event get accepted? A 200 response from the /events endpoint feels like confirmation that everything downstream is working. It is not. Meta scores every event it receives on a separate axis — how well the customer information in that event can be matched to a real Meta account — and a technically successful send can still score low on that axis, quietly capping how much the ad system can attribute and optimize toward it.

What Event Match Quality actually measures

A score out of 10, not a pass/fail flag

Event Match Quality (EMQ) is calculated by looking at which customer information parameters your server sends, the quality of that information, and the percentage of event instances that get matched to a Meta account. It is a graded score, not a binary success signal.

Calculated in real time, per event name

Meta calculates EMQ in real time and reports it separately for each event name — Purchase, Lead, CompleteRegistration, and so on can each carry a different score inside the same dataset, because each depends on which match keys were actually present for that event.

Web-only, as documented today

Meta's own documentation states EMQ is currently available only for web events. Offline events, app events, conversion leads, and integrations still in alpha or beta do not get an EMQ score at all — a scope limit that is easy to miss when auditing a mixed web/app/offline setup.

The four systems Meta scores separately

  1. Match key coverage (the EMQ score itself)

    Which identifiers — email, phone, IP address, user agent, external ID, and others — are present, correctly formatted, and consistently sent for each event. Missing or malformed identifiers pull the score down even when the event itself arrives without error.

  2. Event coverage

    The 7-day average percentage of Meta Pixel (browser) events that are also covered by a matching Conversions API (server) event, sharing a deduplication key. Meta's own documented goal for this metric is 75%; falling well short of it means the server side is only backing up a fraction of what the browser already reports.

  3. Deduplication

    When both the Pixel and the Conversions API report the same real-world action, Meta needs a shared key — typically event_id or external_id — to recognize it as one event, not two. Deduplication key feedback shows what percentage of browser and server events actually carry that shared key.

  4. Data freshness

    The delay between when an event happened and when Meta received it. Meta's stated best practice is real-time delivery; the API reports an upload_frequency value (for example real_time or hourly) per event name, and a consistently delayed feed can undercut attribution even when match quality itself is strong.

Why a "received" event still gets discounted

Meta's Dataset Quality API returns named diagnostics for exactly this situation — specific, documented reasons a technically successful event is still being scored down. Two of the diagnostics published in Meta's own reference are worth knowing before you go looking for a bug that was never a bug:

Server sending IPv4 addresses instead of IPv6

Meta's documentation flags this directly, describing IPv6 as the industry standard with better durability for the integration, and recommends updating server and DNS configuration accordingly.

Server IP address not matching the Pixel's IP address

If the client IP address sent from the server does not match what the Pixel captured in the browser for the same customer, Meta documents this as a direct hit to attribution and optimization — not merely a cosmetic mismatch.

Neither of these produces an error response. Both are silent, and both are common in setups where the server-side event is built from request headers or a proxy layer rather than the same raw client data the Pixel sees.

What the metrics look like when a setup is actually healthy

/10EMQ is scored on a 0–10 scale, per event name, in real time
75%Meta's documented event coverage goal for Pixel events also covered by CAPI
real_timeMeta's stated best-practice data freshness — not hourly or batched

Common causes behind a low or stagnant EMQ score

  • Match keys present in the Pixel payload but never forwarded to the server-side event (email or phone hashed in the browser, dropped before the CAPI call)
  • Missing or inconsistent event_id / external_id values, breaking deduplication and inflating apparent volume while depressing match confidence
  • Server IP address sourced from infrastructure (load balancer, proxy, CDN edge) instead of the actual customer connection
  • Partner or agency integrations sending events without the correct partner_agent attribution, which affects how EMQ is calculated and attributed
  • Access tokens generated through incompatible onboarding paths — Meta's own documentation notes the client system-user token onboarding method is not compatible with the EMQ/Dataset Quality API today

Scaling this across many pixels is its own problem

EMQ is visible per pixel inside Events Manager, but Meta's documentation is explicit that this view does not scale for a tech provider, agency, or platform managing many client pixels at once — which is exactly the position most SaaS platforms and marketing tools integrating the Conversions API are in. Programmatic access exists (the Dataset Quality API), but it needs its own permission tier, and the Advanced access level required for higher rate limits and larger-scale monitoring goes through Meta App Review, not a self-serve toggle.

Note: Event Match Quality, event coverage targets, and diagnostic messages described here are drawn from Meta's own Conversions API / Dataset Quality API developer documentation as of 2026 and are subject to change by Meta at any time. This page is not an official Meta publication or partnership, and no specific EMQ score, ad performance outcome, or approval timeline can be promised.

Related reading: the Facebook Conversions API setup guide covers the dataset, system user token, and App Review prerequisites this scoring system sits on top of, and the Meta Advanced Access guide explains the review step behind the higher-tier ads_management access this kind of at-scale monitoring needs. For hands-on setup and App Review support, see the Facebook App Review service page.