Google Analytics 4 (GA4) uses event-based measurement to record how customers interact with an online store. Ecommerce tracking extends this model with standardized events and parameters that describe product views, shopping cart activity, checkout progress, purchases, refunds, and promotions.

A correctly structured implementation gives an online store more information than basic page views and conversion counts. It can show which products customers view, which products they add to their carts, where they leave the checkout process, and which promotions contribute to purchases.

However, sending an event to Google Analytics does not automatically make it a correctly implemented ecommerce event. The event name, parameters, product information, transaction values, and trigger conditions must follow the GA4 measurement specification.

This article explains the GA4 ecommerce measurement model, the data required to describe products and transactions, and the differences between implementing ecommerce tracking with gtag.js and Google Tag Manager.

Key Takeaways

GA4 ecommerce tracking uses standardized recommended events to measure shopping interactions throughout the customer journey.
The items array contains product-level information and can be included in relevant ecommerce events.
Event-level and item-level parameters serve different purposes and must be structured correctly.
Purchase events require a unique transaction identifier and product information. Monetary values must use the correct currency and calculation method.
GA4 supports item-level discounts, coupons, promotions, and custom item-scoped parameters.
gtag.js and Google Tag Manager implement the same GA4 measurement model through different technical workflows.

How GA4 Ecommerce Tracking Works

GA4 does not use a single ecommerce tracking command. It measures individual interactions through events.

An event represents an action or occurrence. Its parameters provide additional information about that action.

For example, when a customer adds a product to the shopping cart, the website can send an add_to_cart event. The event can contain:

The product identifier.
The product name.
The product price.
The selected quantity.
The product category.
The currency.
The total value of the added items.

Google Analytics receives this information and uses the standardized event and parameter names to populate relevant reports.

Events represent customer interactions

An ecommerce implementation normally follows the customer’s shopping journey.

A typical sequence looks like this:

The customer views a product category or product list.
The customer selects a product.
The customer views the product details.
The customer adds the product to the shopping cart.
The customer views or modifies the cart.
The customer begins checkout.
The customer provides shipping information.
The customer provides payment information.
The customer completes the purchase.
The store may subsequently record a refund.

Not every customer follows every step. Some customers leave before checkout, while others purchase directly after viewing a product.

GA4 events make these interactions measurable. They can be used to build funnels, analyse product performance, evaluate promotions, and investigate where customers abandon the shopping journey.

Recommended events are not automatically collected

Google defines recommended event names and their corresponding parameters. The website or its tracking implementation must still send these events when the relevant actions occur.

For example, GA4 does not automatically know that a customer successfully added a particular product to a custom shopping cart. The ecommerce platform must provide that information.

This distinction matters because an event called add_product is not equivalent to Google’s recommended add_to_cart event. The recommended event name and its expected parameters should be used when the interaction matches Google’s definition.

Google explains the ecommerce event model in its official Measure ecommerce documentation.

All events explained

Fourteen events describe ecommerce interactions. Three measure general website interactions, six describe the lead-generation lifecycle, and one is associated with Enhanced Measurement.

This classification is important. Not every event is an ecommerce event, even though all can contribute to a broader understanding of website activity.

Ecommerce recommended events

These 14 events describe product interactions, shopping cart activity, checkout progress, transactions, and promotions.

Event	GA4 event name	What it measures
View Item List	`view_item_list`	A customer is presented with a product list, category, or collection.
Select Item	`select_item`	A customer selects a product from a list.
View Item	`view_item`	A customer views an individual product detail page.
Add to Cart	`add_to_cart`	A product is successfully added to the shopping cart.
Remove from Cart	`remove_from_cart`	A product is removed from the shopping cart.
View Cart	`view_cart`	A customer views the current shopping cart.
Add to Wishlist	`add_to_wishlist`	A customer saves a product to a wishlist.
Begin Checkout	`begin_checkout`	A customer begins the checkout process.
Add Shipping Info	`add_shipping_info`	A customer submits or completes the relevant shipping-information step.
Add Payment Info	`add_payment_info`	A customer submits payment information during checkout.
Purchase	`purchase`	A transaction is successfully completed.
Refund	`refund`	A full or partial refund is issued or recorded.
View Promotion	`view_promotion`	A promotional element is presented to a customer.
Select Promotion	`select_promotion`	A customer selects or interacts with a promotion.

These events should reflect actual website interactions rather than simply being triggered when a page or button is loaded.

For example, add_to_cart should represent a successful cart update. A click on an Add to Cart button is insufficient when the operation fails because of unavailable stock, validation errors, or another problem.

Similarly, a purchase event should represent a completed transaction, not an unsuccessful attempt to submit an order.

General recommended events

There are three general GA4 recommended events.

Event	GA4 event name	What it measures
Login	`login`	A user successfully logs into an account.
Sign Up	`sign_up`	A user successfully creates an account.
Search	`search`	A user performs a search on the website.

These events are not ecommerce-specific, but they provide useful information about customer behaviour.

For example, account creation and login activity can help businesses understand how customers use account functionality. Search activity can reveal what visitors are looking for and whether the store’s catalogue matches their needs.

There is an important distinction between GA4’s recommended search event and the Enhanced Measurement view_search_results event.

Enhanced Measurement can automatically send view_search_results when GA4 detects a search results page through supported URL query parameters.

These events should not be treated as interchangeable. Their implementation should be reviewed together to avoid overlapping measurement and unnecessary duplicate tracking.

Lead-generation recommended events

The lead-generation events describe the progress of a potential customer through a sales pipeline.

Event	GA4 event name	What it measures
Generate Lead	`generate_lead`	A user submits information that creates a new lead.
Qualify Lead	`qualify_lead`	A lead is assessed and marked as meeting qualification criteria.
Disqualify Lead	`disqualify_lead`	A lead is formally marked as disqualified.
Working Lead	`working_lead`	A representative contacts or is contacted by the lead.
Close Convert Lead	`close_convert_lead`	A lead becomes a customer.
Close Unconvert Lead	`close_unconvert_lead`	A lead is formally marked as not becoming a customer.

These events are useful for businesses that manage leads through a sales process, particularly when the final conversion takes place outside the online store.

They must represent actual lead-status changes.

For example, disqualify_lead should not automatically be sent when someone abandons a shopping cart. An abandoned cart does not necessarily mean that a lead has been formally disqualified.

Likewise, close_unconvert_lead describes the outcome of a lead-generation process. It is not a general ecommerce order-cancellation event.

A completed online purchase should normally be measured through purchase. A lead becoming a customer through a separate sales process can be measured through close_convert_lead.

Google documents these events under recommended events for lead generation.

Enhanced Measurement event

Event	GA4 event name	What it measures
File Download	`file_download`	A user clicks a qualifying file-download link.

Unlike the other events, file_download belongs to GA4 Enhanced Measurement.

When the corresponding Enhanced Measurement setting is enabled for a web data stream, GA4 can automatically collect qualifying file-download interactions without requiring a separate event implementation.

Google detects supported file extensions, including PDF, Word, Excel, presentation, compressed, audio, and video files.

The implementation should account for the existing automatic collection configuration. Sending the same interaction manually when Enhanced Measurement is already collecting it can produce duplicate file_download events.

See Google’s Enhanced Measurement documentation.

Understanding GA4 Event Parameters

An event name identifies the interaction. Parameters describe the details associated with it.

GA4 ecommerce parameters are divided into two important scopes: event-level parameters and item-level parameters.

Event-level parameters

Event-level parameters describe the complete interaction or transaction.

For example, a purchase event can contain:

transaction_id
value
currency
tax
shipping
coupon

These values describe the transaction as a whole.

A purchase containing three different products has one transaction identifier and one event-level currency, even though the items array contains three separate product objects.

Item-level parameters

Item-level parameters describe individual products or services.

Examples include:

item_id
item_name
item_brand
item_category
item_variant
price
quantity
discount
coupon

These values belong inside the corresponding object in the items array.

This distinction is important when an order contains multiple products.

For example, a customer might purchase a blue shirt and a pair of shoes. Both products belong to the same purchase event, but each has its own product identifier, name, category, price, and quantity.

The event-level transaction values should not be confused with the individual item values.

The Ecommerce Items Array

The items array is the central structure used to describe products in GA4 ecommerce events.

It contains one object for each product or service associated with the interaction.

A basic example:

const product = {
    item_id: "SKU_12345",
    item_name: "Stan and Friends Tee",
    affiliation: "Google Merchandise Store",
    coupon: "SUMMER_FUN",
    discount: 2.22,
    index: 0,
    item_brand: "Google",
    item_category: "Apparel",
    item_list_id: "related_products",
    item_list_name: "Related Products",
    item_variant: "green",
    price: 10.01,
    quantity: 3
};

This example describes two units of the same product.

Google requires each item object to contain at least one of item_id or item_name. Providing both is recommended because they offer two ways to identify the product.

An ecommerce event can contain multiple item objects. Google’s ecommerce documentation currently allows up to 200 elements in the items array.

Common item parameters

The following parameters describe different aspects of a product.

Parameter	Purpose
`item_id`	Unique product or item identifier.
`item_name`	Product or item name.
`item_brand`	Brand associated with the product.
`item_category`	Primary product category.
`item_category2`	Second category level.
`item_category3`	Third category level.
`item_category4`	Fourth category level.
`item_category5`	Fifth category level.
`item_variant`	Product variation, such as colour, size, or configuration.
`price`	Monetary unit price of the item.
`quantity`	Number of units associated with the item.
`discount`	Monetary discount applied to one unit of the item.
`coupon`	Coupon code associated with the item.
`index`	Position of the item in a list.
`item_list_id`	Identifier of the product list.
`item_list_name`	Name of the product list.
`affiliation`	Store or affiliation associated with the item.
`location_id`	Physical location associated with the item, when relevant.

Use only parameters for which the website has reliable information. Do not invent product attributes to fill optional fields.

Product identifiers must remain consistent

An ecommerce implementation should use consistent product identifiers across the shopping journey.

For example, if a product is sent with item_id: "SKU-001" in a view_item event, the same identifier should be used when the customer adds it to the cart, begins checkout, and purchases it.

Inconsistent product identifiers can make product-level analysis less reliable because the same product may appear under multiple identifiers.

For variable products, decide whether the store uses a parent product identifier, a variation identifier, or both through separate appropriate fields. The implementation should follow a consistent product catalogue strategy.

Purchase and Refund Measurement

Purchase and refund events have a direct effect on ecommerce revenue measurement. They therefore require particular attention.

The purchase event

The purchase event records when a customer completes a transaction.

A typical purchase payload contains:

transaction_id
value
currency
tax
shipping
coupon
items

The transaction identifier must be unique for each order.

gtag("event", "purchase", {
    transaction_id: "T_12345",
    // Sum of (price * quantity) for all items.
    value: 72.05,
    tax: 3.60,
    shipping: 5.99,
    currency: "EUR",
    coupon: "SUMMER_SALE",
    customer_type: "new",
    items: [
        {
            item_id: "SKU_12345",
            item_name: "Stan and Friends Tee",
            affiliation: "Google Merchandise Store",
            coupon: "SUMMER_FUN",
            discount: 2.22,
            index: 0,
            item_brand: "Google",
            item_category: "Apparel",
            item_list_id: "related_products",
            item_list_name: "Related Products",
            item_variant: "green",
            price: 10.01,
            quantity: 3
        },
        {
            item_id: "SKU_12346",
            item_name: "Google Grey Women's Tee",
            affiliation: "Google Merchandise Store",
            coupon: "SUMMER_FUN",
            discount: 3.33,
            index: 1,
            item_brand: "Google",
            item_category: "Apparel",
            item_list_id: "related_products",
            item_list_name: "Related Products",
            item_variant: "gray",
            price: 21.01,
            promotion_id: "P_12345",
            promotion_name: "Summer Sale",
            quantity: 2
        }]
});

This is an illustrative payload. The website must provide the real order identifier and transaction data.

The value parameter should represent the sum of the item prices multiplied by their quantities. Shipping and tax are reported separately and should not be added to this item-value calculation.

When a value parameter is sent, currency must also be provided. Use a valid three-letter ISO 4217 currency code, such as EUR, USD, or GBP.

The event should be sent after the transaction has actually succeeded. A button click alone is not proof that an order has been accepted or processed.

Google’s purchase event implementation guide provides a practical starting point.

The refund event

The refund event records a refund associated with an existing transaction.

It should reference the original order through transaction_id.

Where item-level refund information is available, include the affected products and refunded quantities. This allows Analytics to produce more useful item-level refund information.

A partial refund must not be represented as a full refund. The event payload should reflect the actual refunded products or transaction data.

Order cancellation and refund are also different operations. An order can be cancelled before payment is captured, while a refund represents money returned or a refund transaction recorded.

The implementation should trigger refund only when the refund has actually been issued or recorded.

Google’s ecommerce documentation explains the refund event and its parameters.

Transaction ID deduplication

GA4 uses transaction_id to help prevent duplicate purchase events in web data streams.

If the same transaction is submitted repeatedly with the same identifier, Analytics can deduplicate the purchase.

However, this is not a replacement for correct event triggering.

The website should still prevent unnecessary repeated purchase events caused by:

Refreshing the order confirmation page.
Loading the same order confirmation more than once.
Multiple tracking scripts handling the same transaction.
Repeated JavaScript callbacks.
Both gtag.js and GTM sending the same purchase.

Transaction identifiers should be unique per order and must not contain personally identifiable information.

Google documents the behaviour and limitations in Minimize duplicate key events with transaction IDs.

Discounts and Coupons

GA4 provides separate parameters for recording discounts and coupon codes.

They represent different information and should not be confused.

The discount parameter

The discount parameter represents the monetary discount applied to one unit of a product. It does not represent a percentage.

Consider this example; a store sells socks for €6.00 per pair. A customer purchases three pairs and receives a €2.00 discount per pair.

The values sent to GA4 should be:

Parameter	Value
Original unit price	€6.00
Unit discount	€2.00
Reported price	€4.00
Reported discount	€2.00
Quantity	3
Item revenue	€12.00

The event’s item value is €12.00 (€4.00 × 3 pairs).

The discounted price must be calculated before sending the event. GA4 does not automatically subtract the discount parameter from price.

This distinction matters because sending the original price as price while also supplying discount would produce incorrect item revenue.

Coupon codes

A coupon can be recorded at two levels. An event-level coupon describes a coupon applied to the entire order. An item-level coupon describes a coupon associated with an individual product.

These parameters are independent. A store should send the coupon at the appropriate level based on how the promotion was actually applied.

For additional details, see Google’s Apply a discount to an ecommerce event.

Promotions and Product Lists

GA4 can measure how customers interact with product lists and promotional content.

These events provide information about product discovery and promotional engagement.

Product list measurement

Two important events are:

view_item_list, when a product list is presented.
select_item, when a customer selects an item from that list.

The event can include:

item_list_id
item_list_name
items
The selected item’s index

The same list identifiers should be used consistently so that product-list impressions and product selections can be analysed together.

Promotion measurement

Promotion tracking uses:

view_promotion
select_promotion

Relevant parameters include:

promotion_id
promotion_name
creative_name
creative_slot
items

For example, a store may present a summer promotion banner that links to a collection of products.

The view_promotion event records the promotion being presented. The select_promotion event records the customer’s interaction with it.

A promotion interaction should be tied to the actual promotional element. Do not send promotion identifiers that are unrelated to the content displayed.

Custom Item-Scoped Parameters

Standard GA4 item parameters cover common product attributes. Some businesses need additional information to describe their product catalogues.

Examples include:

Product material.
Subscription period.
Product condition.
Internal product group.
Manufacturer reference.
Business-specific product classification.

GA4 allows custom parameters inside the items array.

gtag("event", "view_item", {
    currency: "EUR",
    value: 30.03,
    items: [
        {
            item_id: "SKU_12345",
            item_name: "Stan and Friends Tee",
            item_material: "Stainless steel",
            item_condition: "New",
            affiliation: "Google Merchandise Store",
            coupon: "SUMMER_FUN",
            discount: 2.22,
            index: 0,
            item_brand: "Google",
            item_category: "Apparel",
            item_list_id: "related_products",
            item_list_name: "Related Products",
            item_variant: "green",
            price: 10.01,
            quantity: 3
        }
    ]
});

The custom fields in this example are illustrative business-specific parameters.

Sending a parameter is not the same as registering a dimension

Including a custom item parameter in an ecommerce event does not automatically make it available as a reporting dimension in the standard GA4 interface.

To analyse custom item parameters in reports, the relevant item-scoped custom dimension must be registered in Analytics.

Google currently documents:

Up to 27 custom parameters in the items array.
Up to 10 item-scoped custom dimensions for standard properties.
Up to 25 item-scoped custom dimensions for Analytics 360 properties.

These are separate limits. The ability to send a custom item parameter does not mean every parameter can be registered as a custom dimension.

See Create item-scoped custom parameters.

gtag.js vs Google Tag Manager

GA4 ecommerce measurement can be implemented through different methods.

The event model remains the same. The difference is how the website provides event data and how Google Analytics receives it.

gtag.js

gtag.js is Google’s JavaScript tagging library.

A website can send events directly through the gtag() function.

gtag("event", "add_to_cart", {
    currency: "EUR",
    value: 30.03,
    items: [
        {
            item_id: "SKU_12345",
            item_name: "Stan and Friends Tee",
            affiliation: "Google Merchandise Store",
            coupon: "SUMMER_FUN",
            discount: 2.22,
            index: 0,
            item_brand: "Google",
            item_category: "Apparel",
            item_list_id: "related_products",
            item_list_name: "Related Products",
            item_variant: "green",
            price: 10.01,
            quantity: 3
        }
    ]
});

The website’s own JavaScript implementation is responsible for supplying the correct event data and triggering the event at the appropriate moment.

This method is suitable when developers want to implement and control the tracking directly within the website.

Google Tag Manager

Google Tag Manager provides an interface for managing tags, triggers, and variables.

Instead of directly calling the GA4 event through website code, the website pushes event information into the data layer.

dataLayer.push({ ecommerce: null });  // Clear the previous ecommerce object.
dataLayer.push({
    event: "add_to_cart",
    ecommerce: {
        currency: "EUR",
        value: 30.03,
        items: [
            {
                item_id: "SKU_12345",
                item_name: "Stan and Friends Tee",
                coupon: "SUMMER_FUN",
                discount: 2.22,
                index: 0,
                item_brand: "Google",
                item_category: "Apparel",
                item_list_id: "related_products",
                item_list_name: "Related Products",
                item_variant: "green",
                price: 10.01,
                quantity: 3
            }
        ]
    }
});

Google Tag Manager reads the event and its data, evaluates the configured triggers, and sends the relevant parameters through a GA4 Event tag.

This separates the website’s event-data layer from the tag configuration.

Choosing between the two methods

Consideration	gtag.js	Google Tag Manager
Main implementation	Direct JavaScript calls	Data layer, triggers, tags, and variables
Event configuration	Website code	GTM interface
Data source	JavaScript event parameters	Data-layer objects and variables
Trigger handling	Website application logic	GTM triggers based on data-layer events
Configuration changes	Usually require code changes	Many tag changes can be managed in GTM
Technical control	Direct control through website code	Centralized tag management

Neither method automatically produces complete ecommerce tracking. The website must still provide accurate product, cart, checkout, and transaction data.

For implementation instructions, see the two dedicated guides:

GA4 Ecommerce Tracking with gtag.js.
GA4 Ecommerce Tracking with Google Tag Manager.

Data Quality, Duplicate Events and Privacy

The usefulness of ecommerce reports depends on the quality of the data being collected. A technically valid event can still contain incorrect information.

Common problems include:

Incorrect event names.
Missing product identifiers.
Inconsistent product identifiers across events.
Incorrect item quantities.
Sending percentages instead of monetary discount values.
Missing currency when sending monetary values.
Incorrect transaction totals.
Purchase events sent before an order is confirmed.
Refunds reported as cancellations.
Duplicate events sent by overlapping tracking implementations.

Avoid overlapping tracking implementations

A website should not install independent gtag.js and GTM implementations that send the same events to the same GA4 property without a deliberate architecture.

Google’s ecommerce validation documentation warns that using both can double-count events and cause unintended effects.

The same principle applies to automatic and manual tracking. For example, file_download may already be collected through Enhanced Measurement. Adding another implementation without checking the existing configuration can produce duplicate events.

Protect customer information

Ecommerce tracking should contain only information necessary for measurement.

Do not send:

Customer names.
Email addresses.
Telephone numbers.
Payment card numbers.
Passwords.
Other personally identifiable information.

An order identifier should be a transaction reference, not a customer identifier or personal contact detail.

Consent management and data collection should also follow the applicable privacy requirements.

Choosing the Right Implementation Method

A good implementation starts with understanding the data generated by the ecommerce platform.

Before configuring GA4, verify that the store can provide reliable information about:

Products and variations.
Product identifiers and categories.
Shopping cart contents.
Checkout progress.
Shipping and payment selections.
Completed transactions.
Refunds.
Discounts and promotions.

The choice between gtag.js and Google Tag Manager should then reflect the website’s architecture, development workflow, and tag-management requirements.

A direct gtag.js implementation can be appropriate when the tracking logic belongs inside the website application. GTM can be useful when tag configuration needs to be managed through a centralized interface.

Neither method removes the need for application-level event logic. Google Analytics cannot independently determine every successful cart update, order completion, refund, or lead-status change.

The ecommerce platform must provide accurate information at the correct point in the customer journey.

Conclusion

GA4 ecommerce tracking provides a standardized way to measure product interactions, checkout progress, purchases, refunds, and promotions. Its reporting capabilities depend on correctly structured events, consistent product information, accurate monetary values, and reliable transaction identifiers.

There are 24 events categories, keeping those categories distinct helps businesses understand which events describe ecommerce activity, which track general website interactions, and which belong to lead-generation or Enhanced Measurement.

The next step is implementing the measurement model through the appropriate tagging method.

Resources

Playful Sparkle has been engineering digital solutions since 2004. We work across Web Development, Application Development, SEO and Digital Marketing, and other areas of digital product development. Our work focuses on reliable implementations, clear technical architecture, and digital experiences that serve practical business requirements.

Key Takeaways

How GA4 Ecommerce Tracking Works

Events represent customer interactions

Recommended events are not automatically collected

All events explained

Ecommerce recommended events

General recommended events

Lead-generation recommended events

Enhanced Measurement event

Understanding GA4 Event Parameters

Event-level parameters

Item-level parameters

The Ecommerce Items Array

Common item parameters

Product identifiers must remain consistent

Purchase and Refund Measurement

The purchase event

The refund event

Transaction ID deduplication

Discounts and Coupons

The discount parameter

Coupon codes

Promotions and Product Lists

Product list measurement

Promotion measurement

Custom Item-Scoped Parameters

Sending a parameter is not the same as registering a dimension

gtag.js vs Google Tag Manager

gtag.js

Google Tag Manager

Choosing between the two methods

Data Quality, Duplicate Events and Privacy

Avoid overlapping tracking implementations

Protect customer information

Choosing the Right Implementation Method

Conclusion

Resources

Share your love

Zsolt Oroszlány

More Insights

Find Us On

Playful Sparkle SEO Audit

Address

Company

Work

Resources