Using Product Predictions to increase sales
One of the areas I’ve been working on since joining Edument is product prediction engines. In product prediction, we take a set of historical data that indicates what products a customer was interested in, and use it to suggest products that current customers may be interested in. That may be based on the customer’s own purchase history. Often we also want to use the data to compute a set of similar products to the one that the customer is currently viewing – something that works with new customers who we have no historical sales data about.
How a predictor engine typically integrates with an existing database-driven website
For example, if a customer is looking at a travel guide to Russia, from the historical sales data we may see that other customers who purchased this travel guide also tended to purchase a Russian phrasebook or a guide book about neighbouring Ukraine. “Gee,” says the customer. “I guess a phrase book would come in handy too, so I know my borsch from my babushki.” And so you get an extra sale.
The key thing you need to get started with product prediction is a data set. Generally, the larger the better, although extremely large data sets may lead to slow predictions. This is something you will have to assess in your particular use case. To give you an idea of what’s manageable, though, I’ve been comfortably churning out predictions in under 10 milliseconds for data sets containing millions of past purchases. Granted it took me a little effort to achieve this kind of performance, but it’s within reach.
There are two types of data models: boolean models and ratings models. In a boolean model, either a customer has a connection with a product or they don’t. For example:
- They either purchased the product (and have a connection with it) or they didn’t purchase the product (and thus don’t)
- They either wrote a review of the product or they didn’t (note that it could be argued that even if the user wrote a crappy review of a product, they still had an interest in it, so we just treat the presence of a view as a connection)
- They either viewed the item or they didn’t (if you don’t have loads of historical sales data, you could data-mine web logs and try and get some connection data based upon which products a given site visitor viewed, on the basis that visitors to a site will generally tend to view related products; here, site visitors serve the place of customers in the data set).
An alternative is to have a ratings based data model. For example, we may have a large number of product ratings given by customers, on a scale of 1 to 5, where 1 is suckful and 5 is awesome. With a ratings based model, a customer giving a product a rating of 5 implies a stronger connection than a rating of 1. The prediction process then considers these values. Note that ratings are not the only possible source of data for using such a model; you could also consider:
- How many purchases a customer made of a product, if you have a range of products that often lead to repeat orders. For example, if you’re selling beer online, then a customer may have purchased Hobgoblin 10 times, but (understandably) only purchased Carling once.
- If mining web logs, you could consider number of visits to a product page as being your kind of “rating”
Your choice of boolean or rating model will directly influence the prediction algorithm that you use, since some algorithms only work with one model or the other. Which you opt for largely depends on what type of data you have, though as noted even if you have ratings data you may just like to abstract it down to “did the customer rate the product or not”. A boolean model certainly has the benefit of simplicity, and I’ve had very good results using such a model. If you have resources, then trying multiple algorithms and data models and using A-B testing would, of course, give you a far more scientific answer.
User-based and Item-based Predictors
Once you have a data model, there are two general types of predictors that you can use it with: user-based and item-based.
In some cases, you may have extra information that you wish to use to influence product prediction. For example:
A user-based predictor works by building a “network” of users with similar interests, and then making recommendations based on that. That is, given our current user, we can work out the other users nearest to them in the network and give recommendations based upon what those other users purchased. This depends on having some current historical data for the current user. We generally need to pick two things when working with a user-based predictor: a user similarity algorithm that computes the similarity of two users, and a user neighbourhood algorithm that builds the network of most related users. A side-effect of this is that we also win a way to compute “users with similar interests”, which for some cases may be useful.
An item-based predictor works based upon item similarity. To work, it also requires you to select an item similarity algorithm, which determines how similar two items are based on the overlap in customers purchasing them (depending on the algorithm, it actually can make transitive reasoning rather than requiring immediate overlap). To produce recommendations for a user, we go from the items they purchased and find most similar items to all of those. However, the big win from this approach is that we can compute most similar products. This is extremely useful because it gives us a way to make predictions for a product that is currently being viewed.
One additional benefit of an item-based predictor is that they allow for more pre-computation. The reason I could compute most similar products in 10 milliseconds was actually because I could, off-line in a batch job, pre-compute tens of thousands of set intersections that would be used in producing the results rather than computing them on the fly. Thus if you have time constraints or a large data set, item predictors are going to scale better.
- You may want to filter out products that a customer has already added to their basket from the prediction results; they already decided to buy it, so it’s best to show them new things they may also wish to buy.
- If you have some products that are not “family friendly” then you may wish to filter them out. Just because a many parents of kids who like Thomas The Tank Engine also happen to have purchased horror movies doesn’t mean they are suitable recommendations.
- You may want to suggest products in a given price range, which will take the customer over some threshold where they get a volume discount, or can use a voucher, or get free shipping.
An additional tweak can involve re-scoring the predicted items. Prediction engines not only find products to recommend, but they rank them by giving each one a score. When we re-score, we twiddle this score a bit to bias certain products to being more likely to appear at the top of the predictions list. Since a site will only have space to show a selection of the predictions, this can make the difference as to whether a product appears as predicted or not. Use cases for re-scoring include:
- Finding a way to factor in some ratings data when we have a boolean model. For example, if you primarily want to go with a boolean data model based on sales history, you may also want to use customer’s ratings of a product somehow. You could bias items with high ratings to be more likely to appear in the results than items with lower ratings. This helps you make the most of both data sets.
- Biasing products that are more profitable for you to sell towards being ranked as better predictions.
- Biasing products that are on special offer to being ranked higher (perhaps you have a lot of a certain item in stock and want to try to increase sales of it)
Tracking and A-B Testing
Just introducing a product prediction system is not the end of the story – or at least, should not be. It’s also important to track how many purchases are made as a result of the predictions. This just means tracking click-throughs to product pages made from the product prediction results, and setting a flag when such products are later purchased. This way, you can get a sense of the return on investment that your product prediction engine is delivering.
Isn’t this expensive?
Getting a basic product prediction solution in place need not be expensive. Naturally, much time can be spent optimizing predictions and trying out different configurations. However, a basic solution can deliver significant ROI. Then, once you’re comfortable that the predictor is delivering value, you can invest in further optimizing it to increase your sales.
If you’re interested in product prediction solutions, feel free to contact Edument. We’ll be happy to discuss how you can put the data you already have available to good use in making product predictions. We are also experts at integrating with existing systems and data, with specialists in a range of technologies.
Taking things a step further, you may want to make your prediction engine configurable, or even run two parallel versions of it. The first time a visitor hits the site, you select which version of the prediction engine that their visit will fall under. You then store not just that the purchase was the result of a prediction, but which version or configuration of the predictor led to the purchase. By combining that with data on how many predictions were served by each configuration or version, you can get real world data on how well different approaches are working for you, and then pick the configuration that works best.
Jonathan Worthington is an architect and programming mentor at Edument. He works to help development teams improve their software architecture and work more efficiently, following best practices. He is also one of the core developers of the Rakudo Perl 6 compiler, where his work focuses on the implementation of object oriented language features and the type system. In his free time, he enjoys hiking in the mountains, good beer and curry.
Entry filed under: Uncategorized.