If you could only fix one thing in your WooCommerce tracking to know more about what to sell, fix this: make sure every purchase event captures the full product variant — not just the parent SKU, but the specific size, colour, material, or bundle that was actually bought. Roughly 60% of WooCommerce stores don’t. And the 60% that don’t are blind at exactly the level where inventory decisions are made.

This isn’t a grand data-strategy question. It’s a single configuration fix with an outsized payoff: once variant data is reliably captured on every purchase, you can ask your data which variants are selling, which are sitting, and which parent products have one hot variant hiding five cold ones. Without that fix, every stocking decision is a guess dressed up as analysis.

Why Variant-Level Data Is the One Thing That Matters for Stocking#

Inventory decisions don’t happen at the parent-product level. Nobody orders “more of the jacket.” They order more medium black, fewer small navy, replace the grey entirely with charcoal. The decision lives at the variant — size, colour, material, bundle — and every layer of analytics above that layer is too coarse to be useful.

Variant-level purchase data is roughly 3x more useful than parent-product data for restocking decisions. The parent aggregate hides everything a buyer actually needs to know. A parent product that looks like a solid performer at $40,000 in quarterly revenue can turn out to be 80% driven by one variant that’s about to go out of stock and 20% spread across seven variants that should be discontinued.

What “Capturing the Variant” Actually Means#

Every purchase event in GA4 (and by extension, your BigQuery events table if you’re exporting) contains a nested items array. Each entry in that array represents one line item. The GA4 ecommerce schema supports item_id, item_variant, item_category, and price at the line-item level — that’s the correct granularity.

“Capturing the variant” means making sure:

• item_id is the variation SKU, not the parent product SKU (critical distinction on variable products)
• item_variant contains the variant attributes — size, colour, material — in a consistent format
• item_category is populated so you can group variants across parent products
• quantity and price reflect the actual line, not a rolled-up product total

When all four fields arrive correctly on every purchase event, the resulting BigQuery table is queryable at the resolution inventory actually lives at. When any one of them is null or rolled up to the parent, you’ve imported a blurriness into the data that no downstream analysis can undo.

What You Can Actually Ask Your Data Once the Fix Is in Place#

Connect Claude or ChatGPT Analytics to a BigQuery dataset with clean variant data and the kinds of questions you can ask change categorically:

• Which variants across all my parent products are selling fastest relative to stock on hand?
• Which variants haven’t sold in 90 days despite full inventory?
• For each parent product, what’s the ratio between my bestselling and worst-selling variant?
• Which sizes are undersupplied in my catalogue based on purchase distribution?
• Which colour combinations repeat in my top ten products, suggesting broader demand patterns?

Each of these questions becomes answerable in seconds rather than never. None of them are answerable without variant-level data — no matter how clever the AI model or how expensive the analytics tool.

Product demand signals hide in event data the same way repeat-purchase signals and search-term gaps do — you can only read them if they were captured correctly at the time the transaction happened.

How to Check If Your Store Has the Fix#

The check takes about five minutes. Open GA4 (or your BigQuery events table) and pull up any recent purchase event. Expand the items array. For every line item, look for four fields: item_id, item_variant, item_category, price.

• If all four are populated on every line item — you have the fix.
• If item_variant is null or missing — you’re capturing parent-level data only.
• If item_id matches the parent product SKU instead of the variation SKU — same problem.
• If the items array has one entry for the whole order instead of one per line item — the tracking layer is rolling up, and granular analysis is impossible.

If you’re not sure which you’re looking at, ask Claude to run the check directly against your BigQuery dataset. Prompt: “For the last 30 days of purchase events in my BigQuery events table, what percentage of rows in the items array have a non-null item_variant, and what percentage have item_id matching a parent product rather than a variation SKU?”

Why Most Stores Miss This (And How to Actually Fix It)#

Default WooCommerce setups — including the tracking emitted by many popular GTM configurations and GA4 plugins — often send the parent product SKU to analytics instead of the variation SKU when a variable product is purchased. The variation data exists in WooCommerce itself. It just doesn’t always make it to the tracking layer.

The fix is usually configuration, not custom code. But the fix has a compounding cost: every purchase event captured without variant data today is a data point that cannot be re-collected later. Fixing it in three months means you’ve lost three months of variant-level history. Fixing it next year means a year of blindness. The sooner it’s fixed, the sooner the data compounds.

You may be interested in: The Questions You Should Be Asking Your WooCommerce Data Every Week

Here’s How You Actually Do This#

The fix also has to survive the browser. Browser-side-only WooCommerce tracking typically loses 30-50% of events to ad blockers, Safari ITP, and consent rejection — which means even a perfectly-configured GA4 integration delivers variant data for only half the purchases. The other half are invisible regardless of how good the taxonomy is.

Transmute Engine™ is a dedicated Node.js server that runs first-party on your subdomain (for example, data.yourstore.com). The inPIPE WordPress plugin reads WooCommerce purchase events directly from the order hooks — including the full variant metadata WooCommerce already stores — and streams them via API to your Transmute Engine server, which routes them into GA4, Meta CAPI, BigQuery, and Google Ads with variant-level granularity intact. Because the server sits on your own subdomain and the events come from order hooks rather than browser-side JavaScript, the data that browser-only setups are losing stays captured.

Once that pipeline is running, the one-fix-one-outcome relationship actually holds: variant data arrives cleanly, the BigQuery table fills up, and a store owner sitting in front of Claude can genuinely ask what to stock next — and get an answer based on the data rather than on instinct.

Key Takeaways#

• The single most impactful tracking fix for most WooCommerce stores is capturing the full product variant on every purchase event — size, colour, material, bundle — not just the parent SKU.
• Roughly 60% of WooCommerce stores don’t capture variant data. They’re making inventory decisions with tools that are blind at exactly the level inventory actually lives at.
• Variant-level purchase data is approximately 3x more useful than parent-product data for stocking and restocking decisions. The parent aggregate hides everything a buyer actually needs to know.
• Check the fix in five minutes: find a recent purchase event, expand the items array, verify item_id, item_variant, item_category, and price are populated on every line.
• Every correctly-captured purchase event is permanent data. Every one captured incorrectly today is a data point that cannot be re-collected later — the cost of waiting is measured in history you can never buy back.

Frequently Asked Questions#

One fix. Variant data on every purchase event. From there, the data tells you what to stock. See how first-party WooCommerce tracking captures variant data by default at seresa.io.