推荐系统之数据采集

　　推荐系统之数据采集

　　对于做推荐系统或则是策略相关的产品朋友最难的是哪些？是没有数据的支撑。没有数据就没有办法建立用户画像、标签体系；没有办法进行数据统计、指标剖析、AB 实验疗效验证。那么问题来了，数据从哪儿来。这一篇文章就介绍推荐系统中容易使人忽略，又极为重要，又相当多坑的一个环节——数据采集。

　　信息流数据采集完整流程

　　在之家推荐、画像、标签相关的产品总监有数据需求的时侯就会先和数据产品沟通，当然若果公司职位没有分得那么细的话，往往推荐产品或是画像的产品总监要自己去走完这整个流程，这一个流程走出来，就会对数据的完整流转相当的熟悉，当然也是一个心筛的过程，各种坑等着你。接下来我就依照这个流程重点介绍数据采集的全流程，普通页面的数据采集知乎上好多文章介绍，无非就是根据标准的sdk或js进行采集 我们这儿的重点是推荐信息流的数据采集，是以信息流的产品形态为根本出发点。

　　数据需求梳理

　　数据需求来源比较广，可以说假如是中台部门，各种各样的数据需求就会提及这儿上去，如营销、画像、算法、推广、标签等等，那么在考虑到各个具体需求时，既要要建立灵活的数据埋点上报规范，又满足现有需求，为将来可能会出现的需求留出扩充的空间。

　　埋点规范制订

　　信息流的埋点一般遵守以下的原则：

　　以恳求爆光风波埋点为例说明

　　定义：当用户刷新时，客户端恳求推荐插口获取推荐内容。 事件id：recm_req_show 统一风波id的整体格式，各推荐位置以recm_id进行分辨 请求爆光内容格式：一次恳求上报一条日志，收录此次恳求的推荐位置id：recm_id；请求惟一标示：pvid；内容列表itemlist，各推荐位置须要统一上报的内容格式。

　　请求爆光风波上报数据示例

　　也许有的朋友可能不明白里面的参数是哪些意思，为什么如此设计，我在这里解释一下里面规范示例中各参数的意义和作用。但你们牢记各信息流产品形态的参数须要依照实际业务来进行调整和定义。

　　推荐位id分配

　　埋点施行注意事项

　　上面大约介大致介绍了一下该规范的内容，还有三点在埋点施行过程中要注意的：

　　1.必须明晰风波上报的条件

　　比如恳求爆光，就要求在恳求成功后立刻上报；可见爆光则要求在爆光页面逗留超过一定的时长，这个问题在之家最早的规范中没有明晰，每次就会有开发朋友问，什么时候上报。

　　2.必须明晰每一个数组参数从哪些地方取

　　刚才前面介绍的参数，对于埋点朋友比较郁闷的时侯，找不到这种数从哪里取，或者是害怕取错，埋点一旦弄错，后面的数据统计，画像、标签都是错的，所以这个地方产品总监一定得和埋点同事确认清楚每一个参数的正确取数位置。

　　3.必须明晰数据的格式

　　数据格式的确认，主要是为了数据上报后，数仓同事对日志进行处理时才能高效、便捷，如果出现各种各样的格式，这里多个冒号，那里多个空格，这些非标准格式她们都得去处理，耗费时间和精力。

　　埋点初验

　　埋点初验主要是三点：

　　验收是否要所有推荐位都有数据上报 上报的参数是否有所有遗漏 上报的数据格式是否和规范要求一致

　　数据应用

　　当埋点完备、上报的数据经过数仓处理后，接下来就是数据的各类应用了。

　　数据统计

　　数据统计是最重要最基础的应用，特别是对于推荐系统最重要的一个指标CTR，用点击/可见爆光来进行估算。如果没有点击风波和可见爆光风波的埋点，这个数据就不可能形成，那么推荐系统的疗效就很难从量化指标上进行评估。

　　用户画像

　　因为在每条物料透传下来的stra扩充参数中，会带有表征物料的特点，以用户主动发生的行为风波为纽带，将物料的特点传递到用户头上，这个特点就是用户画像中的某个偏好。

　　以之家为例——如果数据采集到某用户近日点击的物料中较高频度出现某车系，那么这个车系都会成为该用户画像中其短期兴趣车系，就可以根据此车系推荐相关的内容，并估算该车系的相像车系或是竞品车系推荐给用户，关于用户画像的详尽介绍可以看下边这篇文章：

　　龚旭东：推荐系统之用户画像

　　还有其他数据应用场景就不再这儿一一介绍了，有兴趣的你们可以单独沟通

　　总结

　　说一下埋点这个工作的实际情况。以我的真实经历，埋点不是个技术活，也不难，需要的是耐心，细心，这个工作再怎样做也不会非常的出彩，所以大部分产品都不乐意干这个活，总会推来推去，最后搞得稀里糊涂，但是假如埋点做不好，上层的应用就做不好。说得不好听的，现如今互联网产品假如数据都搞不对，可以说基本就是死，所以建议这块儿还是专人负责。