I'm still trying to gestate my thinkings on this subject, so apologies in advance if it's not easy to read, has varying levels of specificity in places, or changes over time.

This all emanated from Enchantrix for me. I was happy that fixed prices got added, but annoyed that they were separate from the auctioneer appraisal prices. When I mentioned this in chat, norgs made a convincing argument (which I can't quite remember) to persuade me that maybe they weren't the same price after all. Anyway, it all got me to thinking...

Price #0: Vendor price
This one comes from Blizzard, is (for a given WoW release) static, and should be self evident.

Price #1: Worth price
My current thinking is that there is one key independent price out there for us to calculate: the price an item is "worth." This price is external to other factors, like the current state of the snapshot.
* "Worth" prices are generated by Stats modules (and Util modules), based on scan data, and possibly other data (i.e. WoWecon, our idea for sharing real purchase prices with guildies/others, etc.).
* Each item has a default "worth" price. The user should be able to select, in the Auc-core options, what Stats module to use to generate the "default" worth price anywhere in our application. A likely setting for most people will be some future "Market" price, which we make configurable to allow custom weighting the various other stats modules. I'd suggest we think of a better name other than "market" though, which is confusing because it seems to mean something other than "weighted average of all other stats modules".
* As a matter of practicality, since users can enable and disable the various included and user-defined stats modules, and might accidentally (or purposefully) disable their currently selected "default" module, we should also have a "backup default", which is guaranteed to be present no matter what options the user selects (i.e. they cannot deselect it from loading). There need not be any GUI or public indication of this.
* The user should have the ability to select and persist a different "worth" metric from the default, on a per-item basis. Appraisal is our GUI element that allows them to do so. For each item, it should list all currently available stats modules, and let them select amongst them.
* As a matter of principle, I think the current "market(default)" item should actually be "Default([whatever they selected in options]", and "Market" should continue to just be listed separately as well. If they change the default selection in the options, then the default in Appraisal should automagically change as well.
* Once again, if the selected "worth" metric for an item happens not to be loaded, we should revert to the "default", and if that's not loaded, revert to the "backup default".

Price #2: Sell price
* Sell price is based on two things: "worth price", and other stuff, most likely the current stats of the snapshot - i.e. current competition. Perhaps we should have some sort of module system for the other stuff as well, to allow us to easily package up different types of sell price mechanics, and allow for user submitted modules.
* Failing that, we should at least provide the "undercut" code, to allow the user to modify the "worth price" by the state of the snapshot, if they so desire. Some people prefer not to undercut at all, since they believe this just drives down prices. Others want to adjust the price they list at based on what other auctions are believed to be out there.
* There should be a default "sell price" algorithm the user selects, somehow. (i.e. "worth price only", "undercut", others if we ever think of them)
* Users should be able to override the pricing mechanism from the default on a per-item basis, just like we do for "worth price". This might be somewhat more challenging, because "undercut" might have different sets of options (described below) which I'd like to also remember on a per-item basis. For example, some items I might always want to undercut all competition, some I'm OK being bottom third, etc.
* Brainstorming here, those folks might want to:
** Filter out auctions to include in the undercutting based on how much time they have left (i.e. if I am listing an auction for the next 24h, and there are 3 current auctions but all expire in the next 30m, I might want to just ignore them since they will be gone for the majority of my listing).
** Select how many of the competitive, unfiltered auctions to undercut. For some items I might want to make sure I am always the lowest price. For others I might want to be in the bottom third, or in the middle, or I might know they are in high demand and always sell out so I am OK being at or near the top.
** Otherwise similar options to Auc4 - maximum amount to undercut from "worth price" before displaying red warnings and discounting by some other amount, amount to increase "worth price" if competition is amove worth price, etc.

Price#3 - Buy price
* This is the price at which we are willing to buy an item. It is useful when you are searching the AH for "bargains" (AH searching and BTM). It is also useful for shopping lists of items you need for consumption, either for your crafting professions or your personal use (i.e. raiding).
* We use Evaluators for buy price calculations in BTM. If the auction bid/buyout price is less than the buy price for one or more evaluators, we suggest buying the item.
* BTM uses different valuators to calculate different "buy prices" (resale valuation, vendor valuation, disenchant valuation, snatch valuation, plus other third party valuators). Some of these valuators use the "worth" price (either of the items themselves, or the d/e materials you'd get from the items), some use vendor price (vendor), some use a fixed price the user specifies (snatch). At run time, it compares the profit from each of these (not exactly sure how snatch fits in to this), and suggests you buy for the highest profit reason.
* I suggest that the search tab (and all modules which need to calculate a "buy price") should use these same evaluators, somehow. This was always a failure of Auc Classic imo - we could create these great baserules for BTM, but couldn't also use them on the search tab. BTM "Resale" is just a stealthy combination of the Auc4 bid and buyout searches. (See bid/buyout issue below.) We wanted to add a way to use the GUI to do enchantrix/disenchant and BTM vendor searches, but never got it together. Making the search screen incorporate evaluators is how we should do this. [This was a revelation to me, but the rest of you probably knew this all along, heh.]
* Ideally, rather than having a dropdown of several searches to run the way Auc4 did, our search would check each auction against all evaluators, and list them all in one list based on profitability. This could get complicated though, especially if we want to show all the evaluators which suggested the purchase (in case we want to override the top one for some reason). For example, it might get suggested for resale, but we know the "worth" price is off for the item, so we might pass over it. But what if it was also a purchase candidate for disenchant or vendor reasons? We'd want to know that, too.

Price #4 - Enchantrix fixed prices
* My initial thought is that this really shouldn't be it's own setting at all. Enx should really just choose the "sell price" for the various disenchant reagents. If you've gone into Appraisal and set your selections for the "worth" price of each reagent and the "sell" price for each reagent, then enchantrix should just use these prices, because it is supposed to tell you the alternate worth of an item if, instead of just reselling it or vendoring it, you first disenchant it then resell the results.
* I'm not averse to having a special screen in the Enx options that highlights the current worth/sell price options for each specific d/e reagent, but they really should be stored in a single place (in AucCore, or wherever we are saving per-item worth price now), rather than as a separate entry in Enx.
* Norgs made an argument before against this that I found somewhat persuasive, but I can't remember it now. I think it might have been that he was an enchanter, so to him, the value of the results was not what he could resell them for, but rather what he would otherwise have to buy them for. I don't exactly know how to respond to this, it seems to be a fundamental limitation of the arbitrage spread between the price you will sell for and the (hopefully lower) price you will buy for for all items. I think this is also why we had to add a snatch price at some point - the sell prices weren't enough for the purpose when you are a net consumer of an item, not just a seller/reseller.

Issues:
1 - Are fixed prices types of "worth" metrics, or types of "sell price" metrics? I think they are primarily types of "worth" metrics, when none of our stats modules can accurately capture the items "inherent" worth, because of scam data, patch changes, or just a lack of modelling nuance and complexity on the part of the currently available stats. But I'm not positive there isn't also a "fixed sell price" separate from that.

2 - Bid/Buyout complexity. There might be several ways to handle this, but the interesting case is when bids and buyouts are both "profitable" and match our buying criteria (i.e. if we have filtering based on bid time left, the auction meets that criteria). The bid price is obviously more profitable, but it carries a risk that someone else will buy it out. We probably want a slider that lets us determine how much of a premium we're willing to pay to earn less by paying the buyout price.

3 - In order to set "worth" (and eventually "sell") price options for an item, you have to have that item in your inventory so it shows up in Appraisal. Ideally, there would be some way to set all options (worth price, sell price) for all items without needing to have one in inventory. This is an issue for setting enchantrix "fixed prices" for example.

4 - As an aside, right now our BTM evaluators seem to use the (current) "market price" of the item for it's "worth" price. I suggest changing that to always use the worth price specified for the item (i.e. default if never set, whatever they selected otherwise).

Dinesh, this is a very, very good start to this discussion. I've been having it in my head, with co-workers, and with guildmates for about the last two weeks, the guildmates being most interesting because we have about six of us who control large swathes of our AH.

Here are a few of my thoughts, not formatted nearly as well as yours:

The REAL Market Value
Everything has it and no one knows exactly what it is. The REAL market value of an item is, very simply, the highest price at which someone will buy it. This sounds obvious, but the problem is that there's no way of actually knowing what that is directly, since it's different for every person who plays the game. Market value changes as the population changes, as patches include or remove things, based on days of the week as numbers online change, etc. Since we can't know what it is, let's talk about ways to approximate it.

Auctioneer: Averaging Buyer Listing Prices
I've been a faithful user of auctioneer now since I saw the first versions back in 2005, when the only thing it did was scan the AH and add a fairly basic amount of information to your tooltip. We've seen a LOT of improvements since then, with enchantrix, bottomfeeder, bottomscanner, and hundreds of code pushes revisions. We've seen std dev, IQR, and many statistical enhancements on the algorithm, but auctioneer fundamentally does the same thing it's always done: It averages the listing prices for items on the AH.

Don't get me wrong, the average listing price is very important to know; like I said, I've been using Auctioneer for over 2 years now. However, the problem is very simple: no matter how we slice it statistically, we're still averaging the prices of auctions THAT HAVEN'T SOLD. They MIGHT sell in the future, but we have no way of knowing that. We don't know how many items are normally available, how many sell, or how those have changed over time. Additionally, this data is subject to being poisoned by those who intentionally list items for more than they expect them to sell for; this is especially prevalent with items having no deposit amount, such as enchanting reagants.

Therefore, we can generally say that the real market value will generally be lower than the average shown by Auctioneer, though not necessarily by much.

WOWEcon: Averaging Reported Sold Values
I'm not sure when WOWEcon got my attention, but it's been around for about a year as well. While it looks the same as auctioneer to the uninitiated, it works with a different premise, which is that it collects data from people who run the adds about what auctions actually sold for them, uploads it to a central server, and then distributes this sales data amongst everyone who runs the addon.

Now, on the surface, this sounds like a great idea, and again, it does provide very useful data since we want to know how much things actually sold for. However, we have a number of problems with this data as well.

For one, we only get a relatively small sample of data, since I doubt that even 5% of the sellers on my server use wowecon. I have found that my own buying and selling often comprises the bulk of the server data I see reported, which is problematic, since I try to filter out my effect on the market as much as I can for better data.

The other problem is that even knowing what items sold for doesn't tell you what they COULD have sold for. Just because someone sold a Truestrike Ring for 300g doesn't mean it might not have sold for 500g. Therefore, WOWEcon prices should theoretically be below the actual Market Value; in practice, it's hard to say since many items decline in value over time as well and the data sample is very limited. Also, this doesn't contain any data as to how many items sold at this price vs merely expiring.

Fixed Prices: Experience-based listing values
This is a built-in feature of Auctioneer (in several different ways), but is really it's own separate pricing method and deserves a section. Simply put, this is where the user maintains their own price values for certain items, adjusting them manually as they see fit. The fixed price in both auc4 and auc5, snatch values, watch list baserules, enchanting reagant values; all of these are really the same concept.

If you think about it, this is really the same thing as what WOWEcon tries to do, except that you're maintaining the price list yourself based on successes vs expired auctions, as well as examining the state of the markets yourself. You might lower prices if you see all your auctions expired at a certain price, or if you see a lot of competition at a lower amount; likewise, you might raise your prices if you see a low supply in the market or if everyone is priced well above your rate.

This tends to be my personal method of valuation, though it's manually intensive and really only applies to certain markets that I am very familiar with.

Bean-counter: historical tracking
This isn't really a valuation method, but another means of setting your own fixed prices. Beancounter tracks your listings, successes, and expirations by a combination of hooks at the mailbox and auction house. While it won't set your prices, it's definitely better than just working off of memory. The only downside is that it's not currently working with Auc5 yet and it doesn't seem to work well with BulkMail2Inbox, which I've found is the fastest way to retrieve your mail.

Something that would be really interesting would be to hook this directly to the fixed prices, with successful auctions raising the fixed price by a certain value while failed auctions would lower it. Give the fact that beancounter itself is not yet functional with Auc5, I suspect that sort of hooking is wishful thinkings; it also doesn't really address the issue that it would be reactive to the markets, not proactive.

Extrapolated Successful Auctions
This is where you run multiple scans within a 24-hour period, taking note of auctions that have disappeared before they were scheduled to expire, the assumption being that those missing auctions were purchased for their buyout prices.

This is fundamentally the same idea that WOWEcon is trying to accomplish, but hopes for a larger data sample by extrapolating data from the AH listings instead of hoping for others to use the same addon. Besides the obvious issue of cancelled auctions, which I suspect are not really very frequent, the main issue with this is that it requires frequent scans to identify these missing auctions. Additionally, the pricing data returned will tend to be below the market value, since you are more likely to find items that were bought quickly, indicating they may have been mispriced. Even with those issues, this is still very useful to know.

Minimum Priced Listings
This method, which I have not yet seen outside of my own manual use of the AH, is based on the idea that it is less important to know the average of the listed auctions as it is to know what the minimum listed value is, due to the fact that it has still not been purchased. This value is particularly useful in circumstances in which auctions with buyouts are about to expire, since that tells us that their value was too high for all potential buyers within 2/8/24 hours. Theoretically, the market value can be assumed to be lower than whatever this value should be.

This has the potential to be most useful in situations where we have a lot of listings, with quite a few about to expire. Markets with very few listings wil provide less valuable data; knowing that Pattern: Hurricane Boots is still available at 600g with somewhere between 8 and 24 hours left doesn't really tell you as much as knowing that there are 200 auctions of Arcane Dust and that 15 are about to expire with the lowest one at 1.75g.



Ok, so we have all these pricing methods; what do we do with them for setting a selling price and a buying price? Again, a few thoughts:

1) There should be as few different fixed prices as possible.
Seriously, I know that many people like to keep their reagant prices separate, or maintain a separate snatch list, or a watch list, or various other things, but I personally find that putting as many of these together as possible is best.

2) Buy and sell prices should generally be tied together.
I really like the discount sliders that allow you to purchase based on the expected sell price; my viewpoint is that this should be the model in general, rather than trying to keep different buy thresholds for individual items.

3) Buying should occur after market data is collected, if possible.
One problem I have with the evaluators in bottomscanner is that they don't really take market conditions into account; ideally, we should have todays data on the particular market so that we not only know the average price, but also the minimum listed price, so that we can tell whether we could feasibly undercut this or if we would have to hold onto the item before making a profit. Note that this will be much easier in 2.3 when we get the data as a clump every 15 minutes.

4) Evaluator resale logic should have logic to check different versions of min/max attributes.
This is more of an evaluator-based issue and I may address this with my own resale variant, but my opinion is that since none of this data is really trustworthy, we need to be able to determine the method by which we expect to obtain the highest profit with the lowest optimism. What does that mean? Well, I want to know vendor vs disenchant vs resale profit and pick the highest, BUT for resale, I want it to check for a fixed price; if one is not found, compare std dev against wowecon and pick the most pessimistic as the basis of the valuation.



Wow, it's late. Anyway, these are my initial thoughts. Hope they're useful; I may do some minor coding towards a few of them, but I'm realistic enough to know that I'm not likely to have very much time to spend on it. If you see an idea you like, feel free to run with it.

Posted By: meridun The REAL Market Value

Close, but not quite. The "real market value" is the price at which the number of those wishing to purchase at that price exactly equals those wishing to sell at that price. This equilibrium price will have both buyers who are willing to pay more and sellers who are willing to ask for less. The problem with "real market value" is that works fabulously in theory... but depends on these two components: 1) the market has informational efficiency and 2) the market participants act rationally based on this information.

In theory, everyone has access to the same patch notes, wowecon price lists, norganna.org forum posts. In practice, the players of the WoW auction house do not take advantage of this information. Even if all had access to the information, anyone who has spent any time idly watching /trade will know that rational behavior is not something to be counted on. :)

Please refer to the excellent wikipedia articles on market value, marketplace efficiency, and Walrasian auctions for further reading.

WOWEcon: Averaging Reported Sold Values
For one, we only get a relatively small sample of data, since I doubt that even 5% of the sellers on my server use wowecon. I have found that my own buying and selling often comprises the bulk of the server data I see reported, which is problematic, since I try to filter out my effect on the market as much as I can for better data.

I'm running into the same issue. I found querying against the servers-wide price to be a big help. My patch:

$ diff -p ./Auc-Stat-WOWEcon/WOWEcon.lua ../WOWEcon.lua *** ./Auc-Stat-WOWEcon/WOWEcon.lua Tue Oct 16 00:55:59 2007 --- ../WOWEcon.lua Tue Oct 15 11:59:38 2007 *************** end *** 44,49 **** --- 44,55 ---- function lib.GetPrice(hyperlink, faction, realm) if not (Wowecon and Wowecon.API) then return end local price,seen,specific = Wowecon.API.GetAuctionPrice_ByLink(hyperlink) + local global_price,global_seen,global_specific = Wowecon.API.GetAuctionPrice_ByLink(hyperlink, Wowecon.API.GLOBAL_PRICE) + if price and (price < global_price) then + price=global_price + seen=global_seen + specific=global_specific + end return price, false, seen, specific end
 

Therefore, WOWEcon prices should theoretically be below the actual Market Value; in practice, it's hard to say....

In practice, it's actually impossible to say that the WOWEcon prices are below the real market value. :) Using something like WOWEcon + Auctioneer implies that a market player wishes to increase their actual profits and is thus acting rationally. Consistently purchasing above or selling below the market value is not a rational act, therefore they will purchase at or below, and sell at or above the market value. Here's where it becomes impossible: is this rational market player buying more than he sells, or selling more than he buys? Either way will skew the results and since there aren't many reporting per server, individual server prices are off. Were one to balance this across multiple servers, though (cough use my patch cough :)

hey guys, I'm trying hard to stay out of this topic so as not to overwhelm the discussion, but I do want to point out that I was originally posting from the point of view of an auctioneer designer/developer, and was trying to isolate the different "types" of prices which intellectually exist, and the ways we might implement them.

I am very interest in the resulting discussion as well, but it appears to me that you have largely been identifying different types of "worth price" algorithms that might get auctioneer closer to actually tracking to the "real" worth price. Again, I find those discussions interesting (and indeed can see several new stats modules which might result), but I'd like to separate that discussion intellectually at least from what I was originally trying to accomplish.

In any case, please carry on!

no need to apologize. from a design point of view, i just want to make sure i'm not missing a specific price category. as an example, up until i reverse engineered what we are doing in the BTM tooltips, i never quite put together that there is a "buy" price, one for each evaluator.

Posted By: RockSliceMy take on the various price categories:
Vendor Price:No need to comment more.

Leave it to the bunny to be the contrarian. :) Vendor price should take into account "easily" crafted end-products said item may be sold for. For example, [Netherweave Cloth] vendors for 8s. Two cloth turn into one [Heavy Netherweave Bandage] which vendors for 30s. This raises the "true" vendor price of cloth to 15s.

I agree that "worth price" is a sticky wicket. The "worth" of the item is, in theory based loosely on the iLevel and class bias of allocation of the iLevel points for the item. (A shield with +healing, for example, will have a larger pool of interested buyers than a shield having the same iLevel, but point allocation shifted to +holy). Still complicated, but a bit simpler of a task. (Well, minus items created by Furor who has rather dubious judgement as to "good" allocation of an item's point budget.)

I really like your other descriptions, particularly the "buy for self" category. I won't bat an eye at dropping 50g for that last flask worth only 25g... if I'm planning on using for myself. I'd like to make a way to have that separate from the "buy to resell" price. What's good for the goose is not always good for the gander.

The cloth "upgrade" to bandages belongs in an external valuator (like disencraft, but skipping the enchanting step).
Otherwise you end up with special case rules which don't belong in vendor price.
Raw materials are always different from the crafted produce, especially as the crafted produce can _also_ turn up in the Auction house and needs it's own vendor price anyway.
You need transformative and equivalence functions to properly compare items and work out the "worth", but the vendor price for each is still a fixed value.

Haha, sure. I'm not trying to guide the discussion exactly - this is all interesting to me. We're just in a position where we are still building some fundamental frameworks for AA, and I had done some thinking about what we had and what I thought we needed, and I wanted to write them down so that the other devs could take a look and comment if they felt differently. As interested as I am in new stats modules which better estimate the worth of an item, I just wanted to make sure my original goal wasn't lost in the discussion.

Long story short: carry on.