# Basket prediction at Contoso – using Azure ML with Dynamics AX

This post picks off from one of my previous posts, see link below.

Company background

Contoso is a food delivery B2B company who prides itself on its' customer obsessiveness.

The purpose of Basket prediction service at Contoso is to minimize the order taking time, to make the experience for the customer on the website and in the call-center really fast. To make placing orders such a charm that customers come and place orders because they like to place orders not because they necessarily need the products.

Basket prediction service in the backend is basically a mining algorithm. Most of it is written in data scientist friendly R language. All of it is developed in Azure ML studio, this is possible because the studio treats R as first class citizen, more and more R packages are being made available in Azure ML studio. And it is deployed using Azure ML platform as a REST API.

What do we have to predict?

1. What will the customer buy?
1. Which items will the customer buy?
2. How many quantities of each item will customer buy?

Let's see how each of these were modelled

1. A - Generate how frequently each item was bought by a given customer in a month, say box of mangoes bought most frequently followed by whipped cream
2. B - Generate average of quantity for each item for each customer per month, say 30 boxes of mangoes and 6 packs of whipped cream
3. C - Generate average of unique items per basket for each customer

1. Assign day of the year to the date on which purchase was made for a customer
2. Do this to all purchases for a customer
3. So a purchase made on Jan 1 gets 1 and that made on Feb 2 gets 33 and so on.
4. Calculate the non-buying duration - difference between two purchases
5. D - Use that to score how large next purchase will be given the number of days since last purchase in given month
6. E - Calculate what items have already been bought in current month
7. F - Calculate what quantities have already been bought in current month
8. G - Identify the sequence in which items are placed in the order by the customer (Note: Contoso's customers often work off a shopping list from top to bottom so providing them with this sequence will save them from scrolling & searching)
9. H - Items almost every customer buys but not in A because of period differences

Based on the above model,

Next purchase will have following

1. C unique items,
2. ordered by list generated above in A less already bought items E
3. In quantities B*D - F
4. Plus add H as a non-predicted set to ease order placement since these are very likely to be in the order
5. Sequence the output on website and in call-center based on sequence identified in G

Data from Dynamics AX database is put into another SQL database for transformation and processing. This data is sent to Azure ML for prediction. Results are received back in analytics database and then reprocessed data is made available for Dynamics application and web-shop.

Basket prediction service has been live since Dec 2014. Anecdotal testing suggests that customers like the new approach. Based on their suggestion fine tuning is continuously being made. For instance Contoso was showing products on the web-shop strictly in the sequence that came out of Azure ML. This made products from same category appear distant from each other so Coca-Cola cans were followed by cleaning products and those followed by Sprite and Fanta cans. Contoso rectified the complaint and decided to show products from same categories together as much as possible without diluting the Azure ML suggested sequence. It was also decided not to make changes to Azure ML model since they were in the middle of testing the model to incorporate this feedback but instead to make changes in Dynamics AX call-center and product placement on web-shop. Call-center agents though are less impressed. The agents who are used to searching for products before Azure ML came along still continue to search whatever they need even if the product is shown in predicted basket. Newer call-center agents find this capability as a real time-saver. This result is expected, hopefully with regular cajoling and nudging all agents will get used to new practice and improve productivity.

This model was built in Azure ML studio as already mentioned.

Key learnings here are:

1. Spending good bit of time in scenario definition and stating the problem will reduce the time for feature engineering
2. Data cleansing, transformation takes most of the time
3. Using R in Azure ML studio, model can be written relatively quickly
4. The toughest part is to do A/B testing in a very controlled manner so one can establish the benefit/lack thereof every approach
5. The easiest part is calling the service in any application, Dynamics or otherwise
6. Azure ML platform makes operationalizing a model too damn simple
7. Knowledge of R and statistics is important if you are building a working model using Azure ML studio (Note: you could use out-of-the-box Azure ML apps if you don't have these skills)
8. Getting through from start to finish will need persistence, be prepared & set right expectations
9. Slow is smooth, smooth is fast

Good luck!