Event match quality scores your identifiers, not your setup

Every ad platform scores your events on how much matching information arrived with them. Meta calls it EMQ, and other platforms have their own names for the same idea.

Most people read the score as a verdict on whether their setup is correct. It doesn't measure that. It counts how many identifiers came with the event, and nothing else.

What the score actually counts

A single purchase event can carry roughly eight identifying fields, all hashed before they leave your store:

So a score of 5.2 out of 10 means roughly half of those arrived. Nothing is broken in your setup. The event just travelled light.

The hashing is a requirement of the APIs themselves rather than an option you tick, so email and phone don't leave your store in their original form.

Why an unmatched event costs you

An event the platform can't tie to a person is an event it can't learn from. It still counts in your conversion total, but it contributes nothing to who sees your ad next.

That's the part people miss. Match quality isn't a reporting metric, it's an input to targeting. A campaign delivering conversions the platform can't match will keep spending while its targeting stops improving, and the reported return won't warn you, because the conversions are being counted normally.

Three common objections

"A higher score raises my conversions." It doesn't raise the count. It raises how many of them the platform can attribute and learn from. The number of events you send stays the same; what changes is their share of the optimisation.

"There's a target number I should hit." There's no general target worth putting in your report, because your ceiling is set by your checkout. A store that collects phone numbers and opens customer accounts can reach the high nineties. A store with guest checkout and email only can't, however well configured it is. Compare against your own trend, and against the spread between your destinations: a destination scoring far below the rest points to a connection problem there rather than to your data.

"Sending more events raises the score." Volume isn't in the calculation. Neither is send speed or event naming. The score responds to identifiers only.

If your score drops for a week or two without any setup change, the usual cause is a shift in traffic mix: a higher share of guest checkout, or visitors arriving with no click ID. Check the mix before assuming something broke.

What raises it, in order of impact

1. Send from the order record, not the page. The single biggest step. A page only knows what the page can see, and at the moment a browser fires the purchase event the fields you can rely on are click ID, IP and user agent. The order record carries all of them: the email the customer typed, the phone they gave for delivery, their customer ID, and the shipping city. That's the mechanism behind 87% against 98%, which is the same event sent from where the information lives.
2. Capture the phone at checkout if you don't already. It brings back the customers using relay email addresses.
3. Add your store's customer ID. The most stable identifier you own.
4. Persist the click ID across the session and across payment redirects. Without that, instalment screens drop the field platforms weight most heavily.

In Flowfy, hashed matching information is sent from the order record to every destination, which is what produces the hybrid-path score. Per-event delivery and each platform's response show up in the delivered events log. An aggregated score per destination, tracked over time on one screen, is on the roadmap and hasn't shipped, so today you read the score in each platform's event manager.

What to do next week

Don't optimise for the score. Optimise for sending real identifiers. Start with one change: move the purchase event from the browser to the order record, then check the score again after two weeks.