系列文章：
- 遊戲日志分析（1）：概覽
- 遊戲日志分析（2）：全方位資料采集
- 遊戲日志分析（3）：程式日志規範與埋點
- 遊戲日志分析（4）：線上問題定位與排查
- 遊戲日志分析（5）：資料庫與日志關聯分析
- 遊戲日志分析（6）：CDN/對象存儲日志分析
- 遊戲日志分析（7）：網絡日志查詢與分析
- 遊戲日志分析（8）：資料庫日志分析
- 遊戲日志分析（9）：安全日志分析
- 遊戲日志分析（10）：資料可視化與報表
- 遊戲日志分析（11）：數倉建設
- 遊戲日志分析（12）：實時資料處理與流計算
遊戲挑戰與機遇
我們先看一張圖，這張圖是應用市場的一個報告：統計了最近4年中，一款遊戲從上架到達到90%下載下傳量持續的時間長度（生命周期），橫軸代表的是年份，縱軸代表的是持續的周數。在2012年，一款遊戲平均可以持續180周（也就是說到了2014年仍有人下載下傳），但這個比例每年在持續下滑，到2015年該區間已經到了24周，進入快餐式消費時代。
不管背後原因是什麼，從整個趨勢來看遊戲行業已經從賣方市場（20年前遊戲卡帶互相借閱，一卡難求），到現在的買方市場。
第二個趨勢是：雲計算改變了行業，一個顯著特征是遊戲部署、上線時間縮短了。原先繁重運維工作進一步地減輕，傳統意義上運維轉向了營運。這是時代的挑戰，也是全棧工程師的幸運。
剛才兩點更多是共同面對的問題，第三點就是大資料制造的機遇了。我們把2015年24周打開看一下，機會在哪裡？從圖表中可以看到，遊戲一般有4個階段：研發、增長、成熟、衰退。在增長階段我們會遇到模仿者，搶占市場佔有率。怎麼去應對模仿者？少犯錯、離使用者更近一些，實時更改自己的營運政策。
遊戲運作規律
雖然市場很激烈，但20多年來使用者的習慣仍然不變。我們可以看下ongamesdata在的一副漫畫。面對一款新的遊戲時：
- 使用者首先會嘗試下載下傳demo
- 之後會喜歡上遊戲，和遊戲朝夕相處
- 某些熱愛的玩家會在facebook/twitter等傳播遊戲、引入更多的玩家
- 為遊戲付費
客觀上看遊戲使用者并沒有因為市場競争激烈而減少，相反移動網際網路的出現讓使用者在閑暇時間可以享受遊戲，社交媒體使得好的遊戲更容易傳播，使用者也越來越舍得花錢，市場的機會還是存在的。
為洞察使用者，團隊需要做什麼？
為了能夠讓使用者愛上我們的遊戲，能夠長時間參與，最好的方法就是數字化整個過程。在一個團隊中，不同的人在不同的方面關注遊戲運作的狀态，讓我們來看一些例子，不同的人會關注什麼？
A 總監
總監需要對整體狀況有一個客觀、宏觀的衡量，并能夠快速分析出原因，制定宏觀戰略。例如FarmVille（開心農場）DAU變化舉例：
除此之外，我們可以通過使用者特征、曆史行為記錄，反複參與程度等預測一個遊戲可能的歡迎歡迎程度。例如我們可以根據觀察到的資料（A、B、C）去預測一個結果（例如30天留存率），例如樣本1就有很大機率會留存。
| 名額 | 含義 | 樣本1 | 樣本2 |
|---|---|---|---|
| A | 使用者一周玩的時間 | 4 | 0.5 |
| B | 使用者在遊戲成長速度 | 3.5 | 1 |
| C | 使用者在遊戲中購買道具數目 | 25 | |
| 預測30天留存率 | 95% | 5% |
其他重要名額包括：
- DNU（Daily New Users）： 每日遊戲中的新登入使用者數量
- AU（Active Users）：活躍使用者，統計周期内，登入過遊戲的使用者數。相應的，根據統計周期，有DAU(日活躍使用者)，WAU(周活躍使用者),MAU(月活躍使用者)等。
- PU ( Paying User）：付費使用者
-
APA（Active Payment Account）：活躍付費使用者數。這裡我們要注意“使用者”和“付費使用者”的區分，這也将影響收入的計算。
ARPU(Average Revenue Per User) ：平均每使用者收入，即可通過 總收入/AU 計算得出。
- ARPPU (Average Revenue Per Paying User)： 平均每付費使用者收入，可通過 總收入/APA 計算得出。
- PUR(Pay User Rate)：付費比率，可通過 APA/AU 計算得出。
- LTV(Lift Time Value)：生命周期價值，即平均一個使用者在首次登入遊戲到最後一次登入遊戲内，為該遊戲創造的收入總計
B 遊戲營運者
遊戲總監和規劃主要focus在宏觀戰略層面做出決策，營運則需要在各個階段打精細化之戰。以我們提到的遊戲四個階段為例子：
在遊戲投入市場後，需要在短時間内積累足夠的使用者數，我們會在廣告和推廣上下功夫。例如我們可以從頁面埋點獲得有多少使用者看到廣告、點選了遊戲下載下傳，輸入了賬号。
在遊戲的試玩階段，我們要從玩家的角度去衡量“參與度”。以FPS和頁遊為案例，我們可以把使用者分成幾個階段，衡量每個階段玩家的數目，耗費的時間及轉化率。
營運主要關心的名額有
- CVR (Click Value Rate): 轉化率，衡量CPA廣告效果的名額
- CTR (Click Through Rate): 點選率
- CPC (Cost Per Click): 按點選計費
- CPA (Cost Per Action): 按成果數計費
- CPM (Cost Per Mille): 按千次展現計費
C 遊戲開發者
這裡說的開發者是偏向營運的開發人員，這類角色需要不斷遊戲的參數以確定平衡性與使用者體驗。例如以“今晚吃雞”的FPS遊戲為例，需要統計各道具的平衡性，以及關卡的難度設定：
- 程式員通過不同Kill事件統計武器的平衡性
- 通過地圖可視化，調整關卡的難度與設定
除此之外，一般關心的資料有：
- EED：Enter Event 進入事件
- XED：Exit Event 最後退出事件
D 開發運維人員
開發運維人員（DevOps）最關注的是遊戲的SLA、穩定性、使用者使用的體驗（延時、順暢性）以及成本。另外如何對線上進行快速排查也是至關重要的，主要考慮點有：
- CDN的品質是否符合預期，全國各地的使用者是怎麼來通路的？
- 遊戲各個伺服器分布位置與使用者增長分布
- 遊戲用戶端的卡頓率，崩潰率，使用模式等
- 服務端通路的延時、品質等
- 線上程式的日志查詢、Debug，問題定位
E 客服人員
客服主要進行使用者的咨詢、問題的排查與診斷。例如
- 有使用者丢失道具、如何排查
- 分析使用者行為，是否有作弊等出現
- 登入失敗、充值失敗、下載下傳失敗、無法連接配接伺服器等問題排查
收集使用者行為、優化遊戲整個過程
為了拿到以上結果，遊戲團隊需要做什麼事情？我們可以大緻拆分成三個過程：
- 在遊戲開發階段埋點
- 在各個管道收集資料
- 對資料進行多元度的分析，拿到結果采取行動
在整個過程中串起使用者端和服務端最重要的點就是日志資料。
運作兩種狀态：切片(Snapshot)狀态和增量日志
為了更好了解日志和遊戲的關系，讓我們來看下什麼是日志資料，和遊戲之間是什麼關系：
遊戲在使用者端看起來是兩個行為交替：行動、繪圖。當移動滑鼠、點選鍵盤時我們改變了主人公位置和狀态，之後渲染引擎進行了繪圖。我們可以在一個時間點上對遊戲的狀态進行采樣，例如10：06分，遊戲中所有主人公的位置、金錢和手持武器如下，狀态反映一個時間點下系統的全貌。
日志是狀态與狀态之間的變化量。例如10點-10點06分這個時間上使用者做了哪些操作？日志相比狀态最大的好處是，能夠記錄整個細節。
狀态資料一般會儲存在資料庫（DB 或 NoSQL）中，資料量在幾百G一下。
日志其他作用
除了剛才提到的幫助營運、管道更高效地運作，日志對遊戲還有什麼作用？
- 幫助使用者：
- 找尋丢失：裝備掉了
- 修複資料：機器當機資料丢失了，可以通過日志來進行還原
- 定位異常：
- 找到偷盜、作弊等行為
- 廣告；
- 沒有打赢Boss：缺少什麼道具
- 使用者畫像：年齡、性别、什麼是你的菜？
- 日志可以幫助運維
- 使用者反映卡，在什麼環節
- 登陸失敗，背後是什麼原因
日志處理幾個挑戰
日志有那麼多的作用，那處理起來有哪些挑戰呢？
第一個挑戰和産生相關，遊戲涉及到方方面面的合作。例如涉及遊戲發行商、移動端、網頁端、伺服器端等。是以要從多個次元、多個管道來收集日志，對于每一種日志有獨特處理方法：例如為了分析管道我們需要在網頁埋點；為了拿到使用者的行為，我們需要從移動裝置、服務端等記錄玩家軌迹；為了分析服務的穩定性，我們需要觀察請求的延時等特點。
在這裡我們需要使用一個統一的資料模型，支援各個管道的資料通道來完成統一大事。
第二個挑戰來自規模、性能和穩定性：舉一個直覺例子，假設每秒鐘我們需要收集一個使用者1KB資料，在100W玩家同時線上的情況下，這個數字就是100MB/S處理流量，這個量挑戰不小。如何在資料規模增長的情況下，保持性能的穩定性，是工程師需要關注的。
第三個挑戰來自于需求，在之前我們提到了遊戲團隊中不同人對于需求的産出是不同的。比如對通路日志，營運的需求是統計活躍人數比例，運維關系的是延遲和通路狀态，開發關心的點是哪些資源是熱點，需要進行優化。是以我們需要對一份資料，支援多種處理、統計的方法。
阿裡雲日志服務
阿裡雲的日志服務（log service）是針對日志類資料的一站式服務，2013年研發，有5年多線上運作經驗，經曆雙十一、新春紅包等考驗。對應的Agent運作在100W+機器上，為萬級别應用提供服務。主要特點點如下：
日志服務主要包括 實時采集與消費、資料投遞、查詢與實時分析 等功能，接下來我們介紹下如何利用日志服務進行遊戲日志處理與分析。