Help users avoid the bidding in the last minute problem, prevent sniping

[dblock]

A user bids in the last second does not have their bid registered because the auction may be closing at the same time and the network latency makes it so the bid doesn't arrive on the server quickly enough. This causes the user to be very frustrated as they thought they were clever waiting for the last second to bid.

We need to find a way to tell users that they should be placing max bids in advance. Most definitely bidding in the last 15 seconds has very high odds of the bid not getting through. That is counterintuitive to most users.

Extending the auction doesn't solve the problem because bidding int the last 15 seconds may still be acknowledged server-side after the auction closed (because of latency), and we cannot trust the client's clock and it would be too hard to "reopen" the auction even if we did trust the clock.

[katarinabatina]

Discussed this with @dblock would love to hear thoughts from Platform @joeyAghion

I think online ticket purchasing experiences may be a valuable metaphor to look at to try and solve this problem. When tickets become available for a concert, a flood of users go to buy a ticket.

A user is able to hit buy, w/o entering any credentials (no registering/signing in). The next screen they are presented with is a confirmation. They are asked for name, email, billing, CC, etc. There is a set time limit where the tickets are on hold for this user while they enter all their info and hit confirm.

What if we did this for bids?

A user hits bid, this kicks off a pending bid to the server (telling the server "hey incoming bid, we needs some extra time in this auction). This gives the user time to enter in the credentials they need to complete the bid. This pending bid would also allows us to extend the length of the auction by "x" seconds/minutes.

Thoughts? @dblock does this capture what we talked about?

[joeyAghion]

I like the metaphor!

How much extra time would we grant users who may have a form open?

What would other bidders' experiences be? Would the lot say "bidding extended due to in-progress bids?"

During the extension, would other bidders who had not started bidding by the initial close be allowed to start bidding? Would we extend the close further?

If I was a competing bidder and saw that a lot was extended due to an in-progress bid, I'd be motivated to start bidding myself. If I was a seller (or seller's agent), I'd be incentivized to start a new bidding session just before the close to extend the lot and try to squeeze bidders for every last cent.

[katarinabatina]

@joeyAghion

One the web, it is much easier for us to say, I think these bidders don't need more than 2 min max to complete their confirmation/registration. The kiosks are tough though because we don't know how many steps a bidder has to finishing their bid. I think we would have to close registration on the kiosks to avoid new accounts being created (this could take a while). If the user were bidding from the kiosk and were registered they'd only need another minute to enter their bidder number and PIN.

I am still thinking about what the extension looks like for other users. My gut reaction is to say whoever hits bid before time expires should be allowed to complete their bidding process and may the highest bid of those win. But I think we miss out on the opportunity you outline to potentially get even more bids.

[joeyAghion]

To be clear, I don't see it as an opportunity to get even more bids. I think it's dangerous because it encourages abuse by sellers (trying to create the appearance of last-minute interest) and buyers (trying to be the last to submit bids beyond the close).

[katarinabatina]

circling back to this after some thought:

I do think that for other users the auction should "close" right? Continuing with the ticketing metaphor, if I grab the last ticket (or in this case the last bid before close time) then every other user would see that there are no tickets left (or that the auction has "closed"). If that last bid falls through then the prior bid wins the lot. Not entirely sure that's the best solution @dblock what are your thoughts?