Event Match Quality Score: What It Means and How to Improve It

Event Match Quality describes customer-information signals for supported events. Read the event’s actual diagnostic and recommendations in Events Manager. A score of 8 does not mean that 80% of customers matched, and a higher score does not prove more orders, lower CPA or better profit.

A synthetic normalization and hashing test

Use fictional local test inputs, never real customer records in shared evidence. For an email field that requires normalization and SHA-256, an illustrative input is Learner@Example.Invalid . Lowercase and trim according to the selected field contract to obtain learner@example.invalid. Hash that normalized UTF-8 string once. This reserved-domain example is for local transformation testing, not a fabricated customer to send to Meta.

The calculated single SHA-256 hex digest is cce975b73213a3e504a39f31c171dccbceb387c5c45f116e5a49487582858e36. Hashing that 64-character lowercase hex string again produces 709974b09a526d89d2a02bee8ad958f694492825301969eef21ea34d9d83ee41. The second value differs and is not the required single hash of the normalized email. A payload can have a plausible-looking hash while representing the wrong transformation.

Assign transformation ownership to one layer. Some connectors normalize and hash supported inputs themselves; verify the actual connector behavior rather than prehashing automatically. Meta’s user-data implementation separates customer identifiers, browser identifiers and request context. Use field-specific rules; do not SHA-256 cookies, click identifiers, IP or user agent indiscriminately, and do not invent missing identifiers.

1. Assert the normalized test string and calculated one-hash output in a local test.
2. Pass the value through the actual mapping layer and inspect protected test output for unintended rehashing or field renaming.
3. Test missing input, malformed input and denied destination use. Omit or suppress according to the contract rather than fabricating a value.
4. Keep the synthetic fixture separate from live events and avoid publishing raw customer values or credentials.

Keep separate counters

These counts are illustrative, not a captured Events Manager report. Do not infer accepted logical totals or duplicates from a global subtraction unless event identity and diagnostics support it. In real data, rejected submissions and missing coverage can make that ideal arithmetic invalid. First validate shared Purchase identifiers and browser matching fields.

Observe the fix with consistent eligibility

Suppose the 100-order cohort contains a mapping bug that double-hashes an already approved email. Correct that transformation, then compare like-for-like periods: same event definition, connector, permission policy, reporting settings, timezone and sufficient processing delay. Record raw eligible order count, receipt coverage, duplicates, rejected jobs and displayed EMQ independently. Correcting the field does not change the authoritative 100-order count.

Use only already available permitted identifiers. Do not replay denied events after permission changes merely to raise the score. Account for shifts in device mix and collection eligibility; a diagnostic change across different populations can be misleading. A score that moves upward is a matching observation, not an experiment proving lower customer-acquisition cost.

Keep media spend, paid customers and margin in a separate mature-cohort report. If claiming a commercial effect, use an appropriate controlled comparison and include implementation cost. NovaStorm is not established here as an EMQ repair or customer-data transmission tool.