用户画像标签的设计
需求简单明了: 用户标签的数量多少(以权重来表示)
为方便管理 不同的标签分类(以模块来表示)
字段 gid, 模块名,标签名,标签值,权重
主题分类
人口属性模块、注册信息、终端设备、消费订单属性、消费商品退拒属性、生命周期、活跃属性、事件行为属性、商品偏好属性、价值属性、DSP属性、APP属性、兴趣类关键字、活跃地域标签
商城系统行为日志数据
用户终端属性、访问行为属性、活跃属性、偏好属性
商城系统业务数据
消费订单类属性、消费商品类、价值属性、注册信息
DSP系统竞价日志数据
广告栏位名称、广告平台商、兴趣关键词标签、终端属性、App属性
移动运营商流量日志
终端属性、购物类兴趣关键字、App属性
标签的抽取
每个值都是一个标签
不同日志抽取的标签合并用union合并标签
功能:将当日的标签计算结果,整合历史(前一日)标签结果
要考虑的点:
1. 当日可能有新的人
2. 历史记录中的人,当日可能没出现
3. 历史记录中的人,当日有新标签
4. 历史记录中的人,当日出现出现过的标签
5. 历史记录中的人,有标签当日没有出现
总结出来就是:
-- 对有权重的数据
历史标签 full join 当日标签
2. 历史有,当日有,权重累加
3. 历史有,当日无,权重衰减 (应该有衰减系数字典)
4. 历史无,当日有,取当日
-- 对无权重的数据
无权重标签,都是数仓报表中出来的,而数仓报表的数据,每天抽过来其实都是历史以来积累到当日的全量结果!
直接取当日数据!
1. 地理位置字典构建
2. app信息知识库构建
3. url内容知识库构建
4. idmp字典构建
1. 商城系统用户行为日志
2. dsp竞价日志
3. cmcc流量日志
清洗、过滤
解析
集成
格式转换
******《标签主题体系》******
1. 商城系统用户行为日志
2. dsp竞价日志
3. cmcc流量日志
4. 用户订单统计报表
5. 用户商品统计报表
6. 用户注册信息(注册手机、注册账号、注册性别、注册年龄、注册时间、注册方式(app上注册、pc上注册、微信小程序注册)、注册渠道(自发、百度搜索、x广告推广来的、x活动推广来的))
提取的标签有哪些?
*人口属性信息
*注册信息
*终端属性信息
*商品偏好信息
- 品类偏好
- 品牌偏好
- 价格偏好 : 30天内的商品消费价格区间偏好: 2 -9999.9
rangeid,rangename
1, 0-50
2, 50-100
3, 100-200
4, 200-400
5, 400-600
6, 600-800
7, 800-1000
- 颜色等商品属性偏好:
- 商品相关关键字偏好:瀑布屏:89 黑科技:10
*活跃属性
- 第一次访问时间
- 最近一次访问时间
- 30天内总访问次数
- 30天内总访问时长
- 30天内总访问深度
- 7天内
- .....
- 30天内的平均访问间隔
- ......
- 30天内收藏总次数
- 30天内点赞总次数
- 30天内好评总次数
- 30天内差评总次数
- 30天内分享总次数
*消费属性
- 首单时间
- 末单时间
- 累计消费总额
- 累计客单价
- 累计消费笔数
- 最大单笔消费额
- 最小单笔消费额
- 30天内消费总额
- 30天内客单价
- 30天内消费笔数
- 30天内单笔消费额
- 30天内单笔消费额
- 14天内消费总额
- 14天内客单价
- 14天内消费笔数
- 14天内单笔消费额
- 14天内单笔消费额
- 7天内消费总额
- 7天内客单价
- 7天内消费笔数
- 7天内单笔消费额
- 7天内单笔消费额
- .........
- 0-2点下单次数
- 2-4点下单次数
- 4-6点下单次数
- 6-8点下单次数
- 8-10点下单次数
- .....
*兴趣关键词 (主要来自于dsp日志和cmcc日志)
- 新闻类
- 体育类
- 娱乐类
- 影视类
*DSP广告业务标签
广告栏位
广告平台
.....
******《标签统一计算模型》******
一条数据,n个字段对画像有意义,每个字段变成一个标签,然后横表变竖表,就可以用统一的计算方式来计算(wordcount)
标签 ==》 模块名(id):标签名(id):标签值:权重
有权重:对相同人的相同标签,分组累加聚合
无权重:
有权重: 跟T-1日的full join,该累加累加,该衰减衰减(引用外部的系数字典表及衰减算法,不同标签有不同衰减速度)
无权重: 跟T-1日的full join,有新的就用新的,没有新的保留旧的
画像标签明细数据入库
各类画像运营分析报表的入库
画像结果入库
可能需要根据一个用户的某个标识,查询到这个人的整条或者某些标签数据!
而且,数据量比较庞大(画像数据中人数千万级、亿级)
(假如公司有用户1千万,标签有: 1000 w * 15模块 *10标签 * 3个值 = 45亿个标签)
那么,我们可以选择什么样的数据库来支撑这些需求呢?
mysql是否可以? 数据量小一点可以(百万级别-千万级别),数据量大不合适
优点:查询功能特别强大,速度快,可以写各种复杂sql查询
缺点:数量规模不能太大,而且不便于动态增长!不太适合半结构化数据!(明细标签数据是一个稀疏表)
hbase是否可以? 可以!
优点:数据规模可以很庞大,而且支持动态增长!非常适合存储稀疏表!
缺点:支持的查询功能简单!对复杂查询的支持非常弱!
缺点的改善方案:
创建二级索引!
或者使用phoenix(可以支持创建二级索引,可以支持复杂sql查询,而且查询性能在hbase原生api基础上还有提升!)
elastic search(不是数据库,全文检索引擎)是否可以? 可以!
优点: 数据规模可以比较大(亿级别,10亿就需要深入优化)!
条件查询很方便(全文索引)!
聚合统计查询也能支持!(相比hive、mysql来说,还是很弱的)
缺点: 对复杂查询分析的支持不够强!