Schema.org for Variable Products with ProductModels, Offers

Tips

Creating schema markup for a single product is straightforward and well documented. For modeling multiple product variants for the same, the recommendations are less clear. There are several ways to create schema markup for complex products. You can either 1) Ignore mostly everything that’s different 2) Include the unique Pricing information or 3) Include different aspects of the variants. Below I will describe three common options for modeling Product Variations so that you can maximize the machine understanding of your complex products.

What is a Product Variant?

Let’s first start by defining Product Variants. Below is what WooCommerce and Shopify, two popular eCommerce software say about Product Variants. I would add that Variants are identified as having their own Store Keeping Units (SKUs) which are unique to the Product group and liberally used for eCommerce and Supply Chain information systems.

WooCommerce Variable Products are a product type in WooCommerce that lets you offer a set of variations on a product, with control over prices, stock, image and more for each variation. They can be used for a product like a shirt, where you can offer a large, medium and small and in different colors.

Shopify Product Variants: You can add variants to a product that comes with more than one option, such as color or size. Each combination of options for a product that you sell is a variant of that product. For example, you might sell a t-shirt with two options, such as size and color. The size option might have three option values: small, medium, or large. The color option might have two option values: blue or green. A variant of these options could be a small, blue t-shirt.

1, Simplify and Aggregate Product Offers

For situations where you might want not have all the data readily available or want to start off with something simple (you can always add more details later), you can simplify the product models. This approach would see you publish all the general aspects of your Product, the properties that are the same all variants and make a general statement of the Offers using AggregateOffer. If you’re selling shoes, then each size or color of the shoe would be a different model, they may all have the same price, so then whats often done is to create a single Product and Offer without differencing anything.

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "Clarks Falalala Shoes for Men",
  "image": "https://example.net/shoes/clarks-falalala.jpeg",
  "description": "A great comfortable walking shoe, carried in sizes 9-11, but you wouldn’t really know that unless you applied fancy NLP to this string",
  "offers": {
    "@type": "Offer",
    "price": 45.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  }
}

If you’re selling something that varies in price, for instance, Soap that comes in 250ml 500ml and 1000ml bottles, then you can calculate the lowest price and highest price and output an AggregateOffer such as:

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "Super Suds",
  "image": "https://example.net/soap/super-suds.jpeg",
  "offers": {
    "@type": "AggregateOffer",
    "lowPrice": 5.99,
    "highPrice": 17.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  }
}

2, Each Variant as a Schema.org/Offer

While option 1 is nice, it doesn’t tell the machine-channel anything about the variation of products you carry. Nor does it provide the granularity of Stock information by individual SKU. The next level of detail would be to include each variant’s price and availability as a separate Offer. Each Offer needs (AdWords and Schema App recommended) a SKU to differentiate it from other variants, along with its price and availability. For the examples before, we might generate:

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "Clarks Falalala Shoes for Men",
  "image": "https://example.net/shoes/clarks-falalala.jpeg",
  "description": "A great comfortable walking shoe, carried in sizes 9-11, but now size 11 isn’t in stock",
  "offers": [ {
    "@type": "Offer",
    "sku": "QWERTYSHOE-9",
    "price": 45.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  },{
    "@type": "Offer",
    "sku": "QWERTYSHOE-10",
    "price": 45.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  },{
    "@type": "Offer",
    "sku": "QWERTYSHOE-11",
    "price": 45.99,
    "priceCurrency": "EUR",
    "availability": "OutOfStock"
  } ]
}

The Soap Suds example shows varying Offer properties price, sku and name;

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "Super Suds",
  "image": "https://example.net/soap/super-suds.jpeg",
  "offers": [{
    "@type": "Offer",
    "sku": "egsoapsuds-250",
    "name": "Soap Suds 250 ml",
    "price": 5.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  },{
    "@type": "Offer",
    "sku": "egsoapsuds-500",
    "name": "Soap Suds 500 ml",
    "price": 10.99,
    "priceCurrency": "EUR",
    "availability": "OutOfStock"
  },{
    "@type": "Offer",
    "sku": "egsoapsuds-1000",
    "name": "Soap Suds 1000 ml",
    "price": 17.99,
    "priceCurrency": "EUR",
    "availability": "InStock"
  }]
}

3, Each Variant as a schema.org/ProductModel

Option 2 works well in case of products that don’t have significant varying critical properties. Otherwise, we want to adopt a more formal ProductModel approach. The gist of these is that you define a schema.org/Product as the base Product and common properties for all variants are properties of this Product “parent”. Then, for variations of the Product, ProductModels only define their differentiating characteristics from the parent Product definition. If all iPhones come 64 GB of memory, 2 colors but the iPhone 8+ has 128 GB available in White only, then you would pick out the base characteristics and model out the variations:

{
  "@context": "http://schema.org/",
  "@type": "Product",
  "name": "iPhone 8",
  "description": "A great device, loads of memory, 1 million different apps preloaded, outstanding camera, works on LTE and even makes phone calls!",
  "image": "https://example.net/phones/apple-iphone8-jpeg",
  "offers": {
    "@type": "AggregateOffer",
    "lowPrice": 599.00,
    "highPrice": 899.00,
    "priceCurrency": "USD",
    "availability": "InStock"
  },
  "additionalProperty": {
    "@type": "PropertyValue",
    "name": "Memory",
    "unitCode": "E34", 
    "unitText": "GB",
    "value": "64"
  },
  "model": [ {
    "@type": "ProductModel",
    "name": "iPhone 8 with 64GB",
    "color": "White",
    "offers": {
      "@type": "Offer",
      "price": 599.00,
      "name": "White iPhone 8",
      "availability": "InStock"
    }
  },{
    "@type": "ProductModel",
    "name": "iPhone 8 with 64GB",
    "color": "Red",
    "offers": {
      "@type": "Offer",
      "price": 649.00,
      "name": "red usually costs slightly more because it's faster",
      "availability": "InStock"
    }
  },{
    "@type": "ProductModel",
    "name": "iPhone 8+ with 128GB",
    "color": "White",
    "offers": {
      "@type": "Offer",
      "price": 899.00,
      "name": "White iPhone 8+",
      "availability": "InStock"
    },
    "additionalProperty": {
      "@type": "PropertyValue",
      "name": "Memory",
      "unitCode": "E34",
      "unitText": "GB",
      "value": "128"
    }
  }]
}

ProductModel Examples in the Wild

If you’d like to see more ProductModel examples in the wild, you can use PublicWWW to search for the schema class: e.g. https://publicwww.com/websites/http%3A%2F%2Fschema.org%2FProductModel/

unitCode Lookup Values

If you’re wondering where does the unitCode “E34” come from, then you’ll want lookup UN/CEFACT Common Codes for specifying the unit of measurement. Here are some common codes for various units of measurement. A spreadsheet is available to download http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_Rev9e_2014.xls

UN/CEFACT Common Code Unit of Measurement
28 kg/m²
2N dB
4H µm
4K mA
4P N/m
A24 cd/m²
A86 GHz
A94 g/mol
B22 kA
B32 kg • m2
B43 kJ/(kg.K)
B49 kΩ
B61 lm/W
BAR bar
C16 mm/s
C24 mPa.s
C26 ms
C45 nm
C62 1
C65 Pa.s
C91 1/K
C94 min-1
CDL cd
CEL °C
CMQ cm³
CMT cm
D33 T
D52 W/K
D74 kg/mol
DAY d
DD °
E01 N/cm²
E32 l/h
FAR F
GM g/m²
GRM g
HTZ Hz
HUR h
KEL K
KGM kg
KGS kg/s
KHZ kHz
KL kg/m
KMQ kg/m³
KVT kV
KWT kW
L2 l/min
LTR l
LUM lm
LUX lx
MBR mbar
MHZ MHz
MIN min
MMK mm²
MMQ mm³
MMT mm
MPA MPa
MQH m3/h
MQS m³/s
MTK
MTQ
MTR m
MTS m/s
NEW N
NU N • m
NU N.m
OHM
P1  %
PAL Pa
SEC s
VLT V
WTT W

 

, , , , ,
Previous Post
Schema Markup News Nov 7th, 2017
Next Post
Schema Markup News Nov 14th, 2017

Menu