Event Match Quality: What It Is and How to Improve It

What is event match quality?

Event match quality is a diagnostic Meta shows in Events Manager for each of your events. When you send an event, Meta tries to match it to a person so it can attribute the conversion and use it for optimisation. The match depends on the customer information attached: an email, a phone number, a name, a city, an external ID, the Meta click identifier. Event match quality summarises how strong that matching signal is, on a scale from zero to ten. Meta Business Help documents it as a measure of the customer information sent with your events, not of your traffic or your creative. A low score does not mean fewer sales. It means Meta can see fewer of the sales you are already making, which quietly starves both your reporting and the optimiser.

The score matters because everything downstream depends on matching. Attribution needs a matched event to credit the right ad. Smart optimisation and lookalikes need matched conversions to learn from. If a large share of your events cannot be matched, Meta bids and reports on a fraction of reality, and the fix is almost always in the data you send rather than the budget you spend.

How is event match quality scored?

Event match quality is scored on the identifiers each event carries and how usable they are. Meta does not publish a fixed points value per field, and the exact contribution varies by account, but the pattern is consistent: more identifiers, correctly formatted, produce a higher score. The parameters below are the ones that move it most, and each should be normalised and hashed before it is sent.

Identifier	Why it matters	How to send it
Email	High-uniqueness match key, present for most customers	Lowercased, trimmed, SHA-256 hashed
Phone number	Strong key, especially for phone-first channels	E.164 format with country code, SHA-256 hashed
Name and location	Corroborating signals that raise confidence	Lowercased, hashed, sent with email or phone
External ID and click ID	Ties the event to your own record and the ad click	Sent unhashed as Meta specifies for each

Meta Business Help sets out the customer-information parameters and their formatting rules. TikTok publishes its own equivalent measure, and the TikTok Business Help Center describes how TikTok calculates match quality from the identifiers on each event, so the discipline of sending clean, complete identifiers carries across platforms even though the score itself does not. Datahash explains how match quality and EMQ scores are calculated in its own documentation.

Why does normalisation come before hashing?

Normalisation comes before hashing because a hash is only useful if both sides hash the identical string. SHA-256 turns any input into a fixed, irreversible value, and the NIST-standardised algorithm produces a completely different output for even a one-character difference. So Example@Email.com and example@email.com hash to different strings and never match, even though they are the same address. Normalising first, lowercasing the email, trimming spaces, formatting the phone to E.164, guarantees your hash matches Meta’s copy. Skipping it is the most common reason a match rate is lower than expected, and it is invisible unless you look, because the events still send.

How do you improve event match quality?

Improving event match quality is mostly about sending more identifiers, more accurately, on a path that does not lose them. The practices below are ordered from the highest structural leverage down, and together they are how most accounts move a low score up:

1. Implement server-side tracking through the Conversions API, so events reach Meta even when the browser blocks the pixel.
2. Enable advanced matching, so the identifiers a customer enters, email and phone, are captured and sent with the event.
3. Ensure your checkout and forms require the key identifiers, because a match key you never collect cannot be sent.
4. Normalise every identifier and hash it with SHA-256, so your values match Meta’s records rather than near-miss them.
5. Maintain event consistency, sending the same event with the same identifiers from both the pixel and the server, deduplicated on a shared event ID.
6. Collect no excessive data, keeping to the identifiers that actually raise the match and dropping fields that add risk without signal.
7. Obtain and respect user consent, sending identified events only where consent for measurement was given.
8. Monitor and maintain data quality in Events Manager, watching the score per event and fixing regressions as they appear.

Datahash documents raising your Meta EMQ score and sending more identifiers to lift match rates, which are the two practices that move the number fastest.

Why is server-side tracking the biggest lever?

Server-side tracking is the biggest structural lever on event match quality because it changes what fraction of your events arrive at all. A browser pixel is subject to ad blockers, tracking prevention, and cookie limits, so a share of events, often a large one, never reaches Meta, and an event that does not arrive cannot be matched. The Conversions API sends events from your server, where those restrictions do not apply, so the events survive and carry the identifiers you attach. This is why the practice sits first. Everything else raises the quality of events that arrive; server-side tracking raises how many arrive in the first place. Datahash applies the same server-side pattern to Meta that it uses across every platform it supports.

When does event match quality actually matter?

Event match quality actually matters when a meaningful share of your budget depends on conversions Meta is failing to match, which is most performance accounts, but not all. If you run conversion or sales campaigns, rely on Smart bidding, or build lookalikes from converters, a low score directly weakens all three, and lifting it is high value. If you run pure awareness or reach campaigns with no conversion objective, the score is close to irrelevant, because nothing downstream is using the match. The honest read is that EMQ is a lever, not a KPI. Chase it when attributed conversions and cost per result depend on it, and ignore a one-point wobble that does not move a business outcome. Datahash frames it inside its broader data quality tooling for Signals, where the score sits next to match rates rather than standing alone.

How does deduplication protect the score?

Deduplication protects event match quality by keeping the pixel and the server from counting the same event twice. When you run both paths for reliability, each event should carry the same event ID so Meta keeps one and discards the duplicate. Without it, a single purchase can arrive twice, which inflates your conversion count and corrupts the very optimisation the match quality is meant to feed. Consistent event IDs and consistent identifiers across both paths keep the record clean, so the score reflects genuine matching rather than double sends. Datahash documents event deduplication between the pixel and the server and event validation and schema errors, which is where malformed events that quietly drag the score down get caught.

How does advanced matching lift event match quality?

Advanced matching lifts event match quality by adding the customer identifiers a plain event would omit. A basic pixel event might carry little more than a browser cookie, which matches weakly. Advanced matching captures the email and phone a customer enters on your site, hashes them, and sends them with the event, so Meta has strong, unique keys to match on. It comes in two forms. Automatic advanced matching reads identifiers from your web forms with a setting toggled on, which is quick but limited to what the browser can see. Manual advanced matching sends the identifiers explicitly from your own code or server, which is more work but more complete and more reliable, especially through the Conversions API. The more identifiers advanced matching supplies, and the more accurately they are formatted, the higher the score climbs, because match quality is fundamentally a function of how much good identity signal each event carries.

How does event match quality differ across the pixel and the Conversions API?

Event match quality behaves differently on the browser pixel and the server-side Conversions API, and understanding the split is how you diagnose a low score. The pixel can fill some identifiers automatically from the browser, so a basic pixel event still matches to a degree, but it loses whole events to blockers and cookie limits, and a lost event contributes nothing. The Conversions API loses almost no events, because it does not run in the browser, but it matches only on what you explicitly attach, so a thin server event with no email, phone, or click ID scores poorly. The practical consequence is that the two are complementary: the server path guarantees the event arrives, and the identifiers you attach determine how well it matches. A well-populated Conversions API event usually scores higher than the pixel could, while a sparse one scores worse, which is why populating the server events fully is the work that matters.

How do you diagnose a low event match quality score?

Diagnosing a low event match quality score is a process of checking the identifiers, the formatting, and the delivery in turn. Work through it in order:

1. Open Events Manager and read the score per event, not as an account average, so you find the specific events dragging it down.
2. Check which identifiers each low-scoring event carries, and confirm the strong keys, email and phone, are present rather than only a cookie.
3. Verify normalisation: emails lowercased and trimmed, phone numbers in E.164 with the country code, before hashing.
4. Confirm the identifiers are actually being collected upstream, because a checkout that never asks for a phone number cannot send one.
5. Check that server events are arriving at all, and that they deduplicate cleanly against the pixel on a shared event ID.
6. Fix the earliest failing step, then re-read the score after fresh events flow, since the number updates on new data, not retroactively.

Most low scores resolve at step two or three: the event is either missing a strong identifier or sending one in a format that never matches. Datahash surfaces these in the same data quality view, so the failing step is visible rather than guessed.

Does event match quality affect lookalike audiences?

Event match quality affects lookalike audiences indirectly but materially, because a lookalike is only as good as the seed it is built from. Meta builds a lookalike by finding people similar to a source audience of your converters, and that source is assembled from matched events. If a large share of your conversions never match to a person, the seed audience is smaller and less representative than it should be, so the lookalike is modelled on a partial, possibly skewed, sample. Lift the match quality and more of your real converters enter the seed, which gives Meta a fuller, truer picture to model from. So while event match quality is not itself a targeting setting, it quietly sets the ceiling on how good your prospecting audiences can be. This is part of why the score is worth improving even for advertisers focused on top-of-funnel growth rather than direct attribution.

How does consent affect event match quality?

Consent affects event match quality directly, because the identifiers that raise the score are exactly the ones you may only send when a visitor has agreed to measurement. When someone declines consent, you should not attach their email, phone, or other personal identifiers to an event, which means those events match more weakly by design. This is not a flaw to engineer around; it is the setup working correctly. The right approach is to gate identified events on consent, send fully matched events for visitors who agreed and stripped-back or aggregated signals for those who did not, and let the score reflect that honestly. A high match quality built on data collected without consent is a compliance problem waiting to surface, not a performance win. Handled properly, consent and match quality coexist: you maximise matching within the population that agreed, rather than inflating the number by ignoring the rule. Hashing every identifier before it leaves your systems is part of keeping that flow consistent with GDPR and DPDP.

Why does event match quality vary by event type?

Event match quality varies by event type because different events are captured at different points in the journey, where different identifiers are available. A purchase event fires at checkout, where a customer has usually entered an email and a phone number, so it tends to score well. A top-of-funnel event like a page view or a content view fires before anyone has identified themselves, so it carries little more than a cookie and scores lower, which is expected rather than broken. This is why reading the score per event matters more than reading an account average: a low average often hides a strong purchase event and a weak view event, and the fix for each is different. Concentrate your identifier effort on the events you actually optimise and bid on, usually the ones deepest in the funnel, and do not waste effort forcing identity onto events that happen before the customer has given you any.

What are the limits of event match quality?

Event match quality measures matching, not marketing. A perfect ten does not sell anything: it means Meta can see the conversions you already produce, and no more. It cannot lift a score above the ceiling your data allows, so if customers genuinely do not give you an email or phone, some events will always match poorly, and that is honest rather than fixable. It is also gameable in a way that helps no one: you can raise the number by sending more fields while your actual attributed conversions and cost per result do not improve, which is effort spent on a dashboard. And a high score built on data collected without consent is a compliance problem, not a win. Event match quality is a good diagnostic and a bad target. Treat it as the first, not the last.

What Datahash does about this

Datahash raises event match quality by fixing the two things that hold it down: how many events arrive, and how well each is identified. It runs the Conversions API server-side so events survive browser losses, normalises and SHA-256 hashes every identifier before it leaves your systems, and populates each event with the fullest set of consented match keys, deduplicated against the pixel so nothing is counted twice. The score is visible per event in the same view as match rates, so improvement is measured rather than assumed. Because the hashing happens before send, the flow stays consistent with GDPR and DPDP. Starzplay lifted attributed free-trial subscribers by 11.7% and KFC recorded 5% additional purchases running the Conversions API alongside the pixel, both outcomes of events that matched where they previously did not. The same infrastructure carries the identifier discipline to TikTok, Google, and Snap, so one setup improves matching everywhere you spend.