Troubleshooting

Viewing the Error Logs

The plugin outputs errors into the regular WooCommerce log directory. It is accessible by clicking on the View Logs link in the plugin's settings window and choosing the most recent log with the slug sgadwc. It will show all errors that it encountered. If you don't find a log with the slug sgadwc it means that no errors have been encountered.

The website still shows cached prices, even if a valid discount has been successfully received

It is likely your caching rules are too aggressive.

Make sure to exclude caching if the URL query parameter pv2 is present in the URL.

Example: https://example.com/socks/?pv2=1234

You also must ensure that caching is disabled as soon as a WooCommerce session is active. (Typically a WooCommerce session is created when a visitor adds a product to the cart.)

Make sure that the cache is disabled if at least one of the following server-side WooCommerce cookies has been set:

• woocommerce_cart_hash
• woocommerce_items_in_cart
• wp_woocommerce_session_ (This cookie always attaches a session ID at the end. Make sure that the match is not set to exact but will match any cookie which contains that cookie string.)

Caching

In general 99% of all incompatibilities are caused by caching.

There are two conditions that need to be met for Automated Discounts to work correctly:

• When the URL query parameter pv2 is present in the URL, caching must be disabled.

• WooCommerce sessions must be properly handled by the caching system. Neither page cache, nor server object cache, or any other caching layer should cache pages when a WooCommerce session is active.

Known Incompatibilities

We have come across an install that uses Object Cache Pro (by Rhubarb Group), FlyingPress (by FlyingWeb) and the Astra Pro theme (by Brainstorm Force). Any one of these plugins or themes, or a combination of them, causes Automated Discounts to not work correctly because parts of the output get cached, including Ajax requests.

While FlyingPress may be configured to exclude caching, the other two plugins don't offer a way to exclude caching for specific URLs or WooCommerce sessions.

How to Configure Kinsta Cache

Some Kinsta hosted sites need a specific cache setup to ensure Google Automated Discounts work reliably. Kinsta’s default caching rules do not fully cover the requirements, especially when sessions start or when tracking parameters are involved. This guide explains what Kinsta support must configure and what you, as the site owner, should double check.

Required Cache Exclusions

Ask Kinsta support to add the following Nginx rules to ensure discounts display correctly for all eligible visitors:

if ($http_cookie ~* "s|_sce|sgadwc_session_active") {
  set $skip_cache 1;
}

if ($query_string ~ "^pv2=") {
  set $skip_cache 1;
}

Why these rules matter

• sgadwc_session_active cookie
  This cookie signals that a Google Automated Discounts session is active. If it is present, the visitor must bypass all caching layers.
• pv2 URL parameter
  This parameter is important on the first visit and triggers the Automated Discounts logic. Kinsta normally bypasses caching when a URL contains parameters, but we have confirmed that this does not work reliably on Kinsta when UTM parameters are present. Some stores accidentally upload product URLs with UTM tags to Google Merchant Center, which leads to URLs like: ?utm_source=xxx&pv2=... In these cases, Kinsta cache may still activate unless this explicit rule exists. Adding the pv2 rule is therefore a required safety net.

Clear All Kinsta Cache After Setup

Once Kinsta adds the exclusions, they must clear all cache layers completely:

• Edge cache
• Server cache
• CDN cache
• Any additional Kinsta layer

If the cache is not fully cleared, old cached versions can override the new rules and cause inconsistent behavior.

Important for Store Owners

Remove UTM parameters from Google Merchant Center feeds

• UTM parameters in Shopping product URLs can interfere with the pv2 cache exclusion on Kinsta.
• They are also unnecessary. When Google Ads and Google Merchant Center are linked, Google automatically handles all tracking.
• Recommendation: Remove all UTM parameters from your feed URLs.

Summary

• Make sure Kinsta support adds the two explicit exclusions above.
• Removing UTM parameters in your Shopping feed improves reliability and prevents Kinsta from ignoring your pv2 exclusion.
• With both steps in place, Google Automated Discounts will work smoothly on Kinsta hosted sites.

A Variable Product Shows No Price at All

Google may reject your account with this message:

Discounted price doesn't show on your product page. Your online shop must read discounted prices from Google-generated JSON web tokens and show those discounted prices on your product pages.

If your simple products pass the test but your variable products fail, the cause is usually the product setup rather than the discount. On a variable product WooCommerce only prints a price once a single variation has been resolved. Until then the page shows a price range, or nothing at all. No discount can be displayed on a page that displays no price in the first place.

Symptoms

• Simple products show the discounted price correctly, variable products do not.
• Opening the product page shows a price range, or an empty price area, both with and without the pv2 parameter.
• One or more of the attribute dropdowns (for example Colour or Size) is empty or is missing the option the tested variation uses.
• The plugin's Testing tab flags the variation with a Not selectable on the front end note.

The Cause

A variation dropdown only lists a value when both of the following are true:

1. The value is assigned to the parent product under Product data → Attributes.
2. At least one variation actually uses that value.

The two lists can drift apart. A variation can keep pointing at a colour that was later removed from the parent product's attribute, for example after a feed import, a bulk edit, or an attribute cleanup. The variation still exists, still carries its own price, and is still submitted to Google, but the shopper can never select it, because the dropdown never offers that colour. The page therefore resolves no variation and prints no price, and Google reports that as a missing discounted price.

A second, milder case: if a variation leaves an attribute set to Any, the link cannot preselect a value for it. The shopper still has to choose before a price appears, so a crawler that only loads the URL sees a price range.

How to Fix It

1. Open the product in WordPress and go to Product data → Attributes.
2. Add every value that your variations use, for example the missing colours, and tick Used for variations.
3. Save, then open the Variations tab and make sure each variation has a concrete value for every attribute rather than Any.
4. Reload the product page and pick the combination from the failing test link. A single price must now appear.
5. Go to the plugin's Testing tab, click Reset testing links, and run the tests again.

tip

The plugin picks testing links automatically and prefers variations that a shopper can actually select. When it cannot find enough of them, it still lists what it has and flags each affected row with the reason, so you can see the product data problem before you start debugging the discount.

Product ID Mismatch Issues

If discounts are not being applied when customers click on Google Shopping ads, the cause might be a product ID mismatch between what Google sends and what WooCommerce expects.

Symptoms

• Discounts are not being applied when customers click on Google Shopping ads
• Error logs show "Product ID is not correct" messages
• The browser console shows mismatched expected vs. received product IDs

How to Diagnose

1. Check the WooCommerce logs for errors (WooCommerce → Status → Logs → select logs with the sgadwc slug)
2. Click on a Google Shopping ad link (or a testing link) for one of your products
3. Open your browser's developer console (F12 → Console tab)
4. Look for log messages showing the payload product ID, for example:

   Automated Discounts (1.6.10) Debugger: Product ID is not correct. Expected: 510759 Received: 8722_B16866310

Common Causes

Your Google Merchant Center feed plugin may be using a custom product ID format that includes:

• A custom prefix (e.g., customfeed_, myshop_, feed_)
• Your SKU instead of the WooCommerce Post ID
• A combination of prefix + SKU (e.g., shopify_ABC123)

Built-in Support

The plugin automatically handles these common formats:

• woocommerce_gpf_123 → 123 (WooCommerce Product Feed Pro)
• gla_123 → 123 (Google Listings & Ads)
• Direct SKU matching (if the ID doesn't match, the plugin checks against the product SKU)

Solution for Custom Formats

If your feed plugin uses a different format, use the sgadwc_sanitize_payload_product_id filter to transform the product ID. Add this code to your theme's functions.php or a custom plugin:

add_filter( 'sgadwc_sanitize_payload_product_id', function( $payload_id, $current_id ) {
    // Replace 'yourprefix_' with your actual prefix
    if ( preg_match( '/^yourprefix_(.+)$/', $payload_id, $matches ) ) {
        $sku = $matches[1];
        // Look up product by SKU and return the Post ID
        $product_id = wc_get_product_id_by_sku( $sku );
        if ( $product_id ) {
            return $product_id;
        }
    }
    return $payload_id;
}, 10, 2 );

For more details and examples, see the Developers documentation.

Need Help?

Contact support with:

1. The error message from your debug console
2. The product ID format your feed plugin uses
3. Your feed plugin name