You opened a conversion event in Events Manager and the score sitting next to it is lower than you expected. This page explains what that number is grading, the reasons it reads low, and which fix moves it most for the least work.
Event match quality is a rating Meta puts on the customer information you attach to an event. Open a data source in Events Manager, click into a single event such as Purchase or Lead, and you get a score from 0 to 10 for that event alone. Two events in the same dataset routinely score differently, because they are collected at different points in the funnel and carry different fields.
The grade is not about whether the event arrived, fired on the right page, or carried the right value. It answers one question: given what you sent, how confidently can Meta connect this action to a person who exists on its platforms. The inputs are the customer information parameters riding along with the event, how many are present, and whether each is formatted so it can be compared against Meta's records.
That makes the number a diagnostic, not a target. For how matching relates to deduplication and the two-channel setup, see Meta pixel vs Conversions API. This page stays on the score.
Five causes account for nearly everything we find. They are ordered by how often they turn out to be the answer.
The blunt one, and the most common. A checkout knows the buyer's email, phone number, name, city, state, postal code, and country. If the event leaves your site carrying value and currency and nothing else, the score has almost nothing to work with. That is rarely a decision anyone made. It is what happens when tracking is installed once, quickly, and never revisited.
A pixel with no advanced matching sends what the browser can see on its own: the _fbp browser cookie, the _fbc click cookie when an ad click created one, the IP address, and the user agent string. Those are real matching signals, and they are also the floor. A bare browser install with no email or phone flowing through will sit at a modest score permanently, however clean the rest of the implementation is, because there is no more identity in the payload to grade. Our free Meta pixel audit reports whether advanced matching is switched on for each pixel ID it finds, which tells you quickly whether this is you.
Personal identifiers have to be normalized and hashed with SHA-256 before they leave your systems, and the normalization is where implementations lose points quietly. Lowercase the string, strip leading and trailing whitespace, reduce the phone number to digits with the country code and no symbols, and hash once. A value hashed twice, or with the wrong case, or with a stray space attached, is a valid hash of the wrong string and will never match. Nothing errors. The parameter reads as present and contributes nothing.
Related and even easier to miss. Server integrations that build the payload from a template will happily send an empty string, the literal text "null", or the word "undefined" where a phone number should be, then hash it. Guest checkouts with no phone field and leads captured before the address is known both produce this. Inspect a real payload rather than the code that generates it, and drop the key entirely when you do not have the value.
The most frustrating cause, because the data exists and is simply not being passed. Conversions API implementations frequently omit fbp and fbc, which live in browser cookies and have to be read on the page and forwarded to the backend with the order. They skip external_id, the stable customer ID you already use internally. Some omit client_ip_address and client_user_agent, which are expected on server events and cheap to include. A server event assembled purely from your order table scores worse than the browser event covering the same purchase.
Do these in order and stop when the score is consistent with what your funnel legitimately collects.
Email is normally the strongest single identifier a business has, and phone is close behind when it is collected with a country code. Add them to Purchase and Lead first, since those are the events optimization runs on. If the email comes from a newsletter step and the phone from checkout, send each on the events where it genuinely exists rather than back-filling guesses.
Read the _fbp and _fbc cookies in the browser, attach them to the request that creates the order or the lead, and include them in the Conversions API payload as fbp and fbc. These two are the most direct link between an ad click and the action that followed, they are sent unhashed, and forwarding them is usually a small change in one place. A visitor who arrived without an ad click will have no _fbc, which is expected.
Send your own customer or user identifier as external_id, using the same value from the browser and from the server. Consistency is the whole point. An ID that changes shape between channels, or between a logged-in session and a guest session, adds noise instead of matching power.
Automatic advanced matching is a toggle in your pixel settings in Events Manager. With it on, the pixel looks for identifiers already present in your page's forms and fields and hashes them for you before sending. It is the cheapest improvement available and costs one click. Manual advanced matching goes further: you pass the hashed values yourself in the pixel's init call, which is the right approach when the data sits somewhere the automatic version cannot reach. The toggle changes nothing on a site that never exposes an email in the page, so verify rather than assume.
Do not skip the boring part: add the address fields. City, state, postal code, and country are already sitting in every shipping form, they are hashed like the rest, and they stack with name to resolve people that a single weak identifier would not.
There is no published number that means you passed, so do not chase one. Higher is better, the ceiling depends on your funnel, and a lead-gen form that asks for an email and nothing else has a lower honest maximum than a checkout with a shipping address. Score what your data supports.
The failure mode worth naming is inventing identity to move the number. Placeholder emails, one account's details reused across sessions, or a synthesized external_id that maps to no real person all produce a fuller-looking payload that matches to the wrong people or to nobody. You have made attribution worse while watching a metric improve.
Keep the fix in its lane, too. If your conversion volume does not reconcile with your backend, fix that first, because a better-matched duplicate is still a duplicate. See why your ROAS numbers are wrong, or the Meta pixel firing twice if the symptom is doubled counts.
Open Test Events in Events Manager, trigger the event on your own site, and inspect the payload that arrives. Look for the new parameters listed on the event, not for the score, which will not move on one test. Meta's Payload Helper is useful here too, for confirming a server payload is shaped the way the API expects.
Then leave it for a few days of normal traffic and compare the event against its own previous score. One change at a time is what makes this readable. Deploy hashing corrections, forwarded cookies, and a new external_id in the same release and you learn that something worked without learning what.
If you want the site side checked before you go parameter hunting, our free Meta pixel audit scans your live pages and reads Meta's public configuration for each pixel ID it finds, which includes whether automatic advanced matching is enabled and whether match data is being passed in the init call. It cannot see your score, which lives in Events Manager rather than on your website, so it flags that as something to verify instead of guessing. The broader checklist behind it is the Meta pixel audit guide.
There is no honest single number, and anyone quoting one is guessing. Meta does not publish a pass mark, the scale is relative rather than absolute, and the realistic ceiling for your account depends on what your funnel legitimately collects. A checkout that captures email, phone, and a full shipping address can reach a score that a newsletter form asking only for an email will never touch, and neither of those is broken. Score what your data supports. Write down today's number for each conversion event, make one parameter change, and judge the fix by whether that event's own score moves.
No. Meta received every event it scored, which is why it could score them at all. A low reading means a share of those events could not be tied to an account with confidence, so they are less likely to be attributed to the ad that caused them and they carry less weight as training signal. That is a different failure from an event that never arrived, and it is worth separating the two before you start changing code. Missing events show up as absent volume in Events Manager. Weak matching shows up as volume that arrives with a thin score attached.
Not instantly. The score is calculated over a trailing period of events, so the first hours after a deploy are a blend of the old payload and the new one, and a single test event will not shift the average. Confirm the change is live the same day by opening Test Events and checking that the new parameters appear on the event you just triggered, then come back to the score after a few days of normal traffic before deciding whether it worked. Low-volume events settle more slowly than high-volume ones because there is less to average.
Indirectly, and not as a lever you can pull. The score itself is not an input to the auction. What matters is the underlying thing it describes: matched conversions are the ones that get attributed to your campaigns and feed the delivery model. When more of your conversions resolve to a person, optimization has more to learn from and your reported results reflect more of what actually happened. Expect a better signal and more complete reporting rather than a specific change in cost per result, and never treat raising the number as a substitute for fixing duplicate or missing events first.
Nothing errors when your events arrive thin. They just get attributed less often and teach the algorithm less. Scan your site in about 20 seconds to see what an outside browser can read about your pixel, or have us open Events Manager with you.