To understand that, let's look back and recall that from a whole set of items that we have, we typically do not have any of the user's preferences initially. So we put up global recommendations. Since these global recommendations are the only ones a new user will see, she/he will get bored. Why?

This is because a user wants to be surprised and delighted with new and interesting items from our recommender system, which our recommender will fail at terribly.

However as time passes, and hopefully while we still have active users, the recommender will adapt itself and will have affinity toward a few sets of popular items. This means a vast majority of items will always have a very low to negligible hit-count. And that is what we do not want. So we need to be systematic in our approach towards building a recommender system. To make this a systematic process, we will discuss some themes now, which are:

As we have seen, our recommendations are totally based on knowledge of the past. This knowledge is what lets us best predict the future choices of the users. So the first thing that we need to ensure is that we log (record) the choices that users make. Since, in collaborative filtering and content-based recommendations, we need to model a user's profile before we can make any recommendations; we need to keep a log of a user's activity. A detailed user profile will only increase the confidence with which a recommendation can be made.

In many cases, we have more than one recommendation to provide to a user. In such a situation, we have to ensure that the most appropriate recommendation is provided at the top. That also gives us a chance to put some "interesting" items somewhere near the middle and the bottom positions.

Suppose you went on a site to search for restaurants, and searched for "Biryani." Now there could be thousands of places where you could find such an item, but the system only shows "Chicken Biryani," it would be boring. How about we add items like "Veg Biryani," "Raita," "Mughlai Food," "Hyderabadi Biryani", and so on to the mix? That would make the recommendations more diversified. Sometimes a customer is not decided on a single item, so the recommendations can, do and should help the customer decide what she/he really wants.

Finally, when we make a recommendation, it could be possible that the recommendation is wrong. It could be interesting but not clear as to why the system is generating such a recommendation. We always provide recommendations to a user based on historical data, and the knowledge of a user's choices and preferences. So based on that data explaining why we recommended something is crucial. The user deserves, and in some case expects, an explanation.

Once we have built a recommendation we also need to have a way to evaluate how it will actually perform on a production system. Evaluation is by far the toughest part. Evaluation has its own challenges, which we will break down into three parts:

Out of all the steps involved in creating a recommender system, evaluation is the toughest part. It involves continuous effort. There are so many possible ways a minor change could affect the whole system. Just creating a recommender algorithm and deploying is not the end of story. Evaluation is a continuous process, which must be integrated with the whole development process of the application. That also means that just discussing evaluation strategies of different algorithms will require an entire book to be written. It requires one to understand the data science. However, we will discuss a mature project called PredictionIO in the next chapter, to help us with the tooling.