Jul 03
Rex分享 个性化推荐, 电子商务, 豆瓣
个性化技术就是通过技术手段对每个客户提供有区别的服务。往大了说是增强了用户体验、影响购物过程，往小了说就是就是给每个用户一个不同的页面。
个性化技术中最核心的内容就是个性化推荐系统。
个性化推荐最典型的应用案例就要数豆瓣了。豆瓣里面有一个“豆瓣猜”的功能，它是根据协同过滤算法猜测出用户最可能喜欢的图书、音乐或者电影。由于豆瓣有相当大的用户基数和优秀的算法，所以推荐的结果非常准确。
个性化技术影响着整个用户购物的过程。
- 售前：例如，服装网站个性化的虚拟试穿，豆瓣的豆瓣猜……
- 售中：例如，亚马逊购买一本书后，会推荐一些可能你还要购买的书，进行打包销售。
- 售后：根据客户的一些个人信息进行一对一的回访等。
个性化推荐系统的组成：
- 输入：隐式、显式输入、关键词和项目属性输入、用户购买历史、评分、文本评价、团体购买历史、项目属性
- 推荐：建议、预测、个体评分、评论（其他人的评分和评论）
- 输出：查询推荐、相似推荐、email、评论、评分、top_n、搜索排序……
下一篇我会结合一些电子商务网站的实例，来介绍个性化技术。
Apr 05
Rex互联网, 电子商务 amazon, Recommend, shopping, thisnext, 电子商务, 社会化, 豆瓣
上一篇Blog《一些社会化电子商务的网站》说，this next是一个“wiki型”的社会化电子商务网站。其实是很不负责任的，经过仔细的试用发现并不是哪么回事。如果非要定一个性，哪么this next也是“书签性”的。下面我就来捣鼓捣鼓他的主要功能：
推荐（Recommend）。This next 的主打功能，也是我说This next是书签型的原因。用户可以通过一个URL推荐商品，整个推荐过程的用户体验非常的好。尤其是在Firefox上的浏览器推荐按钮有一个缓缓下拉的效果，从未见过，超赞。同时程序可以自动的获取商品名称和图片，也可以自己上传图片，还可以给商品定一个色系，写一段推荐评论。整个过程相当的享受，但非要提出不足的话，就是当两个人推荐相同的商品的时候会产生两个商品页面，这样关于商品的评论就会分散。
Wish List：这也是一个超赞的功能。可能有些人认为，这样的设计是为了让某些人回过头来购买从前想买的东西。但是他忽略了可以看到Wish List的还有其他人。官方对Wish List的解释可谓是一语道破天际。“It’s also a great idea to keep updated so your pals will know what to get you for your birthday or Christmas.”呵呵，我女朋友一定喜欢这个功能。
List & Tag ：List就类似与豆列，Tag我还有说吗？
Shopcasting：可以理解成一个blog挂件，但意义却远不止此。（下面说）
联盟支持（Affilite Spport）：This Next的重头戏。用户可以提交自己的Amazon等一些网店的网站联盟账号。然后用户生成自己的shopcasting关在自己的Blog上。如果有人点击了这些连接进入了This Next，然后有从This Next进入了你所在联盟网商的网站产生了购物行为，哪么就相当于用户在你的网站上进入了联盟网商的网站产生了购买行为一样，你将拿到购买商品的提成。这个过程看似复杂，其实很简单。就是说只要是通过你的Blog进来的人，产生的提成全部归你，This Next分文不要。有人可能会问，这么干能盈利吗？当然能了，肯定有更多的人没有联盟账号，那样产生的提成不久是This next的了吗？谈到盈利模式，51fanli和支付宝的盈利模式也很值得研究。（跑题了，下回再说）
还有一项是想别的用户提问，不过是通过Email的方式。这样的方式和站内短息比较孰优孰劣很难说。
好了，功能就说这么多。总体上来说，This Next是有很多可以画圈的地方（传说中的可圈可点）的。1、用户体验一级棒，是我觉得体验最好的之一（豆瓣在还没有出九点的时候也是一级棒）。2、重视用户的权益，也就是指“联盟支持”，很大度也很聪明。3、没有自己做比价系统，而是采用shopping.com的数据。这一点在上一篇里已经提到了，在自己熟悉的战场作战，总会有别人没有的优势。4、Wish List女生一定喜欢。……
不足吗？其实不能说不足，他们的团队肯定也是经过深思熟虑的（毕竟已经上线两年了），只是觉得不适合我的地方，就是上面提到的那个无法给商品做一个智能的聚类。技术上应该不难实现的。再有就是Shopping.com的比价系统不准确。我推荐了一本豆瓣上的书，旁边的购买连接不知道给我链到了什么地方去了。
The End ！
Mar 20
Rex分享 算法, 豆瓣
豆瓣一直是中国web2.0的楷模，它神奇的“猜”功能吸引了无数的粉丝。他到底为什么有这么神奇的能力那？古老的读心术吗？当然不是，这全部得力于他的推荐算法。
所谓推荐算法就是利用用户的一些行为，通过一些数学算法，推测出用户可能喜欢的东西。推荐算法主要分为两种（还有一些可能不在本文讲述的范围内）基于内容的推荐和基于协同过滤的推荐。基于内容的推荐比较容易理解，他是通过两样东西的内容之间的相关性进行推荐。比如说，A喜欢一篇400字文章，里面出现了“豆瓣”这个词100次。哪么系统就会推荐一些同样出现了“豆瓣”这个词很多次的文章给A。这就是基于内容的推荐，他的好处是比较好理解、简单、高效，缺点就是只能用来推荐文章等一些文字的东西。对于图片等一些多媒体的内容就无从下手了。
基于协同过滤的推荐算法，正好弥补了这个缺点，他理论上可以推荐世界上的任何一种东西。图片、音乐、样样可以。协同过滤算法主要是通过对未评分项进行评分预测来实现的。不同的协同过滤之间也有很大的不同。
基于用户的协同过滤算法
这种算法基于一个这样的假设“跟你喜好相似的人喜欢的东西你也很有可能喜欢。”所以基于用户的协同过滤主要的任务就是找出用户的最近邻居，从而根据最近邻居的喜好做出未知项的评分预测。这种算法主要分为3个步骤：
一，用户评分。可以分为显性评分和隐形评分两种。显性评分就是直接给项目评分（例如给豆瓣里的书籍评分），隐形评分就是通过评价或是购买的行为给项目评分（例如在当当购买了什么东西）。
二，寻找最近邻居。这一步就是寻找与你距离最近的用户，测算距离一般采用以下三种算法：1.皮尔森相关系数。2.余弦相似性。3调整余弦相似性。调整余弦相似性似乎效果会好一些。
三，推荐。产生了最近邻居集合后，就根据这个集合对未知项进行评分预测。把评分最高的N个项推荐给用户。
这种算法存在性能上的瓶颈，当用户数越来越多的时候，寻找最近邻居的复杂度也会大幅度的增长。因而这种算法无法满足及时推荐的要求。基于项的协同过滤解决了这个问题。
基于项的协同过滤算法
根基于用户的算法相似，只不过第二步改为计算项之间的相似度。由于项之间的相似度比较稳定可以在线下进行，所以解决了基于用户的协同过滤算法存在的性能瓶颈。
豆瓣应该采用的就是基于项的协同过滤算法。但是他不可能只使用一种算法，肯定是综合了许多的算法。至于都有什么算法，比例是什么。那只有豆瓣的工程师知道，我们是猜不出来的。
Mar 10
Rex互联网, 读书 seo, 搜索, 豆瓣
发现悠悠买了新书《搜索引擎优化》。顺手借来看看。
虽然在豆瓣上虽然对这本书的评价很不高，但是他让我从另外一个角度重新认识了一次seo。
这不是一本讲述SEO技巧的书，而是把SEO放在一个业务的层面上来实施。
他提出了一个三个月的计划，一步一步的来实施SEO，并提供一个计划模板，用来跟踪、反馈SEO的效果。
看来SEO已经成为网站的一项业务而并不是codeing时的小技巧，跟我有一样想法的人要洗洗脑了。
我觉得这样书只需要看一下，了解一下大概的意思，等到有需要的时候再拿出来翻翻也不迟。
这本书的网站 http://www.yourseoplan.com/
Mar 01
Rex互联网 UE, 算法, 豆瓣
放假前就看了一系列的关于”好友“设计的文章。总想也以此为题写点什么，但是一拖就拖到了下一年。
引起这一系列他讨论的是”白鸦“发表的《常见功能设计之 “好友”》，里面主要思想就是，好友是单向的，加谁好友是我个人的自由，跟对方无关。所以他基本不赞同99%的”需要对方验证才能添加对方为好友”的做法。（最近看的一本书《small worlds》也提到了好友关系的不对称性）
后来，麦田为好友是双向还是单项做了一个分类，认为对于非专业的交友网站，或者网站主要业务不是建立在“好友”关系之上的网站，９９％的好友关系是单向的。而麦田所做的蚂蚁网就不能采用这种”轻盈“的单项好友的模式。原因是蚂蚁网是”已推荐为核心“的网络应用。推荐必须建立在双方相互确认的条件下。（这一点我本人不是很同意，具体的看法一会儿再说）
魏武挥又发表看法《好友 粉丝 偶像》，提出了所谓”好友，粉丝，偶像“的观点。认为双方认证的才是”好友“，单方面添加的是”粉丝“，单方面被添加的是”偶像“。他的观点应该是提倡单向好友的，并认为好友、粉丝、偶像这三种在单项好友模式下产生的三种状态都有其存在的意义。并且深化了麦田的观点”单向好友不是为了关系，而是为了阅读。“
白鸦借豆瓣改版又写了一篇blog：《再说“双向”好友。(谈豆瓣好友改版)》。借豆瓣的好友问题再一次的强调双向好友不符合人们的现实生活规律。
其实在讨论这个问题前，一定要解决另外一个问题。那就是什么才是网站里所谓的“好友”？只有弄清楚这个东西才能用现实中的规则来优化好友的功能。
先说一下网站里成为好友的几种情况：
- A加B为好友单纯的是为了使自己的“好友”数遥遥领先与其他人，而事实上A根本不认识B，甚至没有说过半句话。
- A因为B的某个东西（例如blog）开始想了解一下他，所以加B为好友，产生一些接触，之后两个人有没有了联系。但他们依然是“好友”。
- A因为B的某个东西（例如blog）开始想了解一下他，所以加B为好友，然后两人一拍即合、相见恨晚。从此两个人成为紧密联系的“好友”
- A认为B是他的偶像，加B为“好友”。目的是想了解偶像的动态。
- A和B以前就认识，理所应当的加为好友。
从这5中情况来看只有3和5才是我们现实中说的好朋友，而其他的情况只是两个人或多或少的存在某种联系而已。所以我下的结论是网站中的好友关系只是一种联系人的关系，并非好朋友。
基于”好友并非好朋友“这个基础，我认为大家讨论的好友应该是单向的还是双向的问题就比较好解决了。举个例子说：
- 我的手机里有几百个联系人，里面有我的朋友，同学，老师…………，里面有一些电话我会拨，但是有一些我是永远不会的（比如说，各科老师的电话，我是在有紧急需要的时候才打的但是这种情况极少）。这些人都是我的”好友“。但是老师那里99.99%没有我的号码。这说明了：”好友“有近有远，而且绝不是对称。
- 我虽然可以确定老师那里99.99%没有我的号码，但是我不能去看他的电话本确认。因为每个人的联系人是一种隐私。
- 我经常受到一些垃圾短信（我想是因为我的号码外泄被某人加为”好友“了）。但是我没有办法阻止他给我发短信，我只能在我的手机里面装一个短信防火墙来屏蔽它。只又一次说明”好友“绝对是单向的，而且我们无法阻止他人联系我，我所能做的只是在我这边阻止他。
- 我的QQ里面有分组，但是我很难把同学和朋友分成两组。这一点还是我的手机做的最好（WindowsMobile），在我查找联系人的时候他会自动的把最近联系过的的联系人放在前面。所以说“好友”的的亲密程度不是自己可以分得清的，但是可以通过算法提供一个较为实用的排序。
通过对这个手机联系人案例的分析，我们完全可以肯定：”好友“绝对是单向的。对于大家讨论的单项好友的一些弊端，我认为是因为没有建立一个好的好友模型的原因。下面就是我根据手机联系人建立的一个好友模型：
原理很简单就是在每个人的前面加一个代理机器人，用它来屏蔽一些我不想要的消息。这个代理机器人的功能有：
- 屏蔽未知联系人消息、
- 屏蔽特定联系人消息、
- 只向好友通知消息、
- 向指定好友发送消息、
- ……
使用这个好友模型就可以解决之前大家提出的问题。例如，麦田提出来的蚂蚁网推销员问题。A加B为好友，B没有加A。A推荐东西给B并没有任何动机问题，因为A认为B是他的好友。如果B觉得这是垃圾信息，完全可以用代理机器人屏蔽他（可能默认的规则就是屏蔽）。换个角度，如果B推荐给他的好友，这个信息当然不会推荐给A，因为B没有加A，甚至B根本不知道A加他为好友。还有麦田提出的一个顾虑：
“需要用户在内心建立两个模型：1，真正的好友（双向）；2订阅关系的好友（单向）。我认为，这样会为用户增加困扰，得不偿失。”
我觉得不然，用户更多的困扰因该是：好友太多，或者是没有好友。我提出的模型可以解决“好友太多和好友太少”的困扰。而真正的好友（双向）一定不会很多（现实中也是这样），没有人会去奢求太多。
RSS