数数TA系统埋点结构优化需求.md 4.9 KB
数数TA系统埋点结构优化需求
一、背景
由于我们的数据量过于庞大，导致TA系统现有的服务器集群的计算压力较大，后台个别报表计算速度很慢（单次计算耗时10分钟甚至更高），影响了数据分析的效率。
数数方面针对这个问题在近期登门拜访，就我们当下的埋点结构、上报方式、报表逻辑进行了梳理，指出了几点可优化的问题。
二、需求内容
1.在线时长监控方式优化
停用在线时长事件，改用用户登出事件监控在线时长
- 事件上报逻辑：
服务器检测到用户离线后，立即上报用户登出事件。同时上报本次登录在线时长。
- 在线时长计算逻辑参考：
方案1.取用户登出事件触发的时间与最近一次用户登录的时间进行计算，求得总在线时长
方案2.用户登录后服务器开始计时，到用户登出时上报本次登录的计时结果
事件名
事件显示名
事件说明
属性名
属性显示名
属性类型
属性说明
logout
用户登出
服务器检测到玩家登出游戏时，上报事件
在线时长
数值
本次登录的在线时长
2.活跃用户监控方式优化
补充用户跨日活跃时，后N日的用户登出、用户登录事件上报
- 事件上报逻辑：
服务器上报用户登出事件时，计算登出日期与最近一次登录日期的天数差N
If 天数差N=0
不进行任何操作，按照默认逻辑上报
If 天数差N>0
设最近一次登录日为第0日，补报第1日至第N日的用户登出、用户登录事件
- 补报时将登出事件的触发日期设在前1日23:59:59（方便计算前1日在线时长）
- 补报时将登录事件的触发日期设在当日00:00:00（方便计算日活以及当日在线时长）
如上图，按补报逻辑进行数据上报，可以准确的统计用户跨日活跃情况下的在线时长、活跃情况。
- 若不进行补报，用户只会在第一日、第三日出现登录行为，第二日的活跃情况、在线时长将会丢失。
- 进行补报后，用户在第一日、第二日、第三日都有登录/登出事件上报，每日的活跃情况、在线时长都会被记录到。
3.游戏产销监控方式优化
将原有产销监控事件下的获得道具、消耗道具事件停用，按道具类别拆分为几个子事件进行上报。减少此类数据查询时的单次计算量。
道具类别脑图详见 [[道具类别]]
道具类别映射表详见道具类别映射表
暂时无法在文档外展示此内容
事件名
事件显示名
事件说明
属性名
属性显示名
属性类型
add_currency
获得货币
获得任意货币时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
del_currency
消耗货币
消耗任意货币时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
add_voucher
获得凭证
获得任意凭证时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
del_voucher
消耗凭证
消耗任意凭证时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
add_play
获得玩法道具
获得任意玩法道具时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
del_play
消耗玩法道具
消耗任意玩法道具时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
add_skin
获得外观
获得任意外观时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
del_skin
消耗外观
消耗任意外观时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
add_other
获得其它道具
获得任意其它道具时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串
del_other
消耗其它道具
消耗任意其它道具时，上报数据
item_id
道具ID
数值
change_num
变动量
数值
change_reason
一级原因
数值
sub_reason
二级原因
字符串