很多游戲運(yùn)營朋友可能不知道，其實(shí)在埋點(diǎn)和報表之間還存在著一條巨大的鴻溝。

這條鴻溝就是怎么去設(shè)計系統(tǒng)的埋點(diǎn)，怎么去推動前后端落地，再到怎么核對校驗(yàn)數(shù)據(jù)、取數(shù)、清洗數(shù)據(jù)、數(shù)據(jù)計算，最后再到數(shù)據(jù)固化形成報表。

以這些路徑里面的埋點(diǎn)為例，我在前文曾經(jīng)放過一張表：

這個其實(shí)只是簡單的字段類型表，當(dāng)真的在做一款游戲的時候，數(shù)據(jù)埋點(diǎn)工作是相當(dāng)繁瑣。

首先需要梳理整個系統(tǒng)的事件和事件類型，然后要定義事件的觸發(fā)時機(jī)，再去定義需要投遞的參數(shù)內(nèi)容和參數(shù)類型。

比如最簡單的登錄行為，什么節(jié)點(diǎn)視為開始登錄，什么節(jié)點(diǎn)視為登錄成功？需要投遞什么樣的參數(shù)？

像渠道的登錄成功的節(jié)點(diǎn)一般是SDK登錄成功，而游戲的登錄成功可能是創(chuàng)角之后進(jìn)入游戲，也可能是直接進(jìn)入游戲，觸發(fā)時機(jī)就明顯不一樣，需要特別定義清楚。

對于游戲運(yùn)營來說，這整套流程是一個專業(yè)度要求較高，并且又非常耗費(fèi)團(tuán)隊資源的工作。很難推動，不做又十分尷尬。

對于大廠來說，已經(jīng)有專業(yè)的數(shù)據(jù)團(tuán)隊（數(shù)據(jù)中臺）給出統(tǒng)一的埋點(diǎn)規(guī)范，作為游戲開發(fā)團(tuán)隊，只要按照規(guī)范投遞即可獲取想要的數(shù)據(jù)和報表。

并且對于一些個性化的分析需求，比如用戶留存系列分析，用戶流失系列分析等，還有專門的數(shù)據(jù)分析團(tuán)隊來支持。

對于小廠來說，數(shù)據(jù)中臺是一個高投入，產(chǎn)出見效慢的工作。

以前習(xí)慣了賺快錢的土老板很難理解做這件事的意義，所以要么就胡亂做一個簡陋的數(shù)據(jù)，要么就上線裸奔（別笑，我以前待過的某團(tuán)隊就是上線裸奔狀態(tài)，什么數(shù)據(jù)都沒有，決策全靠拍腦袋）。

近幾年的第三方數(shù)據(jù)平臺應(yīng)運(yùn)而生，實(shí)際上就是想解決這樣的痛點(diǎn)。但是往往太過標(biāo)準(zhǔn)化的產(chǎn)品只能解決一部分問題，還有一部分需求滿足不了。

所以在這種背景下游戲運(yùn)營與其去費(fèi)力理解怎么做系統(tǒng)埋點(diǎn)，不如先搞清楚什么樣的數(shù)據(jù)報表是我們所需要的，在此基礎(chǔ)之上再想辦法解決數(shù)據(jù)的問題。

當(dāng)你有機(jī)會提數(shù)據(jù)平臺的需求的時候，你至少要知道你想要什么吧？至少要知道你的決策需要依賴哪些數(shù)據(jù)吧？

不客氣地說，我甚至見過不少所謂的項目負(fù)責(zé)人提出的數(shù)據(jù)需求都亂七八糟的。

那么一個通用的數(shù)據(jù)運(yùn)營系統(tǒng)應(yīng)該是什么樣的？

我把通用的的數(shù)據(jù)運(yùn)營系統(tǒng)分成六個部分：

完整高清內(nèi)容在公眾號“姚偉的寫字臺”回復(fù)：“通用游戲運(yùn)營數(shù)據(jù)系統(tǒng)”即可獲取

核心數(shù)據(jù)

核心數(shù)據(jù)主要是反映游戲的大盤狀況，作為運(yùn)營負(fù)責(zé)人或者老板必看的表就是核心日報和綜合運(yùn)營報表。

多說一句，其實(shí)這也是數(shù)據(jù)分析的一個重要邏輯，數(shù)據(jù)異常時，先看大盤數(shù)據(jù)然后再分渠道或者分指標(biāo)去拆分?jǐn)?shù)據(jù)看。

以實(shí)時數(shù)據(jù)為例，實(shí)時數(shù)據(jù)一般關(guān)心的字段有：實(shí)時新增數(shù)據(jù)（累計）、實(shí)時在線人數(shù)（累計）、實(shí)時充值金額（累計）等。

比如在線人數(shù)為，報表參考樣式如下：

數(shù)據(jù)是我隨手填的，真實(shí)的時間應(yīng)該還有23：25，23：20等等，我這里嫌麻煩用省略號了。

注意，后續(xù)的所有報表一般都要支持篩選渠道和服務(wù)器。

一般實(shí)時數(shù)據(jù)的時間間隔在5-15分鐘之間，如果要壓縮到比如5秒左右的話，對于數(shù)據(jù)庫的壓力會非常大，5分鐘基本能滿足需求。

有的時候光報表看起來不夠直觀，負(fù)責(zé)數(shù)據(jù)的同學(xué)可能會做一些數(shù)據(jù)的可視化，比如折線圖等，這樣能充分顯示出數(shù)據(jù)的趨勢和波動。這里就不再展示了。

核心日報

核心日報的字段和樣式不固定，這里不必追求大而全，主要是圍繞運(yùn)營需求和老板需求來，夠用就好。

比如老板關(guān)心dau和收入，運(yùn)營關(guān)心留存和新增，那這里的報表展示這些字段即可。

綜合運(yùn)營報表

運(yùn)營綜合報表反映的就是整個的大盤數(shù)據(jù)，主要包括全部用戶和新用戶的全部數(shù)據(jù)。

大致樣式如圖：

用戶分析

用戶分析主要包括六個部分：新增用戶分析、付費(fèi)分析、活躍分析、流失分析、用戶養(yǎng)成分析、用戶行為路徑分析。

系統(tǒng)分析

系統(tǒng)分析主要四個部分：活動分析、經(jīng)濟(jì)系統(tǒng)分析、玩法系統(tǒng)分析、其他功能分析。

區(qū)服分析

區(qū)服分析主要分5個部分：開服數(shù)據(jù)概覽、開服月分析、開服留存分析、服務(wù)器數(shù)據(jù)

限于篇幅原因，本篇只能展示用戶分析、系統(tǒng)分析和區(qū)服分析的腦圖，詳細(xì)報表形式和內(nèi)容需要單獨(dú)開篇進(jìn)行講解，有興趣的同學(xué)可以留言，人多的話會繼續(xù)更新，畢竟腦圖就寫了幾個小時，完整一篇寫下來要死了…

GM工具其實(shí)嚴(yán)格來說不應(yīng)該歸類于數(shù)據(jù)系統(tǒng)中，但是考慮到很多公司連GM工具都做不好，后續(xù)也會單獨(dú)開篇進(jìn)行講解。

以上內(nèi)容如果能做成運(yùn)營后臺，基本能滿足80%的運(yùn)營和迭代需求，其余20%的個性化需求需要單獨(dú)由數(shù)據(jù)分析師進(jìn)行取數(shù)計算分析。

大廠和不少第三方數(shù)據(jù)平臺現(xiàn)在實(shí)際上也是支持定制計算的（主要是不少運(yùn)營不會寫SQL語句），但是效果一言難盡。所以這里就不再贅述了。

這次游戲數(shù)據(jù)運(yùn)營系統(tǒng)的文章加腦圖寫了差不多七八個小時，如果看的人多的話會更新成一個系列。關(guān)注我的互聯(lián)網(wǎng)領(lǐng)域的朋友放心，我后續(xù)還是會寫互聯(lián)網(wǎng)的產(chǎn)品運(yùn)營方法論的。

作者：姚偉的寫字臺

來源：姚偉的寫字臺