Why You Should Not Build a Recommendation Engine
datacommunitydc.org
Why You Should Not Build a Recommendation Engine
1–10 of 19 posts
Re: Why You Should Not Build a Recommendation Engine
#2Re: Why You Should Not Build a Recommendation Engine
#3Manually 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.
Re: Why You Should Not Build a Recommendation Engine
#4Better 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.
Re: Why You Should Not Build a Recommendation Engine
#5I 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.
Re: Why You Should Not Build a Recommendation Engine
#6Re: Why You Should Not Build a Recommendation Engine
#7Ive been looking for an engine that can handle content-based recommendation
Re: Why You Should Not Build a Recommendation Engine
#8I 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.
Re: Why You Should Not Build a Recommendation Engine
#9Ive been looking for an engine that can handle content-based recommendation
Re: Why You Should Not Build a Recommendation Engine
#10I 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.