GA4 shows more purchases than orders: find the second sender before you blame GA4

What the transaction ID does and does not do

GA4 has a built-in safeguard: Google documents that purchase events with the same transaction ID are treated as one, on web streams. That sounds like duplicates cannot happen, but the safeguard only works under conditions your set-up may not meet.

It does not help when the ID is blank, because Google warns that every purchase with an empty ID is collapsed together, which hides orders instead of duplicating them. It does not help when the ID is generated differently on each send, because then each send looks like a new order. And it protects against a reused ID only if that ID really is unique per order; Google says a fixed ID reused across orders can undercount.

• The ID must be unique per order, such as an order number, and must not identify a customer.
• The documented deduplication applies to web streams, not app streams.

Where extra purchase events usually come from

These are the senders we look for in a diagnosis; they are common patterns rather than a Google list. Two tags listening to the same trigger. A platform integration and a hand-placed tag both enabled. A confirmation page that sends the event again when it is reloaded or reached with the back button. A page-load trigger on a template that is also used by a status page. A test environment sending to the production stream.

Each leaves a fingerprint in DebugView. Two senders produce two events at the same moment. A reload produces a second event seconds or minutes later. A test environment produces events from your own address and unusual order numbers. Whether GA4's reports count the extra event depends on its ID: Google says purchase events with the same transaction ID are treated as one on web streams, so a resend with the same ID shows in DebugView but not as an extra purchase in reports. The over-count in reports comes from different IDs for one order, for example two senders that format the ID differently, or an ID made afresh on each send.

• In an exploration with the Transaction ID dimension, look for one shop order under more than one ID; in DebugView, look for the same ID sent twice, which reports collapse but which points at the sender.
• Check which platform apps and which tags both mention Google Analytics.

A one-order test that locates the fault

Place one order in test mode, or a cheap order you accept paying for and cancelling, with DebugView open on your debug device. Count the purchase events that arrive and note their transaction IDs. Then reload the confirmation page and note whether another arrives. Then place a second order and confirm it produced a different ID.

GA4 and your shop will also differ for reasons that are not duplicates, such as cancelled orders, refunds and different time zones. This test isolates collection from those effects, so run it before comparing weekly totals.

• One order, one event, one non-empty ID is the pass condition.
• Do not trust a comparison of weekly totals until the one-order test passes.

What does not fit, and how the paid outcome is accepted

Past duplicate events stay in historic reports and cannot be deleted by a repair. Reconciling GA4 revenue to your accounts, tax or refunds is a different job. If purchases are missing rather than doubled, a key-event or ecommerce-events job fits better.

For a doubled purchase on one shop, the fixed outcome Fix duplicate GA4 purchases is quoted at £295 as an untested proposal, with payment only after sign-off. Acceptance is the one-order test: a single test order produces exactly one purchase event with a non-empty ID that is unique to that order and recorded against the shop's order record; a reload and back navigation send no further purchase event, because the repair adds a once-per-order guard; a second order produces its own event with a different ID; and once Google has processed the data an exploration lists each test order under its own ID. Send the platform name and your two totals, not order data or logins.