Try also biomimic@gmail.com and see also: Discovering and scoring relationships extracted from human generated lists - K Franks, M Muldoon, R Podowski - US Patent 8,108,417, 2012 http://www.google.com/patents/US8108417
This is wrong. Think of all the companies that start on day 1 with 10,000s or millions of products. Hotels, restaurants, gigs, events, posts, people, other users, questions, articles, songs, etc.
Manually picking stuff is time consuming and might become stale quickly while a basic recommendation engine will take you a day or two. The whole point is to simply expose your consumer to more of your other products in the hope that they engage with one. If you have a wide scope of products, presenting the same tiny number of manual picks would be insane. Editors picks only works if you have a tiny number of products.
So build one if you want. And don't be afraid to make a slightly shit one either. As it's often better than tying up your time manually picking stuff out when you could be doing something better with your time.
Directly giving the users predictions that are based on latent factors has a huge problem -- is there ever really a case where the latent factors have very high prediction ability, but an analyst can't simply see what's driving the preferences by looking at those factors, and then create something better by targeting that interaction directly?
Better to analyze the latent factors, and then use that analysis to gain engineering-type insights into the structure of the problem, and target specifically what's driving people to like something. Exactly as Netflix has been doing in recent years. Exactly as people have done when writing books or developing other entertainment content for centuries.
Just dumping unsupervised clustering on the end users is a poor technique that should stay in the 1990's where it belongs.
Disagree with most of this. You don't need a massive inventory for recommendations to be useful, and you don't need a massive data set of usage data to be able to do them. What really matters is how sparse the user x item matrix is, and I know from experience that you can give ok recommendations even in cases with extremely sparse data.
I also don't like the idea it takes mysterious, scary "hefty data science" to be able to do recommendations.
- If you're recommending based on one thing (i.e. "people who viewed this also viewed.."), you'll be doing cosine similarity on the vector of viewers (i.e. the columns of the user x item matrix).
- If you're recommending based on many things (i.e. "recommended for you"), you'll be doing a matrix factorization of the user x item matrix. Pick SVD or NMF, depending on how sparse the data is.
- You probably won't be doing content based recommendations, without doing breakthrough machine learning research. For a lot of content, no-one really knows how to do this.
I think the key insight in this article is "A recommendation engine is a feature (not a product)". As a side project I built an e-commerce recommendation engine part time over 2-3 months. I didn't want to build out a massive product database and I didn't want to ask users to fill out lengthy profiles so I leveraged existing product and social APIs to handle both. It wasn't very difficult to get something that worked reasonably well - though competing solutions were mostly far worse so maybe I'm selling myself short. In the end it was decently well received (had some press, good user feedback, thousands of initial users) but it failed as a standalone business. Cost of customer acquisition vs customer lifetime value just wasn't there. I've seen no one else succeed in the space so I think the net takeaway is what I referenced at the top - it's really more of a feature than a standalone product. Building the world's best recommendation engine is really just a piece of the puzzle.
I would include recommendation systems based on 'human generated lists'. See: http://www.google.com/patents/US8108417 I have developed these and they are far more powerful and relevant to the subjective user tastes involved with light-weight approaches related to collaborative filtering. An ensemble approach is absolutely the best while also keeping in mind that one user might think they've struck gold in terms of a result while another may not - recommendation systems are highly subjective. However, we had 50mil MAUs and 250mil searches every month and found out that there are ways to get around that. Some are psychological, for example, some users do not want to be 'told' or recommended something by someone else much less an algorithm - they would rather 'Discover' something. This depends on the product context. Is the product space related to music, shoes, books, dates etc. Labeling your recommendations as 'discoveries' works better in some cases, it depends on the user context and the product context.
Everything is a recommendation engine. Mimicking the way humans recommend things to other humans/friends is the ultimate way to build algorithms and architecture for recommendation systems.
One more thing, never forget to include a great spellchecking system, it's icing on the cake here.
Many things can be learned from what's inside Google, Apple, IBM patents. Learn from what inside patents. It's a great way to spark ideas as opposed to going in blind.
I disagree. My company (ePantry) has only hundreds, not thousands, of distinct products, but making recommendations is incredibly important. Showing users the right product at the right time ensures they get the items they want, and it moves the needle on average basket size.
I tried a number of off-the-shelf recommendation systems, none of which worked for the comparatively dense matrix we have (since we only have a few hundred products). I finally rolled one in house which took a few days of work (thanks, redis!) and has a bunch of custom filters that OTS systems wouldn't ever have.
I hate building stuff like this when OTS is available, but everything was overkill, or too hard to configure, or initially gave bad results and required too much black-box tweaking. It's been a success and was way easier than I thought.
Title is a fudge – the article should really be titled "Why you should not build a recommendation engine unless you have lots of existing users and vast amount of content". That message is a lot more common-sensical, from a stats perspective.
Title is a fudge – the article should really be titled "Why you should not build a recommendation engine unless you have lots of existing users and vast amount of content". That message is a lot more common-sensical, from a stats perspective.
Nonsense. The OP sets up a straw man just
to knock it down. The descriptions of
recommendation engines are naive,
uninformed, narrow, and not
at all comprehensive.
What can be done with good applied math
for making recommendations has variety
nearly beyond belief; the approaches
outlined by the OP are, of course, just
silly.
For the cold start problem, that need
not be very difficult -- just start in
niches.
Prioritize building your rec engine feature after you've built user on-boarding features and product on-boarding features because without users and products, rec engines contribute 0 value.
If someone told me to build a recommendation engine, I'd basically use a knn-approach.
You'd need to define
- a similarity measure for users (based on, e.g., what they bought and what they looked at) and
- you just recommend the top items the k nearest users bought (weighted by distance), possibly subtracted by the items already bought by the user in question and cleaned from explicit items.
Of course, the system would start really bad but it would get gradually better. This doesn't sound too complicated nor too simplistic nor "heavy data science".
Unfortunately there are no real technical insights in the article justifying why I shouldn't do this, so anyone can tell me why my approach would be bad or good?
I have to disagree with the definition: "A recommendation engine is a feature (not a product) that filters items by predicting how a user might rate them."
The feature bit is correct, but the rating bit might not be. People very often give high ratings to things they are not interested in. People may highly rate jewelry that they cannot afford, or give a five star rating to a movies considered classics, that they don't actually want to view.
What you are trying to optimize is ultimately purchasing, continued subscription, ad views, or some other profit metric. That can be hard to directly measure, so something like ratings can be a stand in, but you may accidentally optimize for something deeply undesirable like recommending expensive jewelry to everyone that they will never buy.
18 comments
[ 2.8 ms ] story [ 52.6 ms ] threadManually picking stuff is time consuming and might become stale quickly while a basic recommendation engine will take you a day or two. The whole point is to simply expose your consumer to more of your other products in the hope that they engage with one. If you have a wide scope of products, presenting the same tiny number of manual picks would be insane. Editors picks only works if you have a tiny number of products.
So build one if you want. And don't be afraid to make a slightly shit one either. As it's often better than tying up your time manually picking stuff out when you could be doing something better with your time.
Better to analyze the latent factors, and then use that analysis to gain engineering-type insights into the structure of the problem, and target specifically what's driving people to like something. Exactly as Netflix has been doing in recent years. Exactly as people have done when writing books or developing other entertainment content for centuries.
Just dumping unsupervised clustering on the end users is a poor technique that should stay in the 1990's where it belongs.
I also don't like the idea it takes mysterious, scary "hefty data science" to be able to do recommendations.
- If you're recommending based on one thing (i.e. "people who viewed this also viewed.."), you'll be doing cosine similarity on the vector of viewers (i.e. the columns of the user x item matrix).
- If you're recommending based on many things (i.e. "recommended for you"), you'll be doing a matrix factorization of the user x item matrix. Pick SVD or NMF, depending on how sparse the data is.
- You probably won't be doing content based recommendations, without doing breakthrough machine learning research. For a lot of content, no-one really knows how to do this.
I would include recommendation systems based on 'human generated lists'. See: http://www.google.com/patents/US8108417 I have developed these and they are far more powerful and relevant to the subjective user tastes involved with light-weight approaches related to collaborative filtering. An ensemble approach is absolutely the best while also keeping in mind that one user might think they've struck gold in terms of a result while another may not - recommendation systems are highly subjective. However, we had 50mil MAUs and 250mil searches every month and found out that there are ways to get around that. Some are psychological, for example, some users do not want to be 'told' or recommended something by someone else much less an algorithm - they would rather 'Discover' something. This depends on the product context. Is the product space related to music, shoes, books, dates etc. Labeling your recommendations as 'discoveries' works better in some cases, it depends on the user context and the product context.
Everything is a recommendation engine. Mimicking the way humans recommend things to other humans/friends is the ultimate way to build algorithms and architecture for recommendation systems.
One more thing, never forget to include a great spellchecking system, it's icing on the cake here.
I tried a number of off-the-shelf recommendation systems, none of which worked for the comparatively dense matrix we have (since we only have a few hundred products). I finally rolled one in house which took a few days of work (thanks, redis!) and has a bunch of custom filters that OTS systems wouldn't ever have.
I hate building stuff like this when OTS is available, but everything was overkill, or too hard to configure, or initially gave bad results and required too much black-box tweaking. It's been a success and was way easier than I thought.
What can be done with good applied math for making recommendations has variety nearly beyond belief; the approaches outlined by the OP are, of course, just silly.
For the cold start problem, that need not be very difficult -- just start in niches.
value = k1 * users + k2 * products + k3 * products * users
Prioritize building your rec engine feature after you've built user on-boarding features and product on-boarding features because without users and products, rec engines contribute 0 value.
You'd need to define
- a similarity measure for users (based on, e.g., what they bought and what they looked at) and
- you just recommend the top items the k nearest users bought (weighted by distance), possibly subtracted by the items already bought by the user in question and cleaned from explicit items.
Of course, the system would start really bad but it would get gradually better. This doesn't sound too complicated nor too simplistic nor "heavy data science".
Unfortunately there are no real technical insights in the article justifying why I shouldn't do this, so anyone can tell me why my approach would be bad or good?
The feature bit is correct, but the rating bit might not be. People very often give high ratings to things they are not interested in. People may highly rate jewelry that they cannot afford, or give a five star rating to a movies considered classics, that they don't actually want to view.
What you are trying to optimize is ultimately purchasing, continued subscription, ad views, or some other profit metric. That can be hard to directly measure, so something like ratings can be a stand in, but you may accidentally optimize for something deeply undesirable like recommending expensive jewelry to everyone that they will never buy.