window.BCData.product_attributes.instock returns true even if product with variants that has options is out of stock

[fthobe]

Expected behavior

If all variants are out of stock, the root product is unavailable when stock is tracked by variants.

Actual behavior

If all variants are out of stock, the root product is available even if stock is tracked by variants.

Steps to reproduce behavior

Go to https://www.ricomprostaging.it/iphone-7-nero-32-gb-usato-ricondizionato-rigenerato/ Open the console and type: window.BCData.product_attributes.instock If stock is tracked with variants result will be true even if variants are exhausted instead of replying with false. To validate against a product without variants use https://www.ricomprostaging.it/iphone-7-nero-32-gb-nuovo/ window.BCData.product_attributes.instock will give result true / false according to stock

IMPACT

This actually hits hard on multiple levels:

• any implementation of schema.org Availibility is broken, this includes Facebook catalogue google result pages other integrations using schema.org

[fthobe]

@bookernath Hey mate, the issue with cornerstone not returning stock correctly if all variants of a product are depleted and stock is tracked by sku variants was already fixed but seems to reappear due to a bug in BC. Can you give me some guidance if I assume correctly?

[fthobe]

@Tiggerito hey tony, this also impacts your favorite schema.org . In stock and out of stock for products with variants will not work.

[fthobe]

Hey, @bookernath , I know you hate this problem, but Google Shopping is throwing feed violations for products with variants and options on this. I understand that, due to complexity, it's not the most loved topic (probably due to complexity of the issue), but schema.org with options that consider stock is practically broken thanks to this issue as feed validation for google shopping and shopping retargeting fails on this kind of products.

[Tiggerito]

I've seen related issues. One client had merchant centre issues where the feed did not match the structured data we create. This is what I told them:

"We’re using Handlebars on the product page to get product details from the Stencil objects. If a variant is pre-selected for the product page we see some of the variant data in the object, like sku and price. But we don’t see variant values for mpn, weight etc. Not sure why this inconsistency?

I believe themes use graphql to make a second request that returns the full and correct variant data, which they then use to correct the pages content."

We can't use graphql to fix our structured data as services like the merchant centre don't officially run JavaScript when they crawl pages.

For this client it is causing issues with a few things:

https://support.bigcommerce.com/s/question/0D74O000006LfE0/detail

There was a ticket opened (# 04508356) but the response indicated they did not understand the problem, and therefore did not own it.

S&O often set up variant based feeds that go to the variant page (with the sku=). I've not checked, but I think they have the same issue.

[Tiggerito]

window.BCData.product_attributes.instock seems to be working for me. Unfortunately that's in JavaScript so I can't use it. instock is not available in the stencil object. I have access to product.can_purchase but that does not work when stock is at the variant level (always true).

[fthobe]

Actually, jscript for structured data works, jscript for structured data in google shopping doesn't.

window.BCData.product_attributes.instock seems to be working for me. Unfortunately that's in JavaScript so I can't use it. instock is not available in the stencil object. I have access to product.can_purchase but that does not work when stock is at the variant level (always true).

window.BCData.product_attributes.instock does not return correct value if the product has variants and options.

[fthobe]

@bookernath ?

[Tiggerito]

To be more precise. Google Search bot renders pages so can see SD built in JavaScript. I believe Bing also supports rendered SD. But most other consumers do not (Facebook, Pinterest etc.)

The Google Merchant Centre bot is documented to not render at this time. But they are merging things and it should eventually be using the standard bot and rendering. That's where my main problem is as the merchant centre punishes you if the feed does not match the pages content or the structured data on it.

[fthobe]

To be more precise. Google Search bot renders pages so can see SD built in JavaScript. I believe Bing also supports rendered SD. But most other consumers do not (Facebook, Pinterest etc.)

The Google Merchant Centre bot is documented to not render at this time. But they are merging things and it should eventually be using the standard bot and rendering. That's where my main problem is as the merchant centre punishes you if the feed does not match the pages content or the structured data on it.

Can you maybe reach out to them? It seems this problem is left unattended for more than 3 years now!

[Tiggerito]

Can you maybe reach out to them? It seems this problem is left unattended for more than 3 years now!

Which them? BigCommerce? I've not been very successful at getting any fixes made. Even when I get paying clients to submit tickets.

[bookernath]

Hey all,

Thanks for raising this to our attention. I'm having our engineering team take a look in our next engineering sprint, and I'll make a note to provide some kind of update at that stage.

[fthobe]

@bookernath Hey, thank you for your reply. Any idea on when that would be? There's a possible workaround using GraphQL and we would even pay for it to be implemented, but I would like to see it go inside Cornerstone. Given that Cornerstone does not use GraphQL (at all?), would that be something that we can contribute to the codebase or does it have to be fixed on your side.

[fthobe]

@bookernath Hi Nathan, any updates on this one?

[bookernath]

Hey all - this is still being worked on. Hope to have a further update for you on deployment timeline in the next few days. 👍

[Tiggerito]

I've found another issue related to this.

As mentioned, if an option is preselected then some of the properties sent to the product page are actually for the variant/option. like sku, price.

It is not possible to detect if the data is for a variant or the base product in the stencil objects.

Advertising systems typically use the skus, product id or variant id to identify items in their product feed. Tags are meant to use those same ids to track users behaviour. And the structured data on the page is used to confirm this information.

This mixed data means mixed signals are sent. The page is associated with the main product id, but it's sending the variants sku. If a feed uses product id or product sku then the price will be wrong. If a feed uses variant sku then other data will be wrong.

As mentioned, we can't get this data via JavaScript as the consumers do not render the pages. So we need the data available via stencil objects and handlebars.

A start would be to provide extra product data if the variant data is being provided in the main properties. e.g. the products sku and price. Apps like mine could then always provide correct product level data on the product pages.

Long term would be to provide data for the product and all variants. The Google Merchant Centre is already asking for that.

[fthobe]

@Tiggerito Hey, I'd really prefer to outline issues clearly. If you want I can create an issue about that for you!

[fthobe]

@bookernath Any news?

[bookernath]

Hello all - we've been slowly rolling out a fix for this over the last week or so. It should be on about 95% of stores by now. Products which have all child variants out of stock should be correctly reflected in metadata.

I'd love to hear from you @fthobe if you are seeing it fixed on your store.

[fthobe]

Hi @bookernath

Product-Options-v3 Works as expected

Product-Options-v2 Behaves as reported in bug issue. https://www.ricompro.it/test-item-oos/ has all variants out of stock but still reports as in stock. window.BCData.product_attributes.instock as well as metadata.

Please advise. Fabian

[bc-jz]

Hey @fthobe , I checked that product just now and its instock value came back as false. Are you seeing the same or did you change that product? Thank you for all of the feedback on this issue.

[bc-jz]

Hi @Tiggerito , I would like to get your input on what you think would help best to address this issue of mixed base product and variant data on a product page. Your most recent suggestion was asking to have access to some properties from the main product even when a variant is selected. I wonder if that will still be useful to you if there is consistency with the details that are provided.

So I have been looking at the context that is provided and saw the problems where id, mpn, gtin, dimensions (height, width, depth), and weight always come from the base product while sku, upc, and price can be from a selected variant. My initial thought for a fix would be making these values also get updated when a variant is selected by default, however I want to consider other options.

I don't think id should ever be that of the variant since all variants exist under the same product id and having that base id is valuable. I could see adding a variant_id and is_variant_selected properties, or similar, so that it becomes trivial to track when variant details are being presented.

Would you still want a way to access the base product sku and price all of the time if the above changes were made? Do you have any other fields on your radar regarding this topic? Thank you as well for all of your feedback here.

[Tiggerito]

For my scenario I'm interested in the base product for the id, sku and price (and price range). Maybe also a stock status for the product in general.

I like the idea of a is_variant_selected variable. That would help in making the required decisions

[bc-jz]

@Tiggerito Could you elaborate on your scenario? Are you submitting the base product of a product with variants into a product feed instead of the individual variants? Then when the feed crawls your page it is getting back variant details due to having pre-selected options on the product?

I was thinking the main issue was about the consistency of the data:

we don’t see variant values for mpn, weight etc. Not sure why this inconsistency?

It seems like in any case, the structured data we display should take into account whether a variant has been pre-selected. That way you can list individual variants to feeds and provide variant specific versions of product urls. Whether we also add some base details in these cases (beyond id which is there) is a great question and I'd like to know more about your take on this.

[Tiggerito]

We create structured data and implement tags to provide data for systems like Google Ads, Facebook, Pinterst etc.

You have a good point about the structured data needing to match the content of the page, which is the variant if selected. we'd still want to provide the products id to help these systems match things up. They typically call it the item_group_id, which can be the internal product id or the product level sku.

Things get complicated as all the different feed provides do things differently. Some list variants, some products, some use the sku for the id, some the internal id. A good example is your own Facebook connection. It uses the internal ids starting with 'V' or 'P' to say if it is a variant or product id. And then the product id is used for the item_group_id. That works well.

Our solution is designed to match up with the chosen feed, where possible. We just need the product level id and sku to do that.

With regard to this issue, all I need is a way to determine the product and defaulted variants id and sku. Any further data would be a bonus. It would be good to have access to both the product and variant values for things like mpn, gtin etc. That way I can ensure the structured data is telling the truth.

With our tagging we focus on sending the item_group_id (products id or sku). The tags inform the systems about which products have been viewed on lists and details pages. Then the store owner can dynamically remarket to people based on the products they saw. If the feed is variant based it can match up the product seen with all its variants. I think it's best to do this even if there is a default variant set.

Some feeds include the sku query parameter to link directly to a variant pages. The same product level information on those pages would also be helpful. Google has started to reject items if the structured data or content on the page does not match the feed values.

[bc-jz]

@Tiggerito Thank you for this info! Bottomline sounds like:

1) You need the data to be completely consistent on the page 2) You have use of being able to access some base product details even when a variant is selected

I am going to make a plan around these items but at the very least the 1st item is an absolute must. I too am disappointed at the lack of consistency here. I would like to deliver on the 2nd item as well but will need to explore that a bit more.

If you wouldn't mind clarifying for me the service that you are offering, I want to understand why information loaded after the initial page load is unavailable to you. When you state that you "create structured data and implement tags", does this mean you are editing the theme for a store to build out their structured data as needed? Basically going beyond the schema.org meta tag identifiers that are available by default on some themes?

I think it was also mentioned that some feed providers will not load javascript so that initial page load data is vital.

These reasons for not being able to rely on JS loaded data make sense to me but I just want to know if there are some other pieces to this. Thanks again for the feedback!

[Tiggerito]

1. I think the consistency would help many people. e.g. if its a default variant, then the core data should all be for the variant. No need for people to do API calls to correct the page.

2. I like what you previously suggested. A property to flag that it is a defaulted variant, and maybe another complex property that includes the base products data.

It may be handy to have a variant id, but I’m not sure how that works. S&O sometimes use some sort of variant id. It would be good if I could see the same id on the page as well. It could help the stitching of feed data with events and structured data.

We have an app that generates structured data, and soon a second app that adds tags for Google, Facebook, Pinterest, Bing and Twitter.

At the moment the structured data has to be directly included in the html. This is because the Google Merchant Centre and many other consumers do not currently render a page, so would not see dynamically generated structured data. I can include the main product id in that structured data as the item group id which is read by Google Merchant Centre and Facebook. If the page shows a default variant (or uses the sku query parameter) it would be ideal to have all the correct variant data at hand as well as the parents sku if available.

Our structured data is far more configurable and accurate than the basic stuff added to the themes. It is added via the script manager.

For the upcoming tag manager I need to fire events that use ids that match up with the feed system. In most cases this would be the base product id or sku. I’m not sure exactly how to deal with these variant pages yet, but if I have the products sku and variants id, I should have what I need.

It’s quite hard at the moment trying to juggle all these systems so that they all talk the same way. Once our tag manager app is approved we will be doing a lot more real world implementations and learning more about how the jigsaw puzzle can be put together.

Thanks for looking into this.