This is for ecommerce owners and marketers who are checking their store’s tracking, or writing a brief for the person who sets it up. After reading, you’ll know which ecommerce events Google documents for Google Analytics 4, which parameters the purchase event needs, and how transaction_id keeps one order from being counted twice. The guide sticks to Google’s own developer and Analytics Help pages, and it says so where those pages stay quiet.
Google’s Measure ecommerce guide lists events for browsing, the cart, checkout, purchase and refunds[1]. The purchase event requires a transaction_id and an items array. Value and currency are flagged as well, and if you send value you must send currency[2]. Coupon, shipping and tax are optional[2].
The GA4 ecommerce events Google documents
Google’s Measure ecommerce page lists the events by name[1]. It’s easiest to read them in three groups that follow the shopper’s path. The grouping is ours, not Google’s, so treat it as a reading aid.
Browsing
- view_item_list
- select_item
- view_item
- view_promotion
- select_promotion
These cover product lists, individual product views and promotions[1]. The pages we’re drawing on give the names and little else, so we won’t guess at exactly when each one should fire. Open the developer page and read the example for each before you brief anyone.
Cart and checkout
- add_to_wishlist
- add_to_cart
- view_cart
- remove_from_cart
- begin_checkout
- add_shipping_info
- add_payment_info
Google’s reference wording for three of these is short and useful[2]:
- add_to_cart marks an item being added to the cart.
- begin_checkout marks a checkout being started.
- add_shipping_info and add_payment_info mark shipping or payment details being submitted.
Note the verb in the last two: submitted. The event is defined by the shopper sending their details, not by a shipping or payment form simply appearing on screen.
Purchase and refund
- purchase
- refund
Purchase is the one that matters most, because it carries the order. Google’s pages don’t spell out, in the sections we’re using, how refund should be built, so check the developer reference for its parameters rather than assuming they mirror purchase[1].
Watch out
The pages we used don’t say you must send every event on the list. They define what a purchase needs. Beyond that, send the events that answer questions you actually have about your shop.
What the purchase event needs
Google describes purchase as one or more items being bought[2]. Here’s how the parameters break down, using the reference page[2]:
- transaction_id: required.
- items: required.
- value and currency: flagged in the reference as well.
- coupon, shipping and tax: optional.
There’s one dependency to remember. If you set value, currency is required[1][2]. A purchase with a value and no currency is an incomplete event, so check both are sent together.
What goes in value? The guide describes the purchase value as price multiplied by quantity, added up across all the items[1][2]. Settle with your developer in advance what that figure includes. The pages we’ve drawn on list shipping and tax as separate parameters, so agree whether they belong in value before the tag is built.
Tip
When you test, put one order through and compare the transaction_id, the value and the currency in the event with the confirmation email. If any of the three differs, something in the setup needs another look.
The items array
Every ecommerce event that deals with products carries an items array, one element per product[1]. The limits and defaults worth knowing:
- The array can hold up to 200 elements.
- Each item can carry up to 27 custom parameters, on top of the standard ones.
- Each item needs an item_id or an item_name. Google recommends sending both.
- Quantity defaults to 1 if you leave it out.
That last default is easy to miss. If a product line is sent without a quantity, it counts as one unit, so a customer who bought three of something would show as one. Send quantity every time and check it against your order system.
On the ID and name, follow Google’s recommendation and send both[1].
Stopping duplicate purchases
Think about the confirmation page. A customer pays and lands on it, then refreshes it. If the purchase event fires on every load, one order could be reported more than once. The transaction_id is the safeguard here. Analytics Help says purchases that share a transaction ID are deduplicated[4].
That only works if the ID is right. Use a unique ID for each order, and the same ID for the same order every time. Google warns that reusing an ID for different transactions can badly undercount key events[4]. A hardcoded test value or a blank field sent on every order would make all orders share one ID, which is exactly the situation Google warns about.
One gap in what we’ve drawn on: the pages don’t give a time window for how long deduplication applies, so we won’t state one. If it matters for your setup, ask Google or test it.
To mark purchase as a key event and see where it appears, see our walkthrough at https://oxfordimpulse.com/mark-ga4-key-events-where-to-see/ .
Where the data shows up
Don’t expect purchases to appear the second they happen. Purchase data reaches reports, explorations and the Data API after about 24 hours[3]. If you test an order at 10am and see nothing, wait until the next day before assuming the tag is broken.
When it does arrive, open Reports and find the Ecommerce purchases report[5]. It shows item dimensions, so you can see which products sold rather than just how many orders came in[5]. If product names look wrong or missing there, go back to the items array and check item_id and item_name.
FAQs
What is the GA4 purchase event?
It’s the event that marks one or more items being bought[2]. It carries the order details, such as the transaction ID, the items, and the value and currency.
Which parameters does the purchase event require?
Is currency required on a purchase event?
What does transaction_id do in GA4?
It identifies the order. Purchases that share a transaction ID are deduplicated, so a refreshed confirmation page shouldn’t add a second sale[4]. For that to work, every order needs its own unique ID.
Can I reuse a transaction ID?
Not for different orders. Google says reusing an ID across different transactions can badly undercount key events[4]. Use the order number from your shop or another value that’s unique per order.
How many products can one event carry?
How long until purchases appear in GA4?
About 24 hours for reports, explorations and the Data API[3]. Check again the next day before you decide anything is broken.
Where to go from here
Start by testing one real order against the list above: transaction_id present and unique, items filled in, value with currency. Then decide which browsing and checkout events your questions actually need. If you’d rather have someone check your tracking with you, get in touch with Oxford Impulse at https://oxfordimpulse.com/contact/ .
Sources
- Measure ecommerce | Google Analytics | Google for Developers developers.google.com
- Recommended events | Google Analytics | Google for Developers developers.google.com
- Set up a purchase event | Google Analytics | Google for Developers developers.google.com
- Minimize duplicate key events with transaction IDs – Analytics Help support.google.com
- [GA4] Ecommerce purchases report – Analytics Help support.google.com
