Website Infrastructure

Passing the Test

In the May/June Affiliate’s Corner column, I wrote about the ways super-affiliates prefer to be approached by affiliate program managers and merchants for the purpose of program recruitment.

Wooing a super-affiliate over drinks and dinner with offers of exclusive landing pages, significantly higher-than-advertised commission rates, or showering them with free product samples will certainly get their attention, but it does not guarantee that you will get the heavy hitters to join your program, however.

Even if your product is a fabulous fit for the affiliate’s audience and your commission rates are more generous than your competitors’, no super-affiliate will send copious amounts of targeted traffic (read: their highly valued subscribers with whom they’ve worked hard to develop loyal and lasting relationships) to your site unless it first passes an affiliate’s Merchant Site Test.

This test evaluates many aspects of the site from both the affiliate’s and a visitor’s perspective. I personally start with factors that will affect a visitor’s experience, and keep the following questions in mind as I peruse a merchant’s site for the first time.

Does the site load quickly or does the server bog down under graphic-laden pages? If there is a Flash home page, is there an obvious “skip intro” link or am I forced to watch the video to the bitter end? Is the site attractive and professional in appearance or are there broken links, graphics and scripting errors? Is the sales page comprehensive and well written, or is it fraught with spelling and grammatical errors or “holes” in the sales copy?

I also check to see whether the site uses excessive newsletter sign-up popups or advertising fly-ins. Do site preview pop-ups such as Snap Shots block my view of the text each time I cursor over a link? Does a new window open every time I click a link? Although I may understand a merchant’s motivation for using such tactics, I am more concerned that visitors to the site will find such intrusions confusing and/or annoying to the point that they are likely to exit the site and kill any chance of a sale.

Appearance, functionality and copy rarely pose problems with professionally designed and maintained sites. Nor are they an issue for ClickBank affiliates who can code links to send traffic directly to the order form. However, having to bypass a merchant’s home page means that pay-per-click arbitrage isn’t an option for some affiliates, while others will have to write sales copy rather than a product review. Although some affiliates may be willing to make that effort to promote one exceptional product, most will pass on the program if the merchant offers a diverse or large selection of goods.

Another significant factor that I will evaluate is search functionality. Visitors must be able to search for and find what they want quickly and easily. For example, does a clothing site let visitors drill down to choose between designers, color and function, or does a click on the “Dresses” link slowly load a page that displays 50 thumbnails of cocktail, evening and wedding dresses?

If the visitor can find a product that she wants to buy, good affiliates will check to see whether the order process is functional, intuitive and secure. Does the site post a “Hacker-Safe” logo and a privacy policy? Are shipping policies and prices easy to locate, or does a customer have to go through the entire order process to determine the cost to ship to Canada or if GST and PST will be added to her order? Can the customer ship to an address different from the billing address and can she have that dress gift wrapped for her cousin in Amsterdam?

What happens if our customer has questions about either the product or her order? Is there a sizing guide or a customer FAQ? Does the site offer order tracking? Is there a contact link, Live Help badge or telephone number displayed on every page for support?

I’d be thrilled to see all but the last item on that list, as a prominently posted telephone number that encourages phone orders means that potential commissions will be lost through traffic leakage.

Traffic leakage occurs at any point on a site that allows visitors to leave the site without making a purchase through the affiliate’s link. Affiliates that pay for their traffic are particularly sensitive to this problem, and most affiliates will not join a merchant’s affiliate program if there is any leakage at all.

Phone orders must therefore be tracked to the referring affiliate – which does not mean asking your customers from which site they originated. Merchants who aren’t equipped with the technical wizardry to track phone orders should allow affiliates to send their traffic to a version of the site that does not post a phone number, and trust that their super-affiliates’ promotional efforts will more than make up for any sales that may be lost by doing so.

Most traffic leaks occur when merchants link to other sites that may be of interest to their visitors, or to partner sites with which they have reciprocal link agreements. Traffic leakage also occurs when a merchant with two or more online stores links to those other sites without compensating affiliates for sales from any and all of their stores.

The most offensive type of outbound link traffic leaks are affiliate or contextual advertising links (i.e., Google Adwords ads) from which the merchant hopes to profit. Most affiliates consider this practice more “traffic theft” than traffic leakage and will not only not join the program, they will also warn other affiliates of the merchant’s commission-stealing practices.

That’s not to say that as a merchant you shouldn’t promote other merchants’ products. You should. But do it on the back end or from within the secure area of your site, only after your own affiliates have had a fair chance to earn a commission for sending traffic to your site.

As you can see, the Merchant Site Test is comprehensive and super-affiliates are picky to the nth degree! If any aspect of the site misses the bar, most super-affiliates will go on to consider your competitor’s offer and promote their products without so much as a TYBNTY (thank-you-but-no-thank-you) note for your time and treats.

If you’re lucky enough to have a super- affiliate take time from her busy promotional schedule (or lounge chair) to explain why she’s chosen not to join your program, consider implementing her recommendations as soon as possible – and let her know as soon as the changes have been made.

Don’t stop there

Visit a Web developer’s forum and ask for feedback about your site. Ask your site visitors for their comments and suggestions as well. Check the affiliate networks for clues about what your competitors are doing right. For example, ask yourself how a merchant that pays only 8 percent commissions has an EPC that is triple that of the merchant who pays 12 percent. Do your own Merchant Site Test to find out why affiliates love to promote their program.

Getting just one super-affiliate on board can substantially increase a program’s earnings. The first super-affiliate in a program will generally use this advantage to heavily advertise the site or product using pay per click.

As other super-affiliates join the program and competition between affiliates increases, most will rise to the challenge and step up their promotional efforts using a diverse array of creative methods. Exposure to both the product and the affiliate program tend to increase exponentially at that point – which makes for very happy merchants and managers.

When you design your site with a view to building long-term relationships with visitors and potential super- affiliates, you too can get that kind of happy – perhaps even rich.

Rosalind Gardner is a super-affiliate who’s been in the business since 1998. She’s also the author of The Super Affiliate Handbook: How I Made $436,797 in One Year Selling Other People’s Stuff Online. Her best-selling book is available on Amazon and www.SuperAffiliateHandbook.com.

Using Data With Integrity

A crucial element of building and maintaining a database is data integrity – making sure your information is accurate and in the correct format, unchanged by technical glitches. You can personally verify information if you are entering it manually, but when users are filling out forms on your Web site, and that information goes directly into your database, you need another approach.

There are two places to check data validity: on the client and on the server. Checking data on the client involves adding scripts to your Web pages that examine what the users enter before they submit forms to your server. A script checks that the data in the form meets the criteria you have established. If there is a violation, the script can pop up an alert message and request a correction.

To check data on the server, the user must submit the form and let the code on your server verify the data. If there is a violation, your server can return the form again with a notation of the error that needs correction.

In general, server-side checks can be more thorough, as you can check other resources on your server to validate the information. For example, you might have a database of valid discount codes, or you might check that an email address is not already in your system. However, client-side checks provide more immediate feedback to the user, and can save iterations of submitting a form and then correcting any errors. A balanced combination may prove the best choice.

A simple check on the client side could be a matter of confirming whether the user entered any value at all.

More Sophistication

Your checks can be more sophisticated. For example, you can make sure an area code was entered as three digits. And you can see if an email address contains invalid characters like a space, or if it’s missing the @ character.

In some cases you may need to examine more than one form element at the same time, such as only validating an area code if the user has selected the US or Canada. You can add a name property to the form tag. Your JavaScript function would be passed the name of the form, let’s call it “myform,” and could reference a specific form element value like “myform.test.value.”

Once your form has passed all of its client-side checks, it gets sent to your server where more sophisticated checks can be performed. If you have a database of area codes, you can validate that the user entered a legitimate one. Or, you can ensure that a user has not already signed up for your program or for your service.

If the data you receive from a form is placed directly into a database, then it is even more important that you check the information on the server before storing it. Depending on how your server performs its database access, it is possible that users may include data-base commands in their submission that could directly affect your database.

Another example is a search form, where your server performs a search through your database. If the user can search for an email address based on a name in your maillist, and the server executes “select email from maillist where name=”<name>'”, where <name> comes directly from a form submission, then the user could get your entire maillist.

If they submit the name text “‘; select * from maillist where name matches “*”, then both selects would get executed. The first would produce no results, but the second would match every entry in your maillist. If your code looped through and displayed the results of the select, assuming that only one or two matches would occur, then this example would end up displaying your entire maillist.

In both cases the user would have to guess the name of your table, but it seems there are people out there with nothing better to do.

EDWARD ARENBERG, vice president and CTO of EPage, created one of the first fully dynamic Web sites. He manages and develops for EP.com, Epage.com and AdConnect.com.

Setting the Data Table

The last issue of Revenue gave an overview of databases and how they can be used. Let’s delve a little deeper into how you, as manager of an affiliate program, can use a database to improve your service and provide customized information for all of your affiliates.

When creating a database, the first step is to understand what information you want to record, and the important relationships among the data. Similar information is grouped into a table in the database. An affiliate will have a variety of contact information such as an email address, a postal address and perhaps even a separate payment address. All of this information could be placed into a single table. Let’s call this table affiliate_contact.

You may want to record certain accounting information about an affiliate, such as the date a sale was made, what item was sold, how much the affiliate earned and the total dollar amount generate by the sale. This information could be placed into the affiliate_contact table we already created, but we will place it instead into a new table called affiliate_sales. I’ll explain why later.

In database design, you want to create tables that group similar information and then link these tables together based on their relationships. This is where the term “relational” comes from when describing a database. Relational databases, such as Oracle, DB2, SQL Server and MySQL, provide very rich tools for extracting information based on these relationships.

Planning and mapping the information you have into tables is just the first, but perhaps most important, step in developing your database. You could change a database’s design once it is running, but if you have a lot of data, or a lot of code using the database, changes can be difficult and time consuming. So, it is worthwhile to take some time and care in planning your tables. In 10 years, my company, Epage, has gone through a few database redesigns, but there are some tables that have not changed structure since the first design.

Creating basic relationships between tables can be quite easy. Usually, it’s accomplished by having a common item such as a table column in related tables. If your affiliates all have a unique identifier, such as their contact email address, this can be used to link tables together. The affiliate_contact table and the affiliate_sales tables would both have an “email” column with the affiliate’s email address. If you want to retrieve information from both tables, like the affiliate’s first name and last sales date, you could query both tables using the same lookup key (the affiliate’s email address).

There are other ways to generate relationships among tables. We like to generate a unique number or string of characters to identify one of our users. This unique identifier is only used internally to form table relationships, and may never be seen by the user. This way, if a user needs to change their email address, it would only need to be changed in one table. In our example above, both tables, and perhaps many more, would need to be updated.

There are many reasons to break your information into multiple tables. Tables with many columns (email, address, phone, etc.) can be very difficult to manage. Database servers are designed to efficiently deliver results to your queries. But, they can get bogged down when you have a lot of columns that you might want to select from. For example, when you insert a new row, such as adding a new affiliate to the affiliate_contact table, the database must re-optimize the way it retrieves data from that table. The more columns that are in a table, the more work the database must perform.

Efficiency is another reason for multiple tables. Some tables may have only one row (entry) for each affiliate, such as the affiliate_contact table. Other tables, like the affiliate_sales table, may have many rows, one for each sale. If these two tables were combined, there would be a lot of wasted space for repeating the contact information for each sale.

Consider what unique information you want to record for each affiliate when planning your tables. You may want to know certain business information. For example, you may want to know whether the affiliate prefers to be paid by check or electronically. Or you may want to review the payment terms for certain affiliates, such as the percent of the purchase price they earn. A database can record these unique terms for each affiliate, allowing you to personalize how your program works. You might want to offer better terms to a desired affiliate or during a promotional period. When a sale is made, the percentage earned by the affiliate would be read from the database, and the result would be stored into the affiliate_sales table.

If you send multiple mailings to your affiliates, some might not want to receive all of the messages. You could store which type of messages they don’t want in the affiliate_contact table. Or, you might want to contact your top-performing affiliates. Each month you could query the affiliate_sales table to find those top performers.

Once you have the information recorded, how you use it is limited only by your imagination. You could send a special message on the anniversary of an affiliate’s signup. You could determine which affiliates had a big drop-off in month-to-month sales – perhaps they are having a problem you can solve. You could determine characteristics of your best affiliates – perhaps it’s their location – and target more like them.

Another good piece of information to record is how new affiliates found out about your program. If you use a tracking code in your advertising, you can record the code in the affiliate_contact table. Then you could determine not only how many affiliates were generated with a specific code, but how much revenue that advertising generated. One last idea to consider: If your users can refer new affiliates to you, then you could record who referred each affiliate. Offer an incentive to these users, such as a percentage of sales generated by the affiliate, and you have the potential for a huge force generating new affiliates for you, with almost no work on your part.

EDWARD ARENBERG, vice president and CTO of Epage, created one of the first fully dynamic Web sites. He manages and develops for EP.com, Epage.com and AdConnect.com.

Databasics 101

Most small business operators have dabbled with databases, but relatively few use them to their full advantage. So here’s a crash course call it Databasics 101 on why you need them, how they work and what they can do for you.

Businesses live and die on the information they collect and how they put it to use. For example, at my company, we send a reminder for unpaid ads on the day following their entry. This provides a timely reminder with an easy link to our payment page.

The key tool for storing, organizing and making sense of this information is a database. Many programs use a built-in database, such as an email reader, a calendar or a contact manager. These programs are already heavily used by individuals and businesses to manage their activities. However, these programs only perform specific functions.

If you want to send email to all of your clients who registered with you during a particular week last year, you are facing a long manual process with standard personal information management (PIM) tools. A database can provide such a list of addresses with ease. It also can track the performance of individual ads, determine your best customers, provide page-view history for affiliates and automate your billing process.

There are a number of excellent databases that run on desktop computers. Some examples include Access, dBase, FileMaker and 4th Dimension. There are also dozens of programming, scripting and report-generation tools for these databases.

On servers, popular databases include Oracle, DB2, SQL Server, Sybase, Informix, and the freeware MySQL and Postgres. Some of the advantages to having a server-hosted database include the ability to connect from different computers in your office, the option of using a wide variety of programming languages and the benefits of using an industry-standard structured query language (SQL). If you run a Web server for your business, it is relatively easy to connect the Web server to a database.

In my company, for example, we use server databases for both office and Web environments. In the office, we can do on-the-fly queries to find out information about a customer and to determine how much customers spent on each of our features. These queries can be run by anyone in the office, because we access the same common database.

You’re a Sales Machine

Pairing a database with a Web server allows your site to become a customer-driven sales machine. Of course, it will take a little programming to put your business practices online, but the key component is a robust database. With this combination, there are Web sites that support thousands of affiliates, providing customization for each one. The key parameters for each affiliate are stored in a database.

Databases store their data in files optimized for rapid access. You can’t view these files directly, but databases provide facilities for writing and reading information. It’s important that your database provide facilities for backing up this critical information, and that you back it up frequently.

Just about every database has graphical tools for creating, browsing and modifying database content, generally called tables. Desktop databases come bundled with these tools, but for server databases they are often separate products. These tools can help with the creation and casual browsing of database tables.

To take full advantage of a database, you need to look at its scripting or programming interface – a process that may sound harder than it really is. Server and some desktop databases provide a common language called SQL for manipulating their contents. For example, the SQL statement “select email from customer where area code = 310” would select all email addresses from your customer table whose area code is 310. This same statement could be used on any database that supports SQL.

Databases that provide an application programming interface, or API, open their power to third-party or even customer-written applications. One industry-standard API is called open database connectivity (ODBC). ODBC compliance allows third-party applications and programming languages to connect to and manipulate a database.

My company, for example, uses an ODBC interface to connect Java applications to a database. To find all unpaid ads from the prior day, a Java program connects to the database through the ODBC interface. It then issues an SQL request through that connection. The request is something like “select * from classified where starttime > yesterday and starttime < today and paid = 0.” (This is an SQL simplification, but it serves our purpose.) The “*” indicates we are selecting all data from the classified table that meets the criteria.

The classified table contains the classified ad contents as well as information about the ad owner, such as the email address. It’s then a simple matter for the Java program to send an email message reminding the ad owner that the ad still has an amount due. The message can be personalized, and it can include the ad contents of the ad.

This is just one example of how to use a database, but it shows the potential power of one of the most common tools available to small businesses. Doing this operation manually would be a very time-consuming process and would require personal attention every single day. Using a database allows you to automate the entire process, freeing you to focus on growing your business, not just maintaining it.

If the technology is a bit beyond your personal capabilities, don’t despair. Remember, there was a time not long ago when most people were intimidated by the idea of owning their own computer. There are plenty of people around who can help you, and finding them will be well worth your effort.

The best place to start your search for help is from friends who understand the technology. They probably won’t want to do the work for you, and you shouldn’t expect them to. But they can help you screen the person who will do the work.

Professional help doesn’t have to break your budget. In most cases, you should be able to find a contractor for about the same price as a plumber, and often for less. But if you have a complex project in mind, you may want to seek bids from several computer consultants. n

EDWARD ARENBERG, vice president and CTO of EPage, created one of the first fully dynamic Web sites. He manages and develops for EP.com, EPage.com, and AdConnect.com.