對于中小游戲研發團隊來說，選擇足夠細分的領域，沉心打磨產品，精細化運營，做細分領域的爆款，是一條出路。本文作者姚偉，將和大家聊一聊精細化運營的基礎——數據運營系統。

前段時間和好朋友游戲策劃K聊天，他瘋狂和我吐槽對接的發行運營非常不專業，每次收入不行了就來求爺爺告奶奶，活動內容和數值不會設計，活動效果從來不分析等等。出于職業習慣，我就好奇問到，那你是怎么去分析活動效果的呢？他說我看游戲內排行榜??！我：what？看排行榜？沒有其他數據或者后臺嗎？他說沒有啊，后臺啥都看不出來。

對話到這里，其實是比較出乎我的預料的，K的公司可是出過兩款非常知名的產品的，沒想到對于數據后臺的建設還是這么粗放，可想而知其他中小廠的情況，比如下面就是某家研發的數據后臺的原型：

基本的數據匯總，再加上PCU/ACU實時監控就構成了一個運營數據系統。這個系統對于分析來說，基本沒有任何用。

在以前增量市場的情況下，市場對產品的渴求度高，產品追求的是快速上線，迅速占領市場，不需要精細的打磨就可以取得不錯的成績?，F在的情況不同了，市場上的產品非常多。在這樣的背景下，對于中小研發來說，想活下去無非幾種打法：

1、做買量型產品，自己買量或者依附于渠道，用產品數量堆積起來收入。這種模式風險不低，對于買量能力和現金流要求較高；

2、尋找切入相對藍海的市場，比如微信小游戲，快速推出產品，迅速迭代；

3、選擇足夠細分的領域，沉心打磨產品，精細化運營，做細分領域的爆款。

這篇文章就拋磚引玉地談一談關于精細化運營的基礎——運營數據系統。從基礎的開發概念到什么是埋點、埋點的意義、如何做埋點和最后的設計數據報表，希望能對看到這篇文章的人有所幫助。

一、基礎概念出發

前端：前端是指直接和用戶產生交互的部分，前端控制著APP的輸入，可以理解為“看得見”的部分，對于手游來說，安卓的APK和iOS的iPA就屬于前端的集合。進入游戲后，游戲內看到的人物、場景、對話框、按鈕等都屬于前端的內容。

服務端（后端）：后端是指所有隱藏的部分，控制著APP的輸出。可以理解為“看不見”的部分，對于手游來說，后端包括業務邏輯的處理和數據層面的處理。

這里以《貪玩藍月》中的某個場景為例來說明前后端的邏輯：

“古仔控制著法師來打觸龍邪神，戰斗過程中雙方狂甩技能，身上不停爆出紅字9999，最后古仔一招‘冰咆哮’打死了觸龍邪神，爆了一把屠龍寶刀，古仔美滋滋地撿起屠龍寶刀，存放到自己的倉庫，最后到拍賣行以10萬的元寶賣出?！?/p>

這個場景里面，古仔在操作界面上控制法師的走向、控制技能的釋放、控制法師的普通攻擊就是在前端的輸入，而爆出的紅字、技能的特效、觸龍邪神的死亡、屠龍寶刀的掉落這些就是后端控制的輸出，這些輸出在前端控制著展現。

而像觸龍邪神的傷害數值、技能的特殊效果、爆裝備的概率等等，這些則是后端的業務邏輯。

古仔擊殺觸龍邪神、獲得屠龍寶刀和獲得10萬元寶，如果后端均有埋點，則會同步到相應的數據庫里。

這里需要說明一下，手游絕大部分的業務邏輯是寫在服務端的，通過客戶端和服務端的雙向驗證可以一定程度上杜絕外掛。如果古仔的所有信息是記錄在本地，服務端不做任何驗證，那么破解APK之后可以隨意修改古仔的數值，一刀秒殺觸龍邪神不是夢。這也是為什么很多單機的手游最終都會被破解的原因。

二、埋點

什么是埋點

對于游戲來說，埋點就是在游戲關鍵點植入多段代碼，統計追蹤用戶行為，進而作為分析用戶行為，建立用戶畫像，優化提升游戲體驗的基礎。

埋點的意義

到這里大家可能還是不太明白，埋點到底是怎么來幫助我們優化提升游戲體驗的，我這里特別想和大家分享一個關于曹政老師當年在百度的故事，這個故事可以幫大家更好地理解埋點的意義：

我在百度的時候參加過一個孫云豐主持的產品分享會，會上舉了一個例子記憶猶新，說當時百度的首席架構師，晚上沒事干什么呢？上服務器看訪問日志，看一個用戶的搜索行為。為什么要看用戶的搜索行為呢？通過搜索行為的跟蹤來分析用戶的搜索預期，和搜索引擎給出的結果，是否一致，如果存在差異，再通過其他方式來分析到底在哪里出現了差異。

當時講的例子很有意思，說用戶輸入了一個關鍵詞——“蘋果” 。這時候，你無法知道用戶真實目的是什么，因為蘋果是個多指向詞，是一種水果？是一個數碼品牌？還是當時熱播的一部電影？用戶沒有產生有效的點擊，而是搜索了第二個詞——?“蘋果 范冰冰” ，好了，已經知道用戶要找的是當時熱播的電影蘋果，但是用戶目的是什么呢，看劇情介紹，看幕后花絮？還是看電影視頻呢？依然不知道，但已經知道用戶在搜索蘋果的時候，沒有找到他想要的結果。

然后就看到用戶搜索了第三個詞——“蘋果 范冰冰 XX視頻” ，現在終于知道用戶的目的了，當然，這種搜索目標是肯定沒有結果的，然后這個用戶就不斷變換關鍵詞，從百度網頁搜索到視頻搜索，然后再度變換多個關鍵詞，最后，搜了一個關鍵詞——“雅虎”，然后離開了。我們設身處地想一下，用戶為什么搜索雅虎，很容易想到用戶當時的心理，對百度的搜索結果深深的失望，然后跑去雅虎繼續搜索了。但是好玩的是，過了20分鐘，這個用戶又回來了，還在繼續搜索這類關鍵詞，那么，這代表什么呢？雅虎他也沒搜到。最后用戶終于放棄，但是舉這個例子，孫云豐說了一句話，我分享給各位，叫做理解用戶的掙扎。

再回到我上面說的話，埋點是如何幫助玩家提升游戲體驗的？某次游戲上線測試一看，發現玩家留存不高，然后去細分這些流失玩家，發現在15級這個地方流失陡增。很多研發數據埋點做到這個地方就沒了，剩下的就是拍腦袋做改動優化，甚至很多研發連在15級流失這個地方都無法分析出來。如果能找出幾十個完整的玩家行為記錄拿來看，一條一條的去理解玩家做什么，比如說，過15級有個boss任務，玩家去打，沒打過，充錢去打，還是沒打過，又試了幾次，流失了。回頭研究下，玩家在這里挺絕望的，卡了兩三天難以寸進，說明這個boss難度太高了。

所以，完整的埋點的意義在于，既能為我們提供建立用戶畫像，分析用戶行為的基礎，又能給我們建立多緯度的數據報表，分析游戲整體表現帶來幫助。

如何設計埋點

設計游戲內的埋點，需要先梳理清楚基本的埋點思路，也就是制定標準化方案，然后再結合具體的業務場景和業務訴求制定個性化方案。比如MMORPG的埋點和棋牌的埋點就有非常大的差異，但是他們底層的埋點邏輯是一致的。

點擊上圖，可放大查看

需要說明的是，我這里的客戶端投遞和服務端投遞并不是按照嚴格意義上的技術層面的投遞來的，比如服務端的設備信息投遞，實際上是前端投遞給服務端，然后服務端存儲記錄下來的，并不是由服務端投遞。這樣區分是便于大家更好地理解埋點思路。更嚴格的劃分，有興趣的朋友可以和研發進行討論，這里就不再進行贅述了。

以數值貨幣表為例，需要定義的基礎投遞字段如下：

表格：基礎投遞字段

其他類型的表都按照這樣的形式定義即可，基本的游戲埋點在產品層面上就已經完成得差不多了，剩下的就是和開發討論定義每個埋點投遞的時機和最后的埋點測試驗收，這里就不再贅述了。

埋點全部設計測試驗收完成后，接下來就是如何設計報表的問題了。

三、通用數據運營系統

很多游戲運營朋友可能不知道，其實在埋點和報表之間還存在著一條巨大的鴻溝。這條鴻溝就是怎么去設計系統的埋點，怎么去推動前后端落地，再到怎么核對校驗數據、取數、清洗數據、數據計算，最后再到數據固化形成報表。

前面的【表格：基礎投遞字段】，其實只是簡單的字段類型表，當真的在做一款游戲的時候，數據埋點工作是相當繁瑣。

首先需要梳理整個系統的事件和事件類型，然后要定義事件的觸發時機，再去定義需要投遞的參數內容和參數類型。

比如最簡單的登錄行為，什么節點視為開始登錄，什么節點視為登錄成功？需要投遞什么樣的參數？

像渠道的登錄成功的節點一般是SDK登錄成功，而游戲的登錄成功可能是創角之后進入游戲，也可能是直接進入游戲，觸發時機就明顯不一樣，需要特別定義清楚。

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

對于大廠來說，已經有專業的數據團隊（數據中臺）給出統一的埋點規范，作為游戲開發團隊，只要按照規范投遞即可獲取想要的數據和報表。

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

對于小廠來說，數據中臺是一個高投入，產出見效慢的工作。

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

近幾年的第三方數據平臺應運而生，實際上就是想解決這樣的痛點。但是往往太過標準化的產品只能解決一部分問題，還有一部分需求滿足不了。

所以在這種背景下游戲運營與其去費力理解怎么做系統埋點，不如先搞清楚什么樣的數據報表是我們所需要的，在此基礎之上再想辦法解決數據的問題。

當你有機會提數據平臺的需求的時候，你至少要知道你想要什么吧？至少要知道你的決策需要依賴哪些數據吧？

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

那么一個通用的數據運營系統應該是什么樣的？

我把通用的的數據運營系統分成六個部分：

核心數據

核心數據主要是反映游戲的大盤狀況，作為運營負責人或者老板必看的表就是核心日報和綜合運營報表。

多說一句，其實這也是數據分析的一個重要邏輯，數據異常時，先看大盤數據然后再分渠道或者分指標去拆分數據看。

以實時數據為例，實時數據一般關心的字段有：實時新增數據（累計）、實時在線人數（累計）、實時充值金額（累計）等。

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

數據是我隨手填的，真實的時間應該還有23：25，23：20等等，我這里嫌麻煩用省略號了。

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

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

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

核心日報

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

比如老板關心DAU和收入，運營關心留存和新增，那這里的報表展示這些字段即可。

運營綜合報表

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

大致樣式如圖：

用戶分析

用戶分析主要包括六個部分：新增用戶分析、付費分析、活躍分析、流失分析、用戶養成分析、用戶行為路徑分析。

系統分析

系統分析主要四個部分：活動分析、經濟系統分析、玩法系統分析、其他功能分析。

區服分析

區服分析主要分5個部分：開服數據概覽、開服月分析、開服留存分析、服務器數據。

四、結語

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

GM工具其實嚴格來說不應該歸類于數據系統中，但是考慮到很多公司連GM工具都做不好，后續也會單獨開篇進行講解。

以上內容如果能做成運營后臺，基本能滿足80%的運營和迭代需求，其余20%的個性化需求需要單獨由數據分析師進行取數計算分析。

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

作者：獨立出海聯合體

來源：獨立出海聯合體（ID：gameunited）