Tired of losing potential sales because your Web implementation is overly complex? You can avoid a number of common traps with a little vigilance.

Economics teaches that the volume of commerce is inversely correlated to the degree of friction imposed on a particular transaction. If you haven't factored customer friction into your commerce Web site design, you're losing money. In Internet terms, requiring that customers navigate through extensive forms defeats the most spohisticated Web site design. Many customers simply give up mid-transaction and take their business to another site with less bureaucratic overhead. Avoiding customer friction requires a technical solution that lets you retain customers from registration through payment processing.       First, let's define what customer friction means to customers and Web site developers. Customer friction represents the obstacles presented to a customer to register, browse, or purchase products online. For customers, friction includes the following inconveniences: Complicated registration requirements Inconsistent purchase experiences across sites Numerous "identities" (passwords and preferences) to establish and maintain at multiple sites Different payment methods at different Web sites       By the time the customer arrives at the payment and address forms to purchase a product, there might be significantly less inclination (not to mention less time) to complete the purchase.       Smoothing customer friction across the Web site entails that the Web developer: Streamline information gathering from the client Provide online customer service Simplify the registration model and maintain a common identity for customers across multiple sites Maintain a common payment metaphor       I'll focus on minimizing the most common element of customer friction: tracking customer information such as addresses and payment techniques. I'll establish context for the business problem by reviewing the e-commerce marketplace. I'll explain the facets of customer friction as a business problem. Then I'll evaluate the pros and cons for the two main technical solutions to tracking customer information: electronic wallets and cookies. The Market       To gauge the impact of customer friction, it is essential to understand the recent and projected growth for Internet commerce. Once just a trendy buzzword for industry pundits, e-commerce has rapidly grown into a viable, profitable channel for hard goods and digital content. Take a look at Web sites for companies using the Internet as their sole or main channel, like Cisco, Dell, Amazon.com, and Egghead. Along with rapidly increasing revenue comes a flood of new companies offering everything from fraud detection to digital signatures.       The flexibility of Internet commerce business models translates into interesting (and growing) revenue. The first Internet commerce products hit the market around 1996. Early adopters of e-commerce used the first versions of products like Microsoft® Merchant Server (now the Commerce Edition of Microsoft Site Server) to start building Internet stores. As these early versions of commerce servers quickly improved, more vendors of various size (and products) began implementing Internet storefronts. By 1998, some of the companies like Egghead had switched entirely to Web-based merchandising and closed their traditional stores.       A recent study by Jupiter Communications pinpointed the value of electronic commerce transactions in 1996 at $12 million. The study projects that by the year 2000 the value of electronic commerce transactions will rise to approximately $2.16 billion (see Figure 1).       It doesn't take an industry expert to see that this kind of growth will continue to rapidly increase. Consider the hardware used by the customer base for Internet commerce: computer prices continue to drop as modems and connectivity options speed up. Although users remain restricted by the limited bandwidth of a 28.8 Kbps modem, this is still a clear improvement on the 14.4 modems that pervaded the Internet marketplace two years ago, making your graphics-intensive e-commerce site that much easier to browse. Other solutions, from ISDN and ADSL to cable modems and satellite delivery, are becoming more common in households. The Business Problem       Let's examine the facets of customer friction as a business problem. As I mentioned earlier, customer friction spans the general obstacles to browsing and purchasing across sites to specific impediments like a site's convoluted registration page. First of all, let's establish that buying hard or digital goods on the Web will always require a certain level of information from consumers. Otherwise, the fraud margins for Internet commerce would be extraordinary. It's really the ability to find the right level of customer friction that differentiates the successful Web site vendor from the rest.       To appreciate the effect of customer friction on Web site revenue, it's important to understand the scope of Internet commerce revenue as a whole. Because of its distribution and presentation flexibility, Internet commerce appeals to many different kinds of markets. Hard-goods vendors (like Amazon.com) use the Internet as a marketing and order-processing center while the product is distributed through a traditional order fulfillment process. These hard-goods vendors can increase profit margins by decreasing the cost of marketing and taking orders from a broader customer base. Hard Goods, Digital Goods       Hard goods represented the first kind of product in the e-commerce arena. Companies selling everything from flowers to books to CDs wanted to find a more efficient and scalable channel than traditional stores. The vendor took customer information and payment methods through the Internet, and started the purchase down the established assembly line of order fulfillment.       Digital goods—any product whose content is sold and delivered over the Internet—continue to gain ground in the Internet marketplace. Software, streaming video, access to games, daily newspapers, analysts' reports, database searches, information services images, graphics, subscriptions, and even product support are all part of this new market.       The margins for digital content are quite high since the vendor spends no money to manufacture and deliver each additional product sold. This is very different from hard goods where each sale implies manufacturing and distribution costs. For digital content, no inventory monitoring is required since selling the product does not diminish supply. The vendor collects payment on purchase, cutting down on fraud and false remittance. Most importantly, digital goods provide customers with immediate access to the product they purchase. Friction in Business-to-Business Sites       Internet commerce sites are divided into business-to-business sites and business-to-consumer sites. Each type of site carries a different set of challenges for customer friction. For business-to-business sites, the customer is the employee who uses the site to perform some portion of his or her business workflow.       In developing a business-to-business site, your key problem is successfully integrating with another system. Merging the two business flows without disrupting processes like invoicing, auditing, and bill remittance ranks as the top priority. The complexity of the site increases with the level of integration between the two workflows. Business-to-business site developers tend to focus on ease-of-use issues rather than customer friction. Ease of use for business-to-business sites is measured in the learning curve for training on the site and the facility of deployment. Unlike customer friction, ease of use does not represent a streamlined process for the user.       Yet despite the complexities of building a business-to-business site, it can often be easier because you know your audience. As the developer of the site, you get to specify the required browser, ODBC driver, or other environmental variables. In addition, you can assume that the employee (or at least someone in the management chain) using the site has some training. You should factor in customer friction during the design of your page flow since the business-to-business site that allows users to be the most efficient is the most marketable. In the business-to-business world, cutting down on customer friction reduces the amount of time spent on unnecessary screens and increases user efficiency. Friction in Business-to-Consumer Sites       Business-to-consumer sites are presented with the classic challenge of how to draw the customer into the store, offer an engaging product, and persuade the customer to go through with the purchase. The marketing of the store and product represents a different (but related) topic of pitching product on the Internet. It is arguable, though, that the most important piece is actually getting the customer to go through with the purchase. Unlike business-to business sites, business-to-consumer sites have to worry about perceived rather than known customers. For this kind of transaction, you do not know much about a customer entering the store beyond the fact that they have access to the Internet. You do not know how familiar they are with buying products online, their tastes, or even if their credit card is good. As a result, you're often working in the dark when determining exactly how many registration, customer information, or purchase screens the customer will put up with before leaving the site.       Two main causes of customer friction are fear of disclosing personal or credit card information over the Internet and irritation with filling out HTML forms. Through reassurances ranging from sources such as the Presidential Commission on Global Commerce (established in 1998) to credit card companies, the fear of disclosing payment information online is slowly dissipating. However, the frustration with endless HTML forms remains. A vendor trying to gather information about a customer may inadvertently require a customer to fill out six or more forms, including registration, address information, a demographic survey, order information, payment information, and shipping information. With that many fields to fill out, the consumer may leave the store without finishing the purchase process. CyberCash, a payment vendor, reports that 20% to 50% of all customers stop the purchase midway through the process.       Customer friction refers to the entire experience, from entry to customer support. For example, a company called IBill provides Internet billing solutions for companies creating commerce on the Web. Although the company offers to process credit card, 900 number billing, and product sales transactions, the service still maintains a level of customer friction. In order to complete a transaction, the consumer must dial a 900 number. If the consumer has only a single phone line, the consumer must disconnect from the Internet to use the phone.       So what is the ideal level of customer friction? A Web site with a minimal amount of customer friction maintains a history of the client's purchases for a customized shopping experience, provides an online knowledge base for the customer to research technical problems, a forum for customer disputes, and minimal forms for entry and purchase. These features can be broken down into three categories: registration, payment, and customer support. So far, no one product I've seen has addressed all these issues in one automated package. Electronic Wallets       There are several technologies available today to smooth customer friction. As I mentioned earlier, I'll focus specifically on tracking and using customer information for registration and payment.       At the heart of the technical problem in customer friction lies the stateless nature of HTTP. To maintain state on a Web site, you must provide alternate ways to store the client data that you'll use to populate server-side databases and drive page navigation. Two technologies available for maintaining customer information on the client for Internet commerce are electronic wallets and cookies.       Microsoft began offering electronic wallet technology back in 1996, with CyberCash and Verifone following with similar offerings. To date, electronic wallets have not gained widespread acceptance.       A client wallet, in which the user stores address and payment information, provides several advantages. By offering a familiar and easy-to-use graphical interface, wallets add a friendly and familiar atmosphere to the purchase process. When the client visits a Web site that supports the wallet, the client can register at the sites and pay for products by simply opening the wallet and clicking the preferred address or credit card. The client does not have to fill out any forms. The wallet handles the transfer of the information from the client to the server, usually over HTTP with Secure Sockets Layer (SSL). Wallets are generally a free download. You might already have one, since the Microsoft Wallet is installed with Microsoft Internet Explorer 4.0.       Wallets have two main problems. First, using a wallet requires a client download or install of the product that includes the wallet software. A download/install requirement causes customer friction of its own by adding an extra step to the purchase process and extra bits to a client's hard drive. Downloading the wallet could also require extensive (and expensive) customer support if the wallet doesn't integrate smoothly with the user environment. Customers are also restricted to purchasing from the computer storing the wallet.       On the server side, the commerce site must support the wallet for a customer to take advantage of it. A good number of sites already support the main wallet implementations. However, the dependencies on server support and client download reduce the benefits of the wallet to a specific subset of consumers. Since wallets are not supported across all Web sites, customers don't know if they can use their wallet at a site until they reach the point of purchase. Even if you integrate support for multiple wallets onto your commerce site, you still need to find a way to reduce customer friction for non-wallet carrying customers.       One of the central issues with online products generally and electronic wallets specifically revolves around Secure Electronic Transaction (SET) payment support. SET represents the Holy Grail of payment security on the Internet. SET integrates digital certificates to verify the identity of all parties in a payment transfer. Security pundits have lauded SET as the common standard for security, even though SSL technology has always provided a perfectly robust security layer on top of HTTP. The slow negotiations for the protocol, lengthy tests, and prediction of slow adoption continue to retard SET momentum. Recent moves among payment vendors like CyberCash and PaymenTech indicate a swing away from SET-based wallet transactions and toward SSL as the security protocol of choice. Cookies       Opinions vary widely about the safety and intrusiveness of cookies, but very few can argue with their convenience. Cookies are simply text files containing customer-variable information that reside on the client's hard drive. Cookie data contains information gathered while the user navigates through the site. Data ranges from a history of the pages a user has visited to personal information entered once in HTML forms. Cookies do not contain any information that has not already been provided by the user in a form or navigation path. Each site generates its own cookies. If an airline provides a cookie during a ticket purchase, an on- line music store cannot access that cookie and read that cookie's data when the user visits the new site. You can write cookies to a client hard drive using DHTML or through Active Server Pages.       Before cookies came along, developers tracked user session state through hidden fields and/or URL variables on a page. That's not a very elegant solution. With HTTP cookies, Web-based applications can store information about selected items, user preferences, registration information, and other useful data. Cookie technology also provides developers with a certain level of flexibility. Developers can specify an exact expiration date for the cookies, for example.       Cookies without expiration dates live on the user's hard drive until they're manually deleted. The next time that the user connects to the site that provided the cookie, the Web site reads the information stored in the cookie. If the cookie contains registration information, the user enters the Web site without filling out registration forms. If the cookie contains address or payment information, the user can conduct the purchase process quickly, since the server can read cookie information directly into address and/or payment fields. Best of all, the user does not risk manual entry errors and the need to restart the entire purchase process because of a misspelling in a form.       If you want to see what a cookie looks like, check the Cookies folder of your operating system folder. Cookie names usually consist of a name or an anonymous moniker and the Web site name. You can read the cookie data in any text editor.       The bad rap that cookies have as security risks is quite simply overexaggerated. Cookies do not go near the registry or other sensitive areas on the user's hard drive. Nor do cookies access programs or collect information that is locally stored. They're text files. If you're worried about the ethics of writing a cookie file to a consumer's computer, remember that most browsers have a setting to reject cookie download. And weigh the benefits of a streamlined user experience against the inconvenience of a small text file quietly living in a consumer's Cookies folder.       Cookies depend on two HTTP headers: Set-Cookie and Cookie. The server sends the Set-Cookie header when serving up an HTTP request. The client application sends the Cookie header as part of the HTTP request. The actual manipulation of cookie data is performed by the server site to facilitate registration or payment.       When the server processes an HTTP request, the Set-Cookie response header uses the values shown in Figure 2. When the client requests a page from a server site, the Cookie header is included with any HTTP requests that have a cookie whose domain and path match the request. The Cookie header has the same value format as the Set-Cookie header. Cookie Access Utility       Since browsers predating the HTML 2.0 standard do not support cookies, cookie-enabled sites will not be able to provide cookies to users with older browsers. To solve this problem, Microsoft created a utility called the Cookie Munger to provide cookie support for browsers that do not support cookies or have cookies turned off. (Find it at http://msdn.microsoft.com/workshop/server/toolbox/cookie.asp.) You can use this kind of utility to extend cookie support in your customer base.       Cookie Munger is an ISAPI filter that munges outgoing HTML and incoming HTTP transactions to simulate cookies and maintain session state. Since Active Server Pages uses the ASPSESSIONID cookie for session state, the ASP engine expects the browser to send this cookie with HTTP requests. If the ASPSESSIONID cookie is not sent, ASP cannot tell user sessions apart and therefore cannot reliably update the Session object.       The Cookie Munger operates by accepting client HTTP requests for a particular URL. If the headers of the request contain a "Cookie: ASPSESSIONID=xxx" header, the Munger records the ASPSESSIONID. If the URL contains an encoded ASPSESSIONID, the filter generates a Cookie header and removes the ASPSESSIONID from the URL. So when the ASP serves a page, the Cookie Munger replaces Set-Cookie headers with ASPSESSIONIDs and "munges" any local URLs embedded in the page.       The Cookie Munger facilitates cookie use across multiple browsers, which in turn means a wider customer base. Keep in mind, though, that this utility might affect the performance of your Web server. As a filter, the Cookie Munger intercepts all HTTP requests and filters all outgoing ASP data. The filter does not let you configure for a per-browser basis or on a per-user basis. Cookies Using the DHTML Object Model       If you want to store user attributes using browser client code, use DHTML to read and write values in cookies. The DHTML object model offers a cookie property on the document object. You can use the document object to retrieve information about an HTML document, manipulate the HTML elements and text within the document, and process events. Retrieving the object is simple; you just apply the document property to a window or an element object.       The cookie property on the document object specifies a string property. The cookie property has read-write permissions and a simple syntax:

object.cookie = cookie

To determine the value stored in a cookie, you can use string methods such as substring, charAt, indexOf, and lastIndexOf.       The document object also provides a CookieEnabled property for determining whether client-side cookies are enabled in the browser. CookieEnabled is a read-only property that is TRUE if cookies are enabled in the browser or FALSE if not. Cookies Through Active Server Scripts       If you are using ASP, you already maintain session state in the Session object. ASP expects a browser to send the ASPSESSIONID cookie with every request it makes. Without it, ASP does not know which session the user owns, and cannot keep the Session object up-to-date as the user moves from page to page.       The ASP state model extends to cookies. ASP developers use the Cookies collection on the Response object to retrieve values of the cookies sent in an HTTP request. You can manipulate the cookies collection using the arguments shown in Figure 3. You can iterate through the cookies in the Cookie collection, or all the keys in a cookie. (Iterating through keys on a cookie that does not have keys will not produce any output. )       The IReadCookie interface lets you retrieve the values stored in the read-only Cookies collection. To get the IReadCookie interface, call the get_Item method on the read-only Cookies collection. This interface offers three methods to read data from cookies (see Figure 4).       If you have an IReadCookie or IWriteCookie pointer, you can use the QueryInterface method on an IWriteCookie or IReadCookie pointer (respectively).       The following script demonstrates how to use the IReadCookie interface to find and retrieve a cookie given at a fictional Web site:

public interface asp.IReadCookie extends com.Mailan.com.IUnknown { //Methods public abstract com.Mailan.com.IUnknown get_NewEnum(); public abstract boolean getHasKeys(); public abstract com.ms.Mailan.Variant getItem(com.ms.com.Variant); }

The IWriteCookie interface lets you modify the values and attributes of the cookies stored in the write-only Cookies collection (see Figure 5). The IWriteCookie and IReadCookie interfaces support both IUnknown and IDispatch interface methods. Smoothing Customer Friction       Customer friction represents a significant business and technical problem for commerce Web site designers. Consider how much customer friction your consumers will tolerate. You also need to consider the complexity of information requirements for logon or payment purchase. If authentication or payment requirements include multiple screens of user entry, implement a helper technology like cookies. Choose the technology that integrates the most smoothly into your site, whether it's DHTML or ASP scripting.       In the long term, new companies are emerging with solutions that reduce the customer friction obstacle to Internet commerce by providing customers with a common identity and purchase process across sites. Until those services are in place, you'll have to work with the tools available to retain customers from registration to purchase. Successfully managing the level of customer friction can increase your customer retention rate and revenue rates in parallel with your site's hit counter.

http://msdn.microsoft.com/workshop/essentials/forstarters/starts071798.asp http://msdn.microsoft.com/workshop/essentials/wteched98/commerce.asp From the January 1999 issue of Microsoft Internet Developer.