Tag: buying patterns
Connect With Us
True Demand Intelligence – Knowing who is buying what, where and why
Demand Intelligence – Knowing Who is Buying What, Where and Why
SKU numbers are an easy way to keep track of items that are built, stocked and sold. The SKU number itself is arbitrary and contains no ‘intelligence’.
The SKU number was invented for a very good reason. When this practice started, the number of SKU’s was small, and people and systems needed a simple way to track what they had. So ASP-678 may be the SKU number for a toothpaste tube with spearmint flavor, whitening, and tartar control. However, customers do not look for SKUs. They look for toothpaste with whitening, tartar control, flavors, sizes, etc. Customers buy attributes, and combinations of attributes. Some companies code the attributes into the SKUs, by concatenating two or three character codes (like SPWHTC). But this is at best a clumsy way of handling a few attributes. Companies want to know what attributes customers are looking for, and SKU numbers hide the attributes.
As the number of attributes starts to grow, whether you have them coded into the SKU number or not, the problems start to mount! The most important one is that companies do not know what customers are buying, or trying to buy. As the number of choices grows, the number of combinations grows much faster and companies drown in their own SKUs.
SKU intelligence is going behind the SKU numbers and ‘detecting what attributes customers are buying’. Knowing who is buying what, where and why is “True Demand Intelligence”.
Products have attributes. For example, a computer has a processor, a memory, and a hard drive. For each attribute there may be several alternative choices. This means that there are many different product configurations. Some companies make only a fixed subset of all the possible configurations and give each one a SKU number. Other companies allow customers to order exactly what they want, and if this is something new, then they create a new SKU number for it. In either case, a SKU number is supposed to represent a unique product configuration.
If you are trying to figure out what your customers want, then SKU numbers are a form of encryption. You have to look at your sales history in terms of the underlying attributes, and the choices for those attributes. Instead of looking at one SKU number you need to look at perhaps 20 separate attributes. The SKU number is a way of collapsing those 20 dimensions into a single dimension, with tremendous information loss. One of the things that is lost is proximity to other SKU’s, based on attribution. A customer who bought SKU A-1234 might have been satisfied with (or really looking for) SKU B-3728. These two SKUs have the same choices for 18 of the 20 attributes, and differ on only two. This is obvious when the unique configurations are represented as a set of attribute choices, but hidden when they are represented as SKU numbers. The first step in analyzing a sales history has to be expressing it in terms of the underlying attributes. Each SKU number has to be expanded into a list of choices. Then we can begin to find patterns in how the choices are made. The leather seats and the DVD player are usually bought together. Engine block heaters are not ordered on convertibles. Buying patterns exist at the attribute level, not at the SKU level.
“Buying patterns” are popular combinations of attribute choices. These can be pairs of attributes, triples of attributes, or even more. Popularity is measured by the share of sales that have that combination. Buying patterns are helpful in selling, because they reveal how customers can be moved to configurations (SKUs) that we have in stock, or that we would prefer to build. Experienced sales people are skilled at moving customers, but If these patterns are represented in some kind of knowledge base, then a computer can make the recommendations.
Customers also have attributes. The simplest is perhaps geographical location. There are patterns that involve both product attributes and customer attributes. Customers in Florida are more likely to buy convertibles; customers in North Dakota are more likely to buy engine block heaters. Customers may have several attributes, for example demographic attributes for individuals or industry attributes for companies. (We don’t assign SKU numbers to customers!) If your sales history contains information about the customer as well as information about the product, then we can look for buying patterns that are associated with certain kinds of customers.
As an example, for a desktop computer the list of attributes might be: Processor, Memory, Hard Drive, Keyboard, Monitor, Mouse, CD/DVD, Application. A specific SKU number like A-1234 is a code for a specific configuration, say (2GHz, 2GB, 120GB, Ergonomic, 22” flat panel, Wireless, R/W Combo, Gaming). The Application attribute is really a customer attribute, with values like Home, Small Business, or Entertainment, as well as Gaming. This would make it possible to look for typical Gaming configurations and typical Entertainment configurations.
SKU numbers are a useful shorthand for record keeping. Each SKU number represents a unique product configuration. But analyzing SKU numbers is like analyzing telephone numbers. To see the buying patterns, you have to go to the attribute level. The patterns exist among the attributes, so you have to decode the SKU numbers to see them.
Part II: Analytics to Action….. The Holy Grail
Can-you-have-too-much-information?
… in my last blog we talked about reporting, BI and data mining, and ? the information overload. So how can help business users with solutions for better decision making, as opposed to drowning them in more data and pretty charts? That is the Holy Grail and the purpose of all this data!
Lets start by defining analytics. So, what is analytics? Neil Raden of Hired Brains, a market research and management-consulting firm, has said that, “the proper term for interacting with information at the speed of business, analyzing and discovering and following through with the appropriate action, is ‘analytics’. I agree. In the information age, this must be done by specialized applications built on analytics based on the requirements of the actions/recommendations required by a business function. Dumping data on a users lap with the message – “Figure it out!” is NOT analytics, and it not very useful either. (I am reproducing a picture I really like as it conveys the message so very well! The Picture is from mathewingram.com/work)
So – how can we transform the user experience for analytics? As mentioned earlier, this can only be accomplished by focusing the analytics on a business problem with the mission to deliver actionable tasks. The challenge is selecting a business problem that the analytics truly delivers unique capabilities and intelligence that is relevant to that problem. This level of focus can be perceived as very limiting, and hence many choose not to go this route. Why limit the scope of the analytics to one specialization, when we can claim that we can do everything! To that I say – you are better off doing one thing very well, as opposed to many with mediocrity at best.
I am going to bring this back to Emcien, as this is a company that has focused analytics on a very specific business problem. The problem is one of product variety, product variants, and lots of attribution. In this age of product variety, that is a problem that is causing tremendous challenges to various business functions.
The analytics automatically detects what features customers are buying, where you are making money. This SKU or configuration intelligence is leveraged for:
SKU Intelligence Analytics Used to Drive Application Specific Recommendation
- Better forecasting at the mix level - The application uses the analytics intelligence to determine the exact product mix with very high accuracy based on true demand sensing.
- Improving the customer experience at the point of sale - The application uses the analytics intelligence and guides the buyer to a good configuration based on the few features they have called out. And by the way – customers love it when you can recommend a configuration based on the few features they ask for. They want you to stop asking more questions and recommend a good choice.
While the analytics may throw out volumes of data, the user can relax, as he does not have to crawl through volumes of date wondering what it is telling him. Converting analytics to actions and recommendations minimizes human interpretation and error on a day-to-day basis. For analytics to be functional in business applications, this is a mandatory requirement in today’s business environment.
So – when you are evaluating BI tools, Analytics, Data mining….. what ever they are calling it! Ask yourself, how am I adding value to the company? What am I giving my business users? Am I adding more work to their busy schedule by piling on data on their computers???? If the answer is YES, please don’t do it. They will thank you for it.
If the data has not been converted to recommendations the business can act on, you will not get value from your investment!
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