Event Match Quality: what it is and how to improve it

Last updated: 8 September 2026.

Read the score in the context of the event

Meta's Conversions API verification guide describes a score from 1 to 10 and recommends aiming for at least 6.0 where possible. You can inspect it for a Pixel using CAPI in Events Manager and open the score's recommendations.

Treat that recommendation as a diagnostic starting point. The score is not a published percentage of events successfully matched. An 8 does not establish an 80% match rate, and moving from 6 to 8 does not establish a proportional improvement in revenue.

Inspect the actual event and connection method. A Purchase event may legitimately have customer information supplied during checkout. An anonymous PageView often occurs before that information exists. Comparing their scores without considering available and permitted inputs can encourage bad implementation decisions.

A Lead event also needs a precise definition. A completed form, a lead accepted by a CRM and a qualified opportunity are different outcomes. Match quality cannot rescue an event that fires when someone merely opens the form.

Separate matching from the other quality checks

Review five questions independently:

• Collection: Did the intended business outcome produce an event at the correct destination?
• Validity: Does the event describe the correct action, timestamp, value and currency?
• Deduplication: Do browser and server deliveries of the same outcome resolve to one event?
• Freshness: Did the event arrive promptly enough for its intended use?
• Matching: Are the customer identifiers accurate, usable and associated with the person who performed the action?

Meta's verification documentation exposes freshness, deduplication and matching as separate checks. Its received-event overview can also precede deduplication and other processing. A large received count and a strong score are not a reconciliation to business orders.

Use the Meta versus GA4 guide if the problem is disagreement between attributed totals. Use order-level reconciliation when the problem is missing or repeated purchases. Keep the matching work tied to its actual scope.

Open full diagram

Make a field map before adding more data

For each supported identifier, record where it originates, when it becomes available, which permission allows its use, how it is transformed and which sender supplies it. Name the team that owns a missing or malformed value.

That map often reveals a specific failure: the checkout has an email, the application passes it correctly, but a server-side transformation drops it. Another possibility is that a webhook handler sends the server's own user agent instead of the customer's browser context.

Do not solve a missing customer field by substituting an unrelated one. A support agent's email, a company's shared billing address or an enrichment vendor's guessed contact is not necessarily the person who performed the event. More populated fields can still mean worse data.

Email and phone

Meta's customer-information parameter reference requires hashing for email and phone. For email, trim surrounding spaces and lowercase before hashing. Phone formatting requires a country code and removal of formatting characters under the documented rules.

Normalise with knowledge of the input. If a local phone number lacks country context, blindly removing punctuation cannot establish the correct international number. Resolve the source data or omit the unusable identifier rather than inventing a country code.

Check whether the integration or SDK already performs hashing. Meta documents automatic hashing in its Business SDK. Hashing an already hashed value can produce a valid-looking string that no longer represents the expected input.

Browser, click and request context

The same parameter reference says not to hash fbp, fbc, client_ip_address or client_user_agent. These fields are not processed like email.

For server requests, trace request context back to the relevant customer event. Do not forward a reverse proxy's or worker's identity as if it were the visitor's. Where proxy headers are involved, the engineering implementation must distinguish trusted infrastructure from untrusted client-supplied headers.

Keep identifier collection and transmission consistent with the applicable permission and approved data-use rules. Hashing is a transformation for matching, not evidence that permission exists or that the original field is appropriate to send.

Preserve real click and browser identifiers

Meta's fbc and fbp documentation distinguishes click information from a browser identifier. When available and permitted, preserve the actual values through the event delivery path.

The fbclid value is case sensitive. A URL-cleaning rule that lowercases every query value can corrupt it. Test campaign entry, redirects, cross-domain navigation and the checkout handoff before concluding that the server sender cannot obtain the field.

If the _fbc cookie is absent, Meta documents constructing fbc when a real fbclid is present in the request. Its creation-time component uses milliseconds. Do not invent a click ID for someone with no observed click, and do not copy one customer's click identifier across other customers to raise field coverage.

Keep the latest valid association for the actual customer context. A stale browser identifier attached to the wrong signed-in user is not an improvement. Test logout, shared-device and account-switching boundaries using the same discipline as analytics identity handling.

Keep external customer identity separate from event identity

An external_id represents the person in the advertiser's identity system. An event_id identifies an event occurrence. Reusing a customer ID as the permanent identity of every purchase confuses those jobs.

Meta's external-ID documentation recommends hashing and requires consistent representation across the browser and server channels. It also notes that external IDs are not displayed in the Test Events tool. Their absence from that view alone does not prove the sender omitted them.

Use a stable internal identifier with a documented lifecycle. Avoid switching between a CRM contact ID and an application user ID without a verified mapping. For B2B activity, do not assume an account ID shared by several people identifies the individual who acted.

Deduplication has its own contract. Meta's browser/server deduplication guide recommends matching browser eventID and server event_id, alongside the event name, for the same Pixel. Check that separately from the customer-field map.

Test normalisation locally before sending anything

The following Python example only normalises and hashes an already validated email string. It makes no network request, does not validate deliverability and does not configure consent or a complete CAPI payload. Use fictional input when running it locally.

import hashlib
from typing import Optional

def hash_validated_email(raw: Optional[str]) -> Optional[str]:
    if raw is None:
        return None
    normalised = raw.strip().lower()
    if not normalised:
        return None
    return hashlib.sha256(normalised.encode("utf-8")).hexdigest()

example = hash_validated_email("  Ada.Example@example.com  ")
assert example == hash_validated_email("ada.example@example.com")
assert hash_validated_email("   ") is None

An empty field should not become the hash of an empty string. A raw-input function like this should not receive a previously hashed value. Keep input types explicit in the integration so one component owns normalisation and another does not repeat it accidentally.

Then inspect the final outbound field map using appropriate redaction and access controls. A 64-character hexadecimal value only proves that a value has a hash-shaped representation. It does not prove the source belongs to the customer, was normalised correctly or is permitted for this use.

For debugging, prefer counts and transformation outcomes over dumping raw customer information into general application logs. You need to know that a field was present, valid and passed through, not create a second uncontrolled copy of the contact database.

Measure field loss with two denominators

Suppose an illustrative audit starts with 1,000 eligible business purchases. You find 950 corresponding server events after separately checking their event identities. Among those 950, the source records contain 800 emails that are valid and permitted for this use. Only 600 arrive in the expected hashed form.

There are two useful measures:

• Email coverage across the audited server events is 600 / 950, or 63.2%.
• Completeness among events with an available, permitted email is 600 / 800, or 75%.

The first describes coverage. The second exposes avoidable loss in this field's delivery path. Neither is Meta's EMQ score or an observed matching percentage. The other 150 server events may have other valid matching inputs; they should not acquire fabricated email addresses.

After a field-mapping repair, suppose 780 of the 800 eligible emails arrive correctly in a comparable audit population. Completeness becomes 97.5%, and overall email coverage becomes 82.1% if the server-event total remains 950. Those are measurable implementation improvements.

The original 50 business purchases missing from the server dataset remain a separate investigation. Improving field coverage on delivered events does not recover those purchases. Keep the coverage and missing-event counts on the same review record so one green metric cannot hide another defect.

Compare before and after without inventing a sales result

Save the event name, source, population, time range, volume, field coverage, diagnostics and implementation version before the change. Allow the reporting surface to update, then compare the same definitions after the release.

Look for population changes. Purchase EMQ may rise because a larger share of buyers logged in, because the event mix changed, or because a broken anonymous path stopped sending events. A higher score alongside a sharp drop in business-event coverage deserves investigation.

For this implementation review, success means the identified field loss is repaired, formats pass validation, identities remain correct and other quality measures do not regress. Do not promise a specific score increase or cost-per-acquisition improvement from adding one field.

If the business wants to measure performance impact, define a separate evaluation with suitable controls and stable campaign conditions. Before-and-after ROAS can change for many reasons. The incrementality guide explains how to choose evidence for that causal question.

Handle TikTok's score as a separate measurement

TikTok also exposes an Event Match Quality score. Its Events Manager documentation describes it as a weighted average of matching-key coverage and provides event-level matching, deduplication and diagnostic details.

Do not compare a TikTok score numerically with Meta's as if the platforms share one scoring formula. Use TikTok's own parameter requirements and recommendations for its integration. A field transformation written for Meta should not be copied to another destination without checking that destination's contract.

The portable practice is the field audit: determine what is available and permitted, verify formatting and delivery, distinguish deduplication from matching, and monitor the same event population over time.

An analytics and tracking review should identify the specific handoff losing usable information and leave a repeatable check after the repair. Ask for field-level evidence and verified event coverage before accepting a screenshot of a higher score as the result.