Meta Event Match Quality: How to Raise the Score

Below: what each parameter is worth on a short form, the hashing rules that break matching without producing an error, where the fbclid goes when a visitor returns on Thursday, and the order to fix things in.

The score sits next to each event in your dataset's detail view in Events Manager, out of ten with a word label. It answers one question: of the events you sent under this name, how confidently could Meta match them to a person with a Facebook or Instagram account? It is not a grade for your tracking setup, your consent banner or the quality of your leads.

You hash the personal parameters, Meta compares them with hashes of what it holds about its own users, and either finds a person or does not. A match can be credited to the ad that person saw and can join an audience. No match, and the event still counts in your totals but floats free.

• It is a matching score

  Not a data quality grade. A perfect pixel on a form asking only for a first name will score badly, and should.

• It is scored per event

  Lead and Purchase score separately. Fixing one does nothing for the other, and an account average is not a thing.

• It is a rolling figure

  It reflects a window of recent events on a delay, so this morning's deploy will not show this afternoon.

Nothing breaks, and that is the trap. The Lead event still fires, still appears in Events Manager, still counts in Ads Manager. A poor match quality does its damage quietly, in three places.

• AttributionAn unmatched event cannot be credited to the click behind it, so your reported cost per lead looks worse than reality and campaigns get judged on part of their output.
• OptimisationDelivery learns from conversions it can attach to people. The fewer leads it identifies, the thinner the signal behind the next impression it buys.
• AudiencesAn unmatched lead cannot seed a lookalike or be excluded from prospecting, so you keep paying to reach people who already filled in the form.

None of that raises an error, and the gap is invisible inside any single campaign, which is why it survives for years. It is a lever, not a KPI: you are completing the record on conversions you already paid for.

The two that do most of the work

Email and phone are worth building the setup around, and your form collects both already. Email is strongest because most people gave Meta an email address themselves, and a personal address matches better than a work one. Before deciding a B2B account is broken: a form that only ever sees [email protected] will score lower, and the fix is a phone number, not a different pixel.

Everything else, in rough order

Names, city, state, postcode, country and date of birth are weak alone and useful in combination. A surname narrows nothing; a surname with a city and a country narrows a lot. Send what the form or the CRM already holds and do not add fields to feed a score. External id is your own stable identifier, a CRM contact id or a first-party cookie value, and it only pays when the same value goes out for the same person every time.

The fbc and fbp values are different in kind: not data you collected but Meta's own click and browser identifiers, and a live fbc is the strongest single link to an ad click because it carries the click id. On a server event, the client IP address and user agent recreate what a browser reports for free. None of those four are hashed.

Meta publishes no weighting, so treat any ranking as a rule of thumb. The direction is reliable: identifiers people gave Meta beat identifiers they gave you, and a click id beats both.

Personal parameters are hashed with SHA-256 before they leave your systems, and this is where most matches are lost. A hash is all or nothing: change one character before hashing and the output shares nothing with the hash Meta holds. No partial credit, no rejection, and no sign of it except a score that will not rise.

• Email: trim, lowercase, hash. Do not strip dots out of a Gmail address.
• Phone: digits only with the country code, no plus, no spaces, no leading zero. 0151 2345678 becomes 491512345678.
• Names: lowercase, trimmed, no titles or punctuation, each in its own field.
• City: lowercase, spaces and punctuation removed. Frankfurt am Main becomes frankfurtammain.
• State: the two-letter code in lowercase for the US, the lowercased name elsewhere.
• Postcode: lowercase, no spaces; for the UK the area, district and sector part.
• Country: the two-letter ISO code in lowercase. Send de, not Germany or DEU.
• Date of birth: eight digits, year, month, day, nothing between.
• Client IP, user agent, fbc and fbp: never hashed. Hashing them removes them from play.

The five mistakes that produce an unmatchable hash

1. Case. [email protected] and [email protected] are one address and two unrelated hashes. Lowercase on the way out, including anything a human typed into a CRM.
2. Whitespace nobody sees: a trailing space from a paste, a non-breaking space from a form field, a tab from a CSV import. Trim first, or it is invisible forever.
3. A phone number in national format. A leading zero and no country code produce a number Meta has never held. Check this first in a European account.
4. Hashing something already hashed: a CRM storing hashed emails, or a tag template hashing on the way into the server container. Meta accepts a pre-hashed value, so nothing complains and nothing matches.
5. Placeholders: the hash of an empty string, or of the text null, undefined, N/A or 0. Meta counts the parameter as present, so coverage looks complete while the match rate stays put.

A click on a Meta ad lands with an fbclid on the URL. The pixel reads it, wraps it into the _fbc cookie as fb, a subdomain index, a creation timestamp in milliseconds and the fbclid joined by full stops, and sends that as fbc on every later event from the browser. Four things break it.

• The pixel never ran: no consent decision yet, an ad blocker, a script error, or a landing page on a domain the pixel is not on. No cookie, no click id.
• The visitor returned without the parameter. An fbclid only exists on the ad click, so a Monday clicker who submits on Thursday carries fbc only if Monday's cookie survived.
• Cookie lifetime. The _fbc cookie defaults to ninety days, but Safari caps a cookie written by a browser script at seven, which is much of why iOS matches worse.
• A redirect stripped the query string: a link shortener, a consent gate, a CMS redirect from the non-www host, an A/B tool that rewrites URLs.

How to persist it

Stop treating a browser cookie as the only home for the click id. Read the fbclid on the first request, store it server-side against a first-party visitor identifier, and write it onto the lead record at the form fill. The form fill, the call on Thursday and the deal that closes in March then carry the same fbc. If you build the value yourself, keep the format and use the moment you first saw the fbclid as the timestamp. Same discipline that keeps a gclid alive to the closed deal, and the same reason a click id belongs in the CRM.

A story that repeats: the team moves from a browser pixel to a clean Conversions API integration on the promise of better data, and the match quality on the Lead event drops. That is not a fault in the Conversions API. It is what a server knows compared with what a browser never had to be told.

A browser event carries the visitor's IP address, the user agent and the _fbc and _fbp cookies for free. Fire a server event out of your CRM and, unless you carried those four along, all Meta has is what the form collected. The rule is not server instead of browser, it is server with the browser's context attached: capture on the page, send from the server, which is also the case for tracking server-side on your own domain.

Do that and you now send a browser event and a server event for the same lead, which raises the obvious question: does Meta count it twice? Not if both carry the same event name and the same event id. Meta keeps one and discards the other.

1. Generate one id per conversion, not per page view. A UUID created at submit works, and so does a CRM lead id that exists before either event goes out.
2. Send it as the event id on the browser call and in the server payload, with the same event name on both.
3. Send both promptly. Meta deduplicates inside a window of roughly two days; an event arriving later is simply a second conversion.
4. Check rather than assume. The event's detail view reports the overlap between your browser and server sources.

One detail catches people out: Meta keeps the event it received first and drops the later one. It does not merge the payloads. A plan where the browser event carries the cookies and the server event carries the identifiers does not work. Put the full parameter set on both.

Work in this order. It is roughly the order of return on effort.

1. Audit what you send. Open the Lead event and read the parameter list: it shows which parameters arrive and on what share of events. That, not the score, is the work queue.
2. Add the identifiers you already collect. If the form asks for a phone number and only the email reaches Meta, that is the biggest lift available, with no new field.
3. Fix normalisation before adding anything new. A fifth parameter on top of four broken ones changes nothing.
4. Persist fbc and fbp: capture the fbclid on the first request, store it against the visitor and then the lead, and send fbc on every later event.
5. Pass the IP address and user agent on every server event, taken from the visitor's request.
6. Deduplicate: same event name, same event id, both sides carrying the full parameter set.
7. Wait, then re-check. Give it several days of representative volume and compare a full week with the week before.

A guide telling you to send Meta more personal data owes you the other half. All of this applies to visitors who consented. Raising the score is about completing the record for the people who said yes, not routing around the ones who said no.

Server-side changes where the call is made, not whether you were allowed to make it, and a visitor who declined should not have an fbc built on the server because the browser could not write one. Meta's business tools terms put the obligation on you to hold the rights for what you send.

The upside: almost every account loses more matchable events among consented visitors, through missing parameters, broken normalisation and lost click ids, than it could recover by pushing past a decline. More in GDPR-compliant conversion tracking.

LeadJourney captures the click ids at the first visit and keeps them: fbclid, from which it builds fbc and fbp, alongside gclid, li_fat_id and msclkid, plus the UTMs and the landing page. The anonymous first click is joined to the person at the form fill, the call or the booking, so the click id is on the lead record before sales has touched it. Tracking runs server-side on your own domain at 95%+ accuracy.

Events go to Meta over the Conversions API with the full customer information parameter set and event deduplication. Because the journey keeps recording after the form, you can map CRM stages back as conversions: qualified lead, proposal sent, closed won. The deal amount and currency travel with the event, so value based bidding optimises on revenue rather than form fills.

What it does not change is the arithmetic of consent: tracking is first-party and respects consent decisions rather than working around them, so a visitor who declined is not identified. It also cannot invent an identifier your form never collected. Setup is one script on the site or in the GTM container, live in about 21 minutes without a developer, hosted in Frankfurt with a DPA signed.

Read verified reviews on Trustpilot, G2 and leadjourney.io/testimonials.

Keep going with the Meta Conversions API guide, the fix for poor Meta lead quality and why GA4, Meta and Google conversions never match your CRM. Definitions sit in the event match quality glossary entry, and the product side is the Meta Ads integration and the event match quality use case.