從數據來看王者榮耀，最坑的可能不是小學生...

最新 07-04

首先我們來看一組數據：

2017年5月《王者榮耀》用戶規模超2億，

滲透率高達22.3%，

DAU、MAU半年翻倍，

日均新增用戶數達174.8萬，

日均使用次數為2.33次，

最愛晚上玩，日均使用時長47.2分鐘，

晚上9點到晚上11點是遊戲高峰期。

這些華麗麗的數據無疑是象徵著王者榮耀這款遊戲的大成功，從運營的角度反過來想，

如果沒有這些數據，我們是不知道這個遊戲成功，到底是有多成功？

所以說，數據，是體現成果的重要指標。

除此之外，數據還可以更好的幫助自己分析產品定位、走向，比如這組數據：

《王者榮耀》手游日活用戶已經超過5000萬，而這其中女玩家佔了54.1%

玩家49.5%是本科，

玩家52%都在24歲以下，

玩家90.5%在二三線及以下城市，

玩家30%來自華東地區

從數據上來看，有可能坑你的並不是小學生，而是...

女大學生？！

所以說，分析用戶也是運營重要的一部分，那麼今天我們就來聊聊數據運營

今天的分享嘉賓是：

蘭軍（網名：Blues）

梅沙科技創始人，致力於打造營地教育的互聯網平台，原迅雷產品總監、騰訊、YY語音高級產品經理

本文內容將會從蘭軍在騰訊、YY的實戰案例中詳細講解《11步構建產品數據運營體系》，全文7341字，讀完需18分鐘，來不及讀可以先選擇收藏，或者直接看自己感興趣的部分。

第1步：制訂產品目標

第2步：定義產品數據指標

第3步：構建產品數據指標體系

第4步：提出產品數據需求

第5步：上報數據

第6~8步：數據採集與接入、存儲、調度與運算

第9步：獲取數據

第10步：觀測和分析數據

第11步：產品評估與數據應用

在Blues十多年的互聯網行業工作生涯中，很大一部分時間的工作是數據運營，從QQ秀到YY語音，再到迅雷，都經歷了產品數據運營的流程優化、平台構建、分析應用等過程，親歷了數據在產品中的重要地位。

不少人對數據運營的理解，局限於數字統計、原因分析等，其實這些只是數據運營工作的一小部分，數據最終是為產品服務的，數據運營，重點在運營，數據只是工具。

數據運營是做什麼的？個人的理解是：

制訂產品目標，創建數據上報通道和規則流程，觀測產品數據，做好數據預警，分析數據變化原因，根據分析結果優化產品和運營，並對未來數據走勢做出預測，為產品決策提供依據，在產品策劃與運營中融入數據應用。

通俗點說，數據運營搞清楚以下5個問題：

l 我們要做什麼？——目標數據制訂；

l 現狀是什麼？——行業分析，產品數據報表輸出；

l 數據變化的原因？——數據預警，數據變化的原因分析；

l 未來會怎樣？——數據預測；

l 我們應該做什麼？——決策與數據的產品應用。

如何才能構建一個完整的產品數據運營體系？Blues根據自己在YY工作的經驗進行了梳理和總結，整個過程可以分為如下的11步，供大家參考。

第1步：制訂產品目標

這是數據運營的起點，也是產品上線運營後進行評估的標準，以此形成閉環。制訂目標絕不能拍腦袋，可以根據業務發展、行業發展、競品分析、往年產品發展走勢、產品轉化規律等綜合計算得出。制訂目標常用SMART原則來衡量。

（1）S代表具體(Specific)

指工作指標要具體可評，不能籠統。例如我們制定YY語音基礎體驗的產品目標，如果是提升產品體驗，則不夠具體，每個人的理解不一致，當時我們的基礎產品目標則是提升新用戶次日留存，則非常具體。

（2）M代表可度量(Measurable)

指績效指標是數量化或者行為化的，驗證這些績效指標的數據或者信息是可以獲得的；提升新用戶次日留存率，則需要給出具體的數值。

（3）A代表可實現(Attainable)

指績效指標在付出努力的情況下可以實現，避免設立過高或過低的目標；新註冊用戶的次日留存率，也不是拍腦袋得出的，當時我們基於YY新用戶次日留存率的歷史數據和遊戲用戶的新註冊用戶留存率的行業參考數值，制訂了一個相對有挑戰性的目標，從新註冊用戶次日留存率從25%提升到35%。

（4）R代表相關性(Relevant)

是與工作的其它目標是相關聯的；績效指標是與本職工作相關聯的；新用戶的次日留存率，和用戶行為息息相關，例如用戶對語音工具的認可程度，用戶對YY平台的內容喜好程度等，所以新用戶的次日留存和產品的性能、內容受歡迎程有較強的相關性。

（5）T代表有時限(Time-bound)

注重完成目標的特定期限。

產品目標可以這樣制訂：在2013年12月31日前，將YY語音新註冊用戶的次日留存率從25%提升到35%。

新用戶次日留存率的提升，意味著更多用戶的活躍轉化，帶動整個用戶活躍數量的增長。

第2步：定義產品數據指標

產品數據指標是反應產品健康發展的具體的數值，我們需要對數據指標給出明確定義，例如數據上報方法、計算公式等。

例如上文的次日留存率，可以定義為：次日留存率是一個比率，分母是當天新註冊並在當天登錄YY客戶端的YY帳戶數，分子是分母當中在第二天再次登錄YY客戶端的YY帳戶數。

注意這裡的細節，第一天和第二天，需要有明確的時間點，例如0點到24點，計算為一天；問題來了，一個新用戶在第一天的23點註冊並登錄YY客戶端，到第二天的凌晨1點下線；按照上面的定義，這個用戶或許將不會被記錄為次日留存用戶，因為這裡沒有定義清楚數據上報細節。

定義是第二天再次登錄YY客戶端，上面案例的用戶在第二天是沒有登錄行為的，但他確實是連續兩天都在登錄狀態的用戶。

所以針對這個定義，需要補充細節：用戶登錄狀態，如果是5分鐘進行一次心跳包的上報，那麼這位新用戶就可以被上報為第二天的登錄狀態用戶，如果在0點5分之前下線之後，持續到第二天的24點，仍未有登錄狀態，那麼將不被記錄為留存用戶。

我們根據產品目標來選擇數據指標，例如網頁產品，經常用PV、UV、崩失率、人均PV、停留時長等數據進行產品度量。定義產品指標體系，需要產品、開發等各個團隊達成共識，數據指標的定義是清晰的，並且有據可查，不會引起數據解讀的理解差異。

第3步：構建產品數據指標體系

在數據指標提出的基礎上，我們按照產品邏輯進行指標的歸納整理，使之條理化。

新用戶的次日留存率是我們訂製的一個核心目標，但實際上，只看次日留存率還是不夠的，還需要綜合考察影響用戶留存率的多種因素，才能更準確的了解產品的健康發展。如圖1所示，是常用的一種指標體系，包含：用戶新增、用戶活躍、付費、其他數據。

圖1 互聯網產品常用數據指標體系

在我們做YY語音客戶端產品的時候，會用到下面的指標體系，包括：賬號體系、關係鏈數據、狀態感知數據、溝通能力等四大方面。具體指標有：好友的個數分布、觀看頻道節目的時長、IM聊天時長、個人狀態的切換與時長等，如圖2所示：

圖2 IM即時通訊產品數據指標體系

第4步：提出產品數據需求

產品指標體系的建立不是一蹴而就的，產品經理根據產品發展的不同階段，有所側重的進行數據需求的提出，一般的公司都會有產品需求文檔的模板，方便產品和數據上報開發、數據平台等部門同事溝通，進行數據建設。創業型中小企業，產品數據的需求提出到上報或許就是1-2人的事情，但同樣建議做好數據文檔的建設，例如數據指標的定義，數據計算邏輯等。

圖3 YY事業部基礎產品數據需求實現流程圖（施行）

常見的數據上報需求，有兩類：

l 標準協議上報，例如按鈕點擊上報。

l 自定義協議上報。

1. 標準協議上報數據需求範例

表1 標準協議上報數據需求範例模板

1. 自定義協議上報數據需求範例

表2 自定義協議上報數據需求範例模板

報名名稱：YY事業部——基礎產品組——遊戲直播運營日報

第5步：上報數據

這個步驟就是開發根據產品經理的數據需求，按照數據上報規範，完成上報開發，將數據上報到數據伺服器。上報數據的關鍵是數據上報通道的建設，原來在騰訊工作時候，沒有體會到這個環節的艱辛，因為數據平台部門已經做了完備的數據通道搭建，開發按照一定規則，使用統一的數據SDK進行數據上報就可以了。後來在YY，屬於發展型公司，則是從上報通道開始進行建設，也讓我得到更多鍛煉提升的機會。其中很關鍵的一個環節，就是數據上報測試，曾經因為該環節的測試資源沒到位，造成不必要的麻煩。

例如下表，就是頁面流量數據上報的發送函數send_web_pv，源於迅雷哈勃數據平台規範。

表3 頁面流量數據上報的發送函數send_web_pv

下表是某直播做APP數據上報的埋點範例。（數據埋點，就是在功能邏輯中添加統計邏輯）

表4 某直播APP數據上報範例

第6~8步：數據採集與接入、存儲、調度與運算

1.數據的採集與接入

ETL，是英文 Extract-Transform-Load 的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。

ETL一詞較常用在數據倉庫，但其對象並不限於數據倉庫。ETL是構建數據倉庫的重要一環，用戶從數據源抽取出所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據載入到數據倉庫中去。

下圖是產品數據體系的一個常見流程圖，數據採集、存儲、運算，通常就在圖中的數據中心完成。

圖4 數據體系流程

確認完數據上報之後，接下來幾個事情就比較偏技術化了。首先需要上報的數據通過什麼樣的方式採集和存儲到我們的數據中心。

數據採集分為兩步

第一步從業務系統上報到伺服器，這部分主要是通過cgi或者後台server，通過統一的logAPI調用之後，匯總在logServer中進行原始流水數據的存儲。當這部分數據量大了之後，需要考慮用分布式的文件存儲來做，外部常用的分布式文件存儲主要是HDFS。這裡就不細展開。

圖5 原始數據上報存儲到文件的架構圖

數據存儲到文件之後，第二步就進入到ETL的環節，ETL就是指通過抽取（extract）、轉換（transform）、載入（load）把日誌從文本中，基於分析的需求和數據緯度進行清洗，然後存儲在數據倉庫中。

以騰訊為例子：

騰訊大數據平台現在主要從離線和實時兩個方向支撐海量數據接入和處理，核心的系統包括TDW、TRC和TDbank。

圖6 騰訊數據平台系統

在騰訊內部，數據的數據收集、分發、預處理和管理工作，都是通過一個TDBank的平台來實現的。整個平台主要解決在大數據量下面數據收集和處理的量大、實時、多樣的問題。通過數據接入層、處理層和存儲層這樣的三層架構來統一解決接入和存儲的問題。

（1）接入層

接入層可以支持各種格式的業務數據和數據源，包括不同的DB、文件格式、消息數據等。數據接入層會將收集到的各種數據統一成一種內部的數據協議，方便後續數據處理系統使用。

（2）處理層

接下來處理層用插件化的形式來支持多種形式的數據預處理過程。對於離線系統來說，一個重要的功能是將實時採集到的數據進行分類存儲，需要按照某些維度（比如某個key值+時間等維度）進行分類存儲；同時存儲文件的粒度（大小/時間）也是需要定製的，使離線系統能以指定的的粒度來進行離線計算。對於在線系統來說，常見的預處理過程如數據過濾、數據採樣和數據轉換等。

（3）數據存儲層

處理後的數據，使用HDFS作為離線文件的存儲載體。保證數據存儲整體上是可靠的，然後最終把這部分處理後的數據，入庫到騰訊內部的分布式數據倉庫TDW。

圖7 TDW架構圖

TDBank是從業務數據源端實時採集數據，進行預處理和分布式消息緩存後，按照消息訂閱的方式，分發給後端的離線和在線處理系統。

圖8 TDBank數據採集與接入系統

TDBank構建數據源和數據處理系統間的橋樑，將數據處理系統同數據源解耦，為離線計算TDW和在線計算TRC平台提供數據支持。目前通過不斷的改進，將以前Linux+HDFS的模式，轉變為集群+分布式消息隊列的模式，將以前一天才能處理的消息量縮短到2秒鐘！

從實際應用來看，產品在考慮數據採集和接入的時候，主要要關心幾個緯度的問題

l 多個數據源的統一，一般實際的應用過程中，都存在不同的數據格式來源，這個時候，採集和接入這部分，需要把這些數據源進行統一的轉化。

l 採集的實時高效，由於大部分系統都是在線系統，對於數據採集的時效性要求會比較高。

l 臟數據處理，對於一些會影響整個分析統計的臟數據，需要在接入層的時候進行邏輯屏蔽，避免後面統計分析和應用的時候，由於這部分數據導致很多不可預知的問題。

2.數據的存儲與計算

完成數據上報和採集和接入之後，數據就進入存儲的環節，繼續以騰訊為例。

在騰訊內部，有個分布式的數據倉庫用來存儲數據，內部代號叫做TDW，它支持百PB級數據的離線存儲和計算，為業務提供海量、高效、穩定的大數據平台支撐和決策支持。基於開源軟體Hadoop和Hive進行構建，並且根據公司數據量大、計算複雜等特定情況進行了大量優化和改造。

從對外公布的資料來看，TDW基於開源軟體hadoop和hive進行了大量優化和改造，已成為騰訊最大的離線數據處理平台，集群各類機器總數5000台，總存儲突破20PB，日均計算量超過500TB，覆蓋騰訊公司90%以上的業務產品，包含廣點通推薦，用戶畫像，數據挖掘和各類業務報表等，都是通過這個平台來提供基礎能力。

圖8，騰訊TDW分布式數據倉庫

圖9 TDW業務示意圖

從實際應用來看，數據存儲這部分主要考慮幾個問題

l 數據安全性，很多數據是不可恢復的，所以數據存儲的安全可靠永遠是最重要的。一定要投入最多的精力來關注。

l 數據計算和提取的效率，做為存儲源，後面會面臨很多數據查詢和提取分析的工作，這部分的效率需要確保。

l 數據一致性，存儲的數據主備要保證一致性。

第9步：獲取數據

就是產品經理，數據分析人員從數據系統獲得數據的過程，常見的方式是數據報表和數據提取。

報表的格式，一般會在數據需求階段明確，尤其是有積累的公司，通常會有報表模板，照著填入指標就好了。強大一些的數據平台，則可以根據分析需要，自助的選擇欄位（表頭）進行自助報表的配置和計算生成。

下面是做數據報表設計的幾個原則：

1. 提供連續周期的查詢功能

（1）報表要提供查詢的起始時間，可以查看指定時間範圍內的數據。忌諱只有一個時間點，無法看數據的趨勢。

（2）對一段時間範圍內的數據能夠分段或匯總，能夠對不同階段進行比較。

2.查詢條件與維度相匹配

（1）有多少個維度，就提供多少個對應的查詢條件。盡量滿足每個維度都能分析。

（2）查詢條件要提供開、合，以及具體值的過濾功能。既能看總體，又能看明細，還要能看單一。

（3）查詢條件的順序，盡量與維度的順序對應，最好按從大到小的層次。

3. 圖表與數據要一致

（1）圖表顯示的趨勢，要與相應的數據一致，避免數據有異議；

（2）有圖就必須有數據，但是，有數據可以沒有圖；

（3）圖表內的指標不要太多，並且指標間的差距不要太大。

4. 報表要單一

（1）一張報表，只做一份分析功能，多個功能盡量拆到不同的表報中；

（2）在報表中盡量不要有跳轉；

（3）報表只提供查詢功能。

看幾張常用報表，WEB產品的流量報表，來自百度，關注PV、UV、新訪客比率、跳出率、平均訪問時長等。

專門說一下跳出率，這個數據反應了用戶進入網站的著陸頁（不一定是首頁）價值，是否可以吸引用戶進行一次點擊，如果用戶達到著陸頁，沒有任何點擊，則跳出率增大。

圖10 百度統計的網頁數據報表

再看友盟數據平台提供的產品留存率數據報表，通常關注的留存率有：1天後留存、7天後留存、30天後留存。

圖11 友盟的留存數據報表

數據提取，在做產品運營中，是很常見的需求，例如提取某一批銷量較好的商品及其相關欄位，提取某一批指定條件的用戶等。同樣，功能比較完備的數據平台，會有數據自助提取系統，不能滿足自助需求，則需要數據開發寫腳本進行數據提取。

圖12所示，騰訊內部的數據門戶，承擔了諸多產品的數據報表、數據提取、數據報告的功能。

圖12 騰訊數據門戶首頁

第10步：觀測和分析數據

這裡主要是數據變化的監控和統計分析，通常我們會對數據進行自動化的日報表輸出，並標識異動數據，數據的可視化輸出很重要。

常用的軟體是EXCEL和SPSS，可以說是進行數據分析的基本技能，以後再分享個人在實際工作中對這兩款軟體的使用方法和技巧。需要注意的是，在進行數據分析之前，先進行數據準確性的校驗，判斷這些數據是否是你想要的，例如從數據定義到上報邏輯，是否嚴格按照需求文檔進行，數據的上報通道是否會有數據丟包的可能，建議進行原始數據的提取抽樣分析判斷數據準確性。

數據解讀在這個環節至關重要，同一份數據，由於產品熟悉度和分析經驗的差異，解讀結果也大不一樣，因此產品分析人員，必須對產品和用戶相當了解。

絕對數值通常難以進行數據解讀，通常都是通過比較，才更能表達數據含義。

例如某產品上線後的第一周，日均新增註冊10萬人，看起來數據不錯，但是如果這款產品是YY語音推出的新產品，並且通過YY彈窗消息進行用戶觸達，每天千萬次的用戶曝光，僅僅帶來10萬新增，則算不上是較好的產品數據。

圖13 通過比較更清晰表達數據含義

縱向比較，例如分析YY語音新註冊用戶的數據變化，那麼可以和上周同期、上月同期、去年同期進行對比，是否有相似的數據變化規律。

橫向比較，同樣是YY語音新用戶註冊數據的變化，可以從漏斗模型進行分析，從用戶來源的不同渠道去看每個渠道的轉化率是否有變化，例如最上層漏斗，用戶觸達渠道有無哪個數據有較大變化，哪個渠道的某個環節有轉化率的數據變化。還可以進行不同業務的橫向比較，例如YY語音新增註冊數據、多玩網流量數據、YY遊戲新增註冊用戶數據進行對比，查找數據變化原因。

縱橫結合對比，就是把多個數據變化的同一周期時間段曲線進行對比，例如YY新增註冊用戶、多玩網的流量數據、YY遊戲新增註冊用戶的半年數據變化，三條曲線同時進行對比，找出某個數據異常的關鍵節點，再查找運營日誌，看看有無運營活動的組織、有無外部事件的影響、有無特殊日子的影響因素。

第11步：產品評估與數據應用

這是數據運營閉環的終點，同時也是新的起點，數據報表絕不是擺設，也不是應付領導的提問，而是切實的為產品優化和運營的開展服務，正如產品人員的績效，不僅僅是看產品項目是否按時完成，按時發布，更是要持續進行產品數據的觀測分析，評估產品健康度，同時將積累的數據應用到產品設計和運營環節。

數據產品應用，大致可以分為以下幾類：

（1）以效果廣告為代表的精準營銷

推薦周期短，實時性要求高；用戶短期興趣和即時行為影響力大；投放場景上下文和訪問人群特性。

（2）以視頻推薦為代表的內容推薦

長期興趣的累積影響力大；時段和熱點事件；多維度內容相關性很重要。

產品案例：Youtube

（3）以電商推薦為代表的購物推薦

長期+短期興趣+即時行為綜合；最貼近現實，季節與用戶生活信息很關鍵；追求下單與成交，支付相關。

產品案例：亞馬遜、淘寶、京東。