No Attribute Mapping for Condition

Hi @biohazardousx ,

Could you share a screenshot of how you are configuring the rule? Have you considered using the category options available, as in one category for new products, one for refurbished and other for used. Do review these screenshots for an example.

If the image does not load, please click this link: – https://share.cleanshot.com/B2x7C6k4

If the image does not load, please click this link: – https://share.cleanshot.com/qp6xyhrV

We look forward to hearing back from you as soon as possible.

Why not just let it be configured by a custom attribute like other attribute rules? This is a very convoluted way to get around the fact that this wasn’t accounted for when setting up the “Condition” attribute. It also assumes products don’t have options to be Used, Refurbished, or New within the same product, which they sometimes do have all of those options. The only true solution is to actually let us map a custom attribute rather than force us to apply pointless categories to products as a band-aid type solution. I’ll note in my email of the reply to my inquiry, you originally assumed there should have been the ability to map Condition to a custom attribute. Which means you agree with the logic behind what I’m requesting as it was your default view of how it should be working when replying originally.

So back to the point, let’s fix the actual problem and make it work just like some of the other attributes where we’re allowed to map to an existing product attribute rather than setting a default.

@biohazardousx , I’d like to differ here on what is the true solution. The Condition field is a custom field in WooCommerce, unlike any standardised ones like size attribute or Age attribute. While Google considers only 3 states for condition of the product, there are quite a few plugins that add this custom field and offer various state of the product Eg,. Adding one of the options from the fields customized by various plugins will not be ideal and will generate sync errors.

The above solution is a better way at mapping this filed, while not generating any sync errors regardless of whether customers use a custom field, or a custom plugin etc.

Also it’s worthy to “Note: Refurbished and Used products aren’t currently displayed on Demand Gen ads on the Discover surface as clarified in the linked Google Doc.

That said, feel free to make a feature request here for developers to consider this feature in a future release.

If somebody doesn’t configure their attributes correctly, that’s something they would just have to fix. The plugin could even check to make sure they’re valid, as you point out, it’s only 3 options. So how difficult is it programmatically to map New to some type of “new” attribute in the system and translate the correctly over to Google? Not very. So for example, if Google is caps sensitive and it needs to be “New”, but the system’s attribute is “new”, the plugin could easily map to “new” and send “New” to Google.

You could also have a little tutorial/help hint to illustrate that the attributes “Condition” is mapped to is exactly only “New”, “Used”, or “Refurbished”.

Your system neglects the scenario I previously described where a single product has the options of New, Used, or Refurbished within a single product. It is NOT to a site’s advantage with SEO to have 3 separate products to cover the same product with just different condition types, as only one is likely to show up for SEO purposes, and if the person looking for the product was shopping for “New”, but only ended up on a page for “Used”, then that’s a lost sale potentially for the business.

I’m not sure what you mean by standardized fields, as neither Size nor Age are standard. We work with baby clothes as well, and the size ranges and age ranges are all over the place with different vendors, and yet we can merrily map to those without issue. If anything, it’s the opposite, in that Condition is standardized as it ONLY has 3 options with no room for interpretation or variation.

Back to my point, it wasn’t setup correctly when it was developed. It shouldn’t need a feature request to fix something that wasn’t designed to properly allow for all scenarios with product conditions and only a convoluted workaround that is neither ideal nor complete as it merely adds more unnecessary complexity to the category structures; which on a large WooCommerce site can slow things down quite a bit with queries for things that didn’t need to exist.

Hey there @biohazardousx ,

Back to my point, it wasn’t setup correctly when it was developed. It shouldn’t need a feature request to fix something that wasn’t designed to properly allow for all scenarios with product conditions and only a convoluted workaround that is neither ideal nor complete as it merely adds more unnecessary complexity to the category structures; which on a large WooCommerce site can slow things down quite a bit with queries for things that didn’t need to exist.

I understand that you have some suggestions for the developers to consider for the extension. If you feel that it’s more of a bug that the devs should be aware of and fix rather than a feature request, you can submit the issue as a bug as well. Either way, your input would be more than welcome, so feel free to share it here.

Link for reference: https://github.com/woocommerce/google-listings-and-ads/issues/new/choose

The wonderful thing about submitting a request on GitHub is that you’ll be actively contributing to the open-source community with your ideas, and others who have the same concern can bump up the issue and make it more likely to be seen and resolved by the developers!

Meanwhile, I would like to clarify that the solution I shared above works for users who are willing to map the condition attribute with categories, which is the current recommendation.