New feature: Contingency group bidding

[mario]

Gixen introduces a new feature today: contingency group bidding.

Contingency groups are the opposite of regular groups - the remaining snipes get canceled in a contingency group when you lose an item (as opposed to when you win).

As this is a feature very few people will need, and would get many other confused, you have to enable this feature on your settings page. Only then contingency groups will be shown in the group dropdown menu.

Two important notes:
1) Contingency bids are available to mirror users only.
2) Like regular grouped bids, contingency bids are fired from the main server only.

[me]

what the hell are you talking about?

[mario]

What part don't you understand?

[mighel]

You're right I can see not many using but it's a cool idea.

To make sure I have this right, Lets say I'm building an item. I HAVE to have these three particular parts. If I can't get all three parts I would rather get none of them.

SO if if the first item ends and I do not win..then all the bids are canceled. Right?

very cool (if I understand it right!)

[mario]

You got it right. However if you win the first item, and lose the second, you still have to buy the first one.

[Betty]

I understand the idea, but how do you set up a contingency bid? Thanks

[mario]

First you have to enable it on your settings page. This is a necessary step to avoid confusion for users who don't understand what it is, or don't need it.

Once you do this, you will see "Contingency group 1-5" in the same drop box as regular groups.

Please let me know if you have any problems with this.

[betty]

Got it, thanks.

[pyweed]

A really neat application for this feature is when you are interested in a number of items from the same seller, but most are too expensive *individually* when S&H is added in. If however, you can take advantage of S&H discounts for multiple auctions they are worth bidding on.

For example, let's say a baseball card is worth $2 to me. Its S&H charges alone are $3.00, so I won't bother bidding on it, unless I already have won an auction from this seller, who charges only $.50 for S&H when it's bundled with another item. By using the contingency feature I can (assuming I understand it right), place snipe bids on these "additional" cards contingent upon me winning a previous auction.

Brilliant, thanks!

[Cupid]

[pyweed]

I get it -- thanks. Yes, I agree. For my own typical purposes I'd want all contingent bids to stay active provided the first one in the set won.

But on my wish list, this ranks far below augmenting the number of simultaneous groups allowed.

This isn't a complaint, though. I'm a new user and am extremely satisfied so far.

[Zarah]

[Cupid]

Thanks Zara,

I'd also be interested if anyone likes the current functionality better than we are suggesting... I have not seen any scenario quoted where it is better, and I can't think of one myself.

[Joe]

I could see a hierarchy bid system:

Main Item
. . +- Dependant Item 1
. . +- Dependant Item 2
. . +- Dependant Item 3

In this case as long as the main item is won all direct dependant bids are placed.

Main Item
. . +- Dependant Item 1
. . . . . +- Sub-Dependant Item 1

In this case you must win the main item and its dependant item before the bid for the sub-dependant item is placed.

If the bid window were designed to allow for adding a dependant bid to a current bid you could handle any situation. Of course that's easy for me to say as I'm not the one programming this

[mario]

Since introduced, contingecy bids have been used very rarely. I just looked, and at the moment, out of more than 3,000 pending snipes, 0 (zero) are contingency snipes. This is why I am no longer entertaining any idea of expanding them.

[Cupid]

[juangrande]

In the spirit of throwing in one's 2p worth, I'm 100% with Mario. I subscribe to Gixen's mirror service because it's simply the best at what it does: submitting bids seconds before the auctions close. I am, at best, skeptical regarding any new feature that could potentially drain resources of the system and/or the system's administrator.

It might possibly be that a better long-term approach would be to develop a Gixen API so that others could write their own applications implementing whatever fancy bidding and/or auction management feature they're interested in and which send the bid scheduling request to Gixen (the Greasemonkey add-on is already a simple example). Admittedly, this could be a big job and probably should not be considered until Gixen's user base is some multiple of its current level. In the end, my preference would be to jealously protect Gixen's core engine from feature creep. Lean and mean, I say!

How's that for 2p, Mark? Or was it more like 3 or 4p?
_________________
John

"If you don't know where you are going, you will wind up somewhere else."
--- Yogi Berra

[Cupid]

Yes fair comment juangrande, certainly in this case it is not worth the effort to develop fancy network type schemes for bidding and organising dependancies between outcome of auction bids and future actions.
_________________
Mark

[leon.stankowski]

If each item in a bid group had a single control statement then you could accomplish many of the goals of normal group bidding and contingency bidding along with more involved dependencies without too much hassle (in either coding or user setup). I would want the following control statements:

- Bid UNLESS any prior win (emulates normal group)
- Bid UNLESS previous item wins
- Bid ONLY IF any prior win (emulates contingency)
- Bid ONLY IF previous item wins
- Bid ONLY IF first item wins

With the above you could drop the special case code for normal and contingency groups and implement those concepts using item control statements defaulted to the appropriate values for those group types.

BTW - love your service, thanks!

[mario]

True Leon, but imagine the customer support nightmare I would have if I implemented it that way... So many ways for people to misunderstand things. And besides, even contingency groups are used very, very rarely, so I can't justify the effort to add a feature like this.

[compressor5]

For me, Contingency was my reason for subscribing to Gixen. I was happy with the free service, but I found an auction where I needed both items together or niether was worth getting. It payed off big time when I couldn't be there to cancel the second item.

On the flipside, I was one of those tech support nightmares, because I completely didn't understand that the contingency portion would show up at the bottom of the regular group dropdown. So, I can feel you on why you wouldn't want the added headache when someone didn't understand the concept of more bidding options.

Gixen is almost everything I want in a bidding software, but I too agree that adding an option to bid on every item after the first if the first is won would be value added. Few would use it, but I bet there will be some that will consider that feature alone worth a subscription, regardless of whether they use it often.

[Guest]

well I only discovered 2 days ago the range of features of Gixen because of country issue with ebay.... like to put the bidding bar on top instead of below .... which nagged me a lot when I bid on 25+ items ... my bad for not looking in the settings... maybe new feature announcement by logging in may help spread the knowledge, nerds like me may not look at the forum all too often...

Well anyway, a contingency that works:
"
Unlike group bidding, with contingency bidding the remaining snipes in a group are canceled when you LOSE your first item. "

If I understand right ONLY first counts ?

It is what I was looking for for months now. I bid on legos / collectings cards and I am often faced with the issue of 1 main item interests me and If I won that only item, I give a try for other not so interesting stuff of the same seller
this conditional bidding is then a gift to me ^^ thanks.

[mario]

[Guest]

arghh not that nice then... let see what can be done out of it.
I'd replace the description with "are canceled when you first lose an item" or something similar
thanks anyway

[rickyk4]

This is fascinating. I personally don't see a reason to use contingency bidding yet -- but it's good to know there's flexibility enough for when I may need it. Plus, I'm just a geek about technology features.

I can see as an advantage a simple scripting language being made available to all users in an "advanced" tab. If users don't want to bother with the complication then it will default to a basic group bidding system, but you can go to the advanced tab to see what a basic group bid looks like in script form. You can make a boolean-style scripting language with logical ANDs, ORs, NOTs, and XORs, along with brackets "()".

This way, people can even roll their own hybrid contingency and non-contingency bidding system. You make groups contingent upon other groups. If group #1 were a bunch of doohickeys, and group #2 were a bunch of thingamajigs. Something like this:

Regular groups:
reggrp1=(doohick1 OR doohick2 OR doohick3)
reggrp2=(thing1 OR thing2 OR thing3 OR thing4)

Contingency group:
contgrp= reggrp1 AND reggrp2

So in this case, once all of the items in reggrp1 or reggrp2 are exhausted without winning, whichever comes first, will result in the whole contingency group being canceled.

[mario]

I find this very amusing - if I were still at the University I'd probably enjoy making something this for academic purposes. In a real world, however, you would probably be the only one to use this .

Just to give you an idea: at this very moment there are 7578 pending bids. Out of these, 872 are grouped bids, and only 2 are contingency bids.

[rickyk4]

[Craig]

I vote with cupid. In its current form contingency groups are not very useful to me. However, If I could make all subsequent bids contingent upon winning my first bid in the group, it would be useful. A function where I could set a number of primary bids, and if any of those were won, then my secondary bids all went off, would also be very nice. Like others have stated, this would be a very good tool to take advantage of combined shipping discounts. I would certainly use it.

[mario]

What can I do now...? I can't change the existing definition, as that may surprise some users... And another, third, kind of grouping would be awfully confusing... not to mention an extremely low interest in contingency groups all together.

[juangrande]

I don't think you should change a thing, Mario. I personally think fancier features like this should be done on the client side using the Gixen API (which you've pointed out, has not been used by anyone to date). I had hopes after a random comment Keith left that it might be possible to get JBidWatcher to use the Gixen API, but then Keith set me straight. If an auction management program could be written (or adapted) to use the Gixen API, it would answer a lot of the clamoring for more features. Ah, well. I'm just a lowly user and have no programming capability whatsoever.

By the way, you once again deserve a truckload of thanks for fixing yet another glitch caused by eBay. Thanks.
_________________
John

"If you don't know where you are going, you will wind up somewhere else."
--- Yogi Berra

[Craig]

Hello Mario. I just came across this topic and thought that contingency grouping in the alternative form discussed would be a great tool. I have managed without it so far and will continue to do so. With or without it, your site is the best. I use GIXEN all the time, and have had nothing but success. Thanks.

[Cupid]

My tuppence, for what its worth, would be that the current definition should be revised. In its current form I can not think of any strategy that it fits.

By its lack of use I also think the current definition has shown itself to be a redundant feature anyway, so the removal of that definition would not affect many users and I really think that even those that are currently using it would prefer the function that I have suggested that the first item only is the contingent item that dictates whether or not all the other bids are submitted.

If it were changed in that way I would use it occasionally as then it would be worth my while finding many other items that were worth bidding on with a postage discount, as it is since I might only win one more before the rest are cancelled its not worth my while looking so I never bother.
_________________
Mark

[grinin]

[Cupid]

[Finite]

Cupid, I do exactly the same thing - increasing subsequent snipes to take advantage of postage discounts with one seller.

Just posting in here now as having read through the thread I've set up contingency bidding for the first time - and it's an ideal situation for a test of the feature. My first snipe in the set is for a very specific charm bracelet, the subsequent snipes are a variety of charms to go with it as selected by the birthday girl. If I get the bracelet, we're set to go - and with sufficient time to fiddle around with bid levels. If we don't win the bracelet, we move on.

Cheers.

[Finite]

It worked. I'm happy.

Not sure when I'll use the function again but it did everything I needed it too, so I definitely will.

[kaikemmann]

I use contingency bidding every now and than but I only found out today that I misunderstood the function of it.

I expected the following bids to depend only on the succes of the first bid.
I agree that the description on the settings page is misleading and I would prefer very much if it was possible to change the function and have all following bids in fact depend only on the first bid and not on the second or third or ...

Thanks for considering this.

Kai

[mario]

Kai,

Unfortunately the whole idea of contingency groups looked great to me at the time, but it turns out that it is very rarely used. This is why I cannot see myself adding another type of group (or a variant of contingency groups)...

Mario.