Low match quality and a purchase that fired on every reload

Two problems wearing one symptom

Meta’s Purchase numbers weren’t trustworthy, and the match quality score was low. It looked like one problem. It was two.

Match quality

Event Match Quality measures how well Meta can tie a conversion back to a real person. It depends on the identity data you send with the event. I audited every source sending events to Meta: the browser pixel plus several server-side feeds that had piled up over about five years.

The ceiling was the browser pixel itself. It sent no advanced matching on checkout and purchase events. I wired email and name matching into the pixel through GTM, from data the checkout already had.

Purchase EMQ went from 6.1 to 8.3, with 100% Conversions API coverage. Checkout events came up too.

The reload problem

Then I ran a reload test on the order confirmation page. One order produced three Purchase events with three different event IDs.

Meta dedupes on event name plus event ID. The confirmation trigger generated a new ID on every page load, so dedup could never match the copies. Every reload looked like a new sale.

The fix

Two layers, both in GTM:

• Event ID = order ID on the Meta Purchase tag. Now every copy of a purchase carries the same ID, so Meta collapses them.
• A fire-once guard that remembers which orders already fired in this browser. It fails open: if it breaks, tracking keeps working and Meta’s dedup stays as the backstop.

In the same pass I added the order ID to the Google Ads tag and stopped a checkout event from firing on the confirmation page.

How I proved it

Live test: two loads of the confirmation page produced one Purchase, with the event ID equal to the order ID. The reload fired a PageView only.

Limits

Microsoft’s tag has no order ID field, so it relies on the guard. The guard works per browser, so a second device can still re-fire. That’s where Meta’s event ID dedup catches it.