最好走的路越走越难,最难走的路越走越容易

Follow guwendong on Web
  • Subscribe to Beyond Search via RSS
  • Follow @clickstone on SinaWeibo
  • Join Resys Google Group
  • Follow @clickstone on Douban
  • Follow @clickstone on Twitter

Category Archives: 推荐系统

购物车推荐

忘记在哪里看到了这么一个说法,“在结算的时候如果有太多交叉销售的选择的话,可能会让客户迷惑,反而放弃订单”。这句话涉及到电子商务领域的一个重要问题,如此定性的结论显然是不太负责任的,比如何为“太多”。遂在 twitter 上发问。@imrchen 回复说,

只要有“太多”選擇,消費者就會卻步,不論這些選擇是怎麼來的。Barry Schwartz 的 The Paradox of Choice 就很強調 Less is More 這件事。

那么,对待交叉销售问题,业界到底是怎么做的呢?让我们一探究竟。

我选了两本书进行实验:《末日之书》,这个来自豆瓣友邻推荐;《时间旅行者的妻子》,这个是因为我很想看同名电影

第一站,当当

1)进入购物车之前

  • 搜索书名,居然没有输入提示!
    意见:太 out 了,这个应该算是标配了吧。
  • 点击搜索结果里面的对应条目,弹出新窗口进入详细信息页面。
    意见:虽然弹出新窗口基本上已经是中国网民最喜闻乐见的体验了,但我认为也不能乱用。我已经找到了我要的东西了,你还留着这个结果页面搞球啊,我还得费劲把它关了。当然了,我这里是基于使用精确搜索的场景得出上面的结论。使用模糊搜索的场景,保留结果列表页是说得过去的,但我觉得还是需要分析下搜索数据,看哪种比例高。当当购书整体走下来,最突出的问题就是弹出的新窗口太多了。
  • 在书籍详细信息页面里,点击“购买”,又弹出了一个新窗口进入购物车。好吧,我忍了。

2)购物车内

上图是当当的购物车推荐区域,标题是“根据您挑选的商品,当当为您推荐”。

  • 位置,横在页面上部。
    意见:放在这里应该是觉得它比较重要,但在设计上与下面的“已购商品”产生对比,被弱化了很多。
  • 每个推荐商品,显示名称/市场价/当当价,共 3 项信息。
  • 名称有显示不完整的,鼠标放在链接上会提示完整名。
    意见:不能够直接显示完整商品名,感觉不太好。
  • 推测当当应该是认为,市场价/当当价对比,是用户购书关注的一大指标。
  • 推荐条目总共 8 条。
    问题:数目是怎么确定的?

上图是当当的已购商品区域。

  • 位置,无论视觉上,还是设计上,这个区域都是中心。
  • 显示商品名/单品积分/市场价/当当价/优惠/数量/共节省/共获积分/总金额,共 9 项信息。
  • 灰掉了“积分/市场价”,应该是想强调一下“当当价”。
    问题:如果认为灰掉的两项不重要,是否有更好的处理?
  • 变换颜色强调了“共节省/积分”,特别突出的是“总金额”。
  • 提示并进行了“图书促销区”活动的导航。
  • 可以修改商品数量,以及删除商品。

上图是特惠区的促销信息。

  • 位置在页面最下面,一般很难看到。我个人持保留意见,放在此时此地能有用吗?

3)个人看法

  • 要赞一下当当的推荐算法团队,有功力,购物车推荐的相关性不错,多样性也照顾到了。
  • 要搞清楚一个重要问题,基于当当目前的情况,购物车的首要目标是什么:刺激交叉销售,提高单个订单的总金额?还是尽量减少对结算的干扰,以保证订单地完成率?
  • 不了解设计初衷,但感觉购物车推荐部分的产品设计还有提升空间。套个专业术语,信息架构没整明白。

第二站,卓越亚马逊

1)进入购物车之前

  • 搜索书名,Bingo,有输入提示!看来 Amazon 代表了先进生产力啊。
  • 点击搜索结果里面的对应条目,当前页转入详细信息页面。
    问题:是否能够说明在卓越亚马逊这里,使用精确搜索的用户是占大多数的?
  • 在书籍详细信息页面里,点击“购买”,当前页转入购物车。好吧,我承认我是 Amazon 的拥趸。

2)购物车内

根据最近加入购物车的一个商品,在购买操作维度给出的推荐。总共 6 条。

根据最近加入购物车的一个商品,在浏览操作维度给出的推荐。总共 3 条。

根据购物车内的其它商品,在购买操作维度给出的推荐。总共 3 条。

上面三个图片是 Amazon 购物车推荐的三个区域,标题是我们喜闻乐见的“买了… 还买了…”的经典句式。

  • Amazon 清晰地传递了它的理念:购物车的核心目标是,使用交叉销售帮助用户完成更多地购买。
  • 购物车推荐区域基本上进行了满屏显示,无论视觉上,设计上,还是事实上,这里都是中心。
  • 每个推荐商品,显示图片/名称/卓越价/打星/评论数,共 5 项信息。商品名称全部完整显示。
  • 相比文字,图片能够更加有效地传递信息。
  • 三个推荐区域的条目数分别是 6/3/3,总共 12 条。

上图是已购商品区域。

  • 位置,在页面的右上部的独立区域。通过区别于其他的色块设计,使其也足够突出。
  • 显示商品名/作者/包装/卓越价/数量/总金额,共 6 项信息。
  • 突出了商品的卓越价及订单总价。
  • 不能直接修改商品数据,也不能直接删除商品。
  • 有一句看似很多余的提示语,“购物车中的商品价格与该商品页面显示的最新价格一致”。

3)个人看法

  • 卓越亚马逊显然用的是 Amazon 总部的推荐技术,效果毋庸置疑。
  • 细节上仍有待注意,推荐区域稍嫌散乱,且时常可以见到商品图片无法显示的情况。

关于购物推荐

用户购买一件商品,有两个阶段:首先是要知道有这么一个东西;然后评价一下是否需要购买,做出决定。
当当的推荐完成了第一个阶段,能够把相关性比较好的东西自动推给用户,但基本上到此就停住了,在帮助用户作决定这个阶段几乎没有作为。
细节处见真章。可以看到 Amazon 对推荐这件事情的理解的确更加到位。通过给出“打星”与“评论数”,为用户做出决定提供了一些参考。但请注意,我说的不是卓越亚马逊,他抄都没抄明白,Amazon 在同样的地方,还另外给出了书籍的作者,而卓越似乎是自作主张地去掉了。要知道,作者可是用户决定购买一本书的重要因素!

结论

内容写着写着就有点儿发散了。
转回头来,开篇的那句话,其实说的是“Shopping Cart Abandonment Rate”,它是电子商务领域的一个核心问题。它非常重要,因为可以抛开其他所有因素,只需要单纯把这个比例降低,销售收入就能够增加。但也正因为如此,一般的电子商务网站对待购物车都是格外的小心翼翼。这个事情的做法上,没有绝对的正误,一定要数据说话。
但评定标准绝对只有一条。搞清楚我之前提到的那个问题:

  1. 刺激交叉销售,提高单个订单的总金额;
  2. 尽量减少对结算的干扰,以保证订单地完成率。

哪一个能够提升最终的销售收入,哪一个就是你当前的最佳选择。

Update: 开篇的那句话来自 Tangos 的“支付结算页面造成客户流失的常见问题”这篇文章。非常抱歉,我误解了 Tangos 的原意,他说的是“支付结算页”,而不是购物车页面。一旦进入结算流程,现在业内应该已经是统一的做法了,不做任何其他产品的推荐,甚至连导航栏都全部去掉,不让任何因素影响结算完成。虽然跑了题,但这篇文章的内容应该还是具备参考价值的。

 

啤酒和尿布的故事

Resys Group 里的这个讨论而起,又有朋友找我问起了啤酒和尿布的故事~

Long long ago,有这么一个故事。
在一家超市里,有一个有趣的现象:尿布和啤酒赫然摆在一起出售。但是这个奇怪的举措却使尿布和啤酒的销量双双增加了。这不是一个笑话,而是发生在美国沃尔玛连锁店超市的真实案例,并一直为商家所津津乐道。原来,美国的妇女们经常会嘱咐她们的丈夫下班以后要为孩子买尿布,而丈夫在买完尿布之后又要顺手买回自己爱喝的啤酒。

第一次听到这个故事,是在研一的数据挖掘课程上。当时导师讲完之后,我感觉这是个非常神奇的事情。

这之前我最崇拜的是一位名叫泰勒的大哥,此人左手一个小本,右手一支铅笔,脖子上挂着个秒表,没日没夜地,站在那里观察啊,观察啊,观察啊……观察什么啊?挖煤。对,确实是挖煤。就是这个办法,他凭借一己之力,开创了对工业界,尤其是对日本工业界影响深远的时间动作研究,被后人尊称为工业工程之父。

仰望着泰勒,我想,我要是也用泰勒大师的办法,是不是也能搞一个购物动作研究,成为超级市场之父呢?我为自己的灵光乍现而欢呼雀跃,I fucking couldn’t be happier!可转念又一想,那我得写秃多少支铅笔,按坏多少个秒表啊。我没有风险投资,这事儿干不了。

下课回到宿舍,我是埋头狂啃了几天关联规则算法。在自认为得道成仙之后,我便开始四处招摇,逢人便问。
我:你认识“啤酒兄”吗?
~摇头~
我:哦,不认识。
我:那你认识“尿布兄”吗?
~继续摇头~
我:什么,这个也不认识!
我:那算了,你还是回火星去吧。
时间长了,问得多了,我才弄明白,原来“啤酒兄”和“尿布兄”才是真正的火星人,在时间回旋里面,一时半会儿到不了地球,很不靠谱。

现在这事儿靠谱了,都有人专门为这两位仁兄著书立传了。等地球人都认识了他们,数据挖掘从业者的春天就真来了。

其实当年在课上,导师已经和我们说了,这个故事多半是有一些些杜撰的成分在里面的,并且这个故事其实是有多个版本的。但数据挖掘技术需要发展,需要进入业界,需要产业化,就必须有一个简单易懂的故事。就好像一提到进行诚实教育,大家自然就会想到“狼来了”,它通俗、易懂、好接受、容易记忆。故事不一定真实,但结论足够说明问题。

我有一位朋友,01 年本科毕业去了 IBM。在他给 IBM 的求职信上,有一段话让我印象深刻。原话记不住了,大约是这样:
“我喜欢写程序。
当我的同学们在浩渺的星际争霸战场上鏖战,或者围坐在饭岛爱老师身边激昂人生的时候,我却孤独地在 MFC 中深入浅出,每一行优雅的代码,都仿佛美丽的音符一般,让我深陷其中无法自拔。
学习就像太空冒险,越是深入,越能体会到他的博大精深。”

让我们共勉。

 

怎样利用 GReader Share 数据?

这篇文章试图讨论一下郑昀在《基于Google Reader发展起来的个性化推荐系统之三大问题》一文中提出的一些问题。提请注意,我这里的观点是基于 GReader Share 数据限定之下的。

一、火星人现象
郑昀认为主要原因是:“推荐系统无法获知用户以前的知识结构”。

  1. 这是问题一:从根子上就无法完整反映用户的阅读经历。
  2. 这是问题二:如此大量的阅读视野狭窄的用户,推荐系统能否发挥作用呢?

对于问题一,解决办法我觉得只有两个。

  1. 尽可能多的扩展公开的数据源。比如,看我在 twitter 上推过哪些短址;看我在 delicious 上收藏了哪些链接;看我在 douban 上分享了哪些内容。GReader 的用户差不多都是网络的重度使用者,这方面可用的来源肯定不少。比如我,如果你订阅了我的 FriendFeed,那么我一天在看什么,你就差不多能知道一个大概了。
  2. 需要时间来积累。

这个问题,没有捷径。

对于问题二,其实之前在 kuberfeedzshare 的时候,我就和他讨论过。当时说了要写一篇 blog 的,后来由于我太懒就作罢了。我个人意见,GReader Share 的数据不适合做推荐,应该拿来做过滤器。这个后面展开。

二、有时效性和无时效性
大多数情况下,这个世界并不是非黑即白的。
对于时效性,我个人觉得别把它作为一个太过绝对的概念,它是和人相关的,应该作为一个相对的概念来理解。对于新近才接触某个领域的人来讲,翻翻老皇历也是有必要的。比如你看了我之前这篇的唠叨,对汪峰起了兴趣,那挖出他在鲍家街的老八卦看看也挺有意思,这些信息是新鲜的。而对于同样的内容,给我看就没什么意思了,它们out了。

因此,除了像刘未鹏所指出的“将文章分为有时效性(如新闻时政类)和无时效性(如读书笔记、GTD方法等)”这个方法,我觉得还可以从用户这个角度做一些事情。简要来讲,第一,划分用户关注的领域,这个基本是文本分类的问题,方法有不少,但大规模做起来很难,当然也并没有难到不可解决;第二,让用户方便地在时间线上游动,这个需要考虑呈现方式,给个带时间的列表是一种,高级点的像下面这个

三、惊喜很难吗?
我的回答是:确实很难!非常之难!
对于推荐系统的制作者,如果能让用户发出像 @imrchen 这样的感慨,那将是对其工作的最高程度的肯定。

@imrchen: 太神奇了,Amazon 竟然向我推薦 Python 書籍,我從來不曾在亞馬遜買過程式設計的書籍,最近買的和技術有關的書是 Beautiful Data,和 Python 完全搭不上邊。他們怎麼知道我最近在用 Python 開發東西,這樣的推薦未免也太神了吧!?

一个好的推荐系统制作者,需要钻研数据,精修算法,勤于思考,同时最重要的,要有一颗真正愿意帮助用户解决问题的心。

GReader Share 的数据更适合做过滤器

郑昀的文章里面,把 GReader Share 数据所存在的问题已经讲得很清楚了:基于 Google
Reader 的第三方推荐系统,能够拿到的数据是严重不足的。

你无法知道用户有意忽略了哪些文章,你很难拿到他的好友列表,Google不像
FriendFeed那样提供Dislike/Hide的按钮;你只知道他何时Share或like了某篇文章从何处(值得注意的一个细节是,如果用户是
自己订阅了煎蛋并推荐其中一篇文章,显然煎蛋对用户来说更加重要;相比而言,用户只是从其他人的Shared
Items订阅中share了煎蛋的某篇文章,却不去订阅煎蛋,说明煎蛋对他来说可能还不算重要。这个细节有点像“quick
stumbles”的思路)。

在这样的情况下,有效的方法就是最大化已有数据的能量,解决 GReader 本身尚未解决的一个重要问题:如何对阅读列表进行有效的组织。

1、计算 FollowRank
我曾经在 twitter 上感谢过 @imrchen,因为我发现,我好友的 Share List 里面,让我有精读冲动的,好多都是他 Share 出来的。@imrchen 的例子是我自己人肉过滤出来的,其实这个计算是可以自动化的——协同过滤里所有的 User-based 使用的相似度计算方法这里都适用。然后,根据相似度,我们取 Top50 作为我们的推荐种子,可以得到一个推荐列表。kuber 和 xlvector 应该都是这么做的,这也是最标准的 User-based 方法。

但,对于 GReader Share 数据,我建议再多考虑考虑。

这里面有个典型的例子,应该有好些人都订阅了 keso’s view,然后看到好文章就从这个列表里面进行 ReShare。对于这里面的活跃用户A,如果你用 A 的 Share List 和 keso 进行计算的话,有可能就会因为相似度很高,把 A 加入到了给 keso 进行推荐的种子用户里面。这显然是存在问题的。GReader Share 的产品设计,加重了单向 Follow 的因素,因此在种子用户的选择上,必须对传统 User-based 方法进行修正。

GReader 目前尚未提供相应的 API 获取用户的 Follow 数据,另外似乎也没有提供 Share 的时间让我们可以排排序,因此,要得到 ReShare 线路图应该是不太可能的。我这里提供一个变通的思路供讨论。
假设从用户A的 Share List 出发,查找和 A 共同 Share 了某篇文章的用户,可以得到一个候选用户集 ASet。然后设计一个公式,对隶属于 ASet 的用户B,综合考虑下面几个因素。

  1. BShare 包含的来源数目。
  2. 只有 B 单独 Share 的文章数量。
  3. 有 B 参与 Share 的文章,统计总 Like 数和 Share 数。
  4. AShare 与 BShare 交集数量 / AShare 数量。
  5. 第4项得分超过某阙值的周期数。

我把依此计算的结果,定义为用户A对用户B的 FollowRank。

剩下的就简单了,取 FollowRank 的 Top50 作为种子,得到候选集,阙值过滤,排排序,搞掂。

2、区分最新/最热的与我最感兴趣的
时常可以看到关注于解决信息过载问题的探讨,我个人认为,万里长征第一步,就是把用户感兴趣的摘出来,其他的按最新/最热排序。对于 GReader Share,做到此足以。

分析用户的兴趣,前面讲到了可以使用文本分类的办法。简单的还有基于 tag 的办法,不过第三方应该是无法获取 GReader 用户的 tag 数据的,此路不通;但可以绕,比如从 delicious 上提取 url 对应的 tags;然而对于中文内容,delicious 能够提供的帮助相当有限。因此,这里我建议可以考虑使用类似于内容基因的办法,说白了就是基于关键字的方法。我曾经在一些豆瓣影评数据上实验过抽取电影基因,得到的关键字组合还是挺靠谱的。我相信类似的算法用在 GReader Share 上效果应该也不会差,因为 GReader Share 数据集的文章质量应该还是比较好的。

目前在 GReader Share 数据的再利用方面,最领先的无疑是 玩聚SR,但它解决的是社会化排序的问题,是非个性化的。总体来讲,GReader 在个性化方向上能够提高的地方还有很多。像郑昀、kuber、xlvector 这样对此感兴趣的第三方开发者不妨加紧实践,没准哪天就被 Google 收编了。

有兴趣进行讨论的,移步这里

 
猛戳这里

简网指阅 联合创始人 & CTO
ResysChina 发起人
1. 持续关注 个性化推荐 技术;
2. 持续关注 Semantic Web 技术;
3. 评论与上两项相关的互联网业务与产品;

我相信技术的力量!
wendell.gu@GMail.com

Archives