很多游戲運營朋友可能不知道,其實在埋點和報表之間還存在著一條巨大的鴻溝。
這條鴻溝就是怎么去設計系統的埋點,怎么去推動前后端落地,再到怎么核對校驗數據、取數、清洗數據、數據計算,最后再到數據固化形成報表。
以這些路徑里面的埋點為例,我在前文曾經放過一張表:
這個其實只是簡單的字段類型表,當真的在做一款游戲的時候,數據埋點工作是相當繁瑣。
首先需要梳理整個系統的事件和事件類型,然后要定義事件的觸發時機,再去定義需要投遞的參數內容和參數類型。
比如最簡單的登錄行為,什么節點視為開始登錄,什么節點視為登錄成功?需要投遞什么樣的參數?
像渠道的登錄成功的節點一般是SDK登錄成功,而游戲的登錄成功可能是創角之后進入游戲,也可能是直接進入游戲,觸發時機就明顯不一樣,需要特別定義清楚。
對于游戲運營來說,這整套流程是一個專業度要求較高,并且又非常耗費團隊資源的工作。很難推動,不做又十分尷尬。
對于大廠來說,已經有專業的數據團隊(數據中臺)給出統一的埋點規范,作為游戲開發團隊,只要按照規范投遞即可獲取想要的數據和報表。
并且對于一些個性化的分析需求,比如用戶留存系列分析,用戶流失系列分析等,還有專門的數據分析團隊來支持。
對于小廠來說,數據中臺是一個高投入,產出見效慢的工作。
以前習慣了賺快錢的土老板很難理解做這件事的意義,所以要么就胡亂做一個簡陋的數據,要么就上線裸奔(別笑,我以前待過的某團隊就是上線裸奔狀態,什么數據都沒有,決策全靠拍腦袋)。
近幾年的第三方數據平臺應運而生,實際上就是想解決這樣的痛點。但是往往太過標準化的產品只能解決一部分問題,還有一部分需求滿足不了。
所以在這種背景下游戲運營與其去費力理解怎么做系統埋點,不如先搞清楚什么樣的數據報表是我們所需要的,在此基礎之上再想辦法解決數據的問題。
當你有機會提數據平臺的需求的時候,你至少要知道你想要什么吧?至少要知道你的決策需要依賴哪些數據吧?
不客氣地說,我甚至見過不少所謂的項目負責人提出的數據需求都亂七八糟的。
那么一個通用的數據運營系統應該是什么樣的?
我把通用的的數據運營系統分成六個部分:
完整高清內容在公眾號“姚偉的寫字臺”回復:“通用游戲運營數據系統”即可獲取
核心數據主要是反映游戲的大盤狀況,作為運營負責人或者老板必看的表就是核心日報和綜合運營報表。
多說一句,其實這也是數據分析的一個重要邏輯,數據異常時,先看大盤數據然后再分渠道或者分指標去拆分數據看。
以實時數據為例,實時數據一般關心的字段有:實時新增數據(累計)、實時在線人數(累計)、實時充值金額(累計)等。
比如在線人數為,報表參考樣式如下:
數據是我隨手填的,真實的時間應該還有23:25,23:20等等,我這里嫌麻煩用省略號了。
注意,后續的所有報表一般都要支持篩選渠道和服務器。
一般實時數據的時間間隔在5-15分鐘之間,如果要壓縮到比如5秒左右的話,對于數據庫的壓力會非常大,5分鐘基本能滿足需求。
有的時候光報表看起來不夠直觀,負責數據的同學可能會做一些數據的可視化,比如折線圖等,這樣能充分顯示出數據的趨勢和波動。這里就不再展示了。
核心日報的字段和樣式不固定,這里不必追求大而全,主要是圍繞運營需求和老板需求來,夠用就好。
比如老板關心dau和收入,運營關心留存和新增,那這里的報表展示這些字段即可。
運營綜合報表反映的就是整個的大盤數據,主要包括全部用戶和新用戶的全部數據。
大致樣式如圖:
用戶分析主要包括六個部分:新增用戶分析、付費分析、活躍分析、流失分析、用戶養成分析、用戶行為路徑分析。
系統分析主要四個部分:活動分析、經濟系統分析、玩法系統分析、其他功能分析。
區服分析主要分5個部分:開服數據概覽、開服月分析、開服留存分析、服務器數據
限于篇幅原因,本篇只能展示用戶分析、系統分析和區服分析的腦圖,詳細報表形式和內容需要單獨開篇進行講解,有興趣的同學可以留言,人多的話會繼續更新,畢竟腦圖就寫了幾個小時,完整一篇寫下來要死了…
GM工具其實嚴格來說不應該歸類于數據系統中,但是考慮到很多公司連GM工具都做不好,后續也會單獨開篇進行講解。
以上內容如果能做成運營后臺,基本能滿足80%的運營和迭代需求,其余20%的個性化需求需要單獨由數據分析師進行取數計算分析。
大廠和不少第三方數據平臺現在實際上也是支持定制計算的(主要是不少運營不會寫SQL語句),但是效果一言難盡。所以這里就不再贅述了。
這次游戲數據運營系統的文章加腦圖寫了差不多七八個小時,如果看的人多的話會更新成一個系列。關注我的互聯網領域的朋友放心,我后續還是會寫互聯網的產品運營方法論的。
作者:姚偉的寫字臺
來源:姚偉的寫字臺
136 0806 8886【加微信請注明來意】
四川省成都市高新區天府三街1599號(天府三街與南華路交匯處)