Google's proposal for a new shopping related structured data sparks a lively discussion

Google Proposes New Shipping Structured Data

Google published a proposal in the Schema.org Project GitHub instance that proposes proposing an update at Schema.org to expand the shopping structured data so that merchants can provide more shipping information that will likely show up in Google Search and other systems.

Shipping Schema.org Structured Data

The proposed new structured data Type can be used by merchants to provide more shipping details. It also suggests adding the flexibility of using a sitewide shipping structured data that can then be nested with the Organization structured data, thereby avoiding having to repeat the same information thousands of times across a website.

The initial proposal states:

“This is a proposal from Google to support a richer representation of shipping details (such as delivery cost and speed) and make this kind of data explicit. If adopted by schema.org and publishers, we consider it likely that search experiences and other consuming systems could be improved by making use of such markup.

This change introduces a new type, ShippingService, that groups shipping constraints (delivery locations, time, weight and size limits and shipping rate). Redundant fields from ShippingRateSettings are therefore been deprecated in this proposal.

As a consequence, the following changes are also proposed:

some fields in OfferShippingDetails have moved to ShippingService;
ShippingRateSettings has more ways to specify the shipping rate, proportional to the order price or shipping weight;
linking from the Offer should now be done with standard Semantic Web URI linking.”

The proposal is open for discussion and many stakeholders are offering opinions on how the updated and new structured data would work.

For example, one person involved in the discussion asked how a sitewide structured data type placed in the Organization level could be superseded by individual products had different information and someone else provided an answer.

A participant in the GitHub discussion named Tiggerito posted:

“I re-read the document and what you said makes sense. The Organization is a place where shared ShippingConditions can be stored. But the ShippingDetails is always at the ProductGroup or Product level.

This is how I currently deal with Shipping Details:

In the back end the owner can define a global set of shipping details. Each contains the fields Google currently support, like location and times, but not specifics about dimensions. Each entry also has conditions for what product the entry can apply to. This can include a price range and a weight range.

When I’m generating the structured data for a page I include the entries where the product matches the conditions.

This change looks like it will let me change from filtering out the conditions on the server, to including them in the Structured Data on the product page.

Then the consumers of the data can calculate which ShippingConditions are a match and therefore what rates are available when ordering a specific number of the product. Currently, you can only provide prices for shipping one.

The split also means it’s easier to provide product specific information as well as shared shipping information without the need for repetition.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *