Purchase event sends parent product ID instead of variation ID for variable products (GlobalSiteTag.php line 402)

[hardik18882]

Plugin version: 3.5.3
WooCommerce version: 10.5.3
WordPress version: 6.9.1

---

Describe the bug

In GlobalSiteTag.php, the maybe_display_conversion_and_purchase_event_snippets() method builds the purchase event's item list using $item->get_product_id() (line 402). For variable products, this method always returns the parent product ID, never the variation ID.

Since the Google Merchant Center product feed indexes items by variation ID, 100% of purchased item IDs in the purchase event are unmatched in Merchant Center. This breaks basket data reporting in Google Ads entirely.

---

Evidence from Google Ads Diagnostics

Google Ads → Conversions → Goals → Purchase → Diagnostics reports the following:

⚠️ Needs attention
Basket data is being recorded but there are issues that require your attention.

Under the expanded warning:

Many recent conversions have sold item IDs that can't be matched to Merchant Center
Many recent conversions have sold item IDs that can't be matched to products in Merchant Center. This could be because the item IDs are incorrect or because these products haven't been added to Merchant Center.

Conversion action	Action optimisation	Conversion source	Unmatched sold products	Last updated
Google for WooCommerce purchase action	Primary	Website	100.00%	9 Mar 2026

Downloading the unmatched item IDs confirms they are all parent product IDs (e.g. gla_1234), while the Merchant Center feed correctly lists products by variation IDs (e.g. gla_9876).

---

Root cause — GlobalSiteTag.php lines 401–414

foreach ( $order->get_items() as $item_id => $item ) {
    $product_id   = $item->get_product_id(); // ← Always returns parent ID
    $product_name = $item->get_name();
    $quantity     = $item->get_quantity();
    $price        = $order->get_item_total( $item );
    $item_info [] = sprintf(
        '{
        id: "gla_%s",   // ← Sends parent ID e.g. "gla_1234" instead of variation ID "gla_9876"
        ...
        }',
        esc_js( $product_id ),

get_product_id() always returns the parent product ID. For variable products, it never returns the variation ID.

---

Proposed fix — one-liner change on line 402

// Before (buggy):
$product_id = $item->get_product_id();

// After (fixed):
$product_id = $item->get_variation_id() ?: $item->get_product_id();

WC_Order_Item_Product::get_variation_id() returns 0 for simple products, so the ?: $item->get_product_id() fallback ensures simple products continue to work correctly.

---

Secondary bug — same issue in display_page_view_event_snippet() line 508

The cart page tracking has the same problem:

// Buggy — cart page item tracking:
$id = $cart_item['product_id']; // ← Always parent ID

// Fixed:
$id = ! empty( $cart_item['variation_id'] ) ? $cart_item['variation_id'] : $cart_item['product_id'];

---

Steps to reproduce

1. Create a variable product in WooCommerce with at least one variation (e.g. Size: Single, Double, King)
2. Add a specific variation to cart and complete a purchase
3. Open browser DevTools on the thank-you / order confirmation page
4. In the Console run: dataLayer.filter(e => e.event === 'purchase')
5. Inspect items[].id in the purchase event

Expected: id: "gla_9876" ← variation ID, matches Merchant Center feed
Actual: id: "gla_1234" ← parent ID, does not exist in Merchant Center feed

---

Impact

• Google Ads Diagnostics shows 100% unmatched sold products for all stores selling variable products
• Basket data tracking is completely broken for the majority of WooCommerce stores, as variable products are the standard pattern
• Google Ads Smart Bidding cannot optimise on product-level conversion value
• ROAS and product performance reporting is inaccurate

---

Additional context

This is a one-line fix per affected method. The get_variation_id() method is already available on WC_Order_Item_Product and returns 0 safely for non-variable products, making the fix fully backward compatible.

[hardik18882]

👋 Friendly Reminder & Urgency Update

Hi team, bumping this issue as it has been open for some time and wanted to share some additional context on the business impact this is causing.

---

📊 Impact Summary

This bug is not a minor tracking discrepancy — it is causing complete basket data failure for any WooCommerce store using variable products, which is the majority of WooCommerce stores.

The real-world consequences for affected stores:

• 🔴 100% unmatched sold products in Google Ads basket data diagnostics
• 🔴 Smart Bidding is flying blind — Google cannot optimise campaigns on product-level conversion value
• 🔴 ROAS reporting is inaccurate — revenue is tracked but product attribution is completely broken
• 🔴 Merchant Center diagnostics permanently showing "Needs Attention" — eroding trust in the integration
• 🔴 Ad spend is being wasted — without correct basket data, Google's bidding algorithms cannot make informed decisions

---

🔍 Root Cause (Already Identified)

As detailed in the original report, the fix is a single line change in GlobalSiteTag.php line 402:

// Current (broken):
$product_id = $item->get_product_id();

// Fixed:
$product_id = $item->get_variation_id() ?: $item->get_product_id();

And a matching fix on line 508 for cart page tracking:

// Current (broken):
$id = $cart_item['product_id'];

// Fixed:
$id = ! empty( $cart_item['variation_id'] ) 
    ? $cart_item['variation_id'] 
    : $cart_item['product_id'];

This is fully backward compatible — get_variation_id() safely returns 0 for simple products, so the fallback to get_product_id() ensures nothing breaks for non-variable products.

---

⏱️ Why This Needs Urgent Attention

Every day this remains unpatched:

• Stores are losing Google Ads optimisation value they are paying for
• Merchants trust that this official plugin is correctly reporting to Google — it is silently not doing so
• Affected stores are implementing manual workarounds just to get basic purchase tracking working correctly

This plugin is the official, recommended integration between WooCommerce and Google. Stores reasonably expect that purchase events fire with correct product IDs out of the box.

---

🙏 Request

Could the team please:

1. Confirm this is acknowledged and on the roadmap
2. Share an estimated timeline for a patch release
3. Consider a hotfix release given the severity — this does not need to wait for a major release cycle

Thank you for your work on this plugin. We appreciate the team's efforts and just want to make sure this gets the visibility it deserves given the impact on live stores and active ad spend. 🙏

[hardik18882]

Hi @joemcgill ,

Thanks all of you for the quick response and for raising PR #3292 so promptly.

I've reviewed PR #3292 and the proposed fix looks correct — using $item->get_variation_id() ?: $item->get_product_id() on line 402 and the matching fix on line 508 is exactly what's needed.

I can also see the test report from @ankitguptaindia confirms the fix is working correctly in testing.

Given the severity of this issue — 100% unmatched sold products means basket data tracking is completely broken for every WooCommerce store using variable products, which is the majority of WooCommerce stores — could we please request that this fix is prioritised for an expedited patch release rather than waiting for the next scheduled release cycle? Every day this remains unpatched, affected stores are losing Google Ads optimisation value and wasting ad spend on misconfigured Smart Bidding.

The fix is a single line change per method and the test report confirms it is working correctly — it seems well-placed for a fast-tracked hotfix release.

Thank you to the whole team for the incredibly fast turnaround on this so far, it is very much appreciated! 🙏

Regards,

[joemcgill]

Hi @hardik18882! Thanks for your attention with this issue and for the really helpful detail you provided in your report. Given that the existing behavior had been in place for quite some time, we were waiting to confirm the intended behavior with our partners at Google before committing this change. Now that we've confirmed, this has been merged and will be included in the upcoming release.

[hardik18882]

Hi @joemcgill , thank you so much for the update and for the kind words!

Completely understand the need to confirm the intended behaviour with Google first before committing the change — glad it's now confirmed and merged.

We really appreciate the team's fast turnaround on this. Looking forward to the upcoming release. We'll keep an eye out for it! 🙏