不少人對數據運營的理解，局限於數字統計、原因分析等，其實這些隻是數據運營工作的一小部分，數據最終是為產品服務的，數據運營，重點在運營，數據隻是工具。
數據運營是做什麼的 ? 個人的理解是：
制訂產品目標，創建數據上報通道和規則流程，觀測產品數據，做好數據預警，分析數據變化原因，根據分析結果優化產品和運營，並對未來數據走勢做出預測，為產品決策提供依據，在產品策劃與運營中融入數據應用。
通俗點說，數據運營搞清楚以下 5 個問題：
l 我們要做什麼 ? ——目標數據制訂 ;
l 現狀是什麼 ? ——行業分析，產品數據報表輸出 ;
l 數據變化的原因 ? ——數據預警，數據變化的原因分析 ;
l 未來會怎樣 ? ——數據預測 ;
l 我們應該做什麼 ? ——決策與數據的產品應用。
如何才能構建一個完整的產品數據運營體系 ?Blues 根據自己在 YY 工作的經驗進行瞭梳理和總結，整個過程可以分為如下的 11 步，供大傢參考。
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 所示：
第 4 步：提出產品數據需求
產品指標體系的建立不是一蹴而就的，產品經理根據產品發展的不同階段，有所側重的進行數據需求的提出，一般的公司都會有產品需求文檔的模板，方便產品和數據上報開發、數據平臺等部門同事溝通，進行數據建設。創業型中小企業，產品數據的需求提出到上報或許就是 1-2 人的事情，但同樣建議做好數據文檔的建設，例如數據指標的定義，數據計算邏輯等。
圖 3 是 BLUES 在 YY 語音客戶端團隊建立的基礎產品數據需求實現流程。
圖 3 YY 事業部基礎產品數據需求實現流程圖 ( 施行 )
第 5 步：上報數據
這個步驟就是開發根據產品經理的數據需求，按照數據上報規范，完成上報開發，將數據上報到數據服務器。上報數據的關鍵是數據上報通道的建設，原來在騰訊工作時候，沒有體會到這個環節的艱辛，因為數據平臺部門已經做瞭完備的數據通道搭建，開發按照一定規則，使用統一的數據 SDK 進行數據上報就可以瞭。
後來在 YY，屬於發展型公司，則是從上報通道開始進行建設，也讓我得到更多鍛煉提升的機會。其中很關鍵的一個環節，就是數據上報測試，曾經因為該環節的測試資源沒到位，造成不必要的麻煩。
很多創業公司沒有自己的數據平臺，可以利用第三方的數據平臺：網頁產品，可以使用百度統計 ( tongji.baidu.com ) ; 移動端產品，可以使用友盟 ( www.umeng.com ) 、TalkingData ( www.talkingdata.com ) 等平臺。
第 6~8 步：數據采集與接入、存儲、調度與運算
每一步都是一門學問，例如采集數據涉及接口創建，要考慮數據字段的拓展性，數據采集過程中的 ETL 數據清洗流程，客戶端數據上報的正確性校驗等 ; 數據存儲與調度、運算，在大數據時代，更是很有挑戰性的技術活。
1. 數據的采集與接入
ETL，是英文 Extract-Transform-Load 的縮寫，用來描述將數據從來源端經過抽取 ( extract ) 、轉換 ( transform ) 、加載 ( load ) 至目的端的過程。ETL 一詞較常用在數據倉庫，但其對象並不限於數據倉庫。ETL 是構建數據倉庫的重要一環，用戶從數據源抽取出所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中去。
下圖是產品數據體系的一個常見流程圖，數據采集、存儲、運算，通常就在圖中的數據中心完成。
確認完數據上報之後，接下來幾個事情就比較偏技術化瞭。首先需要上報的數據通過什麼樣的方式采集和存儲到我們的數據中心。
數據采集分為兩步，第一步從業務系統上報到服務器，這部分主要是通過 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% 以上的業務產品，包含廣點通推薦，用戶畫像，數據挖掘和各類業務報表等，都是通過這個平臺來提供基礎能力。
圖 9，騰訊 TDW 分佈式數據倉庫
圖 10 TDW 業務示意圖
從實際應用來看，數據存儲這部分主要考慮幾個問題：
l 數據安全性，很多數據是不可恢復的，所以數據存儲的安全可靠永遠是最重要的。一定要投入最多的精力來關註。
l 數據計算和提取的效率，做為存儲源，後面會面臨很多數據查詢和提取分析的工作，這部分的效率需要確保。
l 數據一致性，存儲的數據主備要保證一致性。
第 9 步：獲取數據
就是產品經理，數據分析人員從數據系統獲得數據的過程，常見的方式是數據報表和數據提取。
報表的格式，一般會在數據需求階段明確，尤其是有積累的公司，通常會有報表模板，照著填入指標就好瞭。強大一些的數據平臺，則可以根據分析需要，自助的選擇字段 ( 表頭 ) 進行自助報表的配置和計算生成。
下面是做數據報表設計的幾個原則：
1. 提供連續周期的查詢功能
( 1 ) 報表要提供查詢的起始時間，可以查看指定時間范圍內的數據。忌諱隻有一個時間點，無法看數據的趨勢。
( 2 ) 對一段時間范圍內的數據能夠分段或匯總，能夠對不同階段進行比較。
2. 查詢條件與維度相匹配
( 1 ) 有多少個維度，就提供多少個對應的查詢條件。盡量滿足每個維度都能分析。
( 2 ) 查詢條件要提供開、合，以及具體值的過濾功能。既能看總體，又能看明細，還要能看單一。
( 3 ) 查詢條件的順序，盡量與維度的順序對應，最好按從大到小的層次。
3. 圖表與數據要一致
( 1 ) 圖表顯示的趨勢，要與相應的數據一致，避免數據有異議 ;
( 2 ) 有圖就必須有數據，但是，有數據可以沒有圖 ;
( 3 ) 圖表內的指標不要太多，並且指標間的差距不要太大。
4. 報表要單一
( 1 ) 一張報表，隻做一份分析功能，多個功能盡量拆到不同的表報中 ;
( 2 ) 在報表中盡量不要有跳轉 ;
( 3 ) 報表隻提供查詢功能。
看幾張常用報表，WEB 產品的流量報表，來自百度，關註 PV、UV、新訪客比率、跳出率、平均訪問時長等。
專門說一下跳出率，這個數據反應瞭用戶進入網站的著陸頁 ( 不一定是首頁 ) 價值，是否可以吸引用戶進行一次點擊，如果用戶達到著陸頁，沒有任何點擊，則跳出率增大。
圖 11 百度統計的網頁數據報表
再看友盟數據平臺提供的產品留存率數據報表，通常關註的留存率有：1 天後留存、7 天後留存、30 天後留存。
圖 12 友盟的留存數據報表
數據提取，在做產品運營中，是很常見的需求，例如提取某一批銷量較好的商品及其相關字段，提取某一批指定條件的用戶等。同樣，功能比較完備的數據平臺，會有數據自助提取系統，不能滿足自助需求，則需要數據開發寫腳本進行數據提取。
圖 12 所示，騰訊內部的數據門戶，承擔瞭諸多產品的數據報表、數據提取、數據報告的功能。
圖 13 騰訊數據門戶首頁
第 10 步：觀測和分析數據
這裡主要是數據變化的監控和統計分析，通常我們會對數據進行自動化的日報表輸出，並標識異動數據，數據的可視化輸出很重要。
常用的軟件是 EXCEL 和 SPSS，可以說是進行數據分析的基本技能，以後再分享個人在實際工作中對這兩款軟件的使用方法和技巧。需要註意的是，在進行數據分析之前，先進行數據準確性的校驗，判斷這些數據是否是你想要的，例如從數據定義到上報邏輯，是否嚴格按照需求文檔進行，數據的上報通道是否會有數據丟包的可能，建議進行原始數據的提取抽樣分析判斷數據準確性。
數據解讀在這個環節至關重要，同一份數據，由於產品熟悉度和分析經驗的差異，解讀結果也大不一樣，因此產品分析人員，必須對產品和用戶相當瞭解。
絕對數值通常難以進行數據解讀，通常都是通過比較，才更能表達數據含義。
例如某產品上線後的第一周，日均新增註冊 10 萬人，看起來數據不錯，但是如果這款產品是 YY 語音推出的新產品，並且通過 YY 彈窗消息進行用戶觸達，每天千萬次的用戶曝光，僅僅帶來 10 萬新增，則算不上是較好的產品數據。
圖 13 通過比較更清晰表達數據含義
縱向比較，例如分析 YY 語音新註冊用戶的數據變化，那麼可以和上周同期、上月同期、去年同期進行對比，是否有相似的數據變化規律。
橫向比較，同樣是 YY 語音新用戶註冊數據的變化，可以從漏鬥模型進行分析，從用戶來源的不同渠道去看每個渠道的轉化率是否有變化，例如最上層漏鬥，用戶觸達渠道有無哪個數據有較大變化，哪個渠道的某個環節有轉化率的數據變化。還可以進行不同業務的橫向比較，例如 YY 語音新增註冊數據、多玩網流量數據、YY 遊戲新增註冊用戶數據進行對比，查找數據變化原因。
縱橫結合對比，就是把多個數據變化的同一周期時間段曲線進行對比，例如 YY 新增註冊用戶、多玩網的流量數據、YY 遊戲新增註冊用戶的半年數據變化，三條曲線同時進行對比，找出某個數據異常的關鍵節點，再查找運營日志，看看有無運營活動的組織、有無外部事件的影響、有無特殊日子的影響因素。
第 11 步：產品評估與數據應用
這是數據運營閉環的終點，同時也是新的起點，數據報表絕不是擺設，也不是應付領導的提問，而是切實的為產品優化和運營的開展服務，正如產品人員的績效，不僅僅是看產品項目是否按時完成，按時發佈，更是要持續進行產品數據的觀測分析，評估產品健康度，同時將積累的數據應用到產品設計和運營環節。
例如亞馬遜的個性化推薦產品，例如 QQ 音樂的猜你喜歡，例如淘寶的時光機，例如今日頭條的推薦閱讀等等。數據產品應用，大致可以分為以下幾類：
( 1 ) 以效果廣告為代表的精準營銷
推薦周期短，實時性要求高 ; 用戶短期興趣和即時行為影響力大 ; 投放場景上下文和訪問人群特性。
產品案例：谷歌、Facebook、微信朋友圈。
( 2 ) 以視頻推薦為代表的內容推薦
長期興趣的累積影響力大 ; 時段和熱點事件 ; 多維度內容相關性很重要。
產品案例：Youtube
( 3 ) 以電商推薦為代表的購物推薦
長期 + 短期興趣 + 即時行為綜合 ; 最貼近現實，季節與用戶生活信息很關鍵 ; 追求下單與成交，支付相關。
產品案例：亞馬遜、淘寶、京東。
一張圖，總結數據運營 11 步法則
最後，一張圖小結數據運營 11 步：
圖 14 數據運營 11 步
從制訂產品目標到最後基於目標進行產品評估與運營優化，形成數據運營閉環。這個流程和規范，需要各個部門都能統一意識，每個產品終端都能按照規范流程將數據統一上報，建立公司級的統一數據中心，進行數據倉庫建設，才有可能將數據價值最大化，讓數據成為生產力。
產品數據運營體系如何構建 ? 可以從以下五大要素進行考慮：
( 1 ) 人：專職的數據運營同事
專職的專業的產品同事，負責建立產品數據體系的流程化、標準化，沉淀經驗，推動體系的持續優化發展 ; 專職的專業的開發同事，負責數據上報，報表開發，數據庫開發維護等工作，保證產品數據體系的開發實現 ;
( 2 ) 數據後臺：全面系統的數據倉庫
有一個專門的統一數據倉庫記錄自己產品的特殊個性數據，共性數據充分利用數據平臺部公用接口獲取，共享數據源，充分降低成本。
( 3 ) 數據前臺：固化數據體系展現平臺
需要專業的報表開發同事， 體系化思考報表系統，靈活迭代執行，而不是簡單的承接報表需求，造成報表泛濫。
( 4 ) 工作規范：需求實現流程化
就是前面描述的 11 步構建產品數據體系的流程和方法，其中的數據需求把握好兩點，一是固化需求開發流程化，二是臨時需求工具化。
( 5 ) 工作產出：數據應用
常規的數據工作就是各種數據分析，輸出日報、周報、月報 ; 基於數據分析基礎上進行決策依據提供。進行數據產品開發，例如精準推薦、用戶生命周期管理等產品策劃。
來源：互聯網的一些事（www.yixieshi.com）. 轉載請保留出處 .
