Buying a commodity item is easy. Take the purchase of a new watch, for instance. Whether you have your heart set on a genuine Rolex Sea Dweller, or you simply want to window-shop and pick the third one from the right in the display, the process is simple. Either way, the vendor has one or not. There is a simple binary answer and you can buy or shop elsewhere accordingly.
This is one reason for the run-away success (at least in trading terms) of e-commerce sites like Amazon.com - they sell well-defined commodity items. But what about less easily defined non-commodity items such as last-minute holidays?
Most people don't approach a travel agent with a specific agenda. Counter staff in your local Lunn Poly are unlikely to be approached by customers announcing that they want to fly from Manchester to Athens on BA1234 at 10:30am on the 23rd. Far more typical is: "Well, we want to go to Greece, leaving on the 23rd for about two weeks, and we've got about £300 each - what can you do?"
That works reasonably well with a travel agent, but what happens on the Web? Typically, sites offer a range of search criteria from which you can select the options that most closely resemble your desires. The trouble is that when the answer comes back, you may well find that there are apparently no holidays to suit you at all. This depressing answer is rooted in the fact that most e-commerce sites are backed by relational databases that are geared for exact matching.
Travel agents, being human, are poor at exact matching and great at the art of compromise. "Well, I can't get you to Greece for £300, but how about Cyprus for £290?" Humans can instinctively see what is a close match. Computers can't.
If you are a Web developer you may be thinking, "Hey, I could devise a set of rules that would work here." Any developer worth their salt could design such a system, although it would be complex to write and even more difficult to maintain.
How do you balance price against departure date while taking into account both airport location and return date? Out of several hundred holidays that are a close match, which ones are closest? Worst of all, after you have finally found a set of rules that works for holidays, if you then need to create a Web site for selling insurance policies you will have to start again.
A far more elegant solution is to take an almost academic look at the root problem and try to find a solution that is applicable in the majority of cases. However, at first sight a generic solution seems unlikely. How can you generate a solution that doesn't take into consideration the meaning of the data (in other words, works equally well with data on holidays and horses)?
Suppose, for example, that you sell classic cars. You find that the only factors that buyers care about are price and condition. Price can range from £100 to £50,000 while condition varies from 1 (perfect) to 10 (dreadful). The choice will be wide because for £5,000 you can get a condition 1 Triumph Spitfire and a condition 7 Bentley.
So, you plot a graph of price against condition for all your cars. When a customer comes in and says, "I've got £2,000 and I want a car in condition 2," you consult the graph. Nothing matches exactly but you can see which points on the graph (thus which cars) are close, so you suggest these to the client.
What you have done in drawing the graph is make it easy to visualise the gap between the real data and the desired optimum.
Now imagine that you work with three variables - price, condition and year. You need a three-dimensional graph. Some sort of futuristic holo-projector from Star Wars might be handy, but the principle remains the same - the point closest to the client's specifications represents cars that he/she is most likely to buy. This method can be applied to any set of variables and data.
Applying this approach to e-commerce sites will help users get genuinely useful information from relational databases on the Web. In turn, this could revolutionise the marketing of non-commodity products like holidays.
Dan Marsden is technical director at NCorp