用户个性化推送的基本流程
本文主要阐述的是用户个性化推送的基本流程,让大家对个性化推送有个初步的认知,大牛左转,里面涉及的流程主要基于本公司的情况。涉及到的架构见下图。
基于个性化推送的要求,必然是需要根据当前用户画像而做的实时计算过程,在形式表现上不单单只是个广告图片,部分表现为文本,视频类的等不同内容的推送,要求在一定时间内到达用户,并能跟踪整个推送的效果的过程。
涉及点如下
用户画像的计算
用户来了,这里情况有
用户清掉了缓存app的重置了设备号
用户从来没登陆过
用户曾经登录过,以后没登录
用户登录了一个帐号
用户登录过不同的帐号
本文只讨论登录了一个帐号的情况
以下都是本公司对用户的描述
用户有三种:有效用户、沉睡用户、除去前两种以外的用户。
为了缩短篇幅只讨论有效用户,第二种,与部分第三种用户的画像计算,以及前面用户的识别以后会有专门的一篇文章详细描述。
有效用户这里的活跃指的是一年内玩过至少一次游戏的,能提取到的数据,一般包括用户的唯一通行证,是日活跃,月活跃。是否为付费用户,付费的阶层,付费的周期。在线时长,玩家的进阶,登录的周期,流失可能性的阶层划分,比如3个月没玩,用户所在城市等,这是应用内的画像。
用户访问当前的页面的同时也会产生用户的访问路径,我们实时的收集用户访问的页面数据,比如页面的title,主要用作语义分析,对于论坛相当一部分数据会用户的一种心里变化,对于销售部分主要反映为用户访问了哪些道具,或者活动之类的,有感兴趣的可能性。这是用户当前访问路径的画像。
根据上面这些指标结合个人具体业务的情况我们获得了当前的用户画像与应用内的画像。
对照架构图而言就是用户访问路径,我们通过kafka转发到各个数据处理层如spark,主要用来计算用户实时的画像以及用户当前的变化对他过往画像的影响,并反馈到redis中。hadoop计算量比较大的统计类数据。
内容推荐
哪些部分可以用于推送内容
这里主要指页面,APP等终端的改造,比如特定的页面,特定的APP,目前APP部分暂时并没有通过常连接推送,这块需求还在整理中,app主要是通过webview的方式接入,情况和页面的一样。
方法一按照广告位推送,一个页面有多个广告位,预先将广告位编号埋入页面,按照多个广告位去一次或多次请求,
方法二指定页面编号,请求的时候直接请求页面编号,由于存在页面与广告位的逻辑关系,所以可以将数据按照广告位一次返回。
有哪些内容可以作为推荐
内容介质的属性,这块初始的数值主要由运营人员在原系统判定,比如热门道具,新服活动。
由于我们各个广告位的图片大小不一,素材只能使用当前广告位一样大小的素材。
推荐
redis为了控制数据量,我们放了元数据,比如广告内容,内容标签,广告编号,页面编号,用户画像,以及部分基于协同过滤用户感兴趣比较大的广告
整块的用户能看到什么广告,由nginx的lua模块,通过计算用户的权重与内容标签的得分排序获得。
对接
各个子系统的对接,这里指获取原系统的广告内容,方法若干比如restful,dubbo,etl等。
数据跟踪
主要是用户点击了,推送的内容后产生的后续动作,比如购买行为等,主要用作数据评估,校验效果合理性。