Subject:
|
Re: Mechanics of proxy bidding?
|
Newsgroups:
|
lugnet.market.theory
|
Date:
|
Mon, 1 Nov 1999 15:38:21 GMT
|
Viewed:
|
414 times
|
| |
|
|
Steve Demlow wrote:
> > B 1.00 0.70
> > A 0.80 0.70
>
> As compared to my example in the original post, this global lock-step
> approach raises some of the bids higher than necessary using a local
> single-step solution (where one of the bids ends up at 0.60, the other at
> 0.70). That's not necessarily a problem as long as people understand why
> it's happening, but it seems less desirable to me.
It seems to me that if the assumption of how the proxy works is that a
proxy will be raised to exceed any newer bid, then ALL proxy bids should
be raised to at least that level, not just whichever proxy bid happens
to be the one the step by step algorithm tries to bump. Note that if you
use the scheme where proxy bids are only required to match the new bid,
then the bids from A and B would both go to 0.60. This may be one
argument for the scheme of proxy bids matching not beating new bids.
> > Now what happens if C bids 0.85, which should fail since it isn't one
> > bid increment above A's bid, we need to add an extra finagle before
> > sorting the new bid into step 1, check if it will be enough to beat the
> > lowest proxy. If not, automatically sort it to the bump position,
> > continue step 2 and 3 as above. A refinement of step 3 is that the new
> > minimum bid price probably should be the same for everyone, so you set
> > it to the lower of
> >
> > 1. equal to the bumped bid or one increment higher than the bumped
> > bid
> > 2. the lowest proxy bid which will still stand
> >
> > So now in our example:
> >
> > Step 1: C 0.85 0.00 -> new min bid: 0.80
> > A 0.80 0.70
> > B 1.00 0.70
> >
> > Step 2: B 1.00 0.70
> > A 0.80 0.70
> >
> > Step 3: B 1.00 0.80
> > A 0.80 0.80
>
> So C bids 0.85 but A and B hold onto their bids for less (not equal). It
> seems like that would make C pretty mad. The rules above for determining
> the new minimum bid would have to take this into account and make sure
> the new prices are >= the rejected bid.
General note on online auctions, do they keep track of invalid bids? If
the bids were already up to 0.80, a bid of 0.85 would be invalid. It
seems to me that C's bid should be rejected as invalid (here is where a
justification of eBay's scheme can be made. In eBay's scheme, C gets the
item because his bid was valid considering the current bid levels, and
you don't have to worry about how to handle this case). I can see two
ways to handle this:
- Notify C that his bid was rejected because it didn't exceed a proxy
bid by the required amount. Make the rules clear that this is how it
works.
- Notify any bidder who places an invalid bid that their bid is invalid,
but keep track of the ghost bid, and adjust the asking price
accordingly. Again, make sure the rules are clear.
Todd - how does Auczilla handle this situation?
> > One advantage of doing it this way is that if someone has multiple bids,
> > you don't put them in a bidding war. Lets say we have 4 equivalent lots
> > with the following bids:
> >
> > Step 0: C 1.80 0.50
> > B 2.00 0.50
> > B 2.00 0.50
> > A 1.50 0.50
> >
> > D comes along and bids 1.60:
> > ...
> > Step 3: D 1.60 1.60
> > C 1.80 1.60
> > B 2.00 1.60
> > B 2.00 1.60
> >
> > Other systems, by initally bumping C's bid because it is the newest,
> > would raise C's bid to 1.80 and B's bids to 1.90 (1.80 if you just
> > require proxies to match bids).
>
> No, the proxy-driven bidding will never raise the new prices to more than
> the required increment over the bid that starts the chain of events. In
> the case above the final bids would be a mixture of 1.60 and 1.70 (or
> possibly even all 1.60, I think).
I'm sure I'm confusing things here. The Auczilla notes talk about a
situation where you can make a bid which causes all your bids to rise to
your maximum as the system negotiates your bids against each other. This
is where I think a single step global solution could be built to be less
confusing, though there are probably ways to do it in a step by step
process.
One thing I'd be inclined to add is an additional bid symbol which
indicates that you desire to increase the number of separate bids you
have on a batch of like lots. Then the system would always treat each of
your bids as unique bids. What then would also be nice is a way to
adjust a specific unique bid (with the system assuming that if you come
in and make an unmarked bid that you increase either the lowest proxy or
the highest).
I think it is reasonable to make an offer similar to "I'll take one for
up to a million dollars, but if they sell for no more than a thousand
dollars, I'll take two".
A nice web based bidding system could deal with this. If you place your
new bid against one of your old bids, you're modifying it. If you place
it against someone else's bid, you're placing a new bid for an
additional lot from the batch.
I think it would also be reasonable to be able to reduce proxies, but
the system would not let you reduce it below what is required to
maintain your position at the time the bid is processed (so if you hold
the item at 1.00 with a 2.00 proxy, and you submit a bid to reduce your
proxy to 1.00 but meanwhile someone else has bid 1.10 your proxy would
be reduced to 1.10 or 1.20 depending on whether proxies must meet or
exceed new bids - and possibly 1.20 if proxies need only meet the new
bid, but you think a proxy reduction should change the bid timestamp -
not unreasonable, I think an increase probably should reset the
timestamp - though you could get fancy and keep multiple timestamps for
each bid).
The way I would handle multiple timestamps for each bid is to store the
proxy increases outside the normal bid list. The oldest timestamped bid
then has a pointer to the list of superceding proxy increases. When the
older bid is finally bumped, you introduce the next oldest superceding
bid. If this system is used, I would not change timestamps on proxy
reductions (and if you have a 2.00 proxy which is current and a
superceding 3.00 proxy, and you then submit a 2.50 proxy reduction, you
would just change that superceding proxy to a 2.50 proxy with the same
timestamp).
> > Of course I've probably forgotten some niggling point.
>
> Therein always lies the problem (hence my original post. :) Another thing
> your approach would have to take into account is whether some existing bids
> (e.g. hard bids) are already above the new minimum bid price - you're not
> always going to set all of the bids to the same price.
>
> Thanks for the detailed response!
Since I would like to see a "perfect" bidding system, I'm happy to go
into a detailed analysis. Also it helps to understand current systems.
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
|
|
Message is in Reply To:
 | | Re: Mechanics of proxy bidding?
|
| (...) Yep, I should have been more clear about that: I am seeking to emulate the behavior of the AucZILLA software as closely as possible. So that means that proxy bidding will usually raise the price above the competing bid, not just match it. (...) (25 years ago, 30-Oct-99, to lugnet.market.theory)
|
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
