Why your Event Match Quality is stuck

Is the score low, or is the event volume too small to grade?

Check this before changing anything. Meta grades each event type separately, and a Purchase event with very few instances gives a score that swings on almost nothing. If your store does a handful of orders a day, read the score over a fortnight rather than a day, and read Add to Cart alongside it.

The score also has no memory of your fixes. It reflects recent events, so a change made today shows up over the days that follow rather than on the same screen you were watching.

How many customer details actually leave with each purchase?

This is the cause in most cases, and it is measurable rather than a matter of opinion. A stock browser pixel sends about four things it can see. The order sitting in your store admin holds a name, an email, a phone number, a city, a postcode and a country, and none of them travel unless something sends them.

On our own test store the count went from 4 to 14 once the purchase was reported from the server, read on 18 August 2026. Fourteen and not twenty, because every one of them is a value the order already contained and none was invented to lengthen the list.

Are the details leaving in the format Meta can match?

A detail sent in the wrong shape matches nobody and counts against you exactly as a missing one would. An email has to be lowercased and trimmed before it is scrambled, a phone number has to carry its country code, and the scrambling itself has to happen before the value leaves your server rather than in the shopper's browser.

This is the failure that looks like nothing. The payload is accepted, the event count is right, the score does not move, and there is no error anywhere to explain it.

Is the browser half reporting too, or only the server?

This is the reason nobody mentions, and it is the one we can put a number on. Reporting from the server alone gets you most of the way; the score keeps climbing when the browser reports the same sale as well, matched to it on a shared event identifier so it is counted once.

Our own store read 8.0 out of 10 on 18 August 2026 with the server half alone, and 9.3 out of 10 on 21 August once both halves reported. Same store, same fourteen details, three test orders. That is a small sample and it is stated as one.

What actually moves the score

1. Send the details the order already holds, rather than the four a browser can see. Nothing new is collected from the shopper.
2. Normalise before scrambling: lowercase and trim the email, put the phone in international form, and do all of it on your server.
3. Keep the browser reporting alongside the server, matched on a shared event identifier, so the sale is graded on both and counted once.
4. Read the score over a fortnight, not a day, and read it per event type. A score judged on one afternoon of orders is noise.