过去的一年，一直在做策略相关的产品，很有意思的是，从0到1做的东西占了绝大部分工作成果。文章预计拆分为2~3篇，今天是第1篇，聊一下搭建策略产品的必要性以及应具备的条件。
一、搭建推荐策略的必要性
在做一件事情之前先要问问为什么要做这个事情，这样才能在整个实施的过程中游刃有余，有的放矢。
不过，回答这个问题之前需要对推荐系统有个总体的认知。
1. 关于推荐系统
先大概回顾一下整个互联网阶段对信息处理的演变过程。随着信息技术和互联网的发展，一方面用户足不出户就可以得到的大多数的信息，但是另一方面却逐渐受到很多无关信息的打扰，也就是信息过载。
为了解决信息过载的问题，整个信息处理的过程大概经过了三次演变：
第一次即以门户网站为代表的分类处理技术。通过对互联网的信息，内容进行分类处理，并且在用户端进行不同入口的展示，极大的方便了用户根据类别来筛选自己感兴趣的内容，极具代表性的就是各种门户网站。但是随着内容越来越多，分类也越来越多，太多的分类对用户来说也造成了信息过载，随着出现了第二次演变。
二次演变即以PC互联网时代google，百度为代表的搜索引擎。用户可以根据自己明确的目标需求进行关键词查找，繁重的目标内容检索工作交给了机器去处理，极大的提升了用户信息查看的效率。不难发现，搜索其实是解决了用户在有明确目标的情况下信息检索需求。但是如果用户没有明确的目标呢，这时候搜索引擎也无能为力。紧接着，第三次演变到来。
第三次演变即以移动互联网时代的个性化推荐，也即千人千面，每个人看到的都是单独为其量身打造的内容。和搜索引擎不一样的是，即使用户不主动提供明确的需求，只要它在互联网上发生过相关的行为，那么推荐就可以给到用户最为感兴趣的内容。
简单来说，根据用户的历史行为进行用户兴趣建模，结合内容的特征，给到用户最能满足其兴趣和需求的内容，即推荐。
而推荐策略解决的问题就是如何能够推荐出让用户满意，让业务受益的内容。
当然，这里的内容（一般称之为item）不限其具体的形态，可以是商品，可以是文章，可以是服务等等。
2. 什么业务适合做推荐策略
了解推荐的概念之后，到底哪些业务，哪些场景非常适合去做推荐系统，或者说应该去做推荐策略呢？
这个也是我一直思考的问题，总结了以下几点：
（1）有海量的内容
推荐系统的初衷就是从海量的item当中选出用户最感兴趣的，所以首先要有海量的item，数量不足，就无所谓选择了。
另一方面，从策略的角度来讲，一个策略从诞生，到上线，再到验证，整个过程都需要海量的数据参与，比如：item feature提取，模型训练，指标验证等等，海量的数据能够确保整个过程的准确性、可行性和科学性。
（2）有海量的用户
这个其实和海量的内容是相辅相成的。因为推荐策略本身就是来链接用户和内容的，所以从这个角度来讲的话，有海量内容，就需要有海量的用户与之对应，否则策略是不靠谱的。
从另一个角度来讲，推荐策略本身是为了提高流量的利用效率，这种利用效率可以体现为转化率，UV价值，RPM，GMV等具体指标，需要大量的数据进行验证，否则就没有意义。
因此，如果业务还在发展初期，并没有多少用户，那从产品目标本身角度来讲，这个时候应该主要是以流量导向，而推荐策略并不占据很重要的优先级。
（3）非工具类业务
工具类业务从其诞生一定会有一个明确的目标，对应的用户也有非常明确的需求，所以对于这种业务一般不会去推荐其他同类内容了，当然需要区别一下资源位和推荐。
一般来说，目前应用推荐策略比较多的领域包括：电商、视频、音乐、阅读、社区、社交、广告、基于位置的服务等。
（4）用户逛的场景居多
目前用户碎片化的时间越来越多，用来在产品上“闲逛”的时间也就越多，但是，与之对应的是同质化的产品也越来越多，在争取用户注意力这条道路上，能够基于用户的而历史行为，去实时，精准的推荐用户感兴趣的内容可能是一种最为高效的方式。
个性化推荐目前已经成为了一种新的趋势，每一个产品基本必备一个BI模块。不过，是否值得投入很大的资源去做一个看似高大上的推荐系统，还是需要好好考虑一下的。
二、搭建策略产品需要哪些条件
下面有些内容在之前的文章里面提到过：这一年，我做策略产品遇到的坑，在一个业务线搭建推荐策略产品时，需要先看看如下条件是否满足：
1. 结构化数据是否必备
现在产品人经常讲的数据驱动，我觉得更全面的说是结构化数据驱动。因为处理乱七八糟的数据是一种很糟（dan）糕（teng）的经历。
关于结构化数据的定义可以看之前的文章。对于搭建策略产品而言，主要看三个：
（1）产品埋点是否完备
埋点是唯一能够准确，实时的采集到线上用户行为的手段，而对于链接用户和物品信息的推荐产品来说，用户行为的重要性就不言而喻了。
（2）埋点数据是否存储
对于数据来说，埋点仅仅解决了线上是否有采集工具的问题，至于是否能够真正发挥其数据价值还需要看这些数据是否被存储下来。
就类似城市摄像头，如果仅仅布置了一个可以实时显示当前区域内景象的工具，其实对于城市建设没有任何用处。
在我们之前的一次实施的过程中就遇到过类似的问题。uuid（用户设备编号）本身各种日志是有记录的，但是数据表中却没有把这个字段存下来，导致无法直接使用，如果进行表结构改动，做研发的同学应该知道，这个工程量和复杂量绝对不小。
（3）数据存储结构是否合理
最后一个就是关于存储结构的问题，主要是指数据表结构设计的是否合理。
我见过很多业务线的后台数据的表结构就是按需建表，没有一个统一的规划，就类似一个大的房子，没有提前做统一规划，而是按照各自需要进行分割，结果可想而知。
最主要的额影响就是在搭建系统过程中，表结构需要不停的进行整合，重建，本来三天可以进行入方案开发，会延期一周甚至更长时间用来处理这些问题。
一个不合理的数据库设计，会导致工程效率低下。
这些都是我亲身经历过的事情。可以说以上三点，直接决定了一个业务线是否能够搭建推荐策略产品。
还是那句话：底层数据各种属性不全，最好的规则也白搭。
引以为戒。
总之，结构化的数据对于推荐策略产品的搭建主要有两个作用：
一是用于用户行为feature的建立用于推荐结果的召回，比如：点击行为、关注行为、加购行为、下单行为等；
另一方面是用于对推荐效果的验证，主要是通过线上埋点采集数据，进行计算相关指标进行推荐效果检验。
另外再说一下我关于数据驱动的理解：目前的数据驱动其实大多数停留在数据佐证，人驱动上面，换句话说大多数情况下把数据当做一种工具，用来证实或证伪，然后人再去做相应的决策。
我理解真正的数据驱动应该在用户进来的那一刻开始，数据工程就开始运作，来决定给用户展示什么，怎么展示，怎么引导。
2. 是否有较好的应用场景
前面也提到了，不是所有的业务都适合做推荐策略产品，其实最主要是要看这个业务线当中是否有比较好的应用场景进行支持。
通常来说，我觉得有两种场景是可以用推荐系统进行满足的：
第一种：更加高效满足用户需求。
比如同样对于笔记本这种产品，当我们还无法感知用户对品牌，配置需求的时候，可以按照商品本身各维度进行推荐（物品单边特征），争取把性价比最高，品质最好的产品推荐给用户，逐步引导用户产生消费行为。
这种场景通常可以称作是“千人一面”的场景，就是把业务内最“好”的东西展示给用户，这个“好”的定义随业务线的不同而不同。
另一种：满足用户的个性化需求。
当我们掌握大量了用户行为数据的时候，就可以大概知道一个用户是什么样的，比如他喜欢的品类，能够承受的价格等等，从而去建立他的标签模型，依据该模型即可进行个性化推荐了。
这种场景通常可以成为“千人千面”场景，典型的淘宝首页就是按照这种场景进行搭建，所以，现在一般不叫淘宝购物，而叫“逛”淘宝，这种“逛”的背后就是数据决策的驱动。
其实不难发现，对于不明确用户目标的情况下，推荐有助于高效，精准的给到用户最满意的物品，是这种场景下的不二之选。
以上。
这篇主要讲了关于搭建推荐策略的必要性以及需要具备的相关条件，下一篇会具体复盘一下整个搭建过程的步骤。
