One order.
One purchase event.
Try the clicks that inflate conversion reports. Compare an unguarded flow with an order-ID guard, side by side.
A fictional checkout
A $30 sample order is ready. Submit it, repeat the submission, or revisit the confirmation.
The refresh button simulates a confirmation revisit. A real browser reload also preserves this tab's demonstration state.
Count the order, not the clicks.
What this proves — and what production needs
This is an independent, AI-assisted engineering demonstration, not a deployed WordPress/GTM integration or a previous client result. It sends no requests to Meta and processes no payments. Counters describe the local simulation only.
Two separate controls matter: a stable checkout token prevents repeat submissions from creating another order; a confirmed order ID prevents a confirmation revisit from emitting another Purchase event. A new checkout gets a new token and must still count normally.
Here, a ledger is simulated in browser session storage. Production needs server-enforced idempotency with an atomic uniqueness constraint, verified order state, a defined conversion point, and delivery/retry handling. Browser storage alone cannot guarantee deduplication across devices, cleared storage, or concurrent requests. Meta browser/server deduplication is a separate configuration concern.
For WordPress, the exact hooks depend on the form/plugin and checkout type. Test with GTM Preview and Meta Test Events, check existing tracking sources, and validate repeated submissions, reloads, Back navigation and genuinely new orders before publishing.