From the May 2000 issue of MSDN Magazine This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links. .gif) B2B Frontiers in E-Commerce: Implement Affiliate Programs to Create New Partnerships and Generate Business | | Ted Coombs | | This article assumes you're familiar with ASP and VBScript | | Level of Difficulty 1 2 3 | SUMMARY Like the Internet itself, e-commerce is evolving. Today's e-commerce companies are allowing their customers to plug into existing catalogs and ordering systems, creating new synergistic relationships. Some companies are even adding real-time chat with customer service personnel.
This article gives you an overview of some of the new e-commerce concepts and implementations that are helping forge those new relationships with customers, vendors, and shipping companies.
The importance of these relationships, as well as the specific technologies used to encourage communication and collaboration are discussed and illustrated with representative code samples. | | commerce can mean many different things. Sometimes it's simply a list of products on a Web site as a reference for people to order by phone, fax, or e-mail. Other times it's an innovative shopping mechanism that creates new relationships with customers, vendors, and even parts of the company that fulfill orders and manage finances. However, advanced e-commerce means more than simple order taking. It uses Internet technology to create relationships and automate processes that were previously not possible in any realm.
One such innovation in e-commerce is the affiliate program. Affiliates are extended business partners. Just as there can be many levels and types of business partners, there can be many types of affiliates. Implementing an affiliate program allows you to create new relationships with people who have a vested interest in your success—people like your vendors.
While creating personal relationships is important, one of the current goals of e-commerce is to automate the creation of that personal relationship as much as possible. One type of partnership that can be automated is a business-to-business partnership. Chances are you already partner with businesses like shipping companies to deliver your products. Automating this partnership makes life easier for you, and provides new services to your customers. This article takes a look at a few of the key e-commerce components that are necessary to create new relationships with customers, vendors, and groups within your own company, and how to implement these on your own server.
Partnerships through Affiliate Programs Affiliate programs are among the most important aspects of e-commerce. These programs build customer loyalty and involve others in your business by giving them a vested interest in helping your sales grow. How you choose to integrate an affiliate program is a key element to its success. There are ways to implement affiliate programs by doing very little; you can plug your site into a ready-made affiliate program and have it up and running in a matter of minutes. While this may satisfy your needs in the short term, it also limits you to the features provided by the service you select.
I recommend that you build the affiliate program yourself. It's not difficult, and the few extra hours of effort you put into it will immediately expand your possibilities for interacting with customers, forming new partnerships, and even developing complex, multilevel relationships. The architecture that you implement to provide your affiliate support should also be able to handle other types of partnerships.
At the simplest level you can implement an affiliate program by allowing affiliates to sign up, issuing them IDs and storing their information in a database or Lightweight Directory Access Protocol (LDAP) directory service. To allow your affiliates to sign up, create a Web form to collect the affiliate's contact information and store those values in a database or LDAP directory. (I've used an LDAP directory for the example provided here.) Create a unique identifier for your affiliateID and send your new affiliate their ID in e-mail, as shown in the code in Figure 1.
Once your new affiliate has signed up and included the affiliateID, simply accept it as a URL parameter in your store's Web page. Add the affiliateID to the shopping cart when a product is added, and eventually to the receipt when the product is purchased so that the affiliate can be credited at a later time with their expected percentage or agreed upon fee.
To implement this in an ASP-based store, I recommend creating an include file that's part of your store's Web pages. This file retrieves the affiliateID from the URL that is used to access the page. A sample URL might look something like this:
http://www.yourstore.com/default.asp?
affiliateID=3j43489dsfhkk3493
| You should be aware of how to construct a URL, but if you'd like the specifics you can refer to RFC 2068 (http://www.ietf.org/rfc/rfc2068.txt) to review the official documentation on the subject. Section 3.2.1 defines the general syntax of an HTTP URL.
Storing State The code to extract and store the affiliateID is placed in the include file to simplify coding. Begin by extracting the affiliateID from the URL using the QueryString method of the standard ASP Request object and storing the value in a variable.
affiliateID = Request.QueryString("affiliateID")
| Once your affiliateID contains the affiliateID of the referring affiliate, the value should be saved in some form of session state. You can use cookies, the ASP Session object, a database, and so on. The preferred method for Microsoft® Site Server is to use an LDAP server, a Personalization & Membership Directory, and Active User Objects (AUO). LDAP is the mechanism used to access the Membership Directory, and AUO is a simplified API for writing ASP scripts that access LDAP. If you're not using Site Server, you can still access an LDAP server with the Microsoft Active Directory™ Services Interface (ADSI) from within ASP scripts. You should also remember that ADSI is moving towards becoming a standard in Windows® 2000.
The advantages of using LDAP and AUO/ADSI to maintain session state are efficiency, reliability, scalability, manageability, and cost. Proprietary client/server databases normally charge high license fees for each client, each server, and for the database software development kit, while anyone can get LDAP and LDAP development kits for free. If there is no SDK that meets your specific need, remember that the LDAP specification is publicly available and you can write your own SDK. The same is not true of building your data access strategy using Oracle, Sybase, or SQL Server™.
Using cookies is not an option for storing session state because of the client's ability to turn them off. Moving all your session state variables around in URLs is an option, but it's ugly, cumbersome, and open to hacker manipulation. Storing session state using the Session object has the distinct disadvantage that these values are stored in the memory of a single Web server machine. If that machine goes down or the Web server fails, the session state is lost. In cases where load balancing is used and clients are redirected to other Web servers, the session state doesn't follow them around. Instead, a new session is created, losing the state information that was created previously.
A better option is to maintain the session values in a place where other servers can have access to them and the values will not be lost if the machine goes down or Web server software fails. One choice is to use a database. Even though this would mean that session state is maintained in a place that's both centrally accessible and nonvolatile, it's still not the best choice.
A much better way to store session state is with an LDAP-based membership directory. One advantage of using membership directories is that objects stored in the directory can be given a time to live (TTL) and can expire after the specified time. You could recreate this functionality using a database, but that would be less efficient. With LDAP, the session state can be stored in a RAM-based dynamic portion of the membership directory, increasing performance over database access. Both the membership directory and AUO are part of Site Server 3.0. For a complete description of using Membership and LDAP for managing session state see the article, "Using the Membership Directory and Active User Object (AUO) for Session State Data".
At the beginning of each ASP page of your store you should include the file that gets and stores the affiliateID.
if affiliateID <> "" then
sessionMember.affiliateID = affiliateID
sessionMember.setinfo()
end if
| To include a file named i_session.asp, add the following line outside the script tags:
<!-- #INCLUDE FILE="i_session.asp"-->
| So that the affiliates can split the commission, you can allow your store to accept multiple affiliateIDs. In this case, ensure that the attribute you use to store your affiliateID is multivalued, then change your ASP scripts to store arrays of values into this membership directory attribute.
affiliateID = Request.QueryString("affiliateID")
if affiliateID <> "" then ' delete then append to
' make sure ID is unique
on error resume next
sessionMember.PutEx 4,"affiliateID",Array(affiliateID)
sessionMember.SetInfo
on error goto 0
sessionMember.PutEx 3,"affiliateID",Array(affiliateID)
sessionMember.SetInfo
end if
| By building your own system, you can allow affiliates who add your products to their Web sites to shop using their affiliateID and also accept the commission, giving them a discount of sorts. Why not track the amount of traffic your affiliate brings to your site and reward them with a discount when their traffic is sufficient to warrant it? After all, an affiliate who cares enough about your products to sell them is probably your best customer.
In the membership directory where you store your affiliate's member information, add a multivalued attribute for storing visitor information. The visitor information attribute can store the session ID of the shopper and the number of unique hits on your site. Creating a membership record for your shopper allows you to keep track of important information such as the date and time of their last visit to your site. By selecting a session duration time (such as one hour), you can track unique visits as well as page hits.
Remember that your affiliates are your partners and they may want to create powerful e-commerce interfaces that are closely tied to your site. Your affiliate program should provide a powerful way for them to interact with your site and should operate like an API. When you publish your specification, you're making a guarantee that your API will never break. It's a good idea to state that explicitly in the instructions and documentation you provide to your partners and affiliates. You should also maintain strict versioning so that when you change things, your partner's site will not break. When you do make a change to your business interface, give your partners adequate warning and a justification for changing their sites. Be sure to support all versions until you have reached whatever deadline you've given your partners before retiring the previous version.
The partner architecture allows for more than one level of grouping. For instance, in my e-commerce architecture I have partners who are able to go further than affiliates in electronically integrating their business with mine. A partner can build their own storefront and integrate products with their own on their pages by retrieving product information directly from my catalog with directory service queries. They can also use my shopping cart mechanism to add products from multiple catalogs, and my payment processing system handles the distribution of payments to the right merchants. I call this a multiheaded store.
In a multiheaded store, you must build a filter for your query of the catalog that limits the products to those of the partner store. The catalog stored in the membership directory is then queried only for items belonging to the partner store (see Figure 2). The advantage to a partner program is that shoppers only see the partner's store, unlike other affiliate programs where they are taken to the server hosting the products. In this way, a partner can build an entire store of products from different catalogs and still have the shopper browse their store exclusively.
When the partner's customer gets ready to check out, they then go to your checkout counter. Here is where I have included the added feature of maintaining the appearance of the partner store by loading a template for the partner's store, including complete navigational aids. This exceeds some payment systems' attempts to maintain appearance by displaying the checkout counter using text and background colors sent as a parameter.
Even though the checkout counter's URL points to my secure server, I use the Internet Transfer Control (ITC) so the server makes an outgoing HTTP connection to the store. In my example, I've wrapped the ITC within an ActiveX® control, but you can create an instance of the ITC directly in your ASP code.
BillingURL = http://www.yourstore.com/pfitemplate.asp
Set inetobj = Server.CreateObject("ASPInetWrapper.ASPInet")
BillingPage = inetobj.OpenURL(BillingURL,0)
| In this example the file pfitemplate.asp contains the display, navigation, and any other features the merchant wants included on their billing page. The merchant can include a custom HTML tag (such as <PAYFORIT>), where he wants the billing form included.
The merchant can select this default or choose the ability to place particular form elements on the page by using additional custom tags. Once the template has been retrieved using the ITC and is stored in a string variable (such as BillingPage in the previous example), you can use string manipulation to locate the custom HTML tags and format the page the user will see.
billingtaglocation = instr(BillingPage,"<PAYFORIT>")
firstpart = mid(BillingPage,1,billingtaglocation-1)
secondpart = mid(BillingPage,billingtaglocation + 10)
Response.Write firstpart
| Using this architecture allows the partner merchant to maintain their relationship with the customer right through the checkout process—it gives the merchant complete control over the entire checkout process and over their store. The merchant can include custom processing, such as downloading files upon payment approval. This flexibility makes adding features such as instant messaging possible. Using a vanilla shopping cart and catalog system does not offer that kind of flexibility.
Integrating an instant messaging service such as ICQ or MSN™ Messenger allows you to draw people in to complete a transaction interactively. For example, your store may get an instant message like this: "I am on a small island and neither Airborne nor Federal Express delivers here. Can you ship using UPS?" The shopper can receive an instant response and continue completing their order. Fulfillment teams receiving instantaneous notification that an order has been completed can speed an order on its way.
Using ICQ as your instant message service, you can compose e-mail that is instantly sent as an ICQ express message. The e-mail is addressed to the ICQ number of the person, who will respond at pager.icq.com.
body = request.querystring("shippingcomment")
Set objeMail = Server.CreateObject("CDONTS.NewMail")
objeMail.From = "sales@yourstore.com"
objeMail.To = icqnumber & "@pager.icq.com"
objeMail.Subject = "A shipping comment has been entered."
objeMail.Body = body
objeMail.Send
Set objeMail = Nothing
| There are other instant messaging programs available, but ICQ has created its own API and made it simple for programmers to interact with ICQ from within their programs.
Forming New Partnerships Forming e-commerce partnerships is not limited to close relationships such as the one between merchant and payment processor. Giving your server the ability to make outbound connections to other sites allows you to use services provided on other Web sites, assuming the owners of the other sites don't object to it. There are an increasing number of services an e-commerce site can take advantage of, passing on new abilities to shoppers.
The key to making new services available to shoppers is to integrate them into the real-time shopping experience. To do this, Web servers must have the ability to contact other servers and query them for information. Giving your server this ability is not a simple task. The solution that immediately comes to mind is the ITC that I mentioned earlier. This simple ActiveX control, added to an ASP script, gives your application the ability to make outbound HTTP and HTTPS connections to other servers, returning the results as a string that's easily parsed by your ASP application. Unfortunately, using the ITC is ultimately an unstable solution. The ITC is not thread-safe, and is not recommended for use in a server environment. In a busy site, it will eventually fail. A better solution is for more companies providing services to build APIs that Web developers can use with the assurance that the interface will not break.
The UPS shipping cost calculator and the FedEx Web shipping API both serve as good examples of services residing on another site that you can implement with an API. Incorporating services like these into your own e-commerce site cements a business relationship between you and the shipping company that could not have previously existed in the same manner, and increases the services you can provide to your customers. Best of all, these additional services and relationships are completely automated and simple to add into your e-commerce program.
Payment Processing Another critical component of e-commerce is payment processing. If you are going to provide completely automated shopping from your site, you must form a relationship with a payment processing company. Because of the secure and complex nature of credit card processing, there are companies that specialize in providing gateways to credit card processors such as banks and other merchant card service providers. These companies provide APIs that allow close interaction between the merchant store and the payment processing system.
At the simplest level, the merchant provides order information to the gateway. The gateway company collects financial information such as credit card numbers from the customer using a Secure Sockets Layer (SSL) server, then transmits the credit card request to the card service company. The gateway company then relays the response from the credit card company (approved or declined) and any applicable transaction information back to the merchant store. The merchant store acts on the response, either confirming the order and beginning the fulfillment process or declining the order and allowing the customer to choose a different payment method.
Integrating a gateway service into an online store is usually painless. There are two possible ways that gateways will accept and process your order information. Some gateways, such as Cybersource, provide a component that plugs into your application. For users of the Microsoft pipeline architecture, this takes the form of a pipeline component. Other gateways, such as Echo Inc., have you build a string of name:value pairs and then send the string to a CGI program on the gateway using a secure HTTPS connection.
Pstr = "merchantid:12345, merchantpw:payme, amount:123.45," & _
"creditcard:visa, cardnumber:123456789101112, expmonth:12,
expyear:2000"
Result = inetobj.OpenURL("https://wwws.echo-inc.com/scripts/
INR200.EXE?" _ & pstr,0)
| In practice, the string you construct can become quite long. For example, in a real-life situation the previous string (Pstr) would also include the full address of the person submitting the credit card. (For an added fee, you can request address verification. This allows you to be certain that the address your customer entered is the one registered with the bank, which will cut down on credit card fraud.) Echo's service is more open than other solutions because you do not have to include a custom component in your program. This avoids platform conflicts.
Security is Critical to E-commerce SSL is at the heart of all e-commerce today. In most cases people rely on the SSL built into their secure Web server. Today, companies that want to develop SSL applications either have to purchase the incredibly expensive RSA license or use the Microsoft Security Service Provider Interface (SSPI), WinInet, the Java JSSE, or the SSL freeware called SSLeay.
SSPI gives developers a supported API that is part of the Microsoft Platform SDK for Win32®. It facilitates the creation of SSL-compliant code (as well as code that makes use of other encryption/authentication mechanisms and providers) without requiring any runtime fees or other special licenses to SDKs or encryption libraries like those sold by RSA and other providers.
SSPI is already part of Windows NT® 4.0 and Windows 2000, and a big improvement to the SSPI and its SSL provider were shipped recently with Windows NT Service Pack 4. Microsoft recommends that anyone who wishes to use the SSPI for SSL programming under Windows NT 4.0 apply SP4.
SSPI is also already installed along with Microsoft Internet Explorer 4.0 or later on Windows 9x. However, due to technical issues and some export restriction issues, Microsoft made it possible for developers to use SSPI on Windows 9x for authentication only, not encryption. You'll be happy to know that there is a patch currently under development that will be released for developers to redistribute with their programs. This patch will fix that hole in the SSPI for Windows 9x so that it can be used for coding SSL applications. Windows 2000 contains the fully functional SSPI because it is based on Windows NT technology.
If you want to use a free, supported, and legal SSL API/SDK, an alternative to the SSPI for developers working with Microsoft operating systems is WinInet. The WinInet API is only designed to be used from client programs. It is not supported for developers who build Windows NT-based software that is meant to function as a server or in conjunction with a server (such as in a CGI program or other server-side Web application logic). The WinInet API gives developers only high-level HTTPS functionality, and has some technical limitations and scalability problems that make it unreliable for server-side e-commerce development. But it's great for anyone developing a client program who wants a simple way to write SSL code for Windows.
The Big Picture New ways of forming relationships are being created in the industry every day. Technologies like XML are either updating EDI or replacing it as a means for companies to share business information. It's now possible to automate Internet applications so that every aspect of the transaction is automated: the catalog, payment processing, shipping, inventory control, and business interfaces with vendors.
Some companies, realizing that a completely automated system has removed the very important element of human interaction, are building in the ability to interact with a live person during the e-commerce session. The irony is that human interaction, the old-fashioned way to form a business relationship, is still fairly new in the world of e-commerce. New communications technologies, better scripting interfaces, built-in security, and better data handling are all technologies that help you build new relationships, make new customers, and build a powerful e-commerce platform.
| Ted Coombs is part of a nonprofit science and technology R&D lab called SCIENCE.ORG. Ted is the coauthor of several books including ActiveX Sourcebook, Netscape LiveWire SourceBook, and Setting Up an Internet Site for Dummies. You can reach Ted at tedc@science.org.
|
|
|
|