Fix duplicate purchase events inflating marketing revenue

One test order produces two purchase events after the confirmation page is refreshed. Advertising decisions based on the inflated total can then overvalue the campaign.

Why this happens

Both browser code and a tag manager may send the same event, or a page-load trigger may run repeatedly. A payment confirmation is a business event, not every rendering of a thank-you page.

Step-by-step solution

1. Trace one synthetic order from checkout to confirmation. Inspect network requests and tag previews to identify each sender.

2. Choose a clear event owner and send a stable transaction_id for the same completed order. Apply the destination platform’s documented deduplication rules.

3. Test refresh, back navigation and a repeated webhook. Ensure retries reuse the order identifier and do not manufacture a new purchase.

Worked example

Order TEST-104 should keep that identifier across retries. A second legitimate order, TEST-105, must receive a different identifier even if the buyer and amount are identical.

Verify the fix

Reconcile unique completed test orders with recorded transactions. Verify revenue, currency and refund handling as well as event count; suppressing all repeat users would hide genuine purchases.

Prevent a repeat

Maintain an event specification naming the producer, trigger and identifier. Avoid stacking a new purchase tag on top of an existing integration without auditing it.

Reference

Official documentation or standards guidance

An original Gistmax troubleshooting guide. Scenarios and sample values are illustrative; configuration depends on your software version and environment. Cover diagram: Gistmax Tutorials.