What a transaction ID does
A transaction ID is the reference that identifies one order and no other. It is sent with the purchase event, and analytics and advertising platforms use it as the key that decides whether an incoming record is a new sale or a repeat of one they already have. Send the same identifier twice and the second is discarded; send two different identifiers for one sale and both are kept.
The right value is almost always the order number your shop platform already generates, because it is unique, stable and traceable — you can look it up when a report and your books disagree. What it must never be is a timestamp, a session identifier or a random number generated on the page, because all three produce a fresh value every time the confirmation page loads, which is precisely the situation the field exists to handle.
Why the transaction ID matters
It is the only thing standing between your revenue report and double counting, and a shopper does not have to do anything unusual to trigger it. Refreshing the thank-you page, bookmarking it, reaching it again through the browser’s back button, or returning from a payment gateway that loads the page twice will each send another purchase event.
The consequence is worse than an inflated report. Google Ads and Meta bidding learn from the conversions you send them, so duplicated orders teach the system that some traffic is more profitable than it is, and budget follows that belief. Inflated revenue also flatters return on ad spend, which makes the underlying error hard to spot: nobody investigates a number that looks good.
Where transaction IDs go wrong
Generating the value in the browser is the most common fault, and it defeats deduplication entirely. Sending an empty field is next; a purchase event with no identifier is accepted, so nothing warns you, but no repeat can ever be recognised.
Then there are mismatches between systems. If GA4 receives the shop’s order number while Google Ads receives a different reference for the same sale, neither platform can be reconciled against the other or against your accounts. The same applies to server-side sending: when a purchase arrives from both the browser and the server, they must carry the identical identifier or the order is counted once from each source.
The last one is order numbers that restart. Some shops reset their numbering each year or run separate sequences per branch, which eventually recycles an identifier and causes a genuine new order to be discarded as a duplicate.
How to get it right
Use the platform’s own order number, send it to every system that records the sale, and confirm the value is identical in each. Then test it the way a shopper would break it: place a real order, refresh the confirmation page, navigate away and come back, and complete an order through your payment gateway’s redirect, checking in GA4’s DebugView that only one purchase is recorded each time.
Finally, reconcile a full month of orders and revenue against your shop platform. A gap in either direction points at this field before anything else, and closing it is routine work in an analytics and tracking review.