[Jedd]

That's a lovely idea in theory, but in practice any recommendations made off three data points are far more likely to discourage than encourage you from ever using the service again.

Recommendation engines require a lot more training (by you) to be useful (to you).

Worse yet, without the modest investment in time, including thinking up a new password, there's a very high risk people will randomly click just to see what the results are, which muddies the water for other users.

In any case, non-identified recommendation source data would need to be kept in a silo until the user identified / validated they were not just fiddling around. And that becomes a major mess to manage the data.

Having said that, I do respect people's right to tilt endlessly at windmills in HN comments.

[prawn]

Couldn't it be done via cookie?

[Jedd]

Sure, but the big problem is not so much the tracking (IP, agent, cookie, etc) but the small number of data points.

To properly evaluate the quality of the data you can get out of a recommendation system, you need to put a useful amount of half-way decent data into it.

It's a relatively small cost to create an account -- it took me less than 30s, most of which was recording a new set of credentials in my password store.

One possibly intentional side-effect of requiring even a very simple registration process is that it may reduce the amount of cruft going into the engine. </speculating>

[amazon_not]

All that is all good and well, but for two things:

- it took me less time to input enough ratings to get useful recommendations than to register

- the registration asks for unnecessary information

Solution: if you don't want cruft in your dataset throw away recommendations not linked to a registration. If the users finds the recommendations useful, offer to save the profile by registering.

It's not like you are going to get any less cruft by forcing users tonregister. The only difference is that you are going to end up with a lot of throwaway accounts.