Tag: Amazon

Recommendation engine for configurable products

The Amazon recommendation engine has received a lot of attention and imitation. It has been successful at increasing sales by pointing out that people who bought book x also bought book y. This simulates a helpful book store employee who has an extensive mental map of how books relate to each other. Recommendations have been most successful for books, movies, and music. Companies that sell complex configurable products could also benefit from a system of automated recommendations. Products like trucks, tractors, computers, lighting fixtures, valves, and industrial fans. These are products that the buyer can customize to his own preferences or needs. The buying process is complex, and sales agents make recommendations, just like the book store expert. But many of these products are far more complex than books.

How is a book different from a truck? Could a recommendation engine for books be used to recommend trucks? The purpose of this note is to consider the ways in which the two cases are similar and different, and to explore what a recommendation engine for configurable products might look like.

Books and trucks can both be described in terms of attributes (also called features or characteristics). Books can be described by their genre, author, language, and publication date for instance. Trucks can be described by their engine, transmission, wheelbase, gross vehicle weight, and many other attributes. Books, movies, and music can be classified in sufficient detail with ten or fewer attributes, while configurable products usually have a lot more. Heavy-duty trucks can have anywhere from 30 to 300 attributes. For books, the attributes are used to classify existing books. For configurable products, each attribute represents a choice for a customer who is ordering the product. Each attribute has several alternative options, so an order is really a list of option choices.

Amazon uses attributes to let customers search for a book, but the recommendation engine does not use them. The recommendation engine remembers each customer’s purchase history. For example, Joe has already bought “War and Peace” and “Crime and Punishment”. When he buys “The Sound and the Fury”, a connection is made between “The Sound and the Fury” and “War and Peace”, and another connection is made between “The Sound and the Fury” and “Crime and Punishment”. More accurately, the weights of these connections are increased. The connection between “The Sound and the Fury” and “War and Peace” depends on the number of customers that have bought both books. Commonality depends on common purchase by individual customers.

One big difference between books and trucks is that an individual will buy many books, but is unlikely to buy many trucks. So the basis for the connections between trucks can’t be the common purchases of individual buyers.

Another difference is that only books that have already been written are of interest. No customer is looking for a book that hasn’t been written yet, and you certainly can’t recommend one. But because of the very large number of choices, a buyer who is customizing a truck may arrive at a configuration that has never been built before. So our recommendation system must be able to accommodate trucks that don’t exist yet.

The helpful book store employee will jump from one book to another book that his customer might like. When we look at the helpful sales agent, he is doing something quite different. Based on the first, and usually most important, choices that the buyer makes, he will suggest ways of completing the order. The buyer may really only care about 10 of the 30 choices, and want guidance on what else to choose. The book store employee jumps from one complete item to another complete item. The sales agent is finding a path from a partial order to a complete order.

So we have an initial set of requirements for a recommendation engine for configurable products. It must help a buyer who has made some choices to make additional choices, so as to arrive at a complete order. From the seller’s point of view, we would want these recommendations to guide the buyer toward items that are advantageous. This might mean popular, in stock, and/or profitable. Its concept of the product (e.g. truck) must be broad enough to encompass configurations that have never been built before, and its concept of commonality must be based on something other than common purchases.

To show one way this might be done, consider a different way of making connections. When a customer buys a red truck with a V-8 engine, he is making a connection between red, a value of the Color attribute, and V-8, a value of the Engine attribute. So the customer’s vote is not recorded as a connection between two complete trucks, but as a connection between two attributes. More precisely, it is recorded as a connection between two values, or options, of the two attributes.

When a customer buys a truck with n attributes, we will record his “vote” n times, once for each of the options he has chosen. Then we will also record it nC2 more times for each pair of options. The symbol nC2 stands for the number of different pairs of attributes there are, and can be computed as n*(n-1)/2. For example 10C2=45. The relative popularity of the different pairs of options (like red and V-8) tells us something about how customers are buying the product, and gives us a different basis for making recommendations. (If you want pineapple on your pizza, you probably want Canadian bacon.)

If pairs of options are interesting, then so are triples of options. The same customer vote can be recorded for nC3 different sets of three options (10C3=120). Every option of every attribute has its own popularity (i.e. number of votes). Expressed as a fraction of total units sold it is known as a first-order take rate. Every pair of options also has a popularity, and as a fraction is defined as a second-order take rate. Similarly, each triple has a third-order take rate. Of course we can also define fourth, fifth, and higher-order take rates.

If customer purchases (votes) are recorded in this way, then we will have captured the buying patterns in the form of first, second, third, and higher-order take rates. A new customer who begins to select the options that are important to him will trigger these patterns, which will then serve as the basis for recommending a complete truck. So we see that two complete trucks may be related because they both contain instances of the same fifth-order take rate. This can be true even if neither truck has ever been built before.

We conclude that a recommendation engine for configurable products could be built by mapping customer purchases into a structure of take rates that record the relative popularity of options, pairs of options, triples of options, and so forth.

Comments Off