跳转至

资产快照摘要日志

资产快照摘要日志帮助您分析游戏用户拥有的总资产流动。游戏开发公司执行查询以搜索资产的数量,而此日志配置查询结果,因此生成日志的数量因游戏而异。

  • 在非角色基础的游戏中
    • 市场 * 等级 * 选择活跃用户的时间段(自字段) * 唯一 asset_id 的数量
  • 在角色基础的游戏中
    • (市场 * 等级 * 选择活跃用户的时间段 * 基于角色的唯一 asset_id 的数量 * 角色类型) + (市场 * 等级 * 选择活跃用户的时间段 * 基于角色的唯一 asset_id 的数量 * 账户号码)

HIVE Analytics 可用于通过资产快照摘要日志分析以下状态。

  • 分析用户是仅仅收集资产还是消费资产
  • 分析不同级别资产的流动情况
  • 分析从日志生成时起,活跃用户在一、七和三十天内的资产流动情况

例如,动作益智家庭

  • 分别发送(资产 * 自)
  • 结果是(市场 * 级别 * 资产 * 自),因为按 [市场],[级别] 分组
  • 以以下日志格式发送查询结果:
SELECT 
    CONVERT(CHAR(10), getdate(),120),
    'KAK',
    'actionpuzzlefamily',
    [market],
    level,
    1 AS asset_id, 
    SUM(cash) AS cash, 
    COUNT(*), 
    30
FROM  #TEMP1
WHERE
    [marketcheck] = 1 AND 
    lastlogin >= (GETDATE()-30)
GROUP BY [market],[level]

类别

常见服务器 service_metrics-asset_snapshot_summary_log
测试服务器 service_metrics_test-asset_snapshot_summary_log

作为FTP类型发送

文件命名规范 asset_snapshot_summary_[日期]_[服务器]_[避免重复的ID].json 例如,asset_snapshot_summary_20180705_111500_GLOBAL-4.json

日志规范

Note

蛇形命名的字段,如 server_id,在存储到最终存储(BigQuery)时会转换为驼峰命名,如 serverId,而以未指定形式发送的日志,例如 serverid,不会保存在其列中。

字段名称 描述 类型 是否必填
date 存储日志的时间格式:yyyy-mm-dd hh🇲🇲ss 例如:2012-01-19 16:24:00 string Y
timezone 日志中时间参数的UTC偏移
* 将时区的值固定为**空白或GMT+09:00**,因为发送日志定义为scribe或ftp类型时,日期的值始终为KST。
例如:“GMT+09:00”
* 在发送日志定义为fluentd或http类型时,根据dateTime的值灵活设置时区的值。
例如:“GMT+10:30”
string Y
channel 登录渠道
C2S: HIVE
KAK: Kakao Talk
LIN: LINE
WEI: Weibo
STE: Steam
string(3) Y
game 使用游戏的品牌名称(例如,derbydays)。app_id的第三项
例如,com.com2us.littlelegends.kakao.freefull.apple.global.ios.universal => littlelegends
string (50) Y
market 市场信息
"TS": SKT Tstore
"OL": KT OllehMarket
"OZ": LGU+ OzStore
"AP": Apple Appstore
"GO": Google Play
"SA": Samsung Apps
"LE": Com2us Lebi
"MM": ChinaMobile MobileMarket
"SN": Sina WeiboPoint
"36": Qihu 360Point
"MO": Momo MomoPoint
"DN": DeNA MobagePoint
"NA": NaverAppStore
"AM": Amazon
"ON": OneStore
string(2) Y
level 用户在游戏中的等级(如果角色很多,则为最高等级) int Y
since 生成日志(日期字段)与上次登录之间的时间间隔,作为提取活跃用户的标准
0: 所有用户
1: 提取在生成日志前一天内活跃玩过游戏的用户
7: 提取在生成日志前七天内活跃玩过游戏的用户
30: 提取在生成日志前30天内活跃玩过游戏的用户
11: 提取在生成日志前一天注册的用户
17: 提取在生成日志前七天注册的用户
int Y
asset_id 对于可兑现资产/社交媒体积分,将此值设置为1到100,对于不可兑现资产,从101及更高的值开始
一旦定义,请勿更改。需要测试
(cf. 如果可兑现资产是用户通常在游戏中获得而不是购买的,请从101及更高的数字开始)
将资产类型设置为与cash_var_log/noncash_var_log相同的格式
int Y
asset_name 关于asset_id的简要说明(例如,铃铛、星星、金币、黄金) string(50) Y
amount 与asset_id相关的资产总量 bigint Y
count 与asset_id相关的资产数量 int Y
m_amount 目标资产的最大数量 bigint Y
server_ip 服务器IP堆叠日志(例如,游戏服务器IP) string(32) Y
company 游戏出版公司,日志的目标:
例如,“C2S”:Com2uS,“GVI”:Com2uS Holdings
string(3) Y
server_id 服务器代码
请参考服务器代码表输入服务器代码(JSON输入代码)
string Y
character_type_id 服务器中使用的角色类型的值
如果游戏没有角色,请将此值设置为0
int Y
character_level 服务器中使用的角色等级
如果游戏没有角色,请将此等级设置为 0
int Y
guid 每个日志生成的唯一键
推荐使用 uuid 等随机格式
varchar(64) N

日志示例

{
   "date": "2017-09-05 17:23:01",
   "game": "test",
   "market": "GO",
   "level": 34,
   "since": 17,
   "asset_id": 801,
   "asset_name": "ub9c8uc77cub9acuc9c0",
   "amount": 705,
   "count": 2,
   "m_amount": 405,
   "server_ip": "10.0.0.1",
   "server_id": "GLOBAL",
   "timezone": "UTC+9",
   "character_type_id": 0,
   "character_level": 0,
   "channel": "C2S",
   "company": "GVI",
   "guid": "ca4bd34c867f4617a819ae139d8d6670"
}

如何使用

  • 可以分析用户是消费还是仅仅储蓄的总资产流动。
  • 可以按级别或按活跃用户(一天、7天、30天)区分数据。