數據運營需要掌握哪些技能？怎樣構建屬於自己的數據運營體系？本文作者用十多年的工作經驗，助你一步一步完善數據運營體系。

未來30年數據將成爲生產資料，計算會是生產力，互聯網是一種生產關係。如果我們不數據化，不和互聯網相連，那麼會比過去30年不通電顯得更爲可怕。未來30年，互聯網將不再是互聯網公司的互聯網，互聯網是所有人的互聯網。如果說過去20年互聯網從無到有，那麼未來30年，互聯網將“從有到無”，這個“無”是無處不在的“無”，沒有人能夠離開網絡而存在。

——馬雲，第四屆世界互聯網大會

在我的18年的互聯網行業工作經歷中，很大一部分時間的工作是數據運營，從QQ秀到YY語音，再到迅雷，都經歷了產品數據運營的流程優化、平臺構建、分析應用等過程，親歷了數據運營在產品成長中發揮的重要作用。

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

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

推動團隊明確產品目標，定義產品數據指標，創建數據上報通道和規則流程，高效的推動實現數據需求，觀測產品數據，做好數據預警，分析數據變化原因，根據分析結果進行產品迭代和運營，爲產品決策提供依據，用數據驅動產品和組織成長，達成組織目標。

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

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

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

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

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

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

大致梳理了一下數據運營需要掌握的技能：

上面的這些技能概念較多，其實最基本的就是，先學好統計學，再深入進行業務實踐，熟練掌握分析工具，例如最常用的Excel，再多學一個數據挖掘工具，個人使用的是SPSS。

SPSS的功能包括數據管理、統計分析、圖表分析、輸出管理等。SPSS統計分析過程包括描述性統計、均值比較、一般線性模型、相關分析、迴歸分析、對數線性模型、聚類分析、數據簡化、生存分析、時間序列分析、多重響應等。

工具不難學，重要的是學習統計學，知道不同場景選用什麼分析方法，如何進行分析結果的解讀和應用。

後來，我把自己數據運營工作經歷整理了一份企業構建數據運營體系的層級圖：

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

第一步，制訂產品目標

這是數據運營的起點，也是產品上線運營後進行評估的標準，以此形成閉環。

制訂目標絕不能拍腦袋，可以根據業務發展、行業發展、競品分析、往年產品發展走勢、產品轉化規律等綜合計算得出。制訂目標常用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%。

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

這裏需要注意，需要洞察目標背後的本質，不能唯數據論，例如我做過的提高YY語音新註冊用戶留存率的項目，如果只是看留存率的數據變化，是很容易達到的。

記得當時我用的一個方法是用戶分類，把不同渠道、不同行爲的用戶進行分類，發現有部分垃圾新用戶大大影響了整體留存率數據，這部分用戶很多是機器註冊產生，並非真正的用戶，剔除掉這部分用戶，留存數據高了很多，但這不能說，我們就完成了任務。因爲這個目標的背後，實際是需要獲得活躍用戶的增長，新用戶留存率，只是一個數據體現，所以不能只看新用戶留存率這個單一指標，必須從提高新用戶註冊數量、有效用戶留存、用戶活躍、付費轉化等多個指標來衡量工作價值。

第二步，定義產品數據指標

沿着上面的目標制訂，就需要考慮數據指標，上門的案例，我們給出的目標是新用戶留存率，做好了新用戶留存率，需要去判斷這個數據指標的實現是否真的促進了整個產品活躍用戶的增長。

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

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

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

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

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

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

產品在不同生命週期，關注的數據指標側重點也會不同，下表大致列出了一些各個階段需要重點關注的指標，除了常見的用戶指標、收入指標，我們還必須重視技術層面的性能指標。

好的數據指標，有五個要點可供參考：

（1）能夠反映用戶需求的滿足、產品核心價值以及發展趨勢。這些指標變好了能說明公司是在往好的方向上發展。

（2）好的數據指標是可比較的。比較在不同的時間段，用戶羣體，競爭產品之間的表現，可以更好的洞察產品的實際走向。

（3）易懂、可控。很容易地理解、記住，方便統計。

（4）好的數據指標多數時候是一個比率。

（5）指標隨業務而進化。不同階段的關鍵性指標應該是隨着業務的變化而變化的。

第三步，構建產品數據指標體系

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

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

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

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

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

第四步，提出產品數據需求

產品指標體系的建立不是一蹴而就的，產品經理根據產品發展的不同階段，有所側重的進行數據需求的提出，一般的公司都會有產品需求文檔的模板，方便產品和數據上報開發、數據平臺等部門同事溝通，進行數據建設。

創業型中小企業，產品數據的需求提出到上報或許就是1-2人的事情，但同樣建議做好數據文檔的建設，例如數據指標的定義，數據計算邏輯等。

圖3是我在YY語音客戶端團隊建立的基礎產品數據需求實現流程。其實在大多數時候，並不需要這麼一個數據需求流程，只是當時我們在數據需求剛剛開始進行規範化，數據需求評審過程，也是培訓過程，讓更多同事有數據意識，到後面，數據需求是融入到產品需求流程的。

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

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

1. 標準協議上報，例如按鈕點擊上報；

2. 自定義協議上報。

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

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

（2）自定義協議上報數據需求範例

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

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

第五步，上報數據

這個步驟就是開發根據產品經理的數據需求，按照數據上報規範，完成上報開發，將數據上報到數據服務器。

上報數據的關鍵是數據上報通道的建設，原來在騰訊工作時候，沒有體會到這個環節的艱辛，因爲數據平臺部門已經做了完備的數據通道搭建，開發按照一定規則，使用統一的數據SDK進行數據上報就可以了。

後來在YY，屬於發展型公司，則是從上報通道開始進行建設，也讓我得到更多鍛鍊提升的機會。其中很關鍵的一個環節，就是數據上報測試，曾經因爲該環節的測試資源沒到位，造成不必要的麻煩。

很多創業公司沒有自己的數據平臺，可以利用第三方的數據平臺：網頁產品，可以使用百度統計（tongji.baidu.com）；移動端產品，可以使用友盟(www.umeng.com)、TalkingData(www.talkingdata.com)等平臺。

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

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

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

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

目前也有無埋點的數據上報方式，參見這篇文章《揭開GrowingIO無埋點的神祕面紗》。

第六-八步，數據採集與接入、存儲、調度與運算

每一步都是一門學問，例如採集數據涉及接口創建，要考慮數據字段的拓展性，數據採集過程中的ETL數據清洗流程，客戶端數據上報的正確性校驗等；數據存儲與調度、運算，在大數據時代，更是很有挑戰性的技術活。

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秒鐘！

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

• 多個數據源的統一，一般實際的應用過程中，都存在不同的數據格式來源，這個時候，採集和接入這部分，需要把這些數據源進行統一的轉化。
• 採集的實時高效，由於大部分系統都是在線系統，對於數據採集的時效性要求會比較高。
• 髒數據處理，對於一些會影響整個分析統計的髒數據，需要在接入層的時候進行邏輯屏蔽，避免後面統計分析和應用的時候，由於這部分數據導致很多不可預知的問題。

2. 數據的存儲與計算

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

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

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

圖8 騰訊TDW分佈式數據倉庫

圖9 TDW業務示意圖

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

• 數據安全性，很多數據是不可恢復的，所以數據存儲的安全可靠永遠是最重要的。一定要投入最多的精力來關注。
• 數據計算和提取的效率，做爲存儲源，後面會面臨很多數據查詢和提取分析的工作，這部分的效率需要確保。
• 數據一致性，存儲的數據主備要保證一致性。

這一步的關鍵，企業要構建自己的私有數據平臺，就是找到有數據平臺開發經驗的架構師、工程師，事半功倍，當然，如果是中小企業，直接用雲產品吧，效率更高。

第九步：獲取數據

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

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

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

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

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

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

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

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

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

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

3. 圖表與數據要一致

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

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

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

4. 報表要單一

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

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

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

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

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

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

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

圖11 友盟的留存數據報表

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

第十步：觀測和分析數據

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

數據分析常用於：瞭解產品現狀，瞭解發展趨勢，發現問題，認清用戶，營銷推廣。

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

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

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

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

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

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

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

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

數據分析結果的輸出，通常採用直觀的可視化展現方式，選擇一種合理的圖表，使得分析結果更直觀。

推薦兩個實用的可視化工具：

百度圖說：https://tushuo.baidu.com

文字雲圖：https://wordart.com

自定義圖片生成個性化文字雲圖。

關於文字雲圖的攻略文章：

文字雲圖攻略（二）：自定義圖形做個性文字雲圖

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

這是數據運營閉環的終點，同時也是新的起點，數據報表絕不是擺設，也不是應付領導的提問，而是切實的爲產品優化和運營的開展服務，正如產品人員的績效，不僅僅是看產品項目是否按時完成，按時發佈，更是要持續進行產品數據的觀測分析，評估產品健康度，同時將積累的數據應用到產品設計和運營環節，例如亞馬遜的個性化推薦產品，例如QQ音樂的猜你喜歡，例如淘寶的時光機，例如今日頭條的推薦閱讀等等。數據產品應用，大致可以分爲以下幾類：

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

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

產品案例：谷歌、Facebook、微信朋友圈。

下圖是微信的用戶數據定向能力，可以從地域、性別年齡、手機、婚戀、學歷等多維度進行用戶精準定位：

微信朋友圈廣告，雖然很多人說買不起，但很多時候是你想不想買，隨着數據積累，廣告會越來越精準。

（2）以音頻、視頻推薦爲代表的內容推薦

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

產品案例：Youtube、網易雲音樂、抖音、QQ音樂

下圖是抖音給我推薦的小姐姐、馬雲、風景，大體符合我這個40歲大叔、互聯網從業者、旅遊愛好者的喜歡。

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

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

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

下圖是淘寶給我的推薦，大致符合一個男性用戶、家有小朋友、喜歡戶外運動的用戶的產品推薦。

總結

最後，一張圖小結數據運營11步：

圖14 數據運營11步

從制訂產品目標到最後基於目標進行產品評估與運營優化，形成數據運營閉環。這個流程和規範，需要各個部門都能統一意識，每個產品終端都能按照規範流程將數據統一上報，建立公司級的統一數據中心，進行數據倉庫建設，纔有可能將數據價值最大化，讓數據成爲生產力。

再從組織落地方面小結產品數據運營體系構建，可以從以下五大要素進行考慮：

（1）人：專職的數據運營同事

專職的專業的產品同事，負責建立產品數據體系的流程化、標準化，沉澱經驗，推動體系的持續優化發展；專職的專業的開發同事，負責數據上報，報表開發，數據庫開發維護等工作，保證產品數據體系的開發實現。

（2）數據後臺：全面系統的數據倉庫

有一個專門的統一數據倉庫記錄自己產品的特殊個性數據，共性數據充分利用數據平臺部公用接口獲取，共享數據源，充分降低成本。

（3）數據前臺：固化數據體系展現平臺

需要專業的報表開發同事， 體系化思考報表系統，靈活迭代執行，而不是簡單的承接報表需求，造成報表氾濫。

（4）工作規範：需求實現流程化

就是前面描述的11步構建產品數據體系的流程和方法，其中的數據需求把握好兩點，一是固化需求開發流程化，二是臨時需求工具化。

（5）工作產出：數據應用

常規的數據工作就是各種數據分析，輸出日報、週報、月報；基於數據分析基礎上進行決策依據提供。進行數據產品開發，例如精準推薦、用戶生命週期管理等產品策劃。

以上內容是我多年工作實踐的小結，在此也感謝很多和我共事過的數據工作同事給了很多幫助：恭偉、暢波、春哥、夏聰、宇聞、志華、敬宓、小衛、堅裕等。

#專欄作家#

Blues，微信公衆號：BLUEMIDOU，人人都是產品經理專欄作家，迅雷產品總監，原YY語音、騰訊高級產品經理。具有十年產品經驗，多年產品講師經驗。著名自媒體人，WeMedia自媒體聯盟成員，十佳自媒體人之一。擅長產品策劃、產品運營、數據分析、用戶研究、行業分析等。

本文原創發佈於人人都是產品經理，未經許可，不得轉載。

題圖來自Unsplash，基於CC0協議