写在后面
先就不写了。
工作介绍
- 本次工作:是依据淘宝广告展现和用户点击行为的数据集,去做的一个广告举荐零碎。
- 达到的目标:给咱们一个用户的id,咱们的举荐零碎就返回用户最可能返回的10个广告回来。
- ps:这个工作看似简略,然而有一个实时举荐的问题,零碎须要依据之前的用户点击后果,对召回的广告进行动静调整,从而更新举荐列表。
(召回(match)”指从全量信息汇合中触发尽可能多的正确后果,并将后果返回给“排序“)
数据集介绍
3.1原始样本骨架raw_sample
这个是从淘宝网站中随机抽样了114万用户8天内的广告展现/点击日志(2600万条记录),形成原始的样本骨架。 字段阐明如下:
(脱敏指:对敏感数据进行解决,个人隐私等敏感信息)
- user_id:脱敏后的用户id
- adgroup_id:脱敏后的广告id
- time_stamp:工夫戳
- pid:position_id,广告展现的地位,左上右下等。
- noclk:没有点击1,点击0
- clk:用户点击1,没点0
对这个零碎,咱们转换为一个点击率预测的问题,最初把点击率从大到小排序,靠前的举荐给用户就行了。
为什么给了clk和noclk?
首先这是反馈真实情况的日志,其次,如果只存点击的话,就不知道到底曝光了多少广告给用户,因为没曝光和曝光都能够是不点。所以要两者联合起来才行。
那么仅仅利用以上数据集间接训练,十分可能是训练不准的,所以还要依附其余数据集。
3.2广告根本信息表ad_feature
本数据集涵盖了raw_sample中全副广告的根本信息(约80万条目)。字段阐明如下:
- adgroup_id:脱敏后的广告id
- cate_id:广告品种id
- campaign_id:广告打算id,某种策略
(比方那种领优惠券便宜一点,给了一点转卖商,一点儿给用户,起到加大宣传的作用) - brand_id:广告品牌
price:宝贝的价格
一个广告对应一个宝贝没话说嘛。3.3 用户根本信息表user_profile
本数据集涵盖了raw_sample中全副用户的根本信息(约100多万用户)。字段阐明如下:
- user_id:用户id
- cms_segid:微群ID;
- cms_group_id:cms_group_id;
- final_gender_code:性别 1:男,2:女;
- age_level:年龄档次; 1234
- pvalue_level:生产品位,1:低档,2:中档,3:低档;
- shopping_level:购物深度,1:浅层用户,2:中度用户,3:深度用户(天天买)
- occupation:是否大学生 ,1:是,0:否
- new_user_class_level:城市层级
这个数据集是较量的数据集,数据特色人家的做了肯定的荡涤了的,并且做了相干的labelencoder编码,省去了一些工作,然而咱们实在场景还是要做这些。
有了用户点击广告日志的根本骨架,在加上用户根本信息,广告根本信息,实践上咱们就能够去训练模型进行预测了。
然而有一个问题,数据集又是几百万几千万,比方间接逻辑回归进行训练的话,大部分广告和用户不沾边,而且计算量不得了,只会白白浪费工夫。
所以咱们第一步,先召回,和用户相干的广告。而后再去训练模型,再排序做一个举荐。那怎么召回呢?
果然有一个行为日志的数据集!
3.4 用户的行为日志behavior_log
本数据集涵盖了raw_sample中全副用户22天内的购物行为(共七亿条记录)。字段阐明如下:
和下面的骨架数据集不同的是,下面是广告展现进去受否点击,这里是用户珍藏购买的日志。
- user:用户id
- time_stamp:工夫戳;
- btag:行为类型, 包含以下四种:
类型 | 阐明
pv | 浏览
cart | 退出购物车
fav | 喜爱
buy | 购买 - cate_id:脱敏过的商品类目id;
- brand_id: 脱敏过的品牌id;
这份数据体现用户对商品类目(id)、品牌(id)的浏览、加购物车、珍藏、购买等信息,有了这个表,其实咱们就能够在排序之前,先做一些召回的工作了。
首先就是这里的用户行为类型,这里是实在的浏览,退出购物车,喜爱和购买这样的记录,而咱们如果想拿这份数据召回,比方基于协同过滤的话,咱们须要把这四种行为转换成评分,这样计算机能力认得,比方浏览给1分, 退出购物车。
而后召回出和用户相干的品牌,广告啊,而不是最初的点击率。
有用户id, 又有cat_id和评分数据, 咱们其实就能够利用简略的协同过滤先做一波召回, 找到候选商品, 再映射出候选广告。 而后在思考精排,来一个精准预测。
举荐业务解决次要流程: 召回 ===> 排序 ===> 举荐。而后用到了大数据平台,用一张图来示意就是:
而后咱们大数据平台,就分为离线和实时两个局部解决业务流。
- 离线业务流
先解决用户的历史行为数据, 而后失去评分数据, 而后基于协同过滤进行召回失去候选的商品类别, 而后再去关联广告,失去候选的广告。
相当于做了一个粗略召回。 - 在线解决业务流
所以在线更新的思路就是基于用户新的购买日志或者记录来更新召回的商品类别或者品牌,而后映射出新的候选广告,因为之前缓存了广告的特色和用户特色, 所以基于这些又此造成新的数据对模型测试,而后失去点击的广告概率,排序产生新的后果。
这里曾经把根本的业务流梳理分明了, 上面就简略看一下波及到的技术了,因为是在大数据平台上,所以用到的大部分都是大数据平台相干技术。波及技术:Flume、Kafka、Spark-streming\HDFS、Spark SQL、Spark ML、Redis。
- Flume:日志数据收集
- Kafka:实时日志数据处理队列
- HDFS:存储数据
- Spark SQL:离线解决
- Spark ML:模型训练
- Redis:缓存
5. 波及到点击率预测的几个相干概念
5.1 点击率预测 VS 举荐算法
点击率预测须要给出精准的点击概率,比方广告A点击率0.5%、广告B的点击率0.12%等;而举荐算法很多时候只须要得出一个最优的秩序A>B>C即可。
点击率预测应用的算法通常是如逻辑回归(Logic Regression)这样的机器学习算法,而举荐算法则是一些基于协同过滤举荐、基于内容的举荐等思维实现的算法
5.2 点击率 VS 转化率
点击率预测是对每次广告的点击状况做出预测,能够断定这次为点击或不点击,也能够给出点击或不点击的概率
转化率指的是从状态A进入到状态B的概率,从达到网站到达成交易。
5.3 搜寻和非搜寻广告点击率预测的区别
搜寻中有很强的搜寻信号-“查问词(Query)”,查问词和广告内容的匹配水平很大水平影响了点击概率,搜寻广告的点击率广泛较高
非搜寻广告(例如展现广告,信息流广告)的点击率的计算很多就来源于用户的趣味和广告本身的特色,以及上下文环境。通常好地位能达到百分之几的点击率。对于很多底部的广告,点击率非常低,经常是千分之几,甚至更低
参考链接:
https://blog.csdn.net/wuzhongqiang/article/details/112544230