运营分析系统说明.docx

运营分析系统说明.docx

《运营分析系统说明.docx》由会员分享，可在线阅读，更多相关《运营分析系统说明.docx（31页珍藏版）》请在冰点文库上搜索。

运营分析系统说明

X

X

X

X

运

营

分

析

系

目录2

1概述3

1.1目的3

1.2范围3

1.3定义与约束3

1.4参考资料3

1.5缩略语4

2经营分析系统目录规范4

3经营分析系统标准化指标4

3.1基础数据—在线类4

3.1.1实时在线4

3.1.2容量视图5

3.1.3历史在线5

3.1.4在线时长6

3.2基础数据—用户类8

3.2.1总况8

3.2.2注册用户9

3.2.3注册角色用户数11

3.2.4新注册用户流失跟踪12

3.2.5所有用户活跃情况13

3.2.6消费用户活跃情况15

3.2.7非消费用户活跃情况17

3.2.8活跃度18

3.3基础数据—付费用户类19

3.3.1总况19

3.3.2消费用户19

3.3.3充值用户19

3.3.4包月用户19

3.3.5消费行为活跃流失19

3.3.6消费活跃度19

3.4基础数据—收入类20

3.4.1总况20

3.4.2充值金额20

3.4.3道具收入20

3.4.4包月收入20

3.5游戏内容—玩家类20

3.5.1个体属性20

3.5.2群体属性20

3.6游戏内容—元素类20

3.6.1经济系统20

3.6.2系统物品产出20

3.6.3系统物品回收20

3.6.4其它物品情况20

3.6.5游戏场景展示（ACG类特有）20

3.7游戏内容—交互类21

3.7.1任务系统21

3.7.2交易系统21

3.7.3杀怪和PK21

3.7.4组队信息21

3.7.5副本信息21

4经营分析系统各业务特性指标21

4.1AVA特性指标分析21

4.2CF特性指标分析21

5经营分析系统后台监控信息21

5.1监控报告21

5.2程序运行详情21

5.3程序运行错误描述21

5.4错误影响21

1概述

1.1目的

本说明书是为了详细描述标准化的经营分析系统的各项指标的明确含义而写，防止读者对目前系统中的指标含义不明确而造成不必要的误解。

主要读者是经营分析系统使用人员。

1.2范围

本说明书描述标准化的经营分析系统的各项指标的明确含义，包括所有业务的标准化指标和各业务的特性指标的含义。

不包含设计和实现细节，标准化的经营分析系统实现请参考经营分析系统开发文档及经营分析系统设计文档等等。

1.3定义与约束

1.4参考资料

MMOG经营分析统计框架系统设计说明书》

MMOG经营分析统计框架典型统计设计方案》

1.5缩略语

MMOG

ACG

OSS

World

UIN

MassivelyMultiplayerOnlineGame大型多人冋时在线游戏

Animation、Comic、Game中型休闲游戏

OperationSupportSystem经营支撑系统游戏世界

UserIdentificationNumber用户识别码

2经营分析系统目录规范

目前经营分析系统总体上分为两部分，标准化部分和特性部分。

标准化部分是指经过长期的经验积累，找出所有游戏的共性指标组建而成。

特性类部分，是由于各游戏有自身的一些特点需要分析，所以需要存在。

3经营分析系统标准化指标

3.1基础数据一在线类

3.1.1实时在线

此项是用于展示该业务的实时在线情况的，可以从侧面反映出该业务的运营健康度情况。

如果在线图出现波动，则可以说明GameServer服务器侧有问题或者网络有波动而影响在线波动。

它的展示方式是每5分钟定时向GAMESERVER抓取该SERVER上的实时在线人数，每天会抓取出288个点。

展示方式是取最近24小时内的288个点用平滑曲线把这些点连接起来，来展示该业务的最近24小时内的在线趋势。

目前主要从三个方面来看该业务有在线情况：

总实时在线、分区实时在线和分IDC实

时在线。

3.1.1.1总实时在线

指标含义：

此页面是用来展示该业务所有大区（WORLD）汇总的实时在线趋势，就是把所有大区在线人数在一个图中进行展示。

数据来源：

展示的数据来自于tbRealOnline，使用条件iWorldld=255AND

iChannelld=65535

3.1.1.2分区实时在线

指标含义：

此页面是用来展示该业务各大区（WORLD）分区实时在线趋势，

每个大区的在线趋势单独展示一个图。

数据来源：

展示的数据来自于tbReaIOnline,使用条件iWorldId=所展示的大区

ID（WORLDID）ANDiChannelId=65535

3.1.1.3分IDC实时在线

指标含义：

此页面是用来展示该业务按IDC区分实时在线趋势。

数据来源：

展示的数据来自于tbIdcRealOnlineIDC实时在线统计表

3.1.2容量视图此项数据主要用于监控当前服务器容量是否可以满足玩家的需求,根据服务器的最大容

量和每天的最高在线,可以计算出每个大区、每个IDC以及所有大区汇总的容量使用情况。

如果当长期发现某个大区的容量使用率居高不下，则说明这个大区需要进行扩容了；相反，如果长期发现某个大区的容量使用率低靡不振，则说明这个大区有问题，原因当然是多方面的（如：

服务器状况不稳定不能正常游戏、此大区外挂猖獗造成玩家不想在此游戏、游戏本身没有吸引力等等），可以及时发现找原因，而采取相应的处理手段。

3.1.2.1实时服务器容量

指标含义：

反映各大区服务器实时容量使用率情况，计算方法是用当前各大区的在线人数除以对应大区的容量得出。

总容量使用率则是用所有大区在线汇总除以所有大区容量汇总得出。

数据来源：

实时在线表tbRealOnline和大区容量配置表dbOssConf.tbCapacity。

3.1.2.2服务器容量视图

指标含义：

反映各大区服务器最高容量使用率情况，计算方法是用各大区的昨日最高在线人数除以对应大区的容量得出。

总容量使用率则是用所有大区昨日最高在线汇总除以所有大区容量汇总得出。

数据来源：

历史在线表tbHistoryOnline和大区容量配置表dbOssConf.tbCapacity。

3.1.2.3服务器容量趋势

指标含义：

反映长期以来各大区容量使用率情况趋势的，计算方法是把3.1.2.2中的内容以最近一个月为单位，以曲线图的形式进行展示，可以看出各大区容量长期的一个使用情况的趋势图。

数据来源：

历史在线表tbHistoryOnline和大区容量配置表dbOssConf.tbCapacity。

3.124IDC容量视图

指标含义：

以IDC为单位来反映服务器的容量使用率情况，计算方法是以I

DC为单位，用各IDC的大区昨日最高在线汇总除以对应IDC的所有大区容量汇总得出。

可以以IDC来观察各IDC的服务器及网络健康情况。

数据来源：

历史在线表tbHistoryOnline和大区容量配置表dbOssConf.tbCapacity。

3.1.3历史在线

此项数据主要是对在线的过往历史情况的一个展现，通过此处可以查看该游戏的历史运营情况，何时停机维护了，何时做了活动了，何时是节假日等等信息，基本都可以在历史在线信息中得以很好的展示。

3.1.3.1最高在线和平均在线

指标含义：

展示汇总大区和各分区的历史最高在线、平均在线情况，每天一条

数据，默认展示最近一周的数据。

利用时间框可以对时间段进行选择，下拉框可以对大区进行选择。

计算方法是每天统计前一天各大区的数据。

最高在线：

就是前一天各大区在线人数最高时刻的数值，需要注意的是，所有大区最高在线不是对各大区最高在线的数据的累加而得，而是所有大区汇总最高在线时刻的值。

平均在线：

把昨天抓取的在线点的数据累加，除以抓取点的个数得出，所有大区汇总平均在线，也是用所有大区的在线数据得出。

数据来源：

历史在线表tbHistoryOnline，查询所有大区时iworldid使用255

进行查询。

3.1.3.2服务器在线人数

指标含义：

以自然日为单位按大区对业务的实时在线进行展示，实时在线展示是的游戏现在起最近24小时的实时在线情况，而此处是以自然日为单位，可以查看连续多日的在线情况。

数据来源：

实时在线表tbRealOnline

3.1.3.3IDC在线人数

指标含义：

以自然日为单位按IDC对业务的实时在线进行展示，IDC实时

在线展示是的游戏现在起最近24小时的实时在线情况，而此处是以自然日为单位，可以查看连续多日的各IDC的在线情况。

数据来源：

IDC实时在线表tbldcRealOnline

3.1.4在线时长

此项数据是以玩家的在线时长情况为维度对玩家的游戏行为进行观察。

按在线时长分段

展示玩家的平均在线人数，还增加了按等级展示玩家在线时长分布。

对于ACG类游戏还增

加了对玩家游戏时长的分析统计。

此项数据主要是从侧面来反映游戏对玩家的粘度的，玩家的在线时长越长，说明游戏的粘度越大。

另外，可以从玩家分级别在线情况看出，主要是哪些级别的玩家在线时间比较长，可以看出游戏的健康度。

如果低级别玩家在线时间比较长，说明游戏对新玩家比较有吸引力。

3.1.4.1平均在线时长区间分布

指标含义：

以小时为为单位，分大区对业务昨日玩家的在线情况进行展示。

对于全区汇总的展示，是对玩家数做过去重的，就是说是按独立UIN来计算的。

可以查看昨日玩家总在线人数，昨日玩家总在线时长（小时），玩家平均在线时长，以及以小时为单位的时长区间内玩家人数展示。

计算方法：

从玩家登录日志表进行统计，每个玩家从登录游戏一直到退出游戏内在线时长，如果一天中一个玩家登录多次，则对多次的在线时长进行累加。

全区统计时，对同一个独立UIN的在线时长也时行累加进行计算。

数据来源：

在线时长统计表tbPlayTime

3.1.4.2平均在线时长等级分布

指标含义：

主要是从玩家级别维度来观察，分大区对业务的玩家在线时长的人数分布情况进行展示。

对于全区汇总的展示，是对玩家数做过去重的，就是说是按独立UIN来计算的。

还可以在以在线时长区间的维度来查看昨日各级别玩家在线人数，也可以汇总查看各级别总的在线人数分布。

计算方法：

从玩家登录日志表进行统计，每个玩家从登录游戏一直到退出游戏内在线时长，如果一天中一个玩家登录多次，则对多次的在线时长进行累加，级别就取玩家当天最高级别进行统计。

全区统计时，对同一个独立UIN的在线时长也时行累加进行计算，级别则按玩家所有注册过的区的最高级别来进行计算。

数据来源：

在线时长级别分布统计表tbPlayTimeLvDis

3.1.4.3平均单次在线时长

指标含义：

展示所有玩家平均单次在线时长，以此来查看游戏的在线情况是否正常，服务器是否稳定等等。

如果玩家单次在线时长很短，那么可以从单方面来说明这个游戏无法长时间的进行游戏，或者也有可能是经常异常退出，导致单次在线时长低下。

具体业务可以根据此项内容具体分析。

计算方法：

从玩家登录日志表进行统计，所有玩家的登录次数以及所有玩家的在线时长。

这个统计是不做去重处理的，因为就是要查看所有玩家单次在线的时长。

数据来源：

在线时长统计表tbPlayTime登录次数统计表：

tbRoleLoginTimes

3.144平均游戏时长区间分布（ACG）

说明：

游戏时长只对ACG类游戏存在，因为ACG是需要建立房间才能进行游戏。

这样

游戏时长对于ACG游戏来讲还是很重要的，因为这类游戏的核心就是玩家建议房

间进行游戏，如果游戏时长比在线时长低很多，那就需要分析具体导致此问题的原因了。

指标含义：

以小时为为单位，分大区对业务昨日玩家的打游戏情况进行展示。

对于全区汇总的展示，是对玩家数做过去重的，就是说是按独立UIN来计算的。

可以查看昨日玩家总游戏人数，昨日玩家总游戏时长（小时），玩家平均游戏时长，以及以小时为单位的时长区间内玩家人数展示。

计算方法：

从玩家游戏日志表进行统计，每个玩家从进入游戏房间一直到退出游戏房间的时长，一个玩家一天中多次在房间内参加游戏，则对多次的游戏时长进行累加。

全区统计时，对同一个独立UIN的游戏时长也时行累加进行计算。

数据来源：

ACG游戏时长统计表tbAcgPlayTime

3.1.4.5平均在线时长等级分布（ACG）

指标含义：

主要是从玩家级别维度来观察，分大区对业务的玩家游戏时长的人数分布情况进行展示。

对于全区汇总的展示，是对玩家数做过去重的，就是说是按独立UIN来计算的。

还可以在以游戏时长区间的维度来查看昨日各级别玩家游戏人数，也可以汇总查看各级别总的游戏人数分布。

计算方法：

从玩家登录日志表进行统计，每个玩家从进行游戏房间游戏一直到退出游戏房间的时长，一个玩家一天中多次进入房间参加游戏，则对多次的游戏时长进行累加，级别就取玩家当天最高级别进行统计。

全区统计时，对同一个独立UIN的游戏时长也时行累加进行计算，级别则按玩家所有注册过的区的最高级别来进行计算。

数据来源：

ACG游戏时长级别分布统计表tbAcgPlayTimeLvDis

3.1.4.6游戏、在线时长比（ACG）

指标含义：

在同一个页面中展示游戏用户和在线用户人数比，以及玩家平均游戏时长和平均在线时长比。

比值越高，说明游戏的可玩性比较高。

比值如果很低的话，就可以从一方面说明登录游戏的玩家没有玩游戏，要不就是在聊天，要不就是无法正常游戏，或者是其它原因导致。

这个就需要具体业务具体再做分析了。

计算方法：

这个页面的数据不需要单独统计，就是把上面平均在线时长和平均游戏时长业务的数据整合在一个业务中进行展示，而且增加了比值折线图，从长远趋势可以看出游戏内容对玩家的吸引力。

数据来源：

在线时长统计表tbPlayTime游戏时长统计表：

tbAcgPlayTime

3.2基础数据—用户类

3.2.1总况

这个目录下的数据主要是下面目录数据的汇总，方便本系统用户直观地查看重要的数据。

如果需要了解数据详情，则需要用户点出对应目录下面的页面进行查看和分析。

3.2.1.1用户当日总况

指标含义：

展示该业务的核心指标。

在同一个页面中展示了总注册用户数，日新增注册用户数，日活跃用户数，最高在线，平均在线以及平均在线时长（单位：

小时）这些重要指标，可以让查看该业务的用户，对该业务的核心指标一目了然，而无需去查看多个页面来了解。

计算方法：

这个页面的数据不需要单独统计，就是把其它页面中的数据进行整合展示而已。

数据来源：

注册用户信息统计表tbUserRegister活跃用户信息统计表：

tbUserLogin历史在线表：

tbHistoryOnline在线时长表：

tbPlayTime

3.2.1.2周用户总况

指标含义：

以周为单位展示用户信息。

包括周新增注册用户数，周活跃用户数，周流失用户数及周回流用户数。

计算方法：

这个页面的数据不需要单独统计，就是把其它页面中的数据进行整合展示而已。

数据来源：

注册用户信息统计表tbUserRegister活跃用户信息统计表：

tbUserLogin

3.2.1.3双周用户总况

指标含义：

以双周为单位展示用户信息。

包括双周新增注册用户数，双周活跃用户数，双周流失用户数及双周回流用户数。

计算方法：

这个页面的数据不需要单独统计，就是把其它页面中的数据进行整合展示而已。

数据来源：

注册用户信息统计表tbUserRegister活跃用户信息统计表：

tbUserLogin

3.2.1.4月、双月用户总况

指标含义：

以月为单位展示用户信息。

包括月新增注册用户数，月活跃用户数，月流失用户数、双月活跃用户数及沉默用户数。

计算方法：

这个页面的数据不需要单独统计，就是把其它页面中的数据进行整合展示而已。

数据来源：

注册用户信息统计表tbUserRegister活跃用户信息统计表：

tbUserLogin

3.2.1.5用户流失率总况

指标含义：

以流失用户为观察点展示付费用户、非付费用户及活跃用户的流失情况。

包括非付费用户的周、双周、月流失率，月活跃用户数，付费用户的周、双周、月流失率，月活跃用户数以及活跃用户的周、双周、月流失率，月活跃用户数。

计算方法：

这个页面的数据不需要单独统计，就是把其它页面中的数据进行整

合展示而已。

数据来源：

注册用户信息统计表tbUserRegister活跃用户信息统计表：

tbUserLogin

3.2.1.6掉线用户数

指标含义：

从玩家退出游戏是否正常的角度来查看游戏服务器的稳定性，查看各种退出游戏玩家的数量和退出次数。

例如玩家退出可以分为正常退出（玩家自己关闭客户端退出游戏），异常退出（包括双开游戏被服务器拒绝退出、网络掉线被服务器退出、被认为是外挂踢出等等）。

计算方法：

通过对玩家登出日志进行统计，需要研发的玩家退出日志中记录玩家退出时的状态，是正常退出还是异常退出。

按照玩家退出类型，进行分类统计。

对于同一个玩家多次退出，统计时会统计为1人，但是对退出次数则是会进行累加的。

数据来源：

玩家掉线统计表tbExceptionalOffline玩家掉线类型配置表：

tbOfflineConf

3.2.2注册用户

3.2.2.1注册新增用户数

指标含义：

用来展示该业务注册用户相关信息，包括总注册用户数（游戏内所有大区注册玩家独立UIN数，如果一个玩家在多个区重复注册角色，只会算一次，不重复计算），日新增注册用户数（当天第一次在该业务注册角色的独立UIN玩家数，如果玩家在该业务其它区注册过角色，则不会被计算），周新增注册用户数（最近一周内，第一次在该业务注册角色的独立UIN玩家数），双周新增注册用户数（最近两周内，第一次在该业务注册角色的独立UIN玩家数），月周新增注册用户数（最近30天内，第一次在该业务注册角色的独立UIN玩家数，遇到每个自然月的最后一天，会按自然月进行计算。

例如2月28日时，会计算2月1日到2月28日内该业务的新注册用户数，而不是计算最近30天的，请注意）。

计算方法：

目前大多数业务是根据玩家登入和登出游戏的日志进行统计的，如果玩家是第一次登入游戏，那么就会被认为是新注册用户，然后一直累计到统计当日的注册用户数，就为总注册用户数，周、双周、月的则以统计当天算起，最近7天、14天、30天的新注册用户数。

但是考虑到登入日志偶尔会出现丢失现象，所以现在我们都是对游戏的登入和登出日志都进行统计的。

理论上这种方式统计出的注册用户数应该和游戏注册用户表里的数据是一样的，但是偶尔存在部分玩家注册不成功时，游戏角色表中无玩家信息，但是登录日志中有玩家日志。

或者角色表中有玩家信息，而日志中无记录等问题。

就目前各业务使用情况来看，这种情况影响很小，可以暂不关注。

数据来源：

用户注册信息表tbUserRegister

3.2.2.2新注册用户地区分布

这个指标是从新

指标含义：

新注册用户的定义及计算方法上面已经介绍过了。

注册用户的IP来区分新注册用户的地区分布，目前只能精确到省。

该指标主要用于查看该业务的用户主要来自于哪个地区，可以用来评估地区活动拉新的情况。

目前只能查看所有大区汇总的情况，不支持单区查询。

计算方法：

根据新增玩家第一次登录时IP地址来进行区分，每个独立UIN只会计算一次，就是说如果同一个玩家在多个区注册了角色，那么只以他第一次登录游戏时的IP为准，其它的不会在重复计算。

这个统计还需要依赖于我们所使用的IP库。

数据来源：

新注册用户地区分布表tbDayRegRegionDis

3.2.2.3总注册用户地区分布

指标含义：

所有注册用户按地区分布展示。

用于查看当前该业务所有注册用户的分布情况。

计算方法：

不做另外单独统计，直接对每天新注册用户地区分布的表进行累加。

由于每天的新注册用户是不会和以前的重复的，所以直接累加就可以了。

但是由于存在部分业务不删档前的数据没有删除，所以会发现造成查看总注册用户地区分布里，所有地区的用户累加后，会大于上面统计出的总注册用户数，这个是由于多加了不删档前的数据，如需要去掉，可以联系该业务对应技术人员进行处理。

数据来源：

新注册用户地区分布表tbDayRegRegionDis

3.2.2.4新注册用户存留跟踪（90天）

指标含义：

对每天的新注册用户进行存留分析。

玩家如果登录游戏，则被认为存留，否则被认为流失。

这个指标会对每天的新注册用户，在接下来的90天进行跟踪分析他们的登录行为。

主要用于分析该业务对于新注册用户的吸引力。

所有业务第1天的用户存留都为100%，因为注册当日肯定会登录游戏，那么我们观察的重点就是接下来的情况，正常情况接下来的存留值应该是一个比较稳定的值，这些用户就是我们的目标用户，应该尽量保护他们，让他们持续的玩下去。

刚公测的游戏一般新注册用户存留率会比较高，理想情况应该可以达到30%左右，太低则需要对业务进行调研。

稳定的业务一

般维持在10%左右。

计算方法：

对每天的新注册用户，在接下来的90天进行登录跟踪分析，我们约定注册当日为第一天，接下来为第二天，依次类推，会统计接下来90天的情况。

例子：

例如1月1日新注册用户数为1000人，那么1月1日的第一天存留用户会记录为1000。

接下来观察1月2日当日1月1日注册的1000用户在1月2日的登录情况，我们假设1000人中，有700人在1月2日登录了，那么就会记录1月1日注册用户的第二天存留人数为700。

同理，当这1000人在1月3日有300人登录，则我们会记录1月1日的新注册用户的第三天存留用户数为300。

接下来

会跟踪90天，计算方法和原理是一样的。

从这个例子中也可以看出，留存用户是可以重复的，就是说1月2号登录的700人中，可能在1月3号也登录了，这个在1月3号中是不会做去重处理，请注意。

数据来源：

新注册用户存留分析表tbResidentUser

3.2.2.5新注册存留用户等级分布（30天）

指标含义：

和新注册用户存留跟踪的含义完全相同，只是更细化从用户级别维度来查看新注册用户存留情况。

计算方法：

和新注册用户存留跟踪的方法相同，但是增加每天跟踪用户的级别

细分。

3.2.3注册角色用户数

增加通过各大区的注册角色数来观察游戏，这项指标可以按大区进行查看，以此来反应游戏注册角色过程中的运营情况。

3.2.3.1注册角色用户数

指标含义：

指标含义和注册新增用户数一样，包括总注册角色用户数、日新增注册角色用户数、周新增注册角色用户