写在前面
先就不写了。
任务介绍
- 本次任务:是根据淘宝广告展示和用户点击行为的数据集,去做的一个广告推荐系统。
- 达到的目的:给我们一个用户的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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。