本文内容来自于近期神策数据举办的《智能推荐——应用场景与技术难点剖析》闭门会上的分享内容整理，分享者为神策数据副总裁张涛，曾就职于腾讯、映客和豌豆荚等知名互联网公司。
大家好，我是张涛，在加入神策数据之前的 10 年中，我一直在 C 端产品中从事产品设计和运营管理相关的工作，做的产品包括工具类、电商类、内容类等，在这个过程中，关于搜索推荐操盘过很多实践的项目，有从 0 开始做的，也有在中后期介入做优化迭代的。因此，今天关于推荐的分享可能不那么偏技术视角，这有一个好处，是帮助产品和运营人员更加了解推荐，也让技术更了解业务产品视角下的推荐。
今天的分享将为大家解答以下几个问题。你的公司是否适合采用个性化推荐？如果需要个性化推荐，该如何做好？产品运营在参与到一个推荐系统的构建当中，有哪些常见的坑？有哪些可以避开这些坑的一些简单方法？以及如何修炼成一个优秀的推荐产品经理？
一、 “四个关键”为你揭开推荐系统的神秘面纱
个人认为，推荐系统是根据用户以及不同的场景差异，对信息进行合理的排序、过滤，解决信息过载问题的一套机制。这个定义中包含四个关键点，如下：
1.“根据用户以及不同的场景差异”
对于很多刚开始做推荐的人可能会忽略这一点，大部分人在思考推荐时想的更多的可能是基于用户来做，但其实我从众多实践中发现，很多时候推荐产生价值不仅仅只是说以用户进行区分，相关场景的差异会对于最后推荐效果产生巨大的影响。
2.“推荐的本质是对信息进行合理的排序、过滤”
很多人认为推荐是一个魔盒，非常神奇，其实究其本质是企业有成千上万甚至上亿的 item，不管这些 item 是文章、视频，还是电商里面的商品，然后现在有某个人在一个具体的场景里面，企业需要把这些 item 给他看，那应该把哪个放在第一个？这就是推荐系统背后的运作原理。
3. “推荐系统要解决信息过载的问题”
举个例子，如果你的企业只做爆款商品，整个公司只卖两个商品，这样用户一看就明白了，显然也不需要推荐，所以做推荐的一个前提条件是你公司本身提供的业务里面的信息太多了，对于一个正常的自然人来说，他处理不了那么多信息的时候，企业才需要去帮助用户解决信息过载的问题，从而为用户设计这样一套机制。
4.“一套机制”
这点很好理解，推荐系统是由不同的算法、规则等构成的一套机制。这四点是我从产品视角为你解读了什么是推荐系统，以及他的一些简单作用。
二、推荐系统、广告系统、搜索系统三者有何不同？
事实上，解决我在前面提到的一系列问题，推荐系统并不是唯一的方法。比如，前面所提到的排序、过滤，做技术的同学应该很容易联想到，搜索和广告系统也涉及排序、过滤，且搜索也一定程度上解决了信息过载。那么，这三个系统，它到底有什么区别呢？我从 5 个方面对其进行了对比，下面将一一讲述：
1．用户获取信息的方式。
广告与推荐系统，用户都是被动的，但搜索不一样，用户是主动搜索的，他需要输入一些关键词，会加入一些自己的意见和重点。
2.点击率要求。
这三个系统对点击率都有要求，仅在要求上有些区别，这就不详述了。
3.惊喜度要求。
对于广告和搜索系统来说，不需要太多的惊喜度。比如，如果我搜一个关键词，搜索到我想要的资料时，并不会觉得很惊喜，甚至认为是理所当然，但是在推荐系统里，用户往往对惊喜度是有要求的。
具体来说，用户对于一个推荐系统的期望是希望产品能够给他们一些惊喜，如用户 A 虽然不知道产品用了什么数据、什么方法，但如果突然推荐了一首可能他已经快遗忘的自己却很喜欢的歌时，他就会因感到产品“好懂我”而惊喜。
4.个性化要求。
在广告和搜索系统，个性化的需求是可有可无的，不管有没有系统也能正常运作。但是，对于推荐系统来说，个性化要求非常高，甚至越高越好。因为个性化推荐针对的是差异化的单个场景，一定会有个性化的要求。
5.用户反馈。
广告和搜索系统存在比较隐性的反馈，即对于搜索结果好不好？一般很少有搜索引擎厂商会直接问用户，你喜不喜欢搜索结果，更多是厂商去判定广告效果和搜索效果，一般是通过 CTR，或通过整个产品的某些长期留存表现来判定。但是，对于推荐系统来说，很多推荐产品会直接地问用户的喜好，存在很明显的显性主观表达。
因此，同样是解决类似的一系列问题。 但是这三个不同的系统存在极大的差异（如下图），这些区别直接决定了企业去判断某个业务适不适合使用个性化推荐，以及该如何做好个性化推荐。
三、什么样的产品或业务适合采用个性化推荐？
个人认为，具有媒体性的产品（Media Product）适合使用个性化推荐，这里指的不是只有与媒体相关的才能使用推荐，公司业务为电商的就不行，其实它只是一个概念，包含四个点，但不一定要同时满足，下面我将一一解说。
1.口味很重要（Taste）
产品中的 Taste 本身很重要。举个例子，网上曾有一个很火的梗，在淘宝搜索连衣裙，排在第二位的连衣裙价格，代表了在整个淘宝体系里判定你个人的客单价范围。我们当时试了一下，发现一个特别有趣的现象，就是一般女生搜索出来的价格都会很低，大概一两百元，而我和一些男同事搜索出来会高很多，如我搜索的基本上是一千八左右的连衣裙，仔细想一想也有原因，像女生天天逛淘宝，大大小小什么商品都买，但我上淘宝基本上都是要买相机、电脑，这些价格都在几千或上万元。很容易发现，我们所有人对于买的东西的方向和口味是有差异的。
事实上除了存在差异还存在要求，很多人不希望被一个平台判定其口味是某个方向。比如一个具备推荐系统的网站总给你推荐一些下三滥、低俗的东西，他会想“天哪！我是这样一个人吗？”因此，大家对于一个平台的口味和自己的口味都是有要求的。
2.单位成本不重要（Cost）
“单位成本不重要”我们可以通过这个例子来理解，比如以前我们每天看报纸，因为报纸的单价较便宜，对应到现在的产品，比如我听一首歌、看一篇文章、买一个常规的商品，你的消费行为的 cost 消耗都不高，且不那么重要。
3.有瀑布效应（Information Cascade）
瀑布效应指的是，一旦在社区或平台里产生了一个趋势，那么整个平台的其他人都会跟随这个趋势，比如，微博上转发超过三四千的动态，可能会慢慢地被转发的更多，整个社区会形成这样的一些趋势和倾向，瀑布效应在平台和社区较容易形成。
4.多样性（Diversity）
这一点指的是你的平台的内容本身是具有多样性的，这是推荐的基础。如果整个平台的内容在各种维度、属性上都一致，那么很难做推荐。
基本上，只要满足以上 1-2 个点，我们就可以说它是一个偏媒体型的产品。这方面一个很经典的例子，我们可以看下图，在图中的王守崑是原来负责豆瓣最早的推荐系统的架构师，这是他在很早之前分享中的一页 PPT，我觉得这是讲一个产品适不适合上推荐最直观的一个例子。
当时他们在做豆瓣推荐的时候，首先思考到底应该优先在什么频道上推荐，为此设置了一个判断的标准，开始列一些指标，如下：
豆瓣会根据各个频道的用户数、条目数（豆瓣收录的图书、电影、音乐多少）计算稀疏性，比如图书的条目数是 300 万，同时记录图书用户群体人均会在豆瓣收藏几本书（点看过的视为收藏），豆瓣用人均的看过的次数除以总的条目数算出的值叫做稀疏性。如果一个产品稀疏性太低，那么继续使用现行的推荐系统的相关算法就会出现问题，因为整个待推荐的内容面临很大的群体，如果每一个人喜欢的东西太少时，他就会散落在整个大群体的各个方面，你很难找到人和人之间具体的关系，因为每个人在整个系统里面的表达兴趣太少了。因此，稀疏性低的产品做推荐，要么是工程难度比较高，那么效果可能不太好，一般说稀疏性高一点的产品更容易找到人与人之间契合的东西，当然稀疏性也不能过高，如果稀疏性达到百分之八九十，那所有的用户可能就过于相似，所以豆瓣比较强调稀疏性。
关于多样性，有一个有趣的点需要注意。比如图书的多样性高，大家可能理解图书仅根据一个侦探小说就能分出几十个类型；电影的多样性低，好像和常规的理解不一样，事实上因为电影现在是高度工业化和商业化的产品，他们的类型聚集度是相当高的。所以这给了大家一个启示，在判断自身产品时，不要完全凭直觉，而要真的拿自己公司的实际数据说话。
时效性很好理解，我就不解释了。反馈是指在某个品类中，企业做出一个推荐行为，用户什么时候能给企业一个反馈，也就是用户表达自己喜好的反馈时间周期是快还是慢。比如图书就会很慢，读完可能需要十天半个月，拖延症的人可能还要读半年左右；文章就会很快，只要点我的文章就可以定义为偏好，把这篇文章滚动到底就是喜欢；音乐也是，听完就是喜欢，很快跳过就是不喜欢。
最后，豆瓣会综合前面所有的这些维度属性来判断推荐效果。在图中他们认为推荐效果最好的是单曲，原因是单曲的稀疏性特别高，虽然多样性相对来说低级别，但是因为稀疏性高，加上反馈周期特别快，综合起来效果最好。事实上，这也是为什么大家在互联网的花花世界中，还能记得豆瓣 FM 这个产品。不过，豆瓣在其他方面的推荐效果也不错，比如图书。
以上，就是豆瓣当时内部的一个评估过程，揭示了企业想要做一个推荐产品的时，到底该如何去衡量这个业务适不适合做，效果将怎样，需要定一个衡量的标准。
四、以商业为目的，推荐要做成什么样？
推荐的商业目的一般分为以下几种：
1.用计算机经验取代运营经验（节省成本、提高效率）
这一点非常重要，很多人提到推荐系统会认为是由公司的技术部门负责，像变魔法一样，就把某个事情从人工运营变成了机器运营，然后运营的同学就好像没活干了，但事实不是如此，其实本质上来说它是取代运营经验，但是有个前提条件是你们公司本来有运营经验，我很少见到公司使用推荐系统是完全抛开运营团队，单靠技术团队自己的力量，把推荐系统运作得很好。
事实上，我们可以这样理解这一点：运营积累了一些经验，但是只能通过运营人工的进行一次次干预，这样往往只能对整个区域进行干预，没有办法把经验落地到每一个具体的用户身上，干预每一个用户的体验还是很难。因此，推荐系统就可以帮助解决提升每个用户的体验问题。
2.充分利用流量（提高变现能力）
事实上，很多企业的产品设计以及各种运营方案，可能只能解决众多流量的其中 60% 的需求，另外 40% 的需求被忽略了，或者是不得不忽略，因为企业没有办法给每一个用户或者每一群用户单独配一个运营。此时，推荐系统就可以起到类似分流量的精细化运营的作用。
3.促进信息流动（留住小众用户）
这个价值点可能很多企业没有注意到，因为大多数想使用个性化推荐的公司，都在考虑公司如何赚钱？或用户如何能得到更好的体验？但是，很多产品的推荐系统还有一个很重要的作用是促进信息流动，从而留住小众用户。在很多形态的产品中，不管是社区型的产品，还是电商型的产品，它都会存在一些商品，如果产品的机制运营的不错，这些商品会在短时间之内成为整个社区的话题和爆款。
但是可能社区本身的积淀或产品的话题程度，不可能让它持续地成为话题，但是一定要制造话题，因为其一可以彰显整个社区多样性，其二小众的群体也觉得自己能在大平台得到展现，会更容易留下来，但如果整个社区缺乏这种能力，展示在推荐位置的永远是热门的大众内容，那么长尾的小众社区、小众用户、小众商品就会涌入其他平台，企业便很难养起来那一部分的风。
回到当下来看，像抖音这样的产品，为什么能够让那么多人参与进去？核心在于聚集了多样化的用户，比如经常在抖音上看到一些播放量、点赞量都是几十万的用户，你点进去他的主页来看历史的视频播放，你会发现这个用户可能只有那一个视频几十万，其他的视频只有几百、几千的播放量。但这就是推荐系统的魅力，用户不需要一直是一个大 V，只要偶尔一个内容能够成为爆款，那么平台就能够把这类用户筛选出来，让他吸引更多的人参与进来，而避免说被少数的大 V、头部流量把整个平台给遏制住，这是一个比较有意思的商业目的。
五、产品、运营必知的推荐系统算法
这里是针对常见的一些做推荐的基础思想和算法进行简单的扫盲（之后神策数据公众号会有一篇文章“推荐系统的实践与思考”会对最新的一些推荐系统的架构构建进行专门的介绍），以下三种是比较常见的：
协调过滤（CF）、隐语义模型（LFM）、优势排行（Edgerank），我们最常见到的是CF、其中 Edgerank 主要用于类似 Facebook 做社交的企业。
1.协调过滤（CF）
事实上，大部分的推荐系统的本质是“物以类聚，人以群分”，思路大概可分为两个方面：其一，研究物品，即研究被推荐系统推荐的 item 进行推荐，被称为基于物品的推荐（Item-based）；其二，研究人，即根据人的喜好进行推荐，被称为基于用户的推荐（User-based）。
基于物品的协同过滤是什么意思呢？举个例子，某个电商企业的商品 i 和 j 被同一类人喜欢，因此可以将其归为一类，当用户 u 喜欢 i 但是没有看过 j，就可以把 j 推荐给 u。
基于用户的协同过滤又是什么意思呢？前面提到的物品的协同过滤是先把物品归为一类，然后再推荐相同类的，而基于用户的协调过滤是我们先分析用户。举个例子，我们把用户 A 和 B 归为一类，然后，就可以把 B 喜欢的商品，A 还没看过的 i 也推荐给 A。
2.隐语义模型（LFM）
隐语义模型相对协同过滤会复杂一些，但是本质上也较相似，这根据用户的行为和物品的特征，用机器学习的方法先把物品进行分类，然后再计算用户 A 对每一个类别的兴趣程度。举个例子，某个企业通过机器学习把物品分成了十个类，然后该企业计算用户 A 对每个类别的兴趣程度，可以划分为 1、0.8、0.7、0.5、0.3 等。之后，企业继续计算一个物品 i 对于每个类别的权重，也就是物品 i 到底该被划分到哪个类别，最后，企业根据这两个信息和权重计算出用户对物品 i 的喜爱程度。相比协同过滤，LFM 分的更精细，事实上，现实中不管是人的属性还是物品的属性都千差万别，很难通过单纯的把物品或人分为一类就能满足推荐的需求。
3.优势排行（Edgerank）
Edgerank 是 Facebook 完全基于自身信息流分发构建的一个算法。这能帮助大家理解有时候推荐算法不是简单采用市面上恒定的算法，而要根据公司实际的需求调整。Edgerank 会算三个指标：亲密度（Affinity Score）、边的权重（Edge Weight）、新鲜程度（Time Decay）。
亲密度（Affinity Score）。比如用户 A 发了一些文字信息、视频、图片等，用户 B 从一些第三方应用分享的这些文字、视频、图片来到用户 A 的信息流，Facebook 就会首先算用户 B 与用户 A 的亲密程度（同学？情侣？曾经互动过？），通过系统来计算出 AS 的亲密度分数，当判定为存在亲密度，就会再计算边的权重。
边的权重（Edge Weight）。这指的是用户 B 通过什么样子的边连接到你，是图片？文字？还是通过分享自己喜欢的文章，像这种不同的连接类型，叫做边。 边的权重的不同会帮助更好的推荐。举个例子，如果发现 Facebook 的用户更喜欢看照片，照片的边的权重就会更高；如果用户总发一些没有营养的鸡汤文，这些文章边的权重就会下降。
新鲜程度（Time Decay）指的是内容本身的发布时间的早晚，越近发布的权重会越高。
Facebook 会综合这三个指标给用户做推荐，但是对大多数企业来说无法直接套用，因为这是根据 Facebook 自身信息流的分发需求提炼出的影响因子。
之所以为大家介绍这三种模型，是想让大家简单了解现在做推荐的常规手段，但事实上现在的工程实践远比上面的这些基础模型复杂，我们再来看一下推荐系统的架构图，这不是纯技术角度的架构图，比较偏产品视角。事实上，做推荐系统往往是一个过程，通过多种算法得到一个初步结果，然后再对初步结果进行过滤、排序，再生成一些推荐原因，最后展示推荐结果。在整个过程里面，产品运营参与的环节也比较多，这就是我的一个理解。
六、个性化推荐产品经理的修炼秘籍
做推荐系统往往不是一蹴而就的，中间会有很多失败的因素。我认为常见的失败原因主要分为三个方向：数据质量、太过鲁莽、不理解用户。
很多公司让我帮忙判断是否适合做推荐时，往往发现公司在数据层面上没有什么积累。比如有些企业完全没有统一的地方存储用户信息，可能分散在不同系统、不同部门。这导致做推荐建模时，完全不知道数据在哪找。还有些企业用户的行为信息保存太少，基本上只有一些关键交易信息保留，但整个交易的前置环节，比如用户在首页搜索哪些关键词？在一个页面详情页上反复浏览了几次？是否添加购物车？是否使用优惠券？类似这些信息全部没有保存。虽然推荐系统中的某些关键行为非常重要，但是大部分的推荐系统中的关键行为极少。
对于推荐系统来说，数据越多越好。很多公司，你会发现其用户行为数据收集的相当少。除此之外，当我帮他们把数据找全了想合到一起来使用，却发现合不到一起。比如，公司的浏览数据没有记录 UID，直接只记录了网站上的 cookie，因此只能用 cookie 来判定用户订单，但订单后台直接记录了用户的 UID 或订单号，多个数据源之间没有统一的 ID 识别机制，企业无法把用户的行为数据、业务数据连通。 这些主要是数据质量导致推荐系统失败的原因，缺少一个好的数据基础打地基。
过于鲁莽和不理解用户也是企业会常犯的错误，这些会在下面的秘籍中体现。
秘籍 1 ：明确推荐场景
当大家做推荐系统时，一定要想明白推荐的场景是什么？头条因个性化推荐而爆火，很多人一想到推荐可能就是信息流，这就是过于鲁莽的判定，但其实推荐场景有很多，比如信息流、猜你喜欢、关联推荐以及针对不同的用户推荐不同的产品界面等。
举个例子，现在同样的一个产品，可能 Web 端、移动端都有入口，甚至还存在车载设备的入口等。那么，同样的产品功能，在这三个场景下给用户推荐肯定应该有所不同，而且往往是当产品、运营认知到了这种区别之后，反馈到算法部门，让他们进行调整最终得到某些效果进行对比，不难发现对于这点，认知的经验效果远比调节算法的细节来得更加有用。
另一个典型的例子是用户在售前、售中、售后的不同场景，针对其整个作用的方向不一样。
比如，企业做商品推荐，在售前应该推荐什么商品，能把用户的兴趣激发出来？售中有什么策略能促进用户尽快下单？售后又该怎么做？如果用户刚刚买了一个电视机，又被推荐买另外一个电视机，就是一个典型的糟糕的推荐场景。事实上，用户处在不同周期，推荐算法要解决的问题是不一样的，推荐逻辑也随之不同，所以推荐算法要根据用户在你产品的生命周期进行不同的设计。
秘籍 2：明确目标
这一点指的是推荐系统能解决的问题，个人认为，可以分为从众、兴趣、发现三个方向。
解决从众的需求
很多人认为“从众”是贬义词，事实上，我们大部分人从生理和心理上都有从众的需求，因为从众是人追求安全感的一个体现，所以推荐系统首先解决从众需求。比如，让产品的推荐能告诉用户在这个社区里面现在最流行什么，来帮助其跟随潮流，从而获得归属感和安全感，这个需求通常是稳定的，而且非常重要。
解决兴趣的需求
简单来说，这个平台上有很多内容，但时间、精力有限，用户只想看与自己兴趣相关的。
解决发现的需求
如果产品上的内容我看的差不多了，有没有点新鲜的内容，这就是发现的需求。比如，我是一个爱好做模型的人，但该网站上关于模型的内容已经看的差不多了，网站给我推荐了一些我可能感兴趣，但不是模型相关的内容来解决我发现的需求。
以上就是推荐系统解决的三方面需求目标，不同的目标与之相关的要求也不一样。
对于从众的需求来说，企业希望用户的满意度非常高。当你推荐的流行内容如果被用户发现不是最近流行的，用户的满意度就会很低。然而，对于发现的需求来说，企业对满意度要求就没有那么高，用户自己的预期也不会那么高，所以有时候对于发现的需求，企业为用户推荐错一个或者推荐一个没那么满意的东西，用户很可能会认为机器猜错了很正常，不会介意。就推荐准确率而言，从众一般准确率较低，因为用户不会对所有流行的内容都会仔细查看，但是，兴趣的准确率就要求很高。对于覆盖率，从众因为是迎合整个社区的潮流需求，覆盖率肯定是低的。而兴趣因为针对不同的人来覆盖不同的兴趣，覆盖的会越来越多。发现往往能使产品中很多可能冷门的库存内容重新得到展示。以此类推，多样性、新颖性、惊喜度也是类似。
因此，如果你的企业使用推荐系统，从这个三个方向，最后的考核指标完全不一样。举个例子，我们经常听到产品现在的目标是提高用户收听时长，但逐渐会发现产品处于不同阶段，推荐的目标是完全不一样的，就个人经验总结，一个正常产品的发展轨迹往往如下图。
推荐系统一般最开始都是为了解决从众的需求，也就是如何把社区中流行、热门的内容尽可能地通过推荐系统筛选出来，让更多的人来看。然后慢慢地用户增加，产品内容越来越丰富，便需要做更精细化的运营，这个阶段更注重推荐系统解决单个群体或单个用户的兴趣需求。最后，产品在后期逐渐稳定时便要着手于发现。
举个例子，机核网是神策数据的一个客户，一个专注游戏文化的媒体网站，我是其忠实用户，第一次接触时，我被网站上的深度文章所吸引，我花了大概半年多的时间，把历史文章、电台、视频内容都看了一遍，这个时候作为一个老用户，已经把我兴趣范围之内的东西探索的差不多了，产品提供的价值受到了限制，这个时候企业便需要使用推荐系统去解决和发现一些需求，如何让这一批老用户能够在产品中找到一些新东西，激发新的需求变得非常重要。所以，往往做推荐系统会分为几个阶段。
秘籍 3：大胆拍脑袋
在工作中，很多时候不可避免的需要拍脑袋。下图是 Facebook 的首席产品官 Chris Cox 说的一句话。
大概意思是，在最开始，News feedranking 是 Facebook 最核心的时间流，他们像扳开关一样，有时认为图片的权重不够高，就把图片权重调高一点，然后把故事权重调低一点。比如可能一个图片值五分，如果一个用户加入某个小组只值一分。事实上，给这些行为打 5 分与 1 分没有特别科学的说法，但是，刚开始一定要大胆的拍脑袋，而不是大家都停在一个点，什么都不做。
有时候做推荐系统，关于某些关键行为的权重该如何设置的问题，如果产品运营完全不参与，把这个问题推给技术，技术有时候对业务的理解没有那么深，他可能倾向于用一个很复杂的算法来算权重。
当然，最好的方式更多还是需要产品给技术更多的输入。如果产品告诉技术，在产品里面用户很喜欢图片，可以先把图片权重调高一点，把故事权重调低一点，技术按照这个规则先尝试一下，事实上，在推荐系统整个开发迭代过程中经常会反复的调高调低权重，并且在这个实践应用过程中也会发现其中的优劣势。
再举个例子，之前我在 A 站早期带 A 站的时候，因为当时还较小，养不起一个算法团队，所以我们买了市面上的一些黑盒推荐服务，企业只需要提供数据，服务商就可以把推荐结果给你，最终发现效果特别差，而且你想做相关的调整把某个受欢迎的频道权重调高一点，但因为是纯黑盒推荐，企业自身根本无法直接调整，或企业给服务商提需求，可能需要等几个月才能拿到结果，那么推荐的最终效果就很难保证。所以即使市面上有很多黑盒推荐，接入成本也比较低，但企业会发现推荐系统不是一个接入一次就完成的事情，推荐系统需要在这个过程中不断地去调整，不断地根据业务去反馈。
因此，企业在拍脑袋的时候，需要产品和运营定义到底哪些「用户行为」更重要、或者意味着什么，这是靠机器无法做的。比如，用户看一篇文章滚动到底部，机器并不会认为这有什么价值，但我们会认为该用户对这篇文章真的感兴趣。也就是一个无用的信息，加入了人工的判断认知之后，就可能变成在整个推荐系统里很关键的信号。这个系统里还有很多这种类似的行为需要人为的给这些行为打上一个标记，判定为喜欢或不喜欢的信号，这种信号极其重要，不是大家想象的推荐是根据一些很明确的行为定义的，很多用户的喜欢和不喜欢判断都不是用户主动表达出来的，都是依靠产品、运营、技术一起研究业务、用户流程推断出来的。
那么行为如何彰显喜欢程度或者讨厌程度呢？举个例子，对于电商产品，通常会认为一个用户对于商品的兴趣表达公式是：购买远大于收藏，收藏大于浏览。在做推荐系统时，这些权重就需要考虑进去。
秘籍 4：反复检阅推荐结果
企业不是只要推荐系统上线就可以了，还需要反复检阅推荐结果。一般检阅分两种：离线和在线。
第一个是在线的检阅。在线检阅的核心是企业要理解用户的行为模式，产品要像用户一样去用自身的产品以及推荐模块，设身处地感受一下现在推荐的内容是否是自己想要的，如果推荐的内容不是想看的，就需要和运营、技术沟通，为什么这次推荐的是一个我不想看的内容，就是你要把推荐放到一个实际的场景里，真正地自己去体会去理解用户的行为。
第二个是离线的检阅。过去做产品时，我们有时候会仔细分析给用户推荐的历史结果中是否存在一些很明显的 Bad case，这也是企业改善推荐质量很常见的一种方式。
豆瓣电台过去做中文英文曲库分割就是一个典型例子，当时豆瓣的收听率一直无法上升，最后豆瓣员工进入用户状态，换位思考发现有些人喜欢听中文歌，完全不喜欢英文歌，而还有些人喜欢听英文歌，却反感中文歌。从推荐角度思考，只需要做一个简单的事，把中文跟英文的曲风直接区隔开，区隔开后豆瓣的推荐准确率瞬间提升。
另外一个例子是，有一次我们做商品推荐遇到了瓶颈，我们采取了一个方法，在每次推荐批次的商品中加入几个 10 元包邮或 20 元包邮的商品，最后整个点击率、转化率都提升了，这并不是科学的方法，但当企业做一些在线的体验优化或是离线的 Bad case 校验时，你会发现一些粗暴的解决方法，但是这些对于整体的效果提升很有效。
秘籍 5：多学习一些算法知识
非技术出身的产品、运营，如果真的想把推荐业务做好，建议学一些算法知识，至少简单知道每一个算法的基本优劣势，这样才能为你的优化方向提供目标和思路，沟通更顺畅，更容易碰撞出火花。
比如，当做协同过滤的推荐系统时，当企业有 6000 万的历史用户，平均每个人喜欢十个商品，但是只能推荐 1000 万个商品。对于没有做过推荐系统的大部分人，对其背后的的工程难度是无法想象的，但是你需要配合工程师去理解，如果你不理解工程难度在哪，就提不出比较好的建议。
比如产品、运营需要知道，过热、过冷、太 low 是一些很常见的 Bad case。过热指的是推荐的永远是很重要的内容；过冷就是总推荐一些最冷门的内容，导致用户点击率低；太 low，也是很常见的，内容质量低，用户不喜欢。这也是我认为有时候产品运营参与推进业务可以帮助技术解决的一个特别好的点。在我做产品时，一旦发现有 Bad case，就直接干掉，在这过程中不仅优化了整个推荐的质量，还通过不断地干掉这个动作本身发现一些问题和规律。
再分享一个经典问题——如何做冷启动？现在已经集中在几个大概的方向：1.主动收集，让用户去选一些感兴趣的一些方向，如豆瓣注册后让你选择感兴趣的类目；2.被动收集，如在淘宝网页收集用户的一些点击、浏览等行为数据。
七、推荐系统的未来走向
下面简单聊聊我对推荐系统的未来走向的想法。事实上，现在的一些企业的推荐系统，大部分算法都是混合发挥作用的，也就是复合算法。企业还可以在复合算法基础上加入竞争机制，如在同样一个推荐场景，多个窗口同时运作，这些窗口之间存在相互竞争，最后判定在同一个场景下，到底哪个算法、推荐机制更有效果。又或者企业直接使用机器学习，机器学习会自主做一些 utem、 item 的建模，甚至是算法之间的竞争关系。
事实上，相比我在 2008 年刚入行的时，现在的推荐系统已经非常复杂，我认为之后这些会更复杂、越来越抽象，如今任何一个公司想自己从 0 开始做推荐系统都会非常困难。但是不管基于我过去的产品经验，还是现在在神策数据的经验，总结发现其实构建推荐系统的价值观、企业对于自己公司业务的理解，在整个推荐的搭建过程当中起着至关重要的作用。
以上就是我的全部分享，希望对你有帮助！
不容错过的精彩内容
收藏 ★ 公众号，及时获取精彩内容
戳此，告诉我，你在看☟
扫一扫
610
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
