资产快照摘要日志
资产快照摘要日志帮助您分析游戏用户拥有的总资产流动。游戏开发公司执行查询以搜索资产的数量,而此日志配置查询结果,因此生成日志的数量因游戏而异。
- 在非角色基础的游戏中
- 市场 * 等级 * 选择活跃用户的时间段(自字段) * 唯一 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 hhss 例如: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"
}