Matching Meta Purchase Events Correctly: Preparing Customer Data and Avoiding Duplicates
Part 5 of 5 in the series From pixel to server: tracking that holds

Management Summary
Meta's Conversions API sends purchase information from a website's server to the advertising platform. Two separate tasks matter: linking a purchase to a customer account and recognising when browser and server reports describe the same purchase. Event Match Quality rates the usefulness of the supplied customer details for the first task; a shared purchase identifier supports the second. Together they help make advertising reports more reliable, but a high score does not prove extra sales caused by advertising.
Contents
What EMQ measures
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.
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. Attribution assigns purchases to advertising interactions. Incremental sales are sales caused by advertising that would otherwise not have occurred. Neither a high score nor successful deduplication proves either result or lawful processing.
Field-specific preparation before hashing
Normalisation prepares values in an agreed format, for example by removing surrounding spaces. SHA-256 creates a fixed-length fingerprint of an input. A trailing space changes the hash. Meta therefore specifies field-specific preparation:
em: surrounding whitespace is removed and the email address converted to lowercase. Suspicious control or invisible format characters should trigger validation rather than silent changes to an address.ph: the international number with the correct country code is established before formatting is removed. Removing non-digits alone does not add a country code or correctly handle a national trunk prefix.- Names and address fields: the individual parameter rules apply. A blanket removal of accents is incorrect; Meta’s name example preserves the accented character in
valéry.
Email addresses, telephone numbers and the specified name/address fields require SHA-256 hashing. Client IP address, user agent, fbp and fbc are transmitted unhashed. Hashing external_id is recommended by Meta, rather than universally required by the API. Hashing does not turn linkable customer information into anonymous data.
A deliberately narrow Node.js example
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.
import { createHash } from 'node:crypto';
const sha256 = value => createHash('sha256').update(value, 'utf8').digest('hex');
export function hashEmail(raw) {
if (typeof raw !== 'string') return null;
const email = raw.trim().toLowerCase();
if (/[\p{Cc}\p{Cf}]/u.test(email) || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/u.test(email)) return null;
return sha256(email);
}
export function hashCanonicalPhone(e164) {
if (typeof e164 !== 'string' || !/^\+[1-9][0-9]{6,14}$/.test(e164)) return null;
return sha256(e164.slice(1));
}
Invalid inputs return null and must be omitted from the payload. An SDK is a software library supplied to help an application use a service. An SDK or tag template may already normalise and hash fields: double hashing produces the wrong identifier. The integration’s documentation must therefore state whether each field expects raw text or an already calculated hash.

One event, one shared identifier
The Pixel ID identifies the configured Meta event source; the event identifier distinguishes one purchase from another. The recommended pairing uses the same event name and event identifier for the same Pixel ID. In the browser the parameter is eventID; in CAPI the parameter is event_id. For a purchase, both event names must be Purchase. Meta documents a 48-hour receipt window measured from the first event with that identifier.
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.
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.

Cookies, external IDs and consent
The _fbp and _fbc cookies are stored under the website’s own domain and are therefore first-party cookies. Existing values can populate fbp and fbc. A constructed fbc requires an actually observed fbclid; the click identifier is case-sensitive. Fabricated values do not improve measurement.
An external_id 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.
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 consent management platform (CMP), which records consent choices, must supply a signal that the server integration explicitly checks. Revocation must also stop queued transmissions when consent no longer permits processing. Hashing and server-side transport do not replace these controls.
Validation before relying on the reports
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.
The related implementation walkthrough is Meta Conversions API through server-side GTM.
Questions and answers
Does arrival order matter?
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 or external_id generally requires the browser event first and has different limitations. Queue monitoring should therefore cover maximum delay and the actual matching method.
From pixel to server: tracking that holds
- The Evolution of Web Tracking: From Log Files to the Server-Side Future
- Moving GA4 Visitor IDs to the Server: The Tag Manager Migration Option
- Hosting Google Tag Manager on Cloud Run: Planning Capacity, Reliability and Costs
- Reporting Later CRM Sales to GA4: Using the Measurement Protocol
- Matching Meta Purchase Events Correctly: Preparing Customer Data and Avoiding Duplicates


