Most advertisers lose half of their conversions before Meta ever sees them. Not because the sales didn't happen, but because Meta couldn't match the event back to a real person. That match rate has a name: Event Match Quality, and it quietly decides how good your retargeting is, how accurate your lookalikes are, and how much you pay per lead.

This guide breaks down exactly what EMQ is, why most setups stall at a mediocre 4 to 5 out of 10, the eight signals that push it to 9+, and how Inflowave sends every one of them automatically through a native server-side Conversions API, with no Google Tag Manager and no third-party sGTM hosting to wire up.

What Event Match Quality actually is

Event Match Quality (EMQ) is Meta's score, from 0 to 10, for how confidently it can match a conversion event you send back to a real Facebook or Instagram user. Every event you fire (a lead, a booking, a purchase) carries customer information such as email, phone, and click identifiers. The more of that information you send, correctly formatted and hashed, the more often Meta finds the matching person.

EMQ is not a vanity metric. It directly drives three things you pay for:

• Retargeting reach - unmatched events can't be used to retarget the people who triggered them.
• Lookalike quality - lookalikes are only as good as the seed audience Meta can actually identify.
• Cost per lead and per acquisition - higher match rates give the algorithm cleaner signal to optimize, which lowers CPL.

The EMQ score bands, and what each one costs you

The hidden cost of a 4.8 is that Meta can only identify roughly half of the people who filled out your form. Your retargeting then runs on an audience that is missing leads you already paid to acquire.

Why most setups stall at 4 to 5

A browser pixel alone is throttled by ad blockers, iOS restrictions, and cookie loss, so a large share of events never arrive. Bolting on a basic Conversions API helps, but most native CRM integrations send a fixed, limited payload and inherit a structural ceiling:

• Phone numbers sent in the wrong format, so the hash never matches.
• The fbc and fbp cookies are never read from the browser or forwarded server-side.
• No shared Event ID, so the pixel and the Conversions API double-count the same conversion.
• No control over which fields are sent per event, and CRM fields like city, state, and ZIP are left sitting in the database.

The usual fix is a tangle of Google Tag Manager plus a paid server-side GTM host. It works, but it is fragile, technical, and one more bill. Inflowave takes a different route.

The 8 signals that push EMQ to 9+

Once events are sent server-side, your score comes down to how many of these eight fields are present and correctly built on every event:

1. Event ID - a unique ID shared by the pixel and the Conversions API so Meta merges the two signals into one clean conversion instead of counting it twice.
2. External ID - your CRM contact or lead ID, which links events across sessions and devices for a returning person.
3. fbc (click ID) - the click identifier from the ad URL. The highest-confidence signal, because it ties the conversion to a specific ad click.
4. fbp (browser ID) - Meta's persistent browser identifier, one of the strongest server-side matching keys.
5. Hashed email - normalized to lowercase and trimmed, then SHA-256 hashed. The single highest-impact field.
6. Hashed phone in E.164 - normalized to +15558675309 before hashing. The most commonly broken field anywhere.
7. Hashed first and last name - sent as separate fields, lowercased before hashing.
8. IP address and user agent - server-level enrichment that the browser alone can't reliably provide.

Beyond the eight, Meta rewards demographic fields (city, state, ZIP, country) and, for purchases, a valid Facebook Login ID - which Meta reports drove a 17.59% median increase in additional reported conversions for advertisers who sent it.

How Inflowave sends all of this automatically

Inflowave runs a native, server-side Conversions API. When a lead comes in, a call is booked, or a deal closes anywhere in your CRM, Inflowave builds and ships a fully enriched event straight to Meta, server to server. There is nothing to install, no GTM container to maintain, and no separate sGTM host to pay for.

On every event, Inflowave:

• Hashes email, phone, and first and last name with SHA-256 after normalizing them, so the hashes actually match.
• Normalizes phone numbers to E.164 before hashing, stripping formatting and adding the country code, so the most-broken field becomes a reliable match.
• Captures and forwards fbc and fbp from the original ad click and browser session, the two signals native integrations almost always drop.
• Sends your CRM contact ID as the External ID, so Meta can follow the same person across sessions and devices.
• Generates a shared Event ID and syncs it between the pixel and the Conversions API for clean deduplication.
• Enriches with IP address, user agent, and the demographic fields (city, state, ZIP, country) already sitting in the contact record.
• Logs every event with its response so you can audit exactly what Meta received and why a score moved.

The result is the same payload the expensive GTM-plus-server-side stack produces, generated automatically from data Inflowave already holds about your leads.

Phone numbers: the number one EMQ killer

This is the single most damaging and least-discussed problem. A phone stored as (555) 867-5309, 555-867-5309, or 5558675310 will hash into something Meta has never seen. The signal looks sent, but it contributes zero to your score.

The rule is simple: strip every non-numeric character, prepend the country code, and only then hash. (555) 867-5309 becomes +15558675309, which becomes a SHA-256 hash Meta can match. Inflowave does this conversion on every event before hashing, so the phone signal actually counts.

Deduplication: stop counting every lead twice

When the browser pixel and the Conversions API both fire without a shared Event ID, Meta records two conversions for one lead. Your reported numbers inflate and your CPL math breaks. A single Event ID, passed identically to both the pixel and the server event, lets Meta merge them into one. Inflowave generates and syncs that ID for you.

From match quality to lead score: cleaner signal, smarter spend

Higher EMQ is not only an attribution win, it is a budgeting win. When Meta can identify 90%+ of your converters instead of 50%, your lookalike seed doubles in effective size, your retargeting pools fill with the right people, and the optimizer gets clean signal to chase. That is what pulls CPL down over time.

Inside Inflowave, those well-matched events also feed lead scoring: the same first-party data that maximizes EMQ (source, click ID, engagement, pipeline stage) is what ranks your leads, so your team works the hottest contacts first while Meta optimizes spend toward the people most like them.

EMQ best-practices checklist

• Send events server-side, not from the browser alone.
• Normalize and SHA-256 hash email, phone, and names on every event.
• Convert every phone number to E.164 before hashing.
• Forward fbc and fbp on every event.
• Generate one shared Event ID for the pixel and the Conversions API.
• Map your CRM contact ID as the External ID.
• Include city, state, ZIP, and country where you have them.
• Track high-value events like booking confirmations, not just purchases.
• Check the EMQ score on every event in Events Manager, not just on Purchase.

Common mistakes that keep EMQ low

• Treating a native CAPI toggle as a finished setup. Turning it on confirms something is sent, not that the payload is complete.
• Hashing phone numbers without E.164 normalization, so they silently fail to match.
• Firing the pixel and the Conversions API with no shared Event ID and double-counting.
• Never forwarding fbc and fbp, which severs the link between the ad click and the conversion.
• Leaving city, state, ZIP, and date of birth in the CRM instead of sending the signals Meta explicitly asks for.

Pixel-only vs. Conversions API vs. native server-side

If you only run the pixel, you are leaving the majority of your conversions unmatched the moment a user blocks cookies or opts out of tracking. A basic Conversions API recovers some of that, but the structural gaps above keep it stuck in the 4-5 band. A complete server-side setup is what reaches 9+.

Why server-side tracking wins after iOS 14

The browser pixel runs on the user's device, so every privacy change chips away at it:

• iOS App Tracking Transparency - most users opt out, and the pixel cannot track them at all.
• Safari and Firefox - block third-party cookies by default, erasing pixel matches.
• Ad blockers - more than 40% of users run one, and many strip the pixel before it fires.

Server-side tracking sends the event from your infrastructure straight to Meta after the conversion has already happened, so none of those browser-level blocks apply. That is why server-side events routinely match at far higher rates than the pixel alone, and why Meta now treats the Conversions API as the primary signal rather than a backup.

How to check your Event Match Quality in Events Manager

1. Open Meta Events Manager and select your dataset (pixel).
2. Click the Overview tab and choose an event such as Lead or Purchase.
3. Find the Event Match Quality column - it shows the average score for that event.
4. Click the event to see the breakdown of customer-information parameters Meta received, and which ones are helping or hurting your score.
5. Use the Test Events tab to fire a live event and confirm the parameters arrive correctly before relying on the score.

Check every event that seeds a retargeting audience or lookalike, not just Purchase. A 9 on Purchase means little if your Lead event - the one feeding your prospecting - is sitting at a 4.

Frequently asked questions

What is a good Event Match Quality score?

Anything in the 6-8 band is good, and 9-10 is excellent. Most basic setups sit at 4-5, which means roughly half of your conversions are not being matched. Aim for 8+ on your highest-value events first.

How do I improve Event Match Quality on Facebook?

Send events server-side and include more correctly formatted customer parameters: hashed email, E.164 phone, first and last name, the fbc and fbp cookies, an External ID, and IP and user agent. Each added, correctly built field raises the score. Inflowave assembles all of these automatically.

Do I still need the Meta Pixel if I use the Conversions API?

Yes. The pixel and the Conversions API work best together, with a shared Event ID so Meta deduplicates them into one conversion. The pixel captures browser-side signals like fbp; the server event captures everything else and survives ad blockers.

How do I test my Conversions API events?

Use the Test Events tab in Meta Events Manager to watch events arrive in real time, then check the Event Match Quality column per event once data accumulates. Inflowave also logs each event it sends with Meta's response so you can audit delivery.

Which events should I send through the Conversions API?

At minimum, your conversion events: Lead, Schedule or booking confirmations, and Purchase. For service businesses, calendar bookings are one of the highest-value events and are often the one most setups miss entirely.

What is the difference between the Conversions API and offline conversions?

The Conversions API streams events in near real time from your server, including online actions. Offline conversions are uploaded in batches for events that happen away from your site, such as in-store sales. Most CRM and funnel conversions belong on the Conversions API.

Is the Conversions API worth it?

Yes. For most advertisers it recovers 20-40% of the conversions the pixel alone misses after iOS 14, which directly improves attribution, audience quality, and cost per result. The only real downside is setup complexity, and that disappears when it is built into your CRM, as it is in Inflowave.

What percentage of events should the Conversions API cover?

Meta surfaces a "rate of pixel events also sent via the Conversions API" metric, and you want it as close to 100% as possible. Full coverage with a shared Event ID means every conversion has both a browser and a server signal to match against, which is exactly how a native server-side setup fires.

The bottom line

Event Match Quality is the difference between Meta seeing all of your conversions and seeing half of them. The fix is not a vague best practice, it is eight concrete signals sent correctly on every event. Inflowave builds and sends all of them through a native server-side Conversions API, so you get a 9-grade setup without assembling the stack yourself, and the same first-party data sharpens your lead scoring at the same time.