schemaorg: priceRange property is ambiguous
Hello
The property schema.org/priceRange is ambiguous because it specifies text for a currency range. To use an example from the current docs, schema.org/Hotel includes this property with this example:
Room rates: <span itemprop="priceRange">$100 - $240</span>
The $ sign is ambiguous: Is it USD, CAD, AUD or…?
The schema.org/price property and the accompanying example are much better:
<span itemprop="priceCurrency" content="USD">$</span> <span itemprop="price" content="1000.00">1,000.00</span>
Can priceRange be update to be schema.org/PriceSpecification, which does include minPrice and maxPrice as numbers, as well as the the priceCurrency property that removes the ambiguity?
About this issue
- Original URL
- State: open
- Created 8 years ago
- Reactions: 13
- Comments: 48 (17 by maintainers)
so 5 years have passed… “NO” reaction both from schema.org, and from Google
Scriptures for Developers
<small style="color: #250000;">nakigoe.org/articles/rev.html</small>
+1 for retiring this in favour of a single idiom
@jvandriel It has (very recently, I think) started showing up as ‘recommended’ in the structured data testing tool, triggering a warning. I expect a lot of
localBusinessowners will suddenly be wondering how many dollar signs to award to their software consultancy, law firm, vehicle hire place, etc.Real price range is the best option
$,$$,$$$ is ambiguous cheap, moderate, expensive - You are going to kill the business!
Oh by the way, I’ve got a new website (after being blocked by Microsoft, which did not manage to kill Skype and GitHub completely yet)
nakigoe.org
I too would like to know, I presume it wouldn’t matter if you use a $ or your local currency (providing a location is set).
Does a single $ represent 0-9 ? $$ = 10-99 ? $$$ = 100-999 ?
This thread contradicts that almost suggesting it’s like a 5 star rating but for cost: http://stackoverflow.com/questions/40005100/what-is-the-pricerange-parameter-for-google-structured-data-reviews
Can we get some clarification on exactly what is necessary?
I would suggest proposing a new definition for the property and, if you don’t get shot down, turn it into a PR.
I tend to agree with you about 1 - 5 dollar symbols - it’s sort of analogous with 1-5 star ratings.
As to values: $ = inexpensive $$ = average/moderate $$$ = expensive $$$$ = very expensive $$$$$ = if you have to ask the price, you can’t afford it*
* Apparently attributed to J. P. Morgan, although disputed
tl;dr: We should change the definition of
priceRangeto “the average price of products or services this business offers”. If people feel the need to express the average price as a quantitativeValue, we should expand the range to allow for that.To clear something up, my understanding of
priceRangeand the understanding reflected in the data is not what is the range of prices offered across the spectrum of products offered. It would not be £20 - £10,000 as listed in an earlier example.Instead, it is more along the lines of what can the average client expect to pay at this establishment. That is most often expressed in a number dollar signs. The convention has not been established for schema.org. Two conventions are Facebook and Zagat.
Facebook business pages use: $ = inexpensive $ = average/moderate $$$ = expensive
Zagat uses a similar scale, but adds $$$$ = very expensive
Note that the definitions are not based on quantitative values and are a reflection of the domain. In other words, if there are two Facebook pages: one for a hair salon and one for a restaurant, they may each use “$$” as their
priceRange, but mean very different quantitative values.ALL - looks like most of the votes are in from my cursory glance that we deprecate
priceRange. So going forward we’ll promote the use of the clearer PriceSpecification.I am deprecating usage of
priceRangeand advising everyone I come in contact. @Aaranged @jvandriel I’d say we go ahead and start voicing this. The SDTT will catchup with our community power as it has in the past.@danbri Are you OK with deprecating for next release ? Given the community has spoken and likes the idea of one idiom with PriceSpecification
First of all, ‘my suggestion’ is basically what the spec currently says, apart from the min and max values of 1 vs 5 dollar symbols (the spec currently gives no indication of possible values except for the
'$$$'example).Second of all, I feel like you are completely overthinking this.
priceRangeshould answer only one question: Is this a cheap or an expensive hotel?Now some hotels may like to advertise themselves as cheap, then try to sell you a can of coke for $ 10,-… But as stated before, that’s not our problem. On the other hand, an exclusive 5 star hotel will probably not want to advertise itself as cheap… Whereas a cheap motel will not want you to think it is expensive. So both will pick different ratings.
And yes, it is a range. Two hotels being in the range ‘cheap hotels’ (one dollar symbol) does not mean the rooms will have the exact same prices. It just means they will both be cheap as compared to other hotels in the area.
@vholland Thank you! What you are describing is exactly what I had in mind, based on the current spec text. Except you seem to opt for 1 … 4 dollar symbols instead of 1 … 5. I think the difference there is subtle so both would probably work fine. 5 dollar signs may be a bit ‘safer’ as it includes any existing data with 5 dollar symbols whereas the other way around would mean people who chose a 5 symbol rating system will suddenly have ‘invalid’ values.
priceRangeis already in the spec. No one is inventing anything here. Either deprecate it (and wait for months/years until all tools catch up) or just write down what this thing is currently doing as far as we can tell based on the spec and use in the field. My vote is for the latter as it should be quicker to do and is imho much more productive than deprecating it. Many times a 4/5 symbol rating is all we need to be able to e.g. rank restaurants from cheap to expensive.Here I disagree. As pointed out before, interpreting
priceRangeas a literal min-max range makes no sense. Because saying that a restaurant has a price range of $1-$299, without specifying that the $1 is for a bottle of coke and the $299 is for a group arrangement for 4 people tells you absolutely nothing about the main question of ‘is this an expensive restaurant?’. But it does make everything a whole lot more complex, drags in currency issues etc. So I ask what is the value of that? We haveOfferwhere we can specify all that, with issues like currency resolved (but unfortunately not VAT).A 5 dollar symbols rating system offers a clear, though limited, value in that it allows us to group e.g. restaurants into 5 distinct price ranges. Often, that’s enough. If I just want a quick bite, I’m opting for a cheap restaurant and I’m ok with a wiener schnitzel or hamburger. But if I want to celebrate my wedding anniversary with my wife, I want to make it something special so I filter out the cheap places to find a ‘fancy’ restaurant. It’s that simple. The one example we have in the spec right now clearly indicates that intent and we must assume authors using schema.org will have interpreted it that way. Whether the rating should be 4-star or 5-star is anyone’s guess, but I’m proposing we choose 5-star as it’s inclusive (e.g. backward compatible) and used often (for e.g. hotels, movies etc). Crude as this system is I don’t think many authors will have assumed a 10 star rating system and have values like
'$$$$$$$$$$'.proposal
This proposal is much, much more explicit than the current spec text, without actually changing the current suggested meaning. As such it shouldn’t be very controversial. The only authoritative example we have to go on at the moment is the example of
'$$$'and it leaves us not much choice but to conclude that we are looking at a ‘some amount of dollar symbols’ system here. The questions that then come up are ‘how many dollar symbols max?’ and ‘can we use other currencies’ etc. We should try to answer those questions instead of completely changing the meaning of the field, or scrapping it all together.If the community could reach consensus on this, I would be willing to create a PR for it.
I’m not sure I agree with this. Google is warning that the
priceRangeproperty is an important part of the data as far as they are concerned. Ok that;s pretty clear. But how do they interpret that data?? Well, simple. They interpret it as is mandated by the spec. So let’s check https://schema.org/priceRange … Mmmmm now that is the ambiguous part!Google’s warning is clear. As an implementation it’s not their job to specify how every part of schema.org should be interpreted. That’s precisely what the specification is for! And in this case, the ambiguity is right here, so the issue belongs right here as well.
Questions/comments about how Google interprets markup should be taken to the Google developer forums.
@lucasvazq the point of this issue is we are trying to get a specific definition from schemaorg or some other higher-level authority like google of the exact use case of
priceRange.What you are describing seems to be plausable, however, there is no evidence to back your claim up. This issue have been open since 2016 and instead of schemaorg defining it, but in a weird turn of events it seems like those who actually implement schema on websites have hijacked the definition instead (maybe lead by larger travel-based websites) likely because nobody has defined it yet.
The page you linked does suggest we can add a price range like so:
$10-15BUT, does not suggest exactly what the more generalised$$$means.For example does
$$$equal:That is why we are all here, waiting for an answer…
For Google to make it no longer give an error I use these codes ::
<span itemprop="priceRange" content="$$">Price range $$</span>Will Also work ::
<span itemprop="priceRange" content="0-100">Price range 0-100</span>@joepagan I agree with everything you are saying. I only add info to this issue because it is well indexed and I am sure that more than one who feels lost can end up here and find some hope in our comments. I want as much as you do a more formal definition of how it should be used. Meanwhile, a definition of a price range through fixed numbers (eg 100-1000) works only in the short term. In my country, Argentina, this would make us all update our websites every month: laugh:
I too think there is value in the
priceRangepropery as a simple 5-star system where the stars are dollars… which is how I interpret the current ‘spec’.How about we just change the description to:
Imho, this is just expressing explicitly what the current specification is suggesting.
@vholland Of course some data is better than none. I’d be OK keeping it like I said, but only if we can help the publishers with clarity through tweaks, sure. (not so sure about publishers pushing a stat distribution themselves with
MonetaryAmountDistribution…my feeling is that they give us the pricing data, and averages is acceptable… we as consumers of the data can then produce the stat distribution from learning algorithms, etc. and provide controls/filters to work with the sets, just like we all do for providing comparison shopping experiences)So what’s your suggestion for a better description ? Let settle on that as a community first.
I don’t want to throw the baby out with the bath water. It seems like a few tweaks to the range and description would go a long way.
@joepagan suggested a range and average. In issue #1698, I proposed a
MonetaryAmountDistribution. Perhaps that would be useful here.As for authors being able to be somewhat deceptive, that is beyond our scope. As @danbri often says, “We are providing the dictionary.”
People can use that dictionary for all sorts of things. Nothing stops them from saying the maximum fence price is $3,000 only to find that is if you haul the pieces yourself and install it yourself. It is up to the consumers to figure out how to identify and deal with bad actors.
@Aaranged I am actually the author of the Google forums post you linked! As you can see, I didn’t get any clarification, as for some reason you only get to speak to the middle men/women in that sub. And, in that case, I only got Grace’s opinion on how the data was being used. There was no certainty behind that at all.
I appreciate going to Google direct is the best move to find out exactly what they’re expecting, but, when there is literally nothing to go on from Google’s side, surely the description from Schema.org is how Google would probably interpret the data?
priceRange
The price range of the business, for example $$$.When that description about a property is incredibly vague, maybe you (Schema.org), and, Google, have had talks behind closed doors and forgot to let the public know how this data is meant to be used? Looking at Dan’s Bio, it looks to me like schema & google are merging?
Regardless, I think the idea of a property like that could of benefit to listings and such in the future, though, maybe a min/max/average value would be more beneficial?
Regardless of how much the priceRange specification and description may benefit from improvement, the core issue here is Google’s warning message to webmasters, so it’s contingent on them to clarify what their data expectations are here.
So I’d limit the ping to the Googlers, and limit the plea to “please urge your colleagues to address this long-standing ambiguity.” 😃
Two pertinent URL references here.
The longest-standing (or at least notable) thread in the Google Product Forums on priceRange (22 Dec. 2016).
priceRange for LocalBusiness, what is the preferred way to add this? - Google Product Forums https://productforums.google.com/forum/#!topic/webmasters/ySYoZw0VRQA
For the record, the very knowledgeable Grace Massa Langlois provided this advice: I don’t think marking up dollar symbols is what Google had in mind. The requirement is text therefore using the symbols is fine but you should markup the actual price range, for example, $20 to $80.
But subsequent code provided by Google in their Reviews Data Type specification - AFAIK the only reference to “priceRange” in all the Google Developers documentation (and the second URL I’ll note) - where one will find in the example code for “Critic review examples > Business reviews > Embedded review”, which suggests that “marking up dollar symbols” is precisely what Google is expecting. 😃
"priceRange": "$$$",I can’t go into detail about how various consumers use this value, but for the reasons stated above,
priceRangeis of limited value.Authors tend to interpret values like $$ based on their own domains, so a hotel with priceRange $$$ is not the same as a restaurant with priceRange $$$, or a hair salon with priceRange $$$.
If folks are interested in more precise schema, there were some suggestions earlier in the thread.
Lets ping some top contributors on this issue: @danbri, @RichardWallis, @vholland, @mfhepp, @twamarc, @unor.
As suggested earlier, Google JSON-LD testing tools is advising to include this field, e.g. https://search.google.com/structured-data/testing-tool/u/0/#url=https%3A%2F%2Fgo2cinema.com%2Fvenues%2Fvue-westwood-cross-1001132
However, the directions, in terms of whats the data format is, are lacking.
How do I represent the cinema venue prices?
A big thumbs up from me for this, but eh…
To prevent having to spam a certain product forum after schema.org has made the changes, you might want to inform the sponsors upfront as there’s currently not one that supports
schema.org/PriceSpecificationwhen it comes to rich snippets (and Google does supportpriceRange, don’t know about Bing, Yandex or Yahoo though).Ah gotcha, thanks. Maybe then stop using priceRange in the examples? The advanced price modeling is not that difficult and should really be the one standard way used in the examples IMO.