Implementation of Auctions in Websphere Commerce Suite (WCS)

Manoj Kumar and Manish Gupta

IBM India Research Lab., Block 1, IIT, Hauz Khaz, New Delh1-110016

manoj1@us.ibm.com, gmanish@in.ibm.com

 

 

Abstract:

In this paper we discuss the implementation of an Internet auction system.  We first describe a structure for auction software that facilitates its integration with existing e-commerce systems and allows the buyer/seller management, product description/browsing, and fulfillment/payment capabilities of the existing e-commerce systems to be used in auction process.  Then we present a solution for proxy bidding, a key performance bottleneck in Internet auctions.  In the second half of the paper we address several usability issues from the perspective of both auctioneers and bidders, most of the issues arising because of the difference in nature of interactions on the Internet and face-to-face interactions.  Some of these usability concerns also crop up because the participants in the actions will be increasing less well versed in the art of auctioneering.

 

Keywords: Proxy bidding, Open outcry auction

Wordcount: 4500

 

 

 

 

 

 

 

Implementation of Auctions in Websphere Commerce Suite (WCS)

 

1              Introduction

Auctions or brokered sales are the norm in the business world for negotiating trades of large value. But consumer sales and small-scale purchases traditionally used fixed (posted) prices mechanism, perhaps because of the high overhead cost of using the auction or brokerage method. The new economics of the Internet has made auctions popular in consumer and small business transactions also. Lee and Clark [5] present the economic rationale underlying this transition. Several success stories about Internet auctions are cited by Turban [10].  Finally, the success of ebay underscores the emerging importance of auctions in consumer sales.

 

Many types of auctions are practiced in different real world situations to achieve different business objectives in various social and cultural settings. The business objectives can be obtaining the best price, guaranteed sale, minimizing collusion possibility, etc. Ralph Cassidy [1] presents an extensive survey of auction practices around the world. It is the interplay of sociology, psychology, economics, optimization theory, organizational theory, and several disciplines of computer science in developing a comprehensive auction system that makes auctions research truly exciting

 

Game theoretic treatments of different kinds of auctions can be found in McAfee and McMillan [7], Milgrom [8], and Milgrom and Weber [9], while some experimental results are reported in Kagel [2]. There have been many papers [6], [3], [4], [12], and [13] that describe the salient features of Internet auctions and issues arising out of using auctions for trading over the Internet over the last couple of years. One of the early papers that discuss real time and performance issues in the design of auction servers is that of Wellman and Wurman [12]. They discuss the advantages of decoupling the bidder interface from the auction processing completely. Wurman et al [14], present an extensive breakdown of the auction space that captures the essential similarities and differences of many auction mechanisms in a format more descriptive and useful than simple taxonomies.

 

We implemented an auction system on IBM’s e-commerce platform, the Websphere Commerce Suite (WCS). The auction system has been available as a commercial product for the past two years. Looking back at our research and design experiences, four topics stand out, which are subject of this paper.

 

The first issue was to design the auction subsystem in a manner that allowed it to be integrated with existing commerce platform. The implementation had to be modularized to support the wide variety of auction formats practiced around the world. In Section 2 of this paper we discuss how our design handled this issue. The second challenge was of managing performance. The main challenge here is in processing bids efficiently in an open cry auction, particularly when proxy bidding, i.e., bidding by an agent is allowed. Details about the nature of this problem and our solution are discussed in Section 3.

 

Having implemented a system that could support a wide variety of auction styles, as we demonstrated our system, especially the auctioneer interface that allowed the seller to set up an auction, we were surprised by the confusion that the flexibility had engendered. The result was the re-implementation of the single panel auctioneer interface as a three-tier interface to support auctioneers with different degree of auctioneering skills. The details of the auctioneer interface implementation are briefly discussed in Section 4.1. In Section 4.2 we discuss several interface design issues from the bidders’ perspective. Finally in Section 5 we conclude with a discussion of what in our opinion remains not done and suggestions for some interesting research opportunities in this area.

 

 

 

 

 

Figure 1: Auctioning process in WCS.

2              Overview of Auction Implementation in WCS

From a bidders’ perspective participation in an auction involves the following four steps: 1) registration, which could be optional for an observer but required for participants placing bids; 2) Navigable catalog to find products on auction and learn about them; 3) Interface for bidders to bid for products on auction, keep track of their bids and learn about competing bids as consistent with the auction rules; 4) Settlement at closing of the auction if the bidder happens to win. As shown in Figure 1, the first, second, and fourth steps are common to fixed price based trading in conventional e-commerce systems, Websphere Commerce Suite (WCS), being an example of one such commerce system. Therefore, to support auctions in WCS we implemented just the bidding subsystem, ensuring that it interfaced seamlessly with the payment and fulfillment subsystem and the catalog. Minor changes were needed in the catalog to display products on both auction and fixed price sales. Details of the bidding subsystem our outside the scope of this paper but Section 4.2 contains the usability perspective.

 

From the auctioneer’s/seller’s perspective the auction process consists of six steps: registration, catalog setup, auction setup, auction closing, capturing and processing orders, and payment/fulfillment. The seller’s auction process could have been segmented differently, but the chosen segmentation simplifies the integration of the two auction related processes, auction setup and closing, with the remaining four auction support processes, which are also common to fixed price selling. The catalog setup process is modified so that when describing a product, the seller can specify that the product will be sold through an auction. At the close of the auction the winning bids are captured as orders.

 

The key components of the bidding process are rules governing minimum increments on bid values and quantity bid on, the information about the competing bids that is visible to all bidders during and at the close of auction, and rules/penalties for withdrawal of bids. The two key components of the auction close process are choosing the time at which auction closes and determining the payment to be made by the bidder. The auction closing can depend on a combination of specified deadline and the level of bidding activity. The payment made by the winning bidders is not necessarily the bid they place. Various policies for determining the payments made by the winning bidders and their rationale is discussed in [3] and [4].

 

In our implementation we standardized the interfaces for the above-mentioned components and provided multiple implementations for each of the components. At the time of auction set up the auctioneer can choose the implementation of the individual components individually, barring some combinations that do not make sense. This gives the auctioneer access to a wide variety of auctions.

 

An important point to be made about our implementation of auctions is that each product on auction can have its independent set of auction rules. This enables the auctioneer of different products to choose the set of rules that are best suited for that product and its current market condition.

3              Managing Bids in an Internet auction

Real world open cry auctions typically last for minutes. On the other hand the Internet auctions can continue for days.  In real world, the auction houses provide agents to bid on behalf of bidders who cannot or choose not to attend the auction in person.  Due to the long duration of Internet auctions, the need for bidding agents is exacerbated.  In this section we discuss the implementation of proxy bidders, the software agents that bid in an auction on a human bidder’s behalf. To setup a proxy bidder a human bidder has to specify his maximum willingness to pay (per unit), the quantity, i.e., the number of units desired, and whether the bid is indivisible.  We discuss the problems with straightforward implementations of proxy bidders and propose an efficient implementation of proxy bid agents. 

 

The problem with straightforward implementations of software proxy bidders is that they react too fast and can place a large number of bids before any human participant in the auction gets a chance to react.  On one hand this may preclude many human participants from getting interested in the auction, i.e., in getting emotionally involved, because the proxy bids would have pushed the bids to high levels at the very beginning of the auction.  On the other hand human participants are likely to give jump bids at the beginning of the auction when the bids are low while the software agents will blindly give bids with minimum increments flooding the bid table.  The problem with flooding the bid table has performance consequences.

 

The approach to solving the above problem is to compute the equilibrium position a set of proxy bidders will attain after their bidding frenzy.  Then we can simply have each proxy bidder submit his final bid.  This equilibrium will be disturbed as a human participant places a new bid.  However, once again, the proxy bidders can place their equilibrium bids rather than getting into a bidding war.

 

We assume that both the regular bids and proxy bids are indivisible. If partial fulfillment is allowed, or minimum fulfillment is specified then the situation can be handled by treating the bid as multiple bids for unit item or a bid for minimum acceptable quantity followed by multiple unit bids. In the following description unless specifically mentioned whenever we say, “bids” we imply both the regular bids and proxy bids.  We chose a greedy implementation for determining the winning bids for the product.  While Knapsack algorithms would have provided higher revenue on occasions, most of the potential users advised us that the loss of revenue was preferable to the headache of explaining the Knapsack algorithm to irate bidders (However, since the implementation is modular, optimal algorithms can be incorporated at any time). 

 

Without proxy bidders the greedy algorithm to determine winners in the auction is simple.  The set of bids is arranged in the descending order of per-unit bid value (ties broken based on the policy specified in the auction rules, likely policy being bid quantity and bid submission time), bids are scanned from the high bid value and supply allocated when possible.  The scan continues until the supply is exhausted, or we reach the end of the bid list. The bids that receive their allocation are winners.

 

With proxy bids present in the mix of bids, the winner determination algorithm is modified as follows.  The list of bids is once again ordered in descending order of per-unit bid value. The bid value for proxy bids is the maximum willingness to pay (ties once again resolved by rules governing priorities of regular bids and proxy bids). This ordered list is then traversed accepting bids until a bid is encountered that cannot be allocated fully. An example of such a situation is shown in Figure 2(a) where we show an ordered list of bids (b₁, b₂, …, b_x) and b_x is the first bid that could not be allocated fully. It is easily seen that the list of bids up to b_x (with the exception of b_x, of course) are winners.  We call this winner list W_x.

 

Figure 2: The Proxy Bidding Method

 

 

A key observation at this point is that the proxy bidders of bids in W_x have to collectively win enough quantity to dislodge bid b_x, and therefore, proxy bidders of some bids in W_x need not bid higher than b_x. We select a subset, W_x, the subset of proxy bids from W_x that have collective bid for largest quantity strictly less than q_x, the shortfall of b_x. There are numerous selection criteria for W_x:

1.      Select proxy bids that accept partial quantity,

2.      Select proxy bids based on time of posting, or the maximum willingness to pay,

3.      Select a subset of proxy bids that minimize revenue lost.

 

The proxy bidders of remaining proxy bids in W_x - W_x have to match the per-unit bid value of b_x if b_x is a regular bid, or match the maximum willingness to pay of b_x if b_x is a proxy bid. Thus the proxy bids in W_x - W_x bid an increment higher than b_x to dislodge b_x (see Figure 2(b)), or in other words to preclude being dislodged by b_x. If any proxy bid in W_x - W_x does not beat b_x then b_x will be a winner.  It is assumed that bids in W_x-W_x have a higher priority than b_x so they can dislodge b_x by matching its bid value.

 

The above step is then repeated for the remaining bids including bids in W_x and the remaining unallocated quantity. This process continues until we have either exhausted looking at all the bids or the remaining auction quantity becomes zero.

 

The above model of a proxy agent assumes that the auctioneer can be trusted by the buyer, otherwise in a non-trusted auction the buyer may prefer to implement and execute his own bidding agent, given that the bidding agents hold information that could be used to the advantage of a non-trusted auctioneer (See Ungar, et al [11]). Some of the prominent sites that have bidding agents are ebay.com and amazon.com.

 

4              Usability Features for Internet Auctions

In this section we first discuss the usability issues in auction software from the auctioneer’s perspective.  As the software becomes more flexible, allowing a wide variety of auction styles to be used, the auctioneer’s task of specifying the complete set of rules for an auction becomes more arduous.  The multiple levels of interface for the auctioneers discussed next help in meeting the needs of both groups of auctioneers, those looking for a simple format and those looking to fine tune their auction process.  Internet also creates nuisance for bidders, the nature of and solutions for which are discussed in the second half of this section.

 

4.1             The Auctioneer Interface

The auctioneer interface has three components. The first one is to allow the auctioneer to navigate the products in his catalog and select the ones he wishes to auction.  It is a simple extension of the catalog interface.  The second one allows the auctioneer to monitor the progress of the various products he has on auctions.  These two are quite straightforward and are not discussed further.  In this section we discuss the interface needed to schedule an auction for a product the auctioneer has selected from the catalog. This entails specifying the rules for the auction. As we mentioned in section 2, each product on auction can potentially use different auction rules, the ones best suited for that product.  Furthermore, the set of rules is rather large because of the support for a wide variety of auction styles and their variations.  Consequently, the single panel interface implemented in the first try was quite complex and most frustrating to the programmers pretending to be auctioneers who tried the system out.  Two lessons were learned from this first exercise, we needed to address auctioneers with different levels of sophistication and we needed to provide for previously defined rules for auction.

 

4.1.1           Named rule sets for bidding rules and named auction templates

Rules that define the criteria for accepting a new bid in an auction are an important and significant part the auction rules.  They usually include minimum bid value (per unit), minimum bid quantity, and minimum increment in bid value or bid quantity.  The bid or quantity increments can be a function of the bid or quantity ranges.  Bidding rules are instituted for orderly operation of auction the process and the choice of bid rules usually depends on the level of bidder participation, duration of the auction.  They are usually not impacted by the pricing policy, rules for choosing the time to end the bidding phase, and rules governing withdrawal of bids, etc.  Consequently, a set of bid rules can be used across many auctions and we chose to maintained named sets of predefined bidding rules that can be used across multiple auctions.  Choosing meaningful names for the bidding rule sets is expected to simplify the life of auctioneers.

 

Bidding rules are a part of the auction rules.  A complete set of auction rules can be reused for repeated auction of the same or similar product in similar business conditions.  Hence we chose to maintain named templates for predefined sets of complete auction rules.  As explained next this was also helpful in handling auctioneers with different levels of auction knowledge/experience.

4.1.2           The three levels of auctioneer interface

The following three levels of auctioneer interfaces were created:

1.      Fast auction set up:  This was the simplest interface intended for a person with no auctioneering knowledge.  In this panel the auctioneer was expected to specify the product and quantity on auction, closing date and time for the auction, and the name for the template for the auction rules.  Optionally he could specify the start time of the auction, the default value for which was the current time.  We expected sales mangers of an organization to exercise this interface. The initial implementation of auction software shipped with three basic templates, default open-cry, default sealed-bid, and default Dutch.  All templates would ultimately be derived of these three basic templates.

2.      Modify rules interface: This interface exposed only selected fields of each basic template, and was intended for sales people with some knowledge of auctioneering.

3.      Custom auctions: The final interface exposed all the knobs and dials that could potentially be set.  This interface was intended for use by auction experts consulting for the auctioning organization. The consultants are expected to define one or few named templates to meet the auctioning needs of the organization.  Named auction templates could be defined only from this interface.

4.2             The Bidder Interface

Figure 3 shows how the bidders navigate the auction web site in the auction implementation. Each bubble shows a web page and arcs from one page to another indicate that a hot link is available from the first page to the second. The seven pages marked with asterisk can be accessed any time from the side bar. The auction site URL puts a bidder on the Welcome page from where a registered user can authenticate himself to the web site and initiate a secure session (login). An unregistered user will get the opportunity to fill in a registration form that may be processed online or off-line. After registering, the bidders can browse through or search the products in the auction site, which will possibly result in a product being selected, and its description presented to the bidder. If the product is on auction, the rules of auction can be viewed, and bids can be submitted for that product.

Figure 3: Bidder Navigation Process

From the home page the bidder can also see a list of all auctions at the auction site or a subset of these that are in his personal auction gallery (See Figure 4). An auction gets added to a bidder/shopper’s auction gallery when the bidder explicitly takes an action to do so from certain auction pages, or implicitly when the bidder places his first bid.  From both lists, all auctions or auction gallery, the bidder can select an auction and access the description of the product being auctioned, see the rules of the auction, or bid on the product. For open cry auctions he can also see a subset of the previously submitted high bids for that product. In both these lists, the entry for an auction also includes the auction type, quantity being auctioned (if the rules permit), best bid or current asking price for open cry and Dutch auctions respectively, and auction closing time if determined.

 

From the list of high bids for a product mentioned above, a buyer can increase his existing bid, submit a new bid, and review the auction rules or access the product description. Similarly, from the home page a buyer can access the list of all his bids and perform the same functions. Finally from the home page a buyer can access his mailbox that contains all the notifications sent by the auctioneer to the buyer.

 

Figure 4: "Auction Gallery" of a user

4.2.1           Notifications in the Mailbox and via Email

In a web based application there is no way for the auction server to push information to a bidder unless the web page that the bidder is viewing currently has an applet with a listening socket open or the client sends a request for some information. To circumvent this problem we created a mailbox on the server side. Any message that the server creates for a bidder, for example that he has been outbid, is placed in the mailbox.  There is a flag associated with the message indicating whether the user has seen  the message or not.

 

On every web page related to the auction software, preferably on every page belonging to the auctioneer’s site, an icon is put in a small frame in the sidebar.  This frame is refreshed periodically, perhaps every few minutes. The icon indicates whether there is an unread message in the client’s mailbox and also serves as the hotlink to the web page, which is the interface to the mailbox.

 

E-mail is necessary to communicate with buyers who are viewing one of the auction site pages when a message needs to be delivered to them.  Mailbox is more convenient for those who are on the auctioneer’s site when the message is to be delivered. If a mailbox message is not read from the mailbox within a pre-specified time, the message is sent to the user through e-mail.  In  the future, the frame containing the mailbox can be replaced by an applet programmed to receive notifications sent by the server

4.2.2           Server Clock

It is quite likely that the system clock on the bidders client computer differs from the system clock on the auctioneer’s server by a few minutes.   This will create discrepancies in enforcement of deadlines such as deadlines for receiving bids.  If the bidder’s clock is tardy, for a bid submitted at the last moment by the bidder, the bidder will think that he submitted the bid in time while the auctioneer will reject it as being late.  To prevent such discrepancies the server clock is shown on each auction web page. This is achieved by reading the server clock value periodically, actually in the same step as checking for unread messages from the server, and maintaining the time difference with the server.  This time difference, updated every few minutes, is used to interpolate the server time value and display it on the client screens.  Clearly the server time displayed on the client will lag by the variable round trip time from the client to the server and back.  However, we expect this delay to be sub second, substantially smaller that the discrepancy of several minutes between the client and the server. 

 

4.2.3           Discussion Forum

Discussion forums are needed by the auctioneer to view and respond to queries/messages from shoppers regarding an auction. The administrator can also use these forums to provide shoppers with extra information about the product on auction, auction rules, or future auctions. For auctions to be fair all bidders must have identical information from the auctioneer. Therefore in the discussion forum all the answers or clarifications given by the auctioneer are visible to all the bidders. To prevent collusion the messages from bidders are posted only if the auctioneer deems them to be relevant to the auction.  In our auction implementation, each auction has its own discussion forum.

5              Conclusions and Future Research

Auctions are a mechanism to discover price or negotiate price.  However, settling price is one step in the process of buying or selling a product or a service.  In this paper we discussed an implementation of auction software that implements the price determination step while using the services of existing commerce software for remaining steps. 

 

Much of previous research on auctions has focused on allocation efficiencies, maximization of revenue, and other such economic aspects of auction implementation.  Our own interactions with many potential customers clearly indicated that ease of use from bidders perspective is by far the most desirable property of the auction software, followed by ease of use for the seller/auctioneer.  Ultimately, doing auctions on Internet is about reducing cost of conducting the auction.  For businesses that plan to use auctions regularly, improving the price on a product sold by a small percentage through use of sophisticated auction rules is far less important customer retention.  Complex auction processes run the risk of frustrating bidders who are then likely to switch site loyalties, a bigger loss for the merchant than losing a fractional or a few percentage points.

 

Internet makes a very large number of bidders to participate in auctions.  Auction opportunities have been conceived by businesses where bidder participation can call for handling several thousand bids per second.  Current auction software processes one bid at a time and stores the result in stable storage, i.e., a database table before moving on to the next bid.  This implementation approach has to change, and caching techniques have to be developed to support large auctions.

 

Finally, Internet auctions simplify the task of consolidating data, bids and final selling prices, from past auctions in electronic form.  This data can be analyzed to provide valuable decision support to the sellers and buyers.

6              References

 

[1]               Cassady, Ralph (Jr.), “Auctions and Auctioneering,” Reading, Univ. California Press, Ont. 1979, ISBN 0520002164.

[2]               Kagel J. H. and A.E Roth, “The Handbook of Experimental Economics,” editors J.H. Kagel and A.E. Roth, Princeton University Press 1995, ISBN 0-691-04290-X.

[3]               Kumar M. and S. I. Feldman, “Internet Auctions,”   http://www.ibm.com/iac/papers/auction_fp.pdf, 1998.

[4]               Kumar M. and S. I. Feldman, “Business Negotiations on the Internet,” In Proc. Inet'98, Geneva Switzerland, 1998.

[5]               Lee H. L. and T.H. Clark, “Impact of the Electronic Marketplace on Transaction Cost and Market Structure,” International Journal Of Electronic Commerce, Vol. 1 No. 1, Fall 1996, pp. 127-149.

[6]               Lucking-Reiley David H., “Auctions on the Internet: What's Being Auctioned, and How?” Journal of Industrial Economics, September 2000, vol. 48, no. 3, pp. 227-252.

[7]               McAfee R. P. and John McMillan, “Auctions and Bidding,” Journal of Economic Literature, Vol. 25 No.2, June 1987, pp. 699-738.

[8]               Milgrom Paul, “Auctions and Bidding: A Primer,” Journal of Economic Perspectives, Vol. 3 No. 3, Summer 1989, pp. 3-22.

[9]               Milgrom Paul and R. J. Weber, “A Theory of Auctions and Competitive Bidding,” Econometrica Vol. 50 No. 5, Sept. 1982, pp. 1089-1122.

[10]           Turban Efraim, “Auctions and Bidding on the Internet: An Assessment,” International Journal of Electronic Markets, Vol. 7 No. 4, http://www.electronicmarkets.org/.

[11]           Ungar Lyle H., David C. Parkes and Dean P. Foster, “Cost and Trust Issues in On-Line Auctions,” In Proc. Agents'98 Workshop on Agent Mediated Electronic Trading (AMET'98). Minneapolis/St.Paul, MN. May 10, 1998.

[12]           Wurman P. R. and M. P. Wellman, “Real-time issues in Internet Auctions,” In First IEEE Workshop on Dependable and Real-Time E-Commerce Systems (DARE-98), Denver, CO, USA, June 1998.

[13]           Wurman P. R., M. P. Wellman, and W. E. Walsh, “The Michigan Internet AuctionBot: A configurable auction server for human and software agents,” Second International Conference on Autonomous Agents, pages 301-308, May 1998.

[14]           Wurman P. R., M. P. Wellman, and W. E. Walsh, “A parameterization of the auction design space,” Games and Economic Behavior, volume 2000.