跳轉至

资产快照摘要日志

資產快照摘要日誌幫助您分析遊戲用戶擁有的總資產流動。遊戲開發公司執行查詢以搜索資產數量，這個日誌配置查詢結果，因此生成日誌的數量因遊戲而異。

  • 在角色以外的遊戲情況下
    • 市場 * 等級 * 選擇活躍用戶的時間段（自字段） * 唯一 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 字串 Y
timezone 日誌中時間參數的 UTC 偏移
* 當以 scribe 或 ftp 類型發送日誌定義時，將時區的值固定為 空白或 GMT+09:00，因為日期的值始終為 KST。
例如，"GMT+09:00"
* 當以 fluentd 或 http 類型發送日誌定義時，根據 dateTime 的值靈活設置時區的值。
例如，"GMT+10:30"		 字串 Y
channel 登入渠道
C2S: HIVE
KAK: Kakao Talk
LIN: LINE
WEI: Weibo
STE: Steam		 字串(3) Y
game 使用遊戲的品牌名稱 (例如，derbydays)。app_id 的第三項
例如，com.com2us.littlelegends.kakao.freefull.apple.global.ios.universal => littlelegends		 字串 (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		 字串(2) Y
level 遊戲中用戶的等級 (如果角色很多，則為最高等級) 整數 Y
since 生成日誌 (日期欄位) 與最後登入之間的時間間隔，作為提取活躍用戶的標準
0: 所有用戶
1: 提取在生成日誌前一天內活躍遊玩的用戶
7: 提取在生成日誌前七天內活躍遊玩的用戶
30: 提取在生成日誌前三十天內活躍遊玩的用戶
11: 提取在生成日誌前一天註冊的用戶
17: 提取在生成日誌前七天註冊的用戶		 整數 Y
asset_id 將此值設置為 1 到 100 用於可兌現資產/社交媒體點數，101 及以上用於不可兌現資產
定義後，請勿更改。需要測試
(參考：如果可兌現資產是用戶通常在遊戲中獲得而不是購買的，則設置為 101 及以上的數字)
將資產類型設置為與 cash_var_log/noncash_var_log 相同的格式		 整數 Y
asset_name 關於 asset_id 的簡要說明 (例如，鈴鐺，星星，金球，金子) 字串(50) Y
amount 與 asset_id 相關的資產總額 bigint Y
count 與 asset_id 相關的資產數量 整數 Y
m_amount 目標資產的最大數量 bigint Y
server_ip 伺服器 IP 堆疊日誌 (例如，遊戲伺服器 IP) 字串(32) Y
company 遊戲發行公司，日誌的目標：
例如，"C2S": Com2uS, "GVI": Com2uS Holdings		 字串(3) Y
server_id 伺服器代碼
請參考 伺服器代碼表 輸入伺服器代碼 (JSON 輸入代碼)		 字串 Y
character_type_id 伺服器中使用的角色類型的值
如果遊戲沒有角色，則將此值設置為 0		 整數 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天）來區分數據。