--- title: 'Meta Event Match Quality: diagnose a low or falling score' description: 'Understand Meta Event Match Quality (EMQ), diagnose a low or falling score, and improve customer matching without confusing it with delivery or deduplication.' canonical: 'https://plainrouter.com/library/meta-event-match-quality' format: Explainer published_at: '2026-09-03' last_updated: '2026-10-04' --- # Meta Event Match Quality: diagnose a low or falling score Meta Event Match Quality (EMQ) is a 1–10 score for how well server-event customer information matches Meta accounts. Improve accurate, consented matching fields consistently. Plainrouter normalizes and hashes supported customer fields and displays stored Meta EMQ snapshots. A higher score does not prove delivery, deduplication or attribution. ## How can you improve Event Match Quality without sending unnecessary personal data? Use accurate fields you already collect with consent, and fix formatting or dropped fields before collecting anything new. Do not add unrelated personal data just to raise the score. Check existing email and phone normalization first, then consistent external\_id, available fbp/fbc and the real client IP and user agent. This is a troubleshooting sequence, not a promise that those fields have a universal ranking or that more data improves results. Browser User-Agent remains required for website CAPI events. Plainrouter handles supported customer fields before delivery and shows [stored Meta quality snapshots](). It does not provide a Meta EMQ score for each individual conversion; delivery traces and the stored matching score answer separate questions. ## Which customer information parameters affect Event Match Quality? | Meta parameter | Hashing before Meta delivery | Legitimate source | Missing rate | | --- | --- | --- | --- | | em | Required: normalized SHA-256 | Consented email from checkout or CRM | Unknown; measure your eligible events | | ph | Required: normalized SHA-256 | Consented phone number with country code | Unknown; measure your eligible events | | fn | Required: normalized SHA-256 | Consented first name | Unknown; measure your eligible events | | ln | Required: normalized SHA-256 | Consented last name | Unknown; measure your eligible events | | db | Required: normalized SHA-256 | Date of birth, only where already legitimately collected | Unknown; measure your eligible events | | ge | Required: normalized SHA-256 | Gender, only where already legitimately collected | Unknown; measure your eligible events | | ct | Required: normalized SHA-256 | Consented city | Unknown; measure your eligible events | | st | Required: normalized SHA-256 | Consented state or region | Unknown; measure your eligible events | | zp | Required: normalized SHA-256 | Consented postal code | Unknown; measure your eligible events | | country | Required: normalized SHA-256 | Consented country code | Unknown; measure your eligible events | | external\_id | Recommended; keep representation consistent across channels | Your stable customer or loyalty ID | Unknown; measure your eligible events | | client\_ip\_address | Do not hash | The visitor’s actual browser IP, not your server’s | Unknown; measure your eligible events | | client\_user\_agent | Do not hash | The visitor’s browser User-Agent; required for website events | Unknown; measure your eligible events | | fbc | Do not hash | Permitted \_fbc cookie or captured fbclid | Unknown; measure your eligible events | | fbp | Do not hash | Permitted \_fbp browser cookie | Unknown; measure your eligible events | | subscription\_id | Do not hash | Subscription ID for the transaction | Unknown; measure your eligible events | | fb\_login\_id | Do not hash | Meta app-scoped login ID | Unknown; measure your eligible events | | lead\_id | Do not hash | Meta Lead Ads lead ID | Unknown; measure your eligible events | | anon\_id | Do not hash | App installation ID; app events only | Unknown; measure your eligible events | | madid | Not specified in the cited table; follow app-specific guidance | Android advertising ID or Apple IDFA | Unknown; measure your eligible events | | page\_id | Do not hash | Facebook Page associated with the bot event | Unknown; measure your eligible events | | page\_scoped\_user\_id | Do not hash | Messenger webhook’s page-scoped user ID | Unknown; measure your eligible events | | ctwa\_clid | Do not hash | Click-to-WhatsApp ad click ID | Unknown; measure your eligible events | | ig\_account\_id | Do not hash | Business Instagram account ID | Unknown; measure your eligible events | | ig\_sid | Do not hash | Instagram messaging webhook’s scoped user ID | Unknown; measure your eligible events | Matching-parameter requirements checked on October 4, 2026 against [Meta’s customer-information parameter reference](). This is Meta’s documented list, not a list of fields every event should contain or every Plainrouter input supports. No event sample was supplied, so missing rates are unknown, not 0%. Measure absent fields among eligible, consented events of the same type; a field that does not apply is not a defect. ## How do you diagnose low Meta Event Match Quality? Start by finding which accurate, permitted matching fields are missing from the affected event type. For a purchase, check whether customer details already supplied at checkout reach the server event. For browser-originated events, check whether available ` fbp ` and ` fbc ` values survive the trip from landing page to checkout. 1. Select one event type, such as ` Purchase `, and inspect its parameter diagnostics in Meta Events Manager. Use our [Events Manager diagnostics guide]() for help finding the dataset and reading its diagnostics. 1. Compare an event with the expected customer context against one without it. Trace the missing field back to its source. 1. Repair that transfer or formatting problem, then check that eligible events consistently include the real value. 1. Verify the received fields in Meta Test Events and review a later EMQ measurement. Check delivery and deduplication separately. Plainrouter's public event request separates customer information, network context, browser identifiers, and event identity: | Input | Plainrouter request location | Handling for Meta | | --- | --- | --- | | Email, phone, name, city, ZIP, country | ` user_data ` | Send truthful raw values; Plainrouter normalizes and hashes supported identity fields. | | Stable permitted customer reference | ` user_data.external_id ` | Use a stable non-personal identifier only when your identity policy permits it. | | Originating IP address and user agent | ` user_data ` | Do not hash; derive them only from the originating request when appropriate. | | Valid Meta ` fbp ` and ` fbc ` browser values | ` click_ids ` | Do not hash, reformat, share between visitors, or fabricate them. | | Logical event identity | ` event_id ` | Keep stable across retries and paired browser/server copies; it is for deduplication. | More fields are not automatically better. A copied, stale, guessed, or wrongly attributed value can make the event less trustworthy. Consent also remains an independent requirement: the fact that a field could improve matching does not authorize its collection or use. ## What does Meta Event Match Quality measure? Meta uses the customer information parameters attached to a server event to look for a matching account. EMQ summarizes how effective those parameters are for matching. Meta says the score considers which parameters were received, the proportion of events that contain them, and the quality of the information. Its current [Conversions API optimization training]() treats event matching, coverage, quality, deduplication, and freshness as separate areas to review. That makes EMQ a diagnostic for the match context of an event stream. It can help reveal that checkout events stopped including email, browser events lost ` fbp `, or a new traffic source sends less customer context than the previous mix. Check [delivery]() and [deduplication]() separately: collector acceptance, matching quality, and browser/server pairing answer different questions. ## Why do Purchase and PageView have different EMQ scores? Different event types naturally carry different amounts of context. A ` Purchase ` completed by a known customer may include verified checkout data. A ` PageView ` from a first visit may have only permitted browser and network context. Mixing them into one before-and-after comparison can make a score change look like an implementation regression when only the event population changed. Before attributing a change to a deployment, compare: - The same event names. - Similar traffic sources and regions. - Similar proportions of new and returning visitors. - Equivalent consent states. - Similar measurement windows and snapshot freshness. A campaign launch, checkout redesign, consent-banner change, or increase in background server events can change the mix without changing the event-sending code itself. ## Why did your Event Match Quality score drop? A lower score can follow missing customer fields, lost browser identifiers, or a change in the events and visitors being measured. Check the measurement period before assuming the latest deployment broke matching. 1. Check ` measured_at ` and verify that the compared snapshots cover the period you think they do. 1. Separate score-point movement from relative percentage movement. 1. Compare the event-type and traffic-source mix between the two periods. 1. Inspect representative accepted event requests for missing ` user_data `, ` fbp `, or ` fbc ` values. 1. Confirm the consent integration still resolves and sends the intended permission state before protected data is collected or delivered. 1. Confirm browser context belongs to the same visitor and is not being lost between landing, checkout, and the server event. 1. Check destination delivery separately for authentication errors, validation failures, and other permanent failures. 1. Check whether another integration started sending lower-context events to the same Meta dataset. 1. Use Meta Test Events and Events Manager diagnostics to inspect what Meta received. Change one input path at a time when possible. If event mix, consent logic, cookie capture, and checkout identity all change together, the next snapshot will be harder to explain. ## How Plainrouter presents the score The Signals dashboard and ` GET /reports/emq ` read stored Meta quality snapshots. Opening the dashboard does not trigger a new measurement. Check ` measured_at ` before judging a recent change, and compare the same event types and traffic mix. An empty snapshot list means no measurement has been stored for the workspace yet. It does not mean the EMQ score is zero. See [Signal health and performance]() for the reporting workflow and the [Conversion API reference]() for integration details. ## Understand week-over-week change The week-over-week value is a relative percentage. A move from ` 8.0 ` to ` 7.2 ` is a decline of ` 10% `, even though the score moved by ` 0.8 ` points. State which quantity you are discussing. “Down 0.8 points” and “down 10%” can describe the same change, but they are not interchangeable. ## Frequently asked questions ### What is a good Event Match Quality score? There is no universal score that proves an implementation is complete or a campaign will perform well. Use Meta's current diagnostics for the affected event types, then improve accurate permitted inputs and watch the trend. Do not turn a generic threshold into a product or revenue promise. ### Why did EMQ change when we did not deploy code? The mix of event types, visitors, traffic sources, consent states, and available customer context can change without a deployment. Snapshot timing and changes in other integrations that share the dataset can also affect the displayed value. ### Does an empty Plainrouter EMQ report mean zero? No. An empty ` snapshots ` array means no snapshot has been stored for the workspace yet. Check the workspace configuration and wait for an eligible measurement rather than recording it as ` 0 `. ### Does a 202 response mean the event has high EMQ? No. Plainrouter's HTTP ` 202 ` means the collector accepted the event for processing. It does not prove Meta delivery or report whether Meta matched the event to an account. Inspect destination delivery and EMQ separately. ### Can I send more customer data to improve EMQ? Only send data that is accurate, relevant to the event, and allowed by your consent and privacy policies. Do not collect or fabricate fields solely to influence the score. ### Is EMQ the same as event deduplication? No. EMQ evaluates matching context. Deduplication uses the same stable ` event_id ` to identify browser and server copies of one logical event. Test and monitor both. ## Sources - [Meta Business Help Center: About Event Match Quality]() - [Meta Blueprint: Optimize Meta Conversions API]() - [Plainrouter: Signal health and performance]() - [Plainrouter Conversion API reference]() - [Plainrouter TypeScript SDK getEmqReport operation]() - [Plainrouter TypeScript SDK EMQ response types]() ## Related guides - [Troubleshoot missing Meta Pixel and CAPI events]() - [What is fbclid? How it relates to fbp and fbc]() - [How does Meta event\_id deduplication work?]() - [Can you use Meta CAPI without Google Tag Manager?]() - [How does consent work for server-side tracking?]() ## Check matching fields before delivery Use the [local payload check]() to find malformed customer hashes or browser identifiers in a native Meta request. It reports field-level findings, not an estimated EMQ score. Read Meta's reported measurement in Events Manager or Plainrouter's stored quality snapshots.