Which GA4 events should your online shop track?

Every visit to an online shop produces data: which products people look at, which ones go into the basket, where checkout is abandoned and which campaign brought in the customer who eventually paid. That data decides where the advertising budget goes, which products get featured and which part of checkout needs fixing.

The trouble is that badly configured analytics gives no warning. The reports keep showing figures, charts and trends; they just stop matching what is happening in the shop. And a wrong number that looks reliable is worse than no number at all, because it invites you to act on it.

Google Analytics 4 (GA4) has a set of recommended ecommerce events, documented in its official ecommerce measurement guide. This article translates them into business terms: what each one measures, what data has to come with it and what breaks when it is missing.

Which decisions go wrong with badly configured analytics?

The most common configuration mistakes are not exotic. They turn up in shops of every size:

• Duplicated revenue. If the purchase is recorded when the thank-you page loads, and that page is reloaded, shared or reopened from the browser history, the sale can be counted twice. The fix is the transaction_id parameter, which is required on the purchase event: with a unique identifier per order, GA4 can recognise that it is the same order. Without it, revenue in the report grows faster than revenue in the bank.
• Missing or wrong currency. A sale value without currency is a number without a unit. A shop that charges in pounds or pesos and sends amounts with no currency, or with another country’s, ends up with revenue reports that reconcile with nothing.
• A broken funnel. If you measure the basket and the purchase but not the start of checkout (begin_checkout), there is no way to tell whether people drop out at the basket or at the shipping form. Those are two different problems with two different fixes, and the report blends them together.
• Unattributed campaigns. Sales appear, but as direct or unassigned traffic. The newsletter that worked and the advert that did not look the same, and the budget is split blind.

None of these mistakes stops the shop from selling. What they stop is you knowing why it sells.

The shop funnel, event by event

Each step of the purchase journey has its own recommended event. Put in order, they form a map of the funnel:

Moment	Event	What it tells you
Views a listing or category	view_item_list	Which listings get attention
Picks a product from the listing	select_item	Which positions and products attract the click
Opens the product page	view_item	Which products are viewed and which are bought
Adds it to the basket	add_to_cart	Real purchase intent per product
Saves it for later	add_to_wishlist	Interest that has not converted yet
Reviews the basket	view_cart	How many people get as far as considering payment
Removes something	remove_from_cart	Which products are dropped at the last moment
Starts checkout	begin_checkout	Where the payment process begins
Chooses shipping	add_shipping_info	Which delivery option is chosen (shipping_tier)
Chooses payment	add_payment_info	Which payment method is used (payment_type)
Completes the purchase	purchase	Revenue, orders and products sold
The order is refunded	refund	Revenue that has to be deducted

Promotions have two events of their own: view_promotion, when a banner or offer is shown, and select_promotion, when someone clicks it. Together they tell you whether the home page promotion actually moves sales or just takes up space.

You do not need to implement everything on day one. The minimum for a readable funnel is view_item, add_to_cart, begin_checkout and purchase. Each event you add afterwards sharpens the diagnosis of one particular stretch.

The data each event carries

The event name says what happened. The parameters say how much, of what and under which conditions.

Event parameters. The important ones are value and currency: Google recommends always sending the currency whenever a value is sent. Purchase and refund also require transaction_id. Optionally you can send coupon, tax and shipping. Promotion events are identified with creative_name, creative_slot, promotion_id and promotion_name.

The items array. This is the list of products involved in the event, and it is where much of the report’s value lives:

• Each item needs an item_id or an item_name. Both are recommended.
• If quantity is not set, GA4 assumes 1.
• An event can hold up to 200 items, and each item up to 27 custom parameters.
• Beyond the identifier and name, each item accepts price, quantity, item_brand, item_variant, item_category (up to item_category5 for hierarchies), discount, coupon, affiliation, index, item_list_id, item_list_name, location_id, promotion_id and promotion_name.

Google’s advice is to send every parameter you have data for, even the optional ones. It is more work once, during implementation, and in return you can break sales down by brand, category or variant without touching the code again. Whatever was not sent cannot be recovered later.

An example: the purchase event

This is what a purchase sent with gtag.js on the order confirmation page looks like:

gtag('event', 'purchase', {
  transaction_id: 'ORD-10482',
  currency: 'USD',
  value: 64.00,
  shipping: 4.50,
  coupon: 'WELCOME',
  items: [
    {
      item_id: 'TSH-021',
      item_name: 'Cotton T-shirt',
      item_variant: 'blue',
      item_category: 'Clothing',
      price: 22.00,
      quantity: 2
    },
    {
      item_id: 'CAP-007',
      item_name: 'Cap',
      item_category: 'Accessories',
      price: 20.00,
      quantity: 1
    }
  ]
});

Three things worth checking: the transaction_id comes from the shop’s real order number rather than being made up in the browser; the currency is explicit; and every product carries an identifier, name, price and quantity.

Refunds use the refund event with the same transaction_id as the original order. For a full refund, the identifier is enough. For a partial one, add items with the item_id and quantity of what was returned. Without this event, the report keeps sales that no longer exist.

Checking that it works

An event nobody has checked is an assumption. GA4 has two tools for verifying the setup before you trust the reports:

• Debug mode (DebugView). It shows the events from your test session in the order they happen, with all their parameters. Walk through the whole journey: open a listing, go into a product, add it to the basket, start checkout and complete a test purchase. Check that each event appears and carries what it should: currency, value, transaction ID and products.
• The real-time report. It confirms that events reach the right property and are not firing twice.

Some tests are worth running on purpose: reload the thank-you page, buy with a coupon, buy several units of the same product and compare the report’s total with the order total in the shop. If they do not match, you will know before making decisions on that data.

It is worth repeating the check whenever the checkout, the shop theme or the platform changes. Those are exactly the moments when an event quietly stops being sent. And since every script added to a shop has a cost, keep an eye on measurement not slowing the pages down either; that is covered in what are Core Web Vitals.

Consent and personal data

Measuring visitor behaviour means processing data, and that comes with rules. Google offers Consent Mode, which lets its tags adjust their behaviour according to what the visitor has accepted in your cookie notice. Each country also has its own legislation: in Colombia, for instance, Law 1581 of 2012 governs the processing of personal data, and other markets have theirs.

Which notice you need and how to configure it depends on where you sell and to whom, and that is a question for a legal adviser rather than a blog post. One technical rule does hold everywhere: do not send GA4 data that identifies people, such as email addresses or names, either in event parameters or in URLs.

Getting campaigns properly tagged

Events describe what happens inside the shop. To know which campaign brought in each sale, visits have to arrive with their origin declared, and that is what UTM parameters are for. How they work and which naming convention to follow is explained in what are UTM parameters.

With the UTM builder you can put together the links for your adverts, newsletters and posts with source, medium and campaign written correctly, and it warns you about anything that would split your GA4 reports: capital letters, spaces or a missing medium. That way, when a purchase arrives with a complete purchase event, it also arrives with the name of the campaign behind it.

---

Well-configured ecommerce analytics is not the setup with the most events. It is the one that counts each order once, in the right currency, with its products and its origin. You configure it once, prove it with a test purchase and review it every time the shop changes.