The purchase event and e-commerce
The purchase event records a completed transaction and anchors all e-commerce reporting: revenue, items, and conversion value. It carries a transaction id, a value and currency, and an items array describing what was bought. The discipline is to record the order, not the customer — product and revenue data belong in the event, personal identity does not.
What this means
In GA4 e-commerce, purchase is a recommended event with defined parameters: transaction_id, value, currency, and an items array (item_id, item_name, price, quantity). Those parameters drive revenue, average order value, and product-performance reports. Other steps — view_item, add_to_cart, begin_checkout — lead up to it.
Deduplication and identity
Send the purchase event once per order. A stable transaction_id lets the platform deduplicate if the confirmation page is reloaded, so revenue is not double-counted. Keep the buyer out of it: the transaction_id should reference the order, not the person, and no email or address belongs in parameters.
- Core params: transaction_id, value, currency, items[]
- Stable transaction_id deduplicates reloads
- Order/product data yes; buyer identity no
How it appears in analytics and logs
A purchase event means an order completed. Duplicate transaction ids mean double-counted revenue; missing purchases mean under-reported revenue, often from a tracker that does not fire on the confirmation step.
Diagnostic use case
Measure revenue, items sold, and purchase conversion using a consistent purchase event with a transaction id, while keeping buyer identity out of analytics.
What WebmasterID can help detect
WebmasterID records purchase as a first-party event with order and value data and no customer PII, so revenue analytics stays accurate without ingesting buyer identity.
Common mistakes
- Firing purchase on every confirmation-page reload.
- Reusing a transaction_id and corrupting dedupe.
- Putting customer email or address into parameters.
Privacy and accuracy notes
A purchase event needs order and product data, not the buyer. Keep names, emails, and addresses out; a transaction id should be an order reference, not a customer identifier. This is educational, not legal advice.
Related pages
- The form_submit event
A form_submit event records that a visitor submitted a form — a signup, contact, or checkout form. It is one of the highest-value events because it usually maps to an intent or conversion. The hard rule is that the submitted field values (name, email, message) must never enter analytics: you record that a form was sent and which one, not what was typed.
- Conversion rate: definition and denominators
Conversion rate is the share of some base that converted. The trap is the denominator: conversions per session, per user, and per unique visitor give different numbers and mean different things. Without stating the base, a conversion rate is ambiguous — and comparing rates with different bases is meaningless.
- E-commerce events: the funnel before purchase
E-commerce events are a recommended set that model the shopping funnel before and around purchase: view_item, add_to_cart, begin_checkout, add_payment_info, and purchase. Each shares a common items array, so the same product schema flows through the journey. Implemented consistently, they let you see where buyers drop off — and they carry product data, never buyer identity.
- Event Explorer
Inspect purchase events and their parameters.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.