Proposal to add support for explicit identification of price categories such as sale price #2712
Comments
In those cases where the /priceCurrency has the same value for all UnitPriceSpecifications wouldn't it suffice to specify it directly for the /Offer? Seems a bit overkill to me having to specify the same value over and over again within a single /Offer. |
|
@jvandriel Agreed that should be an option, since I would typically expect all prices to be in the same currency. |
|
In the comments for the second example it's mentioned that
yet in the first example https://schema.org/ListPrice has been specified as value for /priceCategory. Aren't a /ListPrice and "default price" the same thing? And if so, shouldn't it be either one or the other (as in, you either specify /ListPrice OR you don't specify the /priceCategory property to set the standard price as opposed to both being an option)? |
|
@jvandriel Yes, they are the same thing, I wanted to give both examples to start a discussion (I guess I succeeded :) ) on the pros and cons of absence of a /priceCategory implying that the price is the standard (or list) price, or always requiring the explicit specification of /priceCategory if there are multiple prices. |
|
Well if it's up for discussion... ;) Although I like the the idea of using /ListPrice (mostly for debugging purposes during development), personally I feel it'd be best if we try to prevent having to specify it for every single /Offer. More or less the same way as was done by having http://purl.org/goodrelations/v1#Sell be the default value for /businessFunction (discussed in 2348 and #2357). For example, I'd hate to have to write/publish the following: |
|
@jvandriel Agreed that having a default value is the best option for the reason you indicated, it does not make much sense having to specify it when there is only one price. |
|
After observing the usage and description of the existing /priceType property it appears it has the same role as the earlier proposed priceCategory, i.e., representing complete price specifications. We should therefore consider (instead of the original proposal) including /priceType also on /CompoundPriceSpecification and adding a new /PriceTypeEnumeration enumeration (instead of the earlier proposed /PriceCategoryEnumeration). The examples would then look as follows (building on the same changes proposed in #2869 as well): Example 1Example 2 |
|
+1 I am fine with this |
|
Google recently added Merchant listings results to their Rich Results Test tool, and it appears to be throwing an incorrect error: Invalid value in field "priceSpecification" For the following markup (from https://wpsso.com/extend/plugins/wpsso/), which seems to be related to the new priceType property.
"priceSpecification": {
"@context": "https://schema.org",
"@type": "UnitPriceSpecification",
"price": "69.00",
"priceCurrency": "USD",
"priceType": "https://schema.org/ListPrice",
"eligibleQuantity": {
"@context": "https://schema.org",
"@type": "QuantitativeValue",
"value": "1",
"minValue": "1",
"maxValue": "1",
"unitText": "WordPress Site Address URL Licenses"
}
},
The Schema validator and the Google search validator are both fine with this markup - is this a bug in the Google Merchant listings validator? js. |
|
HI JS, since this is a Google-specific question (and not about Schema.org in general) it might be best to ask this on the Google Search forum (https://support.google.com/websearch/thread/new) |
|
Google seems to only accept this ("itemtype" attribute instead of "content") when using metatags: |
|
Estimados, me disculpan por molestar pero he tratado de solucionar un problema con mucha gente y aun no tengo una respuesta confiable de como se debe solucionar, resulta que en nuestro sitio tenemos 2 precios, un precio de lista y otro precio de oferta, y no se si la forma en que se han estructurado los datos es la correcta, será que me pueden ayudar. Por ejemplo, tenemos este producto https://www.beststore.cl/perfumes/68083-perfume-benetton-cold-edt-100ml.html En schema, el precio normal, lo tenemos de esta forma y el precio oferta esta de esta forma
Tengo la sensación de que esto no esta bien hecho, será que me pueden ayudar, por favor. |
|
First off, could you next time please ask your question in English? Because I had to translate your message I am not quite sure what you mean with "precio de oferta". So I guessed you meant 'Sale price'. If not, have a look at: https://schema.org/PriceTypeEnumeration for an overview of the available enumerations. As for the markup, you are probably looking to express something like this: |
|
I apologize for the language, indeed "Precio de Oferta" is SalePrice, continuing with my example, should the salePrice be the cheapest or not? Therefore, it should be like this "offers": { |
|
Generally speaking a |
|
We have done it, but Google sends us the following error in its structured data
|
|
Your markup is not yet how Google wants it. This should work though: |
|
Jharno, thank you very much, but google shows us the following.
|
|
That's because you still left a |
|
Jarno, I wanted to thank you for the help you provided, after a long time, we managed to solve the problem, thank you very much. |
|
Jarno, I'm back, can you help me resolve a question, do you know how I should structure the data to be able to have the price called "before" that I show in the following image?
|
|
Estimados, tengan todos muy buenas tardes, les escribo pues desde esa tema me ayudaron hace algunos meses y ahora tengo otro problema y no se a quien recurrir, resulta que desde parte de mi equipo me dicen que tenemos cerca de 10000 errores en los datos estructurados de unos productos, les dejo un print
Pero no se como poder solucionarlo, al revisar schema veo la advertencia de este producto (
Me gustaría saber como poder solucionar esto, si alguno de ustedes sabe me sería de mucha ayuda |
|
Hi everyone, |
|
Adding another point to this: What about Price/Offer combinations. I thought about using includesObject as part of the offer for the free product I'd appreciate your reply and thoughts :) |
|
Bundles are supported in schema.org since 2012 - the basic pattern is Offer -> includesObject -> TypeAndQuantityNode There could be more examples (PRs always welcome), but the principle has been stable for a decade. The Hotels documentation has an example, see e.g. https://schema.org/docs/hotels.html#meals. If an offer has multiple price components, see CompoundPriceSpecification. If an offer has an initial set of items included (i.e., the price is for the initially included item or items), and you can extend it by adding items or a bundle of items (i.e., you cannot buy these without accepting the base offer), then use addOn. Some more references: |
|
Suggest extending definition of price to add range "priceFrom" priceTo" ? |
|
need suggestion on where to put the discount details under the 'Offer' ? |
|
We added for a product a markup using the different priceTypes: "@type": "Offer", And the merchant listing is not validating anymore due to the use of multiple priceSpecifications: 
Could you please help me solve this? Thanks so much in advance. |
The Google Merchant validator made a change around January 10-11th that requires the "price" and "priceCurrency" properties, even though a "priceSpecification" is included. I would suggest adding the current price (ie. the list price) in the "price" property, keeping your "priceSpecification" array as-is, and checking to see if that works - in my experience, it should. js. |
|
That worked, thank you @jsmoriss 👍 "offers": { |
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 the different prices related to an offer.
Introduction
Many products advertised and sold on the web have different categories of prices, for example:
Currently, schema.org does not provide a structured way of differentiating the categories of prices associated with an offer. The closest option is the /priceType property, but this field is intended to identify different price components, for example cleaning fee, service fee, downpayment, monthly installment payment, recycling fee, airport surcharge, etc. Several price components are combined together to make up a single price category.
See also issues #829 and more recently #2689 for a discussion on Compound pricing.
Proposal
We believe allowing an explicit and structured way of expressing the category of a /priceSpecification would benefit the ecosystem.
This design builds on the approach explored in #2689 which introduced an enumeration (e.g. /PriceTypeEnumeration) for the existing /priceType property. Alongside this we propose another enumeration (e.g., _/PriceCategoryEnumeration) _for different categories of prices, and a property /priceCategory to reference these. Example 2 below shows both of these dimensions being used in a single scenario.
New property /priceCategory would then be added to types /UnitPriceSpecification and /CompoundPriceSpecification to allow specification of a price category for singular prices as well as compound prices.
Example 1
The following example illustrates how to specify three different price categories (MSRP, list price, and sale price) for an offer using the proposed new enumeration
Note that the sale price specification in this example has an explicit date range to indicate when the sale price is valid. Also note the absence of properties /price and /priceCurrency at the offer level.
Example 2
The following example, building on the example given in issue #2689, illustrates a combination of price categories and price types.
This example builds on the example in #2689 by adding a second compound sale price. The difference in this example between the default price (which comes without the /priceCategory property) and the sale price are the downpayment and installment price components. The subscription price component is unchanged.
Note that this example has modified the example in #2689 by moving the down payment under /CompoundPriceSpecification.
Consideration
Different price categories can be used under different circumstances, for example a product sold on the web could have a different sales price than a product advertised on the web. We could consider adding yet another pricing dimension to model how the price should be used, but this seems overkill and can instead be modeled by adding more enumeration values to the proposed /PriceCategoryEnumeration type.
The text was updated successfully, but these errors were encountered: