Context - This is a proposal from Google based on our experience consuming schema.org Offer markup and working with similar data from online merchants. If it were accepted, it would make it easier for us and others to understand flexible pricing models, for example an offer whose price consists of several separate price components.

Introduction

Many wireless devices, such a mobile phones, tablet computers, and smart watches advertised and sold on the web often have several price components, for example:

• a one-time upfront payment ("down payment"), e.g. 215 GBP
• monthly installment payments to pay the remaining balance for the device, e.g., 12 months at 38.65 GBP/month
• a contract for a wireless subscription plan (for phone and data service), e.g., a minimum duration of 24 months at 15 GBP/month.

Currently, Schema.Org does not provide a structured way of identifying the different price components of an offer, the closest option is the /priceType property part of the /UnitPriceSpecification type, which is free-form Text.

We believe allowing an explicit and structured way of expressing the type of a price component would benefit the ecosystem.

Proposal

Our proposal is to add a new enumeration, for example /PriceTypeEnumeration, with values such as "Installment" and "Subscription". We would allow the new enumeration as an alternative type on property /priceType.

Example

The example offer given in the introduction could be expressed through the following schema when using the proposed /PriceTypeEnumeration:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "sku": "GZDU23L/B",
  "image": "https://www.example.com/phone_5_32_slvr.jpg",
  "name": "Phone 5" 32GB Silver",
  "description": "New phone 5" screen in silver with 32GB + contract",
  "gtin14": "00821793049157",
  "mpn": "G-2PW4100-021-B",
  "brand": {
    "@type": "Thing",
    "name": "PhoneBrand"
  },
  "color": "Silver",
  "offers": {
    "@type": "Offer",
    "url": "http://www.example.com/GZDU23LB",
    "itemCondition": "https://schema.org/NewCondition",
    "availability": "https://schema.org/InStock",
    "price" : 215,
    "priceCurrency": "GBP",
    "priceSpecification": {
      "@type": "CompoundPriceSpecification",
      "priceComponent": [
        {
          "@type": "UnitPriceSpecification",
          "priceType": "https://schema.org/Installment",
          "price": 38.65,
          "billingIncrement": 1,
          "unitCode": "MON",
          "eligibleQuantity": {
            "@type": "QuantitativeValue",
            "value": 12,
            "unitCode": "MON"
          }
        },
        {
          "@type": "UnitPriceSpecification",
          "priceType": "https://schema.org/Subscription",
          "price": 15,
          "billingIncrement": 1,
          "unitCode": "MON",
          "eligibleQuantity": {
            "@type": "QuantitativeValue",
            "minValue": 24,
            "unitCode": "MON"
          }
        }
      ]
    }
  }
}

In this example, the /price property on /Offer is used to provide the up-front price that the consumer has to pay. The additional monthly installment and subscription payments are provided using 2 separate /priceComponent properties grouped using /CompoundPriceSpecification. See also #829 for a discussion on compound pricing.

Some considerations

• We explored the use of /RepaymentSpecification to model installment payments. However, /RepaymentSpecification models only installment payments, which seems too narrow in scope since many other types of pricing exist as well, including the aforementioned subscription payments, but also activation fees, cleaning fees, early-termination fees, optional warranties, and damage insurance (covering other domains than wireless devices as well).
• Instead of modeling the up-front payment under the /price property of /Offer it might seem more consistent to add it as an additional /priceComponent under /CompoundPriceSpecification. However absence of /price on /Offer might confuse existing systems consuming structured Offer data while relying on the presence of the /price property. A potential solution could be one where the total minimum lifetime price (215 + 12x38.65 + 24x15 = 1038.80 GBP) is provided in Offer.price while providing the up-front payment under CompoundPriceSpecification but that appears redundant.