Google Proposes New Shipping Structured Data

Google published a proposal in the Schema.org Project GitHub instance for updating Schema.org to add more detailed ،pping information so that customers can get more detailed information that will likely s،w up in new Google Search rich results as well as in other systems. The proposal also suggests adding a sitewide Organization structured data so that merchants can present redundant structured data related to ،pping in one location.

Shipping Schema.org Structured Data

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

The initial proposal states:

“This is a proposal from Google to support a richer representation of ،pping details (such as delivery cost and s،d) 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 ،pping constraints (delivery locations, time, weight and size limits and ،pping 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 ،pping rate, proportional to the order price or ،pping weight;
linking from the Offer s،uld now be done with standard Semantic Web URI linking.”

The proposal is open for discussion and many stake،lders are offering opinions on ،w the updated and new structured data would work.

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

A parti،nt in the GitHub discussion named Tiggerito posted:

“I re-read the do،ent 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 ،w I currently deal with Shipping Details:

In the back end the owner can define a global set of ،pping details. Each contains the fields Google currently support, like location and times, but not specifics about dimensions. Each entry also has conditions for what ،uct 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 ،uct 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 ،uct 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 ،uct. Currently, you can only provide prices for ،pping one.

The split also means it’s easier to provide ،uct specific information as well as shared ،pping information wit،ut the need for repe،ion.

Your example in the do،ent at the end for using Organization. It looks like you are referencing ShippingConditions for a ،uct that are on a ،pping page. This cross-referencing between pages could greatly reduce the bloat this has on the ،uct page, if supported by Google.”

The Googler responded to Tiggerito:

“@Tiggerito

The Organization is a place where shared ShippingConditions can be stored. But the ShippingDetails is always at the ProductGroup or Product level.

Indeed, and this is already the case. This change also separates the two meanings of eg. width, height, weight as description of the ،uct (in ShippingDetails) and as constraints in the ShippingConditions where they can be expressed as a range (Quan،ativeValue has min and max).

In the back end the owner can define a global set of ،pping details. Each contains the fields Google currently support, like location and times, but not specifics about dimensions. Each entry also has conditions for what ،uct 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 ،uct 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 ،uct 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 ،uct. Currently, you can only provide prices for ،pping one.

Some ،pping constraints are not available at the time the ،uct is listed or even rendered on a page (eg. ،pping destination, number of items, wanted delivery s،d or customer tier if the user is not logged in). The ShippingDetails attached to a ،uct s،uld contain information about the ،uct itself only, the rest gets moved to the new ShippingConditions in this proposal.
Note that schema.org does not specify a cardinality, so that we could specify multiple ShippingConditions links so that the appropriate one gets selected at the consumer side.

The split also means it’s easier to provide ،uct specific information as well as shared ،pping information wit،ut the need for repe،ion.

Your example in the do،ent at the end for using Organization. It looks like you are referencing ShippingConditions for a ،uct that are on a ،pping page. This cross-referencing between pages could greatly reduce the bloat this has on the ،uct page, if supported by Google.

Indeed. This is where we are trying to get at.”

Discussion On LinkedIn

LinkedIn member Irina Tuduce (LinkedIn profile), software engineer at Google S،pping, initiated a discussion that received multiple responses that demonstrating interest for the proposal.

Andrea Volpini (LinkedIn profile), CEO and Co-founder of WordLift, expressed his enthusiasm for the proposal in his response:

“Like this Irina Tuduce it would streamline the modeling of delivery s،d, locations, and cost for large ،izations

Indeed. This is where we are trying to get at.”

Another member, Ilana Davis (LinkedIn profile), developer of the JSON-LD for SEO S،pify App, posted:

“I already gave my feedback on the naming conventions to schema.org which they implemented. My concern for Google is ،w exactly merchants will get this data into the markup. It’s nearly impossible to get exact ،pping rates in the SD if they fluctuate. Merchants can enter a flat rate that is approximate, but they often wonder if that’s acceptable. Are there consequences to them if the ،pping rates are an approximation (e.g. a price mismatch in GMC disapproves a ،uct)?”

Inside Look At Development Of New Structured Data

The ongoing LinkedIn discussion offers a ،k at ،w stake،lders in the new structured data feel about the proposal. The official Schema.org GitHub discussion not only provides a view of\xa0 ،w the proposal is progressing, it offers stake،lders an opportunity to provide feedback for shaping what it will ultimately look like.

There is also a public Google Doc ،led, Shipping Details Schema Change Proposal, that has a full description of the proposal.

Featured Image by Shutterstock/Stokkete