-
Notifications
You must be signed in to change notification settings - Fork 851
Proposal to add support for explicit identification of price types such as installments and subscriptions #2689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Unsure if this is necessary, but it may be helpful to include a way of indicating that a particular Installment or Subscription price is only valid for a certain time frame before changing into another price, e.g. '$9.95 for the first 12 months, then $15.99'. |
@earthrefresh That is a good suggestion since that is pretty common scenario. To make this explicit we need a way to sequence /priceComponents of the same type, for example through a /sequenceNumber, or, maybe more flexible, a /billingStart property under /UnitPriceSpecification. The latter would specify when the periodic payments for a /priceComponent would start. |
ping @mfhepp |
After observing the usage and description of the existing /priceType property it appears to be intended for complete price specifications. We should therefore consider introducing a new /priceComponentType property with corresponding enumeration /PriceComponentTypeEnumeration to represent the types of pricing components. This would be instead of the original idea, which proposed building on the existing /priceType property to model pricing components. The example given earlier would then change as follows:
This example has 3 other changes compared to the original example:
|
* First cut adding support for price components * Fix syntax error * Fix typo
Per #2735 how to specify a period of time? The |
Would this suffice for what you're trying to accomplish @jaygray0919 ?
|
I've merged the PR but didn't yet update release notes. @alex-jansen and @mfhepp are still talking about it this week. Summary of currently commited changes (and links to drafts): "Add support for explicit identification of pricing categories (e.g. of line items in an invoice) such as installments and subscriptions."
|
Consider Now consider It seems to us that we need the Am I missing a key point in the preceding dialog? |
@jaygray0919 Taking the example from @jvandriel a bit further, one could have 2 UnitPriceSpecifications under 1 CompoundPriceSpecification, where the first has a discounted price of 180 for the first year and then a price of 249.99 that starts after the first year and runs for 1 or more years. This would make use of the existing billingIncrement, unitCode, and eligibleQuantity properties together with the billingStart property, which specifies that the 2nd payment starts after the first year. This leads to the following snippet:
For example markup in the field that does something similar, see: |
@alex-jansen But what if the |
@jaygray0919 Agree there must be a way to specify the duration of such periodic payments. Our idea was to use the /eligibleQuantity property for that purpose, so for example a monthly billing of 15 Euro for a duration of 12 months could be expressed as follows.
After rereading the description of /eligibleQuantity ("The interval and unit of measurement of ordering quantities for which the offer or price specification is valid...") it could be interpreted as being intended for quantities ordered and not so much for time durations (@mfhepp for more insight). An alternative option would be introducing another property /billingDuration of type /Number, which would lead to the following example:
This means the total price of 180 Euro per year would be paid in increments of 1 month for a duration of 12 months. Taking this one step further where the price increases to 249.99/year after the first 12 months for a minimum period of, say, 18 additional months:
The minimum 18 months period requirement means we would require /QuantitativeValue as a type for /billingDuration. Would an additional property /billingDuration be better than using the existing /eligibleQuantity ? |
How would you feel if |
I don't see a problem adding Duration as an alternative type so happy to submit a pull request for that. How would you express a minimum duration, for example a cell phone wireless contract or an apartment lease for a minimum of 12 months and then extended month-to-month? |
I'll take that as a challenge and work on a response soon. Our current design has a product identifier for each period. For example, product acquisition for |
Added in release 11.0 |
Can't be correct because unitCode is 'MON'. I am sorry but that example confused me. IMHO: 15/month leads to 180 after 12 month. Everthing else is inconsistent.
I agree with you if we would specify:
@alex-jansen, Pls confirm or clarify that. |
Ok |
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:
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:
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
The text was updated successfully, but these errors were encountered: