The refund event
refund is a GA4 recommended e-commerce event that records a refund against a prior transaction. It references the original transaction_id and carries the refunded value (and items, for partial refunds). It matters because reported revenue is misleading if refunds are not subtracted — refund events let analytics reflect net revenue rather than gross.
What this means
refund is a GA4 recommended retail event. A full refund references the original `transaction_id`; a partial refund also includes the specific `items` and quantities being refunded along with the refunded `value` and `currency`. GA4 uses it to adjust revenue downward so reports reflect what was actually kept.
Without refund events, dashboards overstate earnings — every cancelled or returned order still counts as revenue.
Net revenue and refund monitoring
Firing refund events keeps revenue honest: gross purchase revenue minus refunds approximates net. Beyond accounting, refund patterns are diagnostic — a product or acquisition source with an outsized refund rate may indicate misrepresentation, quality problems, or fraudulent orders. Always reference the original transaction so the refund nets against the right purchase, and send currency with value.
- Full refund references the original transaction_id
- Partial refund lists the specific items refunded
- Lets reports show net rather than gross revenue
How it appears in analytics and logs
A refund event means a previous purchase was reversed in full or part. A rising refund rate for a product or source can signal quality issues, misleading marketing, or fraud.
Diagnostic use case
Record refunds so revenue reports show net rather than gross, and so you can monitor refund rates by product or campaign.
What WebmasterID can help detect
WebmasterID can record refund events first-party tied to the original transaction, so net revenue is visible without third-party e-commerce tags.
Common mistakes
- Reporting gross revenue while ignoring refunds.
- Omitting the transaction_id so the refund cannot net.
- Sending a partial refund without the refunded items.
Privacy and accuracy notes
A refund event references a transaction_id and amounts, not a person. Keep customer identifiers and payment data out of the payload.
Related pages
- 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.
- 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.
- The begin_checkout event
begin_checkout is a GA4 recommended e-commerce event that fires when a visitor starts checkout. It carries the items in the order plus currency, value, and an optional coupon. It marks the transition from cart to purchase flow and is the entry point for measuring checkout abandonment — the gap between starting checkout and completing a purchase.
- Event Explorer
Inspect refund and revenue events.
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.