September 8, 2009 Posted by: Roy Marsten
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
August 20, 2009 Posted by: Russ Caldwell
Self service is a term we all know, such as pay-at-the-pump gas and self-checkout stations at some grocery stores, and now more obscure things like video game kiosks by GameFly, but the true tidal wave of self-service hasn’t even started, and it’s going to be good for both the consumer and the manufacturer, if done right.
Self Service Grocery Scanner
When you checkout your soda and cereal by swiping products across a scanner at the auto-checkout stations, there isn’t much complexity other than when you get a problem with the scanner reading a smudged bar code or trying to locate the button for ‘snap beans’ when you put those on the scale. The transaction is smooth, quick and you are in control, which is a good feeling as a buyer, you are not being sold, you are buying just what you want, quickly and easily.
But what happens if you try to buy a “configurable product“? In the grocery store, the only thing configurable is the weight of produce, but other than that, the costs and configurations are set in stone and are detected by reading the bar codes. Easy to understand as the buyer and relatively easy to deal with as the seller. Configurable products are those where you have to make many choices before you can order the one product. Products like computers, cars and thousands of others where the buyer has to describe their preferences or choices so the product can be created and delivered. It’s even more complex in a B2B environment than it is in B2C, where the products available and choices are astronomical. Products like Lighting, Valves, Agriculture and Construction Equipment, Lifts, Electrical equipment, cooking equipment and conveyors have more choices and variants than you can imagine and that variety makes it hard to order, build and deliver efficiently.
Usually a large direct sales force is sent out with complex price books (sometimes online in PDF form) to sit with customers and prospects and help them combine choices in hopefully valid ways. The choices a customer have to make are quite extensive, ranging from tens to hundreds of choices. Most of these choices the customer doesn’t care about, but they are required by the manufacturer just so they can build a valid product. Customers care about the few things that matter to them but after that, they will just choose things that “seem to make sense” just to complete the order. Sometimes they don’t even do that, they get so frustrated with 60 more questions about features and options on the product (many of which they don’t understand) that they walk away.
In some cases companies believe that putting in a configurator is the solution to their problem. Configurator’s automate the order process by ensuring that the order is VALID. The engineering and marketing rules that drive what can be built and offered are setup in a configurator such that the user ordering the product is led through valid questions and end up with a build-able product. Now this product may be build-able but it also may be a one-off low-margin brand new SKU that manufacturing hasn’t built before and requires some parts they aren’t carrying at this time. All this for something that was only 2 choices from a very popular configuration. And those 2 differences only happened because the customer was asked 20 more questions after they entered the 5 things they cared about. They chose as best they could, but without any guidance or suggestions, ended up on a new SKU which will ultimately explode into huge numbers of parts and processes to support the new SKU.
Now if the customer only had to enter the 5 things they cared about and the system recommended the combination of other choices such that the customer’s price limit was met and the configuration wasn’t a new SKU and the SKU had a good margin, then it would have been a win-win for everyone. And the whole process could be complete quickly and easily. The customer wouldn’t have to answer any other questions and would feel that same feeling that you do when you swipe your can of soup across the scanner at the market. The manufacturer wins as well because the customer was guided toward an existing configuration so the cost of creating and supporting a new SKU was avoided. It’s happening now with recommendation engines that leverage buying patterns to suggest full configurations based on the few attributes a customer gives it. Just like Amazon can recommend other books you might want to read based on the current “fly fishing” book you are looking at now, suggestion engines can be utilized to provide this convenience for much more complex products.
That’s the self-service tidal wave that’s coming, when all products, not matter how complicated can be ordered by simply asking for the attributes that YOU care about, what your price limit is and then Voila! it’s done. Customers will order more from companies that offer this convenience. Just think about how often you walk into the gas station to pay as opposed to pay at the pump. And if you had two stations to fill up at, one was pay at the pump and the other required you stand in line after pumping the gas, which do you think you would most often go to? Simplification is good for everyone, and profitable too.
Comments Off