Event Match Quality: Why Meta Ignores Some of Your Conversions

You send Meta a Purchase event for every sale. Events Manager shows them arriving. And yet campaign reporting shows fewer conversions than you sent, and the algorithm seems to optimize like it’s half blind. The usual culprit is event match quality: Meta received the event but couldn’t confidently tie it to a person on Facebook or Instagram, so it can’t credit an ad or learn from it.

For a high-ticket funnel, where you might send 20 purchase events a month instead of 2,000, every unmatched event hurts. This guide explains what Event Match Quality (EMQ) measures, why server-side events from call funnels often score poorly, which parameters move the score, and how to diagnose the warnings Meta shows in Events Manager.

What Event Match Quality actually measures

When Meta receives a conversion, from the browser pixel or the Conversions API, it tries to match it to a Meta account. It does this using the customer information you include: email, phone, name, location, browser identifiers and so on. Event Match Quality is Meta’s score, shown per event in Events Manager on a scale of 0 to 10, for how useful that customer information is for matching.

A few things are worth understanding about it:

• It’s per event type. Your Lead event can score 8 while your Purchase event scores 4, because they’re sent from different places with different data.
• It’s an estimate of matchability, not a match rate. A higher score means Meta expects to match more of those events, which means better attribution and better optimization.
• It weighs parameters differently. Strong identifiers like email and phone carry more weight than, say, a city on its own. The click ID (fbc) and browser ID (fbp) are especially valuable because they tie the event to a specific browser that saw your ad.

An unmatched event isn’t just missing from a report. It’s a signal the algorithm can’t use. If you’re trying to teach Meta to find buyers rather than form-fillers, as in pixel conditioning, unmatched purchases are wasted lessons.

The parameters that matter

Meta’s Conversions API accepts a set of customer information parameters. The ones you’ll care about most for a call funnel:

Parameter	What it is	Hashed?	Typical source in a call funnel
em	Email	Yes (SHA-256)	Opt-in, application, calendar
ph	Phone	Yes	Application, calendar, CRM
fn, ln	First and last name	Yes	Application, payment
ct, st, zp, country	City, state, postal code, country	Yes	Visitor location or billing address
external_id	Your own contact ID	Recommended	Your CRM or attribution tool
client_ip_address	Visitor’s IP	No	Browser session
client_user_agent	Visitor’s browser string	No	Browser session
fbc	Click ID from the ad click	No	fbclid in the landing URL
fbp	Meta browser ID cookie	No	_fbp cookie on your site

Hashing matters: Meta expects personal fields normalized (lowercase, trimmed, phone in international digits) and then hashed with SHA-256. A server sending unhashed or badly normalized email gets a lower score than one sending clean hashes. IP, user agent, fbc and fbp are sent unhashed.

Why call-funnel conversions often score low

The browser pixel on a landing page naturally sends IP, user agent and fbp, and often fbc if the visitor came from an ad. That’s why Lead and PageView events tend to score reasonably well.

The events you care most about in a sales-call business, like Qualified Call, Show, Purchase, happen somewhere else. A purchase fires from a server when Stripe confirms a charge, maybe nine days after the visit. A call outcome fires from your CRM after the rep marks it. These events come from a server with no browser attached, and if the system sending them doesn’t remember the original session, they arrive at Meta with just an email and maybe a phone.

Email alone is a decent identifier, but it’s often the wrong email. The buyer applied with a work address and has their Facebook account under a personal one. Without fbc, fbp, IP and location to back it up, the match fails.

So the fix isn’t about the event itself. It’s about carrying the browser data from the original visit through to the server event days or weeks later.

How to raise your score

1. Store the session with the contact

Your attribution or tracking layer should record each visitor’s fbc, fbp, IP and user agent when they arrive, and attach those to the contact once they’re identified. When the purchase fires later from the server, it pulls them from the contact record. This is the single biggest improvement most call funnels can make, and it’s the core of server-side tracking.

2. Send every identifier you legitimately have

Email and phone together beat either alone. Add first and last name from the application. Send external_id consistently so Meta can connect events from the same person over time.

3. Add location

Country, state, city and postal code are moderate-strength signals on their own, but they help confirm a match when email is ambiguous. Most call funnels don’t collect an address, so this has to come from the visitor’s session. The Callix pixel records each visitor’s approximate country, state, city and postal code and sends them hashed with Meta conversions, so Meta has location to match on even when the application never asked for it.

4. Send the visitor’s real IP

If your tracking script is served through a shared endpoint, every event might report the same server IP, which is worse than useless. Pages that serve the Callix pixel from your own domain send each visitor’s own IP address instead of a shared one.

5. Normalize before hashing

Lowercase and trim emails, strip formatting from phones and include the country code, lowercase city names. A phone hashed as (365) 292-1234 will never match one hashed as 13652921234.

The “Send missing IP address parameter” warning

One diagnostic shows up often in Events Manager for server events: a recommendation to send the missing IP address parameter. It usually means some of your server events include a user agent but no IP, or vice versa. Meta wants the two together because they describe the same browser.

This tends to happen with contacts whose sessions were recorded before your tracking captured IP, or in setups that fill user agent from one place and IP from another. Callix now sends a visitor’s browser and IP address to Meta together, or neither, which clears the warning for conversions from visitors tracked before the pixel recorded their own IP.

Other common Events Manager diagnostics worth checking alongside it: events with invalid or unhashed parameters, deduplication issues between browser and server events (see our Conversions API walkthrough), and events arriving with a timestamp too far in the past.

A worked example

Say you send Meta 40 Purchase events a month from Stripe through the Conversions API, with email and phone only. EMQ for Purchase sits in the 4 to 5 range, and Ads Manager attributes 22 of the 40 to campaigns.

You change the setup so each purchase carries the buyer’s original fbc and fbp from their landing page visit, their IP and user agent from that session, their name from the application, and approximate location. Over the next few weeks, EMQ for Purchase climbs, and Ads Manager attributes more of the 40 to campaigns. The spend didn’t change and the sales didn’t change. Meta simply sees more of them, so its view of which ads drive purchases gets closer to the truth, and so does its optimization.

The numbers are illustrative. How much your score moves depends on what you’re sending today. But the direction is consistent: server events that carry browser context match far better than server events that don’t.

When the visitor didn’t click an ad

Not every buyer arrives via a Meta click, and that’s fine. Organic and direct visitors still have an fbp cookie if your Meta pixel is on the page, and sending it still helps Meta match the event. If you’re fixing up a contact whose source is missing, Callix’s Link attribution on the CRM record can take an _fbp value, Meta’s browser ID, and find the matching visit even when the lead didn’t come from an ad.

Which events to fix first

If your scores are low across the board, don’t try to fix everything at once. Prioritize by what Meta is optimizing toward.

If your campaigns optimize for Lead, the Lead event’s match quality matters most today, because that’s the signal the algorithm is learning from right now. It’s usually the easiest to improve too, since it fires close to the visit and the browser data is fresh.

If you’re moving optimization deeper into the funnel, toward Qualified Call or Purchase, those events need to be fixed before you switch. A purchase event with weak matching gives Meta fewer usable examples, and with only a few dozen purchases a month, you can’t afford to lose a third of them. A reasonable rule: get the deeper event matching well and arriving reliably for a few weeks before you make it the optimization goal.

Low-volume events also benefit most from each improvement. Moving a Lead event from 6 to 7 changes little when you send thousands. Moving a Purchase event from 4 to 7 when you send 30 a month can be the difference between Meta having enough matched events to learn and not.

A checklist for your next Events Manager review

• Open each event’s EMQ score and compare browser vs. server events.
• For server events, check which parameters Meta says are present and what share of events include each.
• Confirm fbc and fbp are present on server purchases, not just leads.
• Confirm IP and user agent arrive together.
• Check the diagnostics tab for hashing or formatting errors.
• Look at event timestamps: events sent with today’s date for a sale that happened last month distort reporting.

Event match quality isn’t a vanity score. It’s the gate every conversion has to pass through before Meta can use it. For more on getting downstream outcomes back to ad platforms in the first place, see how to pass CRM data back to your ad platforms.