标签归档:内容推荐

基于KNN的相关内容推荐

  如果做网站的内容运营,相关内容推荐可以帮助用户更快地寻找和发现感兴趣的信息,从而提升网站内容浏览的流畅性,进而提升网站的价值转化。相关内容推荐最常见的两块就是“关联推荐”和“相关内容推荐”,关联推荐就是我们常说的购物篮分析,即使用购买了某商品的用户同时购买了什么这个规则来发现商品间的潜在联系,之前有相关的文章介绍——向上营销、交叉营销与关联推荐;关联推荐是基于用户行为分析的推荐,而相关内容推荐是基于内容固有特征的推荐,只与内容本身有关,与用户的行为完全无关,所以相关内容推荐的模型是一种“冷启动”的算法,不需要任何历史浏览访问数据的支持。

内容固有属性

  相关内容推荐因为完全不借助用户浏览行为的数据,所以底层数据不依赖于网站的点击流日志,唯一的基础数据就是内容的固有属性及完整信息。我们以豆瓣网的几大块内容为例来看看对于这些内容一般包含哪些固有属性:

书籍 书名、作者、出版时间、出版社、分类、标签
音乐 专辑名、歌手、发行时间、发行方、风格流派、标签
电影 电影名称、导演、演员、上映时间、制片方、类型、标签

  豆瓣很多地方都使用了“标签”这个词,用贴标签的形式来完成内容的分类和标识,但其实标签又分为很多种,有些标签是在内容生成时就被贴上的,有些可能是后续用户贴上去的,而且豆瓣一般为内容和标签定义了原始分类,如书籍分为文学、流行、文化……既然分类和标签内容源生就带有,那同样可以作为内容的固有属性。

  还需要说明的是,这里不涉及文本挖掘和字符切分模糊匹配等问题,因此内容的标题、简介和全文不参与文本相似度的分析,虽然这些可能在构建完整的相关内容模型中不可缺少,但这里只考虑一些固有属性是否相同实现简单应用。基于上述豆瓣几类内容的属性特征,选择和整理适合分析的内容属性如下:

attributes-of-content

  “作者”就是指内容的创造者,“来源”指内容的发布方或获取渠道,“分类”为内容归属的类别,“标签”可以包含对内容的各类描述信息和关键词等。这里为了能够尽可能清晰地描述整个分析模型和思路只选取了大部分内容都包含的一些属性,如果要构建更加高效的相关内容分析模型,需要更完整的内容属性,可以根据自身内容的特征进行属性的定义和选取。

KNN算法及应用

  KNN(K-Nearest Neighbor algorithm),K最近邻算法,通过计算样本个体间的距离或者相似度寻找与每个样本个体最相近的K个个体,算法的时间复杂度跟样本的个数直接相关,需要完成一次两两比较的过程。KNN一般被用于分类算法,在给定分类规则的训练集的基础上对总体的样本进行分类,是一种监督学习(Supervised learning)方法。

KNN

  这里我们不用KNN来实现分类,我们使用KNN最原始的算法思路,即为每个内容寻找K个与其最相似的内容,并推荐给用户。相当于每个内容之间都会完成一次两两比较的过程,如果你的网站有n个内容,那么算法的时间复杂度为Cn2,即n(n-1)/2。但是用内容固有属性有一个好处就是因为固有属性一旦创建后基本保持不变,因此算法输出的数据一旦计算好之后不需要重复计算去刷新,也就是对于网站内容而言,原有内容的数据在首次初始化之后可以不断重复使用,只要更新新增内容的数据就可以,数据的统计计算可以使用增量更新的形式,这样可以有效地减少服务器的计算压力。

相关内容模型

  有了基础数据和算法的支持,我们就可以创建数据模型了。先看下基础数据的类型,作者、分类、来源和标签都是字符型,其中作者、分类、来源基本可以当做是单个值的属性,标签一般包含多个值。首先由于都是字符可以确定属性之间相似性的判定只能通过“是否相同”,无法体现数值上的差异,所以对于作者、分类、来源这几个单值属性而言,比较的结果就是一个布尔型的度量,相同或者不相同;对于标签这个多值属性可以考虑使用Jaccard相关系数,但因为每个内容标签的个数存在较大差异,使用验证后的结果并不理想,所以不考虑使用(当然,如果内容的标签个数比较固定,Jaccard相关系数是有效的)。因此,直接创建加权相似度模型如下,首先是标签的相似度分值设定:

相同标签数 图书比例 相似度分值
0 70% 0
1 20% 1
2 6% 2
3 3% 4
>=4 1% 5

  再结合作者、分类和来源,通过加权设定总体的相似度分值:

属性 相同时分值 不同时分值 权重 加权分值分布
作者 1 0 25 [0,25]
分类 1 0 10 [0,10]
来源 1 0 15 [0,15]
标签 [1,5] 0 10 [0,50]

  将所有属性加权相似度分值的结果相加应该分布在[0,100],分值越高说明内容间的相似度越高。对于这种简单的加权相似度评分模型,估计又有很多人要问权重是怎么确定的,确实,这里的权重并没有通过任何定量分析模型的方法去计算,只是简单的经验估计,但估计的过程经过反复地调整和优化,也就是不断地尝试调整各属性的权重系数并输出结果,抽样检验结果是否符合预期、是否有提升优化的空间。

  基于上述内容间相似度的计算结果,套用KNN的原理实现相关内容推荐就异常简单了,只要根据每个内容与之比较的所有内容的相似度分值降序排列取前K个内容作为该内容的最相关内容推荐给用户就可以了。当然中间可能会涉及相同相似度分值的内容如何排序的问题(因为模型的关系分值分布可能不会很离散),建议如果相似度分值相同使用随机排序,以保证推荐结果有一定的变化,均匀内容的曝光。

  好了,所有的分析流程介绍完了,好像跟前一篇的距离和相似度度量完全没有关系,其实距离和相似度度量是KNN的基础算法,因为KNN的个体相似度或邻近的距离都会选择距离度量和相似度度量中的某种方法进行计算,但这里考虑到了现实的数据情况和应用环境,并不是KNN就一定要硬套欧氏距离,其实换一种简单的方法可能反而更加适合整个模型,而且模型的最终效果可能会更理想。所以一切的数据挖掘算法的选择和使用都是基于数据模型的有效性和输出结果的效果来决定的,并不是简单的算法效果就一定不好,而高级复杂的算法一定更加有效。对了,如果你已经做了相关内容推荐,那么优化相关内容推荐这篇文章里面介绍的一些方法将是检验推荐效果的一个很好的参考。

优化相关内容推荐

——让用户更容易地找到需要的信息4

  博客之前的一篇文章——优化网站导航设计,介绍了如何评价网站导航功能及基于分析的优化。但后来才发现其中遗漏了Google Analytics上一个很实用的功能——Navigation Summary,字面上翻译是“导航概要”,但似乎用“页面上下游”(百度统计上的称呼,拿过来先借用下)分析更加贴切。它能够很好地分析网站导航的实现度(说得直观点就是导航功能上的有效点击或操作),下面就来介绍下这个功能。

更好地衡量导航实现度

  先看一下我的“文章专题推荐”这个导航索引页面的在GA的Navigation Summary报表(该功能在Content模块的Top Content标签下面):

featured-topics-navigation-summary

  从上图可以看到页面被浏览的次数(图中标注1),有多少的比例的Visits是从站外进入这个页面开始访问网站的(图中标注2),有多少的比例的Visits是从网站内部的页面跳转到这个页面的(图中标注3),有多少的比例的Visits在浏览的该页面后离开了网站(图中标注4),有多少比例的Visits从该页面进入了网站的其他页面(图中标注5,4和5部分现在貌似数据有点问题);同时列出了网站内部前10名的上游页面(浏览该页面之前用户所在的那个页面,图中标注6)和下游页面(浏览该页面后紧接着浏览的下一个页面,图中标注7),及它们各自所占的百分比。这里需要注意的是有时会在上游页面和下游页面出现与选择页面相同的URI地址,比如你选择首页(/)进行分析,上游页面和下游页面也出现了首页地址(/),这个主要是刷新操作引起的,GA会把页面刷新统计到Pageviews里面。

  通过上面这个功能,我们就不再需要通过导航页面的离开率(Exit Rate)来粗略估计有多少的Visits留在了网站并可能点击了导航页面的链接。并且通过Navigation Summary我们不仅可以看到有多少Visits从导航页直接离开了,而且可以通过分析导航页的下游页面更加准确地衡量有效点击率,排除那些刷新、返回或者调到其他非导航列表页的操作,将那些导航页面中的链接的点击率(%Clicks)相加,就是该导航页面的有效点击转化(CTR),也就是该导航功能的实现度指标了。以上表为例,排除返回首页(/)、页面刷新(/featured-topics/)及跳转到非导航页面中的页面(/about/、/site-map/等)这些点击,将剩下的实现了导航功能的有效点击率相加就是该导航功能的实现度,可惜GA上的上下游页面都只能显示前10个。

  上面是对前一篇关于优化导航设计的内容的补充,其实页面的上下游分析是一种很有效的网站分析方法,不仅可以用于分析导航实现度,下面介绍一下它的另外一种应用——相关内容推荐效果分析。

网站的相关内容推荐

related-content  博客之前的一篇文章——优化网站信息架构中介绍了大部分的网站可能都是基于树形结构来进行购建的,但是原始的树形结构本身存在一个问题就是叶子节点(或者说是网站的内容节点)之间没有直接的联系,也就是用户无法从一个底层的内容页直接跳转到另外一个底层内容页,需要返回首页或者中间导航索引页面才能进入其他的内容页面,从那篇文章的树形架构图中也有体现,底层页面之间没有直接相连的线条。所以很多网站都会在内容的结尾或侧边栏提供相关内容的推荐,比如亚马逊、淘宝等电子商务网站产品页面会有同类别、同价位的产品推荐,或者是用户在购买该产品的同时也购买了的产品推荐,豆瓣上的书籍、音乐、电影页面也提供了相关内容的推荐。

  这些功能很多都是基于内容相关度的算法来实现的,之前的文章——向上营销、交叉营销与关联推荐介绍过基于用户行为的关联推荐方法。其实很多博客也有类似的功能,即每个文章结尾的相关文章,下图是我的博客的电子商务网站RFM分析这篇文章的相关文章列表:

rfm-related-posts

  我是用Wordpress的插件——Yet Another Related Posts Plugin来实现这个功能的,按照插件的介绍,它是通过计算文章的标题、正文、标签和分类的相关度选取排名前几的显示到页面上。这个功能很棒,它打通了文章页面之间的通道,也许用户在看完一篇文章之后还想浏览下相关的文章,那么相关内容推荐就提供了很好的途径,用户不需要再回退到内容的检索页面,直接点击就行,帮助用户更加方便、快速地定位到想要寻找的信息上。

相关内容推荐效果分析

  网站中的相关内容推荐功能很多都是借助机器算法来自动生成的,所以从某种层度上来说,算法一定会存在优劣,我们需要通过分析来评估功能的实现效果,从而不断地对算法进行优化。而基于用户浏览行为的分析是评估功能实现效果的最有效的方法,所以网站分析又有了用武之地了,上面介绍的Google Analytics上的Navigation Summary就是非常适合用来分析相关内容推荐效果的工具。这里还是以电子商务网站RFM分析这篇文章的上下游页面分析为例看看我使用的这个插件的效果到底怎样:

rfm-navigation-summary

  从上下游页面的列表中查看那些来源于内容页面和去往其他内容页的比例,其中哪些页面的流入和流出的比例最高,然后再与网站相关内容推荐列表中的排名进行比较,这样就能反应网站功能的相关性与用户眼中的相关性是否一致,从而检验功能的实现效果。

  如果进行算法调整,那么同样可以用该方法检验算法调整前后的上下游页面转化比例,从而衡量在算法调整后相关内容推荐功能是否真正得到了优化。而我们要做的就是通过不断优化相关内容推荐的算法使网站内容的相关度排名与用户对内容的预期相关性尽量达成一致,这样才会使页面上显示的相关内容就是用户想要寻找的内容,从而满足用户的需求。

  这里需要注意几个问题:

  1. 也许一个内容页面里面会有不止一处的相关推荐模块,或者会有多处出现其他内容页的链接,在GA的报表上提供的是所有流入流出的总和,所以如果只是评测某一推荐模块的效果,需要区分该模块中的链接,也许加URL参数会是一个解决方案。
  2. 注意数据的时间区间与网站内容的变化带来的相关内容推荐的变化。Google Analytics上默认的时间区间是前一个月,你可以选择合适的区间来进行分析和比较,注意网站内容的更新对相关内容推荐带来的影响。
  3. 有些相关内容间的推荐并不是双向的,比如在购买MP3的页面推荐耳塞,而在购买耳塞的页面可能并不会去推荐MP3,所以有时有必要对上游页面和下游页面分开分析,注意转化的方向性。

  上面就是我想到的Google Analytics的Navigation Summary功能的两个应用实例,你是不是还想到了更多的应用,欢迎分享你的观点。

向上营销、交叉营销与关联推荐

  我们会发现很多网站都具备了内容推荐的功能,不仅是像B2C电子商务类的卓越的图书推荐,也包括兴趣类网站像豆瓣的豆瓣猜等。这类功能无疑在帮助用户发现需求,促进商品购买和服务应用方面起到了显著性的效果。那么这类的推荐是怎么得到的呢?其实跟网站数据分析不无相关,我们可以来简单看一下它的原理和实现。

  关联推荐在营销上被分为两类:

  向上营销(Up Marketing):根据既有客户过去的消费喜好,提供更高价值或者其他用以加强其原有功能或者用途的产品或服务。

  交叉营销(Cross Marketing):从客户的购买行为中发现客户的多种需求,向其推销相关的产品或服务。

  向上营销是基于同类产品线的升级或优化产品的推荐,而交叉营销是基于相似但不同类的产品的推荐。举个简单的例子,可以看一下苹果的产品线:

Apple-products-compare

当你购买一个ipod nano3的时候,向你推荐升级产品nano4、nano5或者功能类似的itouch就叫做“向上营销”;而推荐Iphone、Mac或ipad的时候就是“交叉营销”了。

  而关联推荐在实现方式上也可以分为两种:以产品分析为基础的关联推荐和以用户分析为基础的关联推荐。产品分析的关联推荐指的是通过分析产品的特征发现它们之间的共同点,比如《Web Analytics》和《Web Analytics 2.0》的作者都是Avinash Kaushik,而且书名都包含Web Analytics,都是网站分析类的书籍,同时也可能是同一个出版社……那么基于产品的关联就可以向购买了《Web Analytics》的用户推荐《Web Analytics 2.0》。而基于用户分析的推荐是通过分析用户的历史行为数据,可能会发现购买了《Web Analytics》的很多用户也买了《The Elements of User Experience》这本书,那么就可以基于这个发现进行推荐,这种方法就是数据挖掘中的关联规则(Association Rules)挖掘,其中最经典的案例就是沃尔玛的啤酒和尿布的故事。

beer-and-diapers

  目前很多的关联推荐还是基于产品层面的,因为实现上更为简单(对于网站而言,产品数据明显少于用户行为数据,而且可能相差好几个数量级,所以分析工作就会轻很多),基于产品的推荐更多地以上面所述的两种营销手段来实现,更偏向于传统的“推式”营销(个人对这种营销方式比较没有好感,尤其“捆绑销售”之类)。

基于用户行为分析的关联推荐

  所以个人更偏向于基于用户分析的实现方式,这样更有利于发现用户的潜在需求,帮助用户更好的选择它们需要的产品,并由用户决定是否购买,也就是所谓的“拉式”营销。通过向用户推荐产品或服务,激发用户的潜在需求,促使用户消费,更加符合“以用户为中心”的理念。所以下面主要简单描述下以用户行为分析为基础的关联推荐,无论你是电子商务网站或是其他任何类型的网站,其实都可以实现这个功能,只要你具备以下前提:

  1. 能够有效地识别网站用户;
  2. 保留了用户的历史行为数据(点击流数据(clickstream)或运营数据(outcomes));
  3. 当然还需要一个不错的网站数据分析师。

  这里以电子商务网站为例来说明一下关联规则的具体实现。目前大部分电子商务网站都提供用户注册的功能,而购物的用户一般都是基于登录的条件下完成的,所以这里为用户识别提供了最为有效的标示符——用户ID(关于用户识别的方法,请参考这篇文章——网站用户的识别);同时网站会把所有用户的购物数据储存在自己的运营数据库里面,这个为用户行为分析提供了数据基础——用户历史购物数据。所以满足了上述的前两个条件,我们就可以着手进行分析了。

  关联规则的实现原理是从所有的用户购物数据中(如果数据量过大,可以选取一定的时间区间,如一年、一个季度等),寻找当用户购买了A商品的基础上,又购买了B商品的人数所占的比例,当这个比例达到了预设的一个目标水平的时候,我们就认为这两个商品是存在一定关联的,所以当用户购买了A商品但还未购买B商品时,我们就可以向该类用户推荐B商品。如下图:

Relevance-Recommendation

  从上图可以看到其中牵涉3个集合:所有购买过商品的用户全集U、购买了A商品的用户集合A以及在购买了A商品之后又购买了B商品的用户集合G。基于这3个集合可以计算关联规则挖掘中的2个关键指标——支持度(Support)置信度(Confidence)

  支持度=购买了A和B商品(集合G)的人数/所有购买过商品(集合U)的人数

  置信度=购买了A和B商品(集合G)的人数/购买了A商品(集合A)的人数

  得到这两个指标之后,需要为这两个指标设立一个最低门槛,即最小支持度和最小置信度。因为在用户的购买行为中,购买A商品的用户可能不仅购买B商品,还购买了C、D、E……等一系列商品,所以我们需要分别算出所有这些组合的支持度和置信度,只有满足比如支持度>0.2,置信度>0.6的这些商品组合才可以认为是有关联的,值得推荐的。

  当然,如果你的网站不是电子商务网站,你同样可以用用户浏览网站的点击流数据实现关联推荐的功能。同样是基于用户历史行为,比如浏览了A页面的用户也浏览的B页面、观看了A视频的用户也观看了B视频、下载了A文件的用户也下载了B文件……

  数据挖掘中的关联规则挖掘一般采用基于频繁集的Apriori算法,是一个较为简单有效的算法,这里就不具体介绍了,有兴趣的朋友可以去查下资料。

在进行关联规则分析时需要注意的一些问题

  • 注意关联推荐的适用范围和前提条件,并不是每一类网站都适合或需要进行关联推荐的;
  • 最小支持度和最小执行度的设立需要根据网站运营的特征设定,不宜偏高或偏低,建议基于实验或实践的基础上不断优化,寻找一个最佳的权衡点。
  • 需要特别注意的是,在关联规则中A商品与B商品有关联,并不意味着B商品与A商品的关联也成立,因为两者的置信度算法是不同的,关联方向不可逆。
  • 关联规则分析在算法上其实并不难,但是要将其在网站上真正实现好,在满足上面3个前提的基础上还需要持续地优化算法,而更主要的是需要网站各部门的协作实现。

  所以,基于用户行为分析的关联推荐完全从用户的角度进行分析,比单纯地比较产品间的关联更为深入和有效,更加符合用户的行为习惯,有利于发现用户的潜在需求,不妨尝试一下。