Event Match Quality (EMQ)

Meta rates each event name on which customer information parameters your server events carry, how consistently they are present, and how often they lead to a successful match against an account. The score is shown next to the event in Events Manager with a short rating and a breakdown of which parameters were sent, how often, and which are missing. The score only concerns events sent through the Conversions API; the browser pixel matches through its own cookies and does not get an EMQ.

It is worth being clear about what the score does not measure. It says nothing about whether your events are deduplicated, whether the event volume is right, or whether a Lead event actually represents a lead. A perfect 10 on events that fire for every spam submission is still a campaign optimising on spam.

Every parameter is a key Meta can try against its account records. Some identify one person on their own, others only narrow the field, and the score rewards sending several together. Personal identifiers are hashed with SHA-256 before sending; the click ID, browser ID, IP address and user agent are sent as they are.

• Email (em)

  The address the person typed into your form, normalised and hashed. The single most useful key for a lead, because most Meta accounts are registered with one.

• Phone (ph)

  In international format, digits only, then hashed. Especially valuable for call-heavy businesses where the phone number is the field every lead fills in.

• Click ID (fbc)

  Built from the fbclid that Meta appends to the landing URL of an ad click. It points at a specific click, which makes it a very strong match.

• Browser ID (fbp)

  The value of the _fbp cookie the pixel sets. It identifies the browser rather than the person, and helps Meta join the server event to what the pixel saw.

• IP address and user agent

  Required on website events. Taken from the visitor's own request; a server's IP in this field lowers matching for every event you send.

• External ID

  Your own identifier for the person, typically the CRM contact ID, sent from both pixel and server so Meta can link events across visits.

Hashed first name, last name, city, postcode, country, date of birth and gender also count. They rarely identify a person alone but each one improves the odds when it is combined with the others.

Suppose a campaign produces 100 leads in a month at €8,000 spend. With Lead events Meta can match 60 of them, the campaign reports 60 leads at €133 each. With events it can match 90, the same campaign reports 90 leads at €89 each. Nothing changed in the market; only the matching did. Three consequences follow from that gap.

• AttributionUnmatched leads are missing from the campaign report, so the cost per lead you see is higher than the one you pay, and budget decisions rest on the wrong number.
• OptimisationMeta's delivery learns from matched conversions. Fewer matches mean a smaller training set, slower exit from the learning phase and audiences built from a thinner sample.
• CRM eventsA qualified lead or a won deal sent from the CRM days later carries no fresh browser signals. Its match depends entirely on the email, phone and click ID you stored at the form submit.

That last point is why lead generation setups score lower than shops unless they plan for it: the events that matter most arrive latest and have the least to match on. The Event Match Quality use case goes through the same problem from the account's point of view.

1. Capture fbc and fbp at the form submit and store them on the lead record, so a stage change three weeks later can be sent with the click that started it.
2. Send the email and phone the lead typed, normalised the way Meta specifies before hashing: lowercase, no spaces, phone with country code and no symbols.
3. Add an external ID on both the pixel and the server events, for example the CRM contact ID, so Meta can join the form submit to the later stages.
4. Pass the original IP address and user agent from the session, not your server's, on every website event.
5. Check the Test Events tab in Events Manager while setting up: it shows which parameters arrived on each event before the score has time to move.

Doing this by hand means a form handler, a place to store identifiers in the CRM and a job that posts events on stage changes. Doing it with server-side tracking means the tracker that saw the click keeps the identifiers and reuses them for every later event.

Event Match Quality is a readout, not a goal in itself: it tells you how much of what you send Meta can actually use. For a lead generation business the score is decided at the form submit, when the click ID, the email and the phone number are either stored for later or lost. Store them, send them with every stage that follows, and the leads you pay for are the leads Meta counts. The Meta lead quality guide covers what to send once the matching works.