After checking some paid prices entered by the users, I noticed a few that are almost half the price of the retail price.
I assume these ones are prices paid by users that shared a bottle 50/50.
I also do this from time to time and enter the full price, but that´s not exactly correct for my buying stats.
How about adding a checkbox if its a shared bottle? Users can enter the price of the bottle and also enter the quantity they purchased., For example there is a 200€ bottling with 70cl that is shared 50/50. You enter 100€ price point and quantity 50%. For the Market price calculation the App will automatically multiply the price by 2 and there you go.
I agree with you, good idea. And w would also add an aspect. When you see the prices for a set (like the Hampden 8 Marks or SBS Caroni set), it seems that the people sometimes apply the price of complete set to one or all of the bottles. I would suggest to divide the price by number of bottles in the set and apply the result to each of the bottles (like many people already do).
Is that why I sometimes see 30€ user price on a 100€+ bottle? I thought those were either maliciously entered to mess with the average or fat-fingered (I also sometimes almost miss to enter the last 2 zeros on a round price, so 200,00€ can easily become 2,00€ )
I don’t have shared bottles, that’s why it didn’t occur to me that this could be a thing. And even if, i would not enter them with a price in my collection, or at least exclude them from market value calculation (-> does this also ignore the price for the user price stats? if so, it could serve as a workaround)
Wouldn’t it suffice to add a 375ml sample? I believe that’s possible right now. Counting the same bottle twice for two users might distort the bottle overview: there are 312 bottles known for release x, but somehow the user base has collected 420 of them. Count how many split bottles are among them!
That’s exactly how I handle it. The person who keeps the bottle enters the bottle as “open” with the full price. The one who takes half enters a 35cl sample (or in my case 3x10cl and 1x5cl). Through the fact that we also alternate (over a longer period of time) “balances” the purchase price in the purchase statistics again.
Well, it is an issue for the original bottle, of course. Simplest would be to insert a custom size (you can enter a custom value for bottles as well), and enter half the sum, while the other one you shared the bottle with does the same as a sample. Of course this is a bit wonky, and has the risk that both use the bottle entry… And distorts the market value calculation part based on user price Input.
If one really wants to avoid this I agree, we need a “shared bottles” option. Just a checkbox in the bottle menu, that allows the other App User to be linked, who will then get the bottle automatically in their inbox (perhaps a “A new bottle has been shared by X, do you want to add it to your database” dialog is in order then). The only other thing required is the percentage of the share, and to recognizee that within the collection cost calculation (relevant only for opened bottles).
But a shared bottle is at the end the same as a sample, just bigger. So why would we need a special option for this incl. a process that can break and needs to be maintained etc.?
In a bottle split one person has an open bottle and the other one a big (or multiple) sample, no?
Well, I it is a rather psychological thing, I guess.
Both could enter it as a sample. Then it would not be added to the price calculator at all, I guess (bad for Oliver, who needs the data ). It would also be missing from the summary of how many bottles are present opened etc. in the community (perhaps bad for the community and bad for Oliver who needs the data). This is assuredly currently the best option for users.
At least one of them might want to have the bottle in his bottle section, not sample section, then the price would possibly be distorted. (bad for the community or good, depending if one wants to buy and sell, and how many sellers take the distorted price for their own pricing, and also bad for Oliver due to false data).
Or both use the bottle entry, bad again…
On the end user site this is not too complicated, until one takes all the possible data and dependencies into account. After all, finally, data given by the community to the app is something of a value, that makes the whole effort affordable for Oliver.
)
). It would also be missing from the summary of how many bottles are present opened etc. in the community (perhaps bad for the community and bad for Oliver who needs the data). This is assuredly currently the best option for users.