{"id":8831,"date":"2026-08-18T06:23:00","date_gmt":"2026-08-18T04:23:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8831"},"modified":"2026-10-24T01:42:42","modified_gmt":"2026-10-23T23:42:42","slug":"meta-conversions-api-maximizing-event-match-quality-emq-and-deduplication","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/meta-conversions-api-maximizing-event-match-quality-emq-and-deduplication\/","title":{"rendered":"Meta Conversions API: Maximizing Event Match Quality (EMQ) and Deduplication"},"content":{"rendered":"
What EMQ measures<\/h2>\n
Meta Pixel sends events from a browser; the Conversions API (CAPI) sends events from a server. When both report the same purchase, matching identifies a possible Meta account and deduplication identifies the repeated event. These are separate tasks.<\/p>\n
Event Match Quality (EMQ) is a score out of 10 for the customer information supplied with web events. The score indicates how useful the information may be for matching. An EMQ of 8 does not mean that 80% of purchases were matched. Neither a high score nor successful deduplication proves correct attribution, incremental sales or lawful processing.<\/p>\n
Normalise each field before hashing<\/h2>\n
SHA-256 creates a fixed-length fingerprint of an input. A trailing space changes the hash. Meta therefore specifies field-specific preparation:<\/p>\n
\n
em<\/code>: trim surrounding whitespace and convert the email address to lowercase. Suspicious control or invisible format characters should trigger validation rather than silent changes to an address.<\/li>\n
ph<\/code>: establish the international number with the correct country code before removing formatting. Removing non-digits alone does not add a country code or correctly handle a national trunk prefix.<\/li>\n
Names and address fields: follow the individual parameter rules. A blanket removal of accents is incorrect; Meta’s name example preserves the accented character in val\u00e9ry<\/code>.<\/li>\n<\/ul>\n
Email addresses, telephone numbers and the specified name\/address fields require SHA-256 hashing. Client IP address, user agent, fbp<\/code> and fbc<\/code> are transmitted unhashed. Hashing external_id<\/code> is recommended by Meta, rather than universally required by the API. Hashing does not turn linkable customer information into anonymous data.<\/p>\n
A deliberately narrow Node.js example<\/h3>\n
The following ES module hashes an email address or an already validated international telephone number. The email check is a basic plausibility check, not full address validation. Telephone parsing and country validation belong upstream; the regular expression only checks the accepted shape. National or formatted numbers are rejected instead of guessed. A significant zero after a country code remains intact.<\/p>\n
import { createHash } from 'node:crypto';\nconst sha256 = value => createHash('sha256').update(value, 'utf8').digest('hex');\nexport function hashEmail(raw) {\n if (typeof raw !== 'string') return null;\n const email = raw.trim().toLowerCase();\n if (\/[\\p{Cc}\\p{Cf}]\/u.test(email) || !\/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$\/u.test(email)) return null;\n return sha256(email);\n}\nexport function hashCanonicalPhone(e164) {\n if (typeof e164 !== 'string' || !\/^\\+[1-9][0-9]{6,14}$\/.test(e164)) return null;\n return sha256(e164.slice(1));\n}\n<\/code><\/pre>\n
Invalid inputs return null<\/code> and must be omitted from the payload. An SDK or tag template may already normalise and hash fields: double hashing produces the wrong identifier. The selected integration’s input contract therefore matters.<\/p>\n\nField-specific normalisation precedes hashing. Deduplication additionally requires a matching event name, Pixel ID and receipt window.<\/figcaption><\/figure>\n
One event, one shared identifier<\/h2>\n
The recommended pairing uses the same event name and event identifier for the same Pixel ID. In the browser the parameter is eventID<\/code>; in CAPI the parameter is event_id<\/code>. For a purchase, both event names must be Purchase<\/code>. Meta documents a 48-hour receipt window measured from the first event with that identifier.<\/p>\n
The identifier can originate in the backend or browser. A stable purchase-event identifier created once and passed to both paths is preferable to two independently generated values. Retries of the same event retain the identifier; a new purchase receives a new identifier. An identifier shared by all purchases would collapse distinct events.<\/p>\n
Fast delivery reduces queue-related problems, but does not guarantee an immediate dashboard update. The server payload is not always retained or merged in full. Meta describes several strategies and generally prefers the first event received when the contents do not differ meaningfully.<\/p>\n
Cookies, external IDs and consent<\/h2>\n
The _fbp<\/code> and _fbc<\/code> cookies are first-party cookies. Existing values can populate fbp<\/code> and fbc<\/code>. A constructed fbc<\/code> requires an actually observed fbclid<\/code>; the click identifier is case-sensitive. Fabricated values do not improve measurement.<\/p>\n
An external_id<\/code> is an advertiser-assigned customer identifier. Meta can associate the identifier with an account after a match using other customer information, then reuse that association for later events. Associations expire periodically. Consistent identifiers can help continuity, but cannot guarantee cross-device attribution weeks later or extend an attribution window.<\/p>\n
For a consent-based advertising setup, the browser and server paths both need the applicable consent check. Google Consent Mode does not automatically block a Meta server tag: the CMP signal must be explicitly mapped and enforced. Revocation must also stop queued transmissions when consent no longer permits processing. Hashing and server-side transport do not replace these controls.<\/p>\n
Validation before relying on the reports<\/h2>\n
A controlled purchase should produce a browser event and a server event with identical name and identifier, followed by the expected deduplication result. Separate checks cover absent consent, withdrawal, retries, delayed delivery and missing identifiers. EMQ trends are useful diagnostics alongside event counts and processing errors, not a standalone quality certificate.<\/p>\n
The related implementation walkthrough is Meta Conversions API through server-side GTM<\/span>.<\/p>\n
\n
Questions and answers<\/h2>\n
Does arrival order matter?<\/h3>\n
With the recommended event-ID pairing, either channel can arrive first within the documented window. Arrival order can affect the retained data; richer server parameters are not guaranteed to survive. The alternative pairing using fbp<\/code> or external_id<\/code> generally requires the browser event first and has different limitations. Queue monitoring should therefore cover maximum delay and the actual matching method.<\/p>\n<\/div>\n
![\"Normalisation](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/quality-8831-20261024.png\")