從需求到數據到改進，如何造成閉環

本文由做者周巧芬受權網易雲社區發佈。

互聯網的產品相對傳統IT產業而言，需求更富有多樣性。傳統IT行業的需求點可能是固定且符合驗收條件。但互聯網的產品則更多的從用戶體驗出發，更多的用數據來講話，無論是PV、UV、轉化率、留存等等。很顯然在一個接着一個的迭代背後，咱們必需要讓需求到數據到改進實現閉環，才能在產品上精益求精。今天就來探討下如何從項目經理的角度出發，將這些環節造成閉環，更好的爲產品的精益求精服務。

近期，筆者所在的團隊也正在探討全流程項目管理的探索。項目經理在理清這些環節之餘，更多的參與其中，想必對行業背景的積累以及產品觀等多有益處。

什麼是閉環？

閉環(閉環結構）也叫反饋控制系統，是將系統輸出量的測量值與所指望的給定值相比較，由此產生一個誤差信號，利用此誤差信號進行調節控制，使輸出值儘可能接近於指望值。

顧名思義，要造成一個閉環，則須要一個指望值，一個測量值，並有反饋和調節。對於互聯網產品來講，亦是如此。而對於互聯網產品而言，指望值和測量值每每都是由數據去呈現。所以對於需求—數據—改進的閉環，可分解爲如下三點：

l 產品功能交互設計之初，明確方向，設定指標（KPI）。

l 產品開發過程作好埋點，確認數據來源，獲取數據。

l 分析數據，並反饋到產品功能交互設計。

下面，分別展開講講每一點在項目中咱們應該如何去作。此處只是從項目經理的角度出發咱們在項目開展中能夠去關注的環節，對於數據驅動創新等更專業的內容建議你們能夠閱讀《精益數據分析》。

1. 功能設計之初，制定指標

明肯定義：

產品的孵化和各功能模塊的設計在最初的時候都有一個初衷，去解決用戶的痛點。從產品初衷到產品形態，如何去衡量咱們作的每個功能用戶是買帳的。在最初始階段，咱們就須要設定指標來衡量，而其中數據指標是最爲量化和直觀的。但在這個過程當中，不能僅僅就提出數據指標，更要明肯定義每一個指標的具體意義以及計算方式。

舉個例子，好比想用每日活躍用戶的數量來衡量app的受歡迎程度。初一看以爲這樣的指標很合理，但實際上是不夠的，由於沒有對活躍用戶作一個定義，是登陸到前臺就算活躍用戶仍是產生行爲了纔算活躍用戶。又好比，留存率，也有不一樣的維度，是第二天留存仍是7日留存，什麼樣的用戶可被定義爲留存用戶。不一樣的定義會極大的影響咱們的判斷。因此咱們必須作到精肯定義，排除可能形成干擾的其餘因素。

而每一個指標的背後，都應該爲產品的方向和目標服務。好比一個即時通信的工具，那麼用戶之間的消息量、好友數也許是咱們衡量這個產品健康度的指標，由於這兩個指標和咱們的核心功能切合。

一般來講，在產品設計之初，產品經理和策劃就應該根據本身對產品的思考整理出核心指標。核心指標也並非不變的，在產品MVP驗證探索階段，也許產品的方向均可能發生變化，此時核心指標也會發生相應的轉變。

達成共識：

在定義好核心的指標以後，咱們應該針對這樣的指標整個團隊達成共識。這樣的方式能夠採起屢次的頭腦風暴，以及討論會。在這樣的過程當中，其實你們能夠更加深刻的去挖掘。參與人員包含運營市場產品設計以及開發測試，只有你們共同理解目標，在每一個工做環節才能集中精力爲這樣的目標去努力奮鬥。同時這樣的一個過程也創建你們對產品的一種主人翁意識。

1. 鋪平數據來源之路

對於數據指標達成一致意見以後，那又如何常規的獲取數據呢？

在產品研發過程當中，對於數據獲取的途徑一併考慮，則能夠節約不少後期跑取數據的繁複過程。好比數據埋點的接入，核心kpi系統的搭建。都是用來呈現常規數據的手段，隨用隨查，而無需再要開發人員跑取。

在咱們平常產品中，一般數據的來源有三處，一個是服務器數據庫數據、二是日誌數據，三是埋點後收集的數據。服務器的數據和日誌的數據相對來講比較精準，但很難作用戶使用路徑的分析。而埋點數據，因爲受第三方數據分析系統的上傳策略限制，在精確性上存在必定的折損，一般用來作用戶路徑的分析，數據對比，以及平常觀測。

數據埋點：市面上目前有不少種第三方數據分析統計平臺，好比GA等，但功能較爲完善的一般都須要收費。目前咱們使用的是網易杭研新推出的hubble。

對於埋點，會涉及到埋點事件，以及埋點事件的屬性和標籤，結合數據分析平臺。產品策劃一樣須要在產品設計過程當中，理清楚埋點的需求，提交給開發。而埋點的需求一般會結合分析用戶行爲、各維度數據呈現的要求。以下圖就是hubble當前提供的分析功能。以及某產品策劃整理的埋點文檔。

圖1 hubble提供的功能列表

圖2 某產品埋點文檔示例

一樣埋點需求文檔也是須要在產品迭代中不斷的維護更新。所以，也建議你們將埋點需求文檔和需求管理結合起來。在總體的開發流程中，關注埋點需求的落實和驗證。在開發工做量上，埋點需求處理起來較爲簡單。而驗證的環節能夠經過埋點包來完成，也能夠直接在第三方後臺查看數據生成的情況。

所謂工欲善其事必先利其器，想讓數據驅動，那麼這些工做的完備開展會極大的幫助你們的平常工做。

1. 數據指標帶來的反饋

有了數據，咱們又應該如何去對待數據從而帶來正向的反饋呢？

對於團隊

數據指標應該按期的反饋給團隊，作到數據信息透明。這個有不少的方式，好比例行的數據週報發送，數據平臺的權限開放。另外，也須要培養和調動你們對數據的敏感性。咱們之前一直在談如何提升成員的ownership感，而我認爲，讓你們更透明的瞭解本身正在爲之奮鬥的產品的情況則是很是重要的一點。核心數據指標較爲健康，總體向上的趨勢，對團隊來講無疑是最好的激勵。而當數據下滑或者出現異常，整個團隊就須要提升危機感，從而共同審視當前的工做，是否能夠爲了數據上揚而作些力所能及的事情。

對於產品和運營：

上面講了那麼多，其實最終仍是要爲產品和運營服務。那麼最後一環咱們應該怎麼作，才能真正的達到閉環，讓數據真正的被利用起來呢。配合相應案例，但願對你們能有所思考。

l 預警和產品、運營的優化：

數據的異常變更，可能提示着某個異常，舉個例子：某產品在頁面上端作了黃條的消息提示，用來作平常信息通知等。但在一次版本改版中，爲了便於區分不一樣的信息類型，新增了灰條。數據後臺則會發現，頂端消息通知的點擊率大幅度的降低，灰色相對黃色，醒目程度大打折扣。後續產品作了緊急調整，棄用灰條。

又好比用戶流失預警系統，下圖則是某產品流失預警中的某個表格。很顯然，經過這個表格，則能夠明顯的發現有一部分用戶流失機率較高。從而能夠抽取這部分用戶，對這部分的用戶作一些特徵的挖掘，或者直接經過電話訪問等方式來調查用戶流失的緣由。從而使得產品在這些方面獲得檢討和優化。固然，也能夠針對高流失機率的用戶作一些運營活動的召回。

圖3 某產品流失預警數據表之一

又好比下圖所示：則是某產品平常數據週報中很常見的一點。我以爲已經無需贅述，你們天然就能夠看到在這個過程當中，運營策略發生的變化。。

圖4 某產品平常數據運營週報部分截圖

l 驗證設想， A/Btest

舉個很簡單的例子，某產品須要獲取用戶的GPS信息，便於補充用戶畫像的數據。但因爲手機系統權限的設計，獲取GPS信息會在app啓動初始彈窗詢問用戶是否容許。在這樣的狀況下，產品猜想會有對新用戶的註冊轉化率有必定的影響。

因而，挑取兩個小衆化的渠道來作測試，只針對這兩個渠道下載包的用戶作了GPS信息的收集。最終發現註冊轉化率的數據上和以前對比沒有異常和波動。獲得這個結論後，則能夠大膽的將此功能開放到全局平臺。

再舉個例子：在某產品的某個頁面中，對於商品的展現方式如何能帶來更高的點擊率，設計了兩個模式。所以須要對這兩種方案設計A/B test。以下圖所示，就是A/B test的數據對比，很顯然，下圖中的D版本明顯點擊優於其餘版本。最終則考慮全部的頁面所有切到D方案。

圖5 某產品A/B test數據對比圖

綜上幾個案例，我相信你們確定能夠看到數據在產品和運營中的這種反饋做用。而這個過程更多的須要產品策劃和運營具備必定的數據驅動意識，在這個方向上的精進，無疑對工做會帶來很大的益處。

如上，是筆者在平常項目管理過程當中，對於需求—數據—改進 閉環造成的見解。對於數據創新驅動業務等課題，已經有不少專業性的文章和書籍作了研究，但筆者想表達的是，在平常工做中，咱們關注點點滴滴，踏實作好每一步纔是最重要的。

免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐

更多網易技術、產品、運營經驗分享請訪問網易雲社區。

文章來源： 網易雲社區