Here’s a question your GA4 cannot answer for most WooCommerce stores: which section of your homepage is actually generating sales? Not which section gets the most clicks — which one converts browsers into buyers. If you’ve looked at the item list reports in GA4 and found a column full of (not set), you’ve discovered the answer. GA4 doesn’t know. It was never told.
70% of ecommerce stores have broken or incomplete tracking configurations (Conversios, 2025). Missing product discovery events — specifically view_item_list and select_item — is among the most common failures, and the most commercially costly one that generates no errors whatsoever.
The Five-Event Hierarchy GA4 Expects
GA4’s ecommerce schema is built around a product journey with five stages. Most WooCommerce stores implement three of them.
The full hierarchy is: view_item_list → select_item → view_item → add_to_cart → purchase. Standard WooCommerce tracking plugins fire the last three. The first two — the discovery layer — are almost universally absent.
view_item_list fires when products appear in a list context: a category page, a homepage featured section, a search results grid, a related products widget. It records which list the customer saw, which products were in it, and which position each product occupied.
select_item fires when a customer clicks a product from that list — the moment of choosing. It carries the list name and position through to the product detail page, maintaining the discovery context that explains why this customer clicked this product.
Without both events, GA4’s item list dimension is permanently empty. GA4’s item_list_name shows (not set) for 100% of purchase events when view_item_list and select_item are not implemented — GA4 has no mechanism to infer list origin from the purchase event alone (Google Analytics Developer Documentation, 2025). It cannot look backwards. If the context was not captured at the list stage, it is gone.
You may be interested in: Your WooCommerce items Array Is Sending Google Product Data It Cannot Use
What (not set) Actually Costs You
The item list dimension answers questions that drive real product placement decisions.
Your store has a homepage with sections — a hero banner, a featured products block, a bestsellers carousel, a new arrivals row. You chose which products go where. You probably made that decision based on instinct, seasonal timing, or supplier margin. Not based on which placement converts best — because GA4 cannot tell you.
Your category pages have a sort order. The products at the top get seen more. Some convert the visitors who see them. Others do not. Without view_item_list position data, you cannot measure revenue per impression by product position — you cannot know whether moving a product from position 8 to position 2 would double its sales contribution or change nothing.
73% of GA4 implementations have silent misconfigurations causing 30-40% data loss (SR Analytics, 2025). Missing view_item_list is silent in the worst possible way — no error, no warning, no red flag in the GA4 interface. The item list reports show (not set) and most store owners assume that is normal. It is not normal. It is a structural gap in product discovery analytics.
Most WooCommerce stores use fewer than 5 of GA4’s 50 available custom dimensions (Growthopedia, 2025). Product discovery context — item_list_name, item_list_id, and item position index — is consistently among the least implemented, and the most commercially relevant to fix.
Why Browser-Side Tracking Cannot Fix This
The obvious response is to implement view_item_list via your tracking plugin or GTM. For some stores, that partially works. For most WooCommerce stores, it runs into a structural problem: list context is lost across page navigations.
Here is what happens in a typical WooCommerce session. A customer visits your category page. Your tracking script fires view_item_list with item_list_name: "Women's Jackets". The customer clicks a product. A new page loads — the product detail page. Your tracking script fires view_item. But the page that just loaded has no access to the dataLayer from the previous page. The list context — which list this customer came from, which position they clicked — is gone from the browser’s memory unless you explicitly passed it through the URL or stored it in a cookie before navigation.
When the customer eventually purchases, the purchase event fires with whatever items array your checkout page has available. That array contains product IDs, quantities, and prices. It does not contain item_list_name — because that data lived on a page that no longer exists in the browser context.
You may be interested in: GA4 Content Groups Show Not Set for WooCommerce Products
The Session-Level Fix
The solution is to capture list context at the server level, where it persists across page navigations without browser dependency.
When a customer views a category page, WooCommerce knows exactly which archive is being rendered — the category name, the query, the sort order. When a customer clicks a product from that category, WooCommerce processes the request server-side. The referrer, the session, the category context — all accessible before the product page begins to render.
Server-side session enrichment captures the last-known list context and stores it against the session identifier. When the add_to_cart event fires, the list context is appended. When the purchase event fires, every item in the order carries its discovery origin: which list it came from and which position it occupied. The item_list_name dimension in GA4 shows real values instead of (not set).
GA4 allows item position index tracking via the index parameter in view_item_list (Google Analytics Developer Documentation, 2025). With server-side enrichment carrying that index through to the purchase event, you can measure revenue per position — turning category page ordering from instinct into a measurable decision.
Transmute Engine™ is a first-party Node.js server running on your own subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce category and archive context server-side, maintains list attribution in the session layer, and routes fully enriched view_item_list, select_item, and purchase events to GA4 Measurement Protocol — carrying item_list_name and item position through the complete journey from first impression to completed order.
Key Takeaways
- GA4 has a five-event ecommerce hierarchy — most WooCommerce stores implement only the last three, leaving the discovery layer (view_item_list, select_item) entirely dark
- item_list_name shows (not set) for every purchase when view_item_list is missing — GA4 cannot infer which category or list a product came from after the fact
- Without discovery data, product placement is guesswork — you cannot measure which homepage section, category position, or product list drives the highest revenue per impression
- Browser-side tracking loses list context across page navigations — the category page dataLayer does not persist to the product page or checkout without deliberate engineering
- Server-side session enrichment captures and carries list context through the complete journey, populating item_list_name and item position on every purchase event
GA4 can only populate item_list_name if the view_item_list event fires with a list name before any product is clicked. Most WooCommerce tracking setups implement view_item, add_to_cart, and purchase — but not view_item_list or select_item. Without those two events, GA4 has no discovery context to associate with any downstream purchase. The (not set) value cannot be fixed retroactively — it requires implementing the missing events going forward.
You need the view_item_list event firing on every category page, archive page, and product list with item_list_name set to the category or list name. The select_item event must fire on product clicks, carrying the same list name. That context must then be preserved through to the purchase event — via session storage, URL parameters, or server-side session enrichment. Once implemented, GA4’s item list report shows revenue broken down by list name, revealing which category pages are driving purchases.
No. GA4 Enhanced Measurement does not automatically fire view_item_list events. Standard WooCommerce GA4 plugins typically implement view_item, add_to_cart, and purchase — but not the discovery events. view_item_list and select_item require explicit implementation, either through custom dataLayer code, GTM triggers, or a server-side tracking layer that captures category and archive context directly from WooCommerce.
Yes. Performance Max uses product-level engagement signals to decide which products to feature in Shopping ads. view_item_list events provide product impression context — how often each product appears in list views and whether those views lead to clicks and purchases. Without this discovery layer, PMax receives a weaker signal set dominated by add_to_cart and purchase events alone, losing the upstream engagement data that helps it identify high-potential products earlier in the funnel.
Your category pages are generating revenue every day. GA4 can see the sales — but without view_item_list, it cannot see the journey that produced them. Seresa captures that discovery layer server-side, so your item list reports show what is actually driving your store’s performance.