神策資料徐美玲：資料分析之產品應用實踐
在以“場景賦能·驅動有數”為主題的神策 2018 資料驅動大會現場，神策資料業務諮詢專家徐美玲發表了名為《資料分析之產品應用實踐》的主題演講，以下內容根據現場演講整理所得。
溫馨提示：在文末可下載完整版 PPT
本文主要內容為：
資料分析方法 業務流程的融入
一、資料分析方法
這一部分的內容分為兩方面：
1.資料分析的通用方法，以及如何與業務結合。
2.在實際產品迭代過程中，如何利用資料進行搭建。
神策資料經常提資料驅動，那麼資料驅動到底是什麼意思呢？
首先，是業務訴求到資料需求的轉譯。
在這個過程當中，有時連一些專業的資料分析人員都認為根本無從下手，他們不知道尋找什麼樣的資料去代表現在的業務。所以該階段的核心，要先搞清楚業務訴求，落實清楚客戶究竟希望解決何種問題，並轉譯成何種資料需求，以及能夠代表的問題又是什麼。這是訴求到業務應用的第一個步驟。接著，在資料需求明確的情況下，核心點變成了如何選取資料來源與分析方法，這是第二步。
第三步——資料分析。我們用找到的資料來源與分析方法，通過交叉、分群等分析思路診斷定位問題，但資料分析對實際業務應用還存在著距離。因為我們雖然發現了資料特徵，但是資料表現意味著“業務有什麼問題？用什麼方法能夠解決這個問題？”等方面內容。
所以，第四步“資料表現到業務特徵提取”和第五步“業務特徵到解決方案的追索”就是資料驅動對業務產生最大幫助的兩個環節，但由於職能邊界、深度配合以及人員能力等問題，導致許多公司在這兩步驟上的應用和處理能力較弱。
其實，許多產品本身包含運營活動、渠道分析等內容，因為產品最終是所有業務的沉澱，資料的業務特徵最終都要通過產品承載，產品分析最終其實會涵蓋絕大多數業務場景。那麼，資料分析到底是如何與產品應用結合的呢？下面為大家展開介紹。
常用的分析指標 1.滲透率
其中日活滲透率最常用，即 DAU 裡面每天都是什麼情況。每天有 10 萬人登入，其中 10% 的人做了什麼，每天業務產生價值就是 10%，當滲透率提升到 30%，意味著價值提升了 3 倍。所以，滲透率是很多產品夢寐以求實現的大盤基礎。
曝光點選率也是常用的資料指標，很多時候，曝光資源非常緊張，尤其是在平臺運營位資源有限的情況下，提供什麼樣的產品內容，對最終價值有著重要的意義。所以我們會評估曝光點選率，如果產品對 100 萬用戶做了產品曝光，最終只有 10 萬人點選，那曝光點選率就只有 10%。另外，在何種入口設計成何種樣式，才能讓入口展示變得更有吸引力，也是提升滲透率的例子。
2.轉化率
轉化率直接代表產品功能有沒有完成對使用者的基礎轉化，神策分析在轉化率中提供了非常重要的功能——視窗期設定。比如電商使用者選擇購買日用品的決策相對較快，視窗期設定為 1 個小時或 1 天都是合理的，運營人員可以在視窗期看到使用者是否完成轉化。但如果面對的是理財或投資類產品，涉及比價、實名認證、繫結銀行卡等步驟，使用者決策週期很長，所以視窗期的設定時間就要從產品本身的特點出發。
3.留存流失率
神策資料的分析師及諮詢團隊在做具體功能診斷時，除了關注上述兩個資料指標外還會關注產品的留存與流失情況。留存通常意味著使用者的整體體驗是較好的，所以最終價值的傳遞效果也是較好的。留存率一般作為這種長期綜合評估產品價值的指標，所以如果客戶做產品的增長體制，相比留存率而言，上述提到的轉化率可能並不是很好的綜合指標。
4.使用者路徑和分佈
這兩種分析指標相對少見，因為這樣的應用場景非常強調對資料的理解。客戶可能發現轉化率與滲透率表現都不太好，所以特別希望知道表現不佳的原因，希望能看到使用者流量在各環節發生了什麼，以及流失點在哪，所以這是相對微觀的資料指標。而分佈是黏性價值的體現，使用者今天登入 10 次與登入 1 次、使用 1 個小時和 10 秒鐘的價值不一樣，所以分佈能較好的衡量使用者整體質量與黏性的分類維度。
分析型別及思路 功能/體驗分析。功能從入口到最終的出口轉化怎麼樣？達到的比例效果如何？留存表現怎麼樣？這是功能留存裡面關注的三個維度。
頁面/場景分析。其中，互動點選率/點選頻次，印證了使用者互動的比率與互動深度有多少。另外，核心功能中的入口功能有沒有促進場景的轉化，以及最後的留存表現也是很重要的考察維度。
內容策略分析。看內容策略優劣與否，一般檢視推薦產品的使用者曝光點選率、有效互動率，比如說使用者在短視訊平臺上播放了 30% 或者 50% 是一次有效的互動，那這樣的有效互動就是與自己業務有關的資料。另外，需要分析深度轉化率以及留存表現。
神策資料強調資料分析對業務產生價值，所以我們要考慮很多維度，甚至客戶的營收維度都需要考慮，因為分析維度太片面或者太淺，就不可能關聯到真正的業務場景。接下來與大家分享一個採集的思考框架，究竟怎麼把使用者的設計轉化為採集埋點。
首先是採集範疇，我們要思考入口來源在哪裡，是否進行了採集，核心互動是否採集，以及出口分流場景有沒有采集。
第二是採集時機，很多人不清楚採集資料代表的含義，其實是不清楚資料來源到底是在什麼階段採集的。比如註冊，註冊可以被細分到很多場景中，前端操作做了註冊按鈕的提交，代表使用者有註冊意願，但如果當前網路狀況不好，前端的請求就傳送失敗。使用者從有意願產生到意願最終成功到伺服器是一個成功的路徑，可是如果驗證碼收不到，那麼當然不能用請求發出事件代表使用者註冊意願，接下來就是圍繞軟硬體環境、業務特徵、業務結果、使用者分類方面的屬性維度。
神策資料在為使用者推薦採集策略的時候，通常會讓客戶思考清楚到底希望何種業務特徵資料在何種場景以何種時機採集，才能符合客戶的業務需求。
事件屬性：使用環境維度 此類使用環境維度包括軟體環境、硬體環境和網路環境。其中，軟體環境包括作業系統、作業系統版本、應用版本；硬體環境包括：埠、機型、品牌、解析度；網路環境包括2G、3G、4G、WIFI 等。比如解析度在安卓機型上比較複雜， H5 頁面就會常常導致很多業務出現相容錯誤，而相容性有問題的話，業務就沒有辦法操作。所以，在產品釋出新功能的時候，如果出現業務異常，可以直接從三種使用環境維度中尋找原因，比如說新版本出現問題而舊版本沒有，這就說明後端業務功能沒有問題，僅僅是該版本出現異常情況。
事件屬性：業務關聯的維度 業務關聯維度強調對業務的理解以及維度採集是否全面，也就是資料採集的時候，是否可以很準確地下鑽。舉個例子，影響支付成功率的核心維度有哪些？第一，支付埠。支付埠細分為 H5、微信端、IOS、安卓、PC 端等。接下來，支付通道、支付方式、支付銀行卡等都可以持續細分。維度下鑽強調大家對業務的理解，以及分析思路跟業務的強匹配。
分群分層：人群+場景的差異化 其中包括偏好差異、階段差異與場景差異。常見的分層分群思路：
1.使用者生命週期。到底是新使用者、老使用者，還是迴流使用者？
2.目標受眾。是潛在使用者、核心使用者還是邊緣使用者？如果是核心使用者在某些指標上問題比較大，其實說明問題很嚴重。如果是邊緣使用者，那麼該群體在資料上的相對下降是正常的。
3.使用者特徵。指使用者的年齡、性別等特徵，比較常見。
4.興趣偏好。指使用者喜歡的二次元、古風、韓風等，比較常見。我們在使用者行為採集、調研裡面關注最後兩個特徵，因為後臺伺服器很少能採集到這兩類資料。所以，我們用這類特徵的時候，要用人口學調研資料抽樣檢測人群差異，輔助使用伺服器資料。
接下來跟大家分享一個工作中的例項——視訊產品新增流失分析。
首先，用 5W2H 分析產品流失的整體情況。比如，到底什麼算是流失？什麼人流失？什麼時候流失？什麼地方流失？為什麼流失？怎麼流失的？有多嚴重？接著根據流失情況思考要如何解決問題，降低流失率。老闆都希望在這兩類問題上反饋給他相應的回答。
那麼流失率當然是分析該問題的常見指標。接著我們要去定義流失行為，比如對本身使用頻率偏低的產品，可能會將流失週期定義為 30 天，如果是一個高頻的社交產品、遊戲產品，流失很可能定義為 7 天已經足夠。那用什麼樣的具體行為來衡量呢？——App 啟動。一些對“定義”嚴格的企業會非常關心使用者細緻的具體行為，通過使用者啟動 App 觀看視訊的這一操作，判斷使用者是否流失以及設定定義特徵等。然後通過流失程度、趨勢、階段、行為特點來分析流失特徵。
接下來就涉及到流失的原因分析。我們要思考為什麼會出現流失、流失的場景是什麼、使用者的主觀感受是什麼，是沒有辦法滿足使用者需求？還是有更好的產品把你取代？同時產品體驗也是原因分析裡面比較重要的判斷標準。流失去向、迴流可能性及條件、影響維度、分群分層等也是另外幾個方面的分析思路。
另一個很重要的分析維度——資料來源。
我們用資料表徵分析一個產品，會涉及到提取規則。而傳統 BI 的提需求流程冗長，業務人員使用起來也非常困難，一旦 BI 提資料時產生錯誤的理解或者遺漏，那麼提取的東西將無法符合需求，時間成本極高。而我們在對資料來源的定義上，審查的比較嚴格，我們不想增加任何一道使用門檻，我們希望用門檻把命題體系化，用更好的科學方法分析問題。
既然分析問題，就要把握分析問題的關鍵。從整體出發分析該問題的時候，就要提煉分析結論的關鍵點，比如流失率、流失趨勢、流失場景、流失原因、滿意度、流失去向以及迴流概率等。除此之外，還要從來源渠道、來源關鍵詞、來源埠、業務場景等維度交叉分析，比如整體流失率可能並不差，但卻發現從某某渠道來的使用者流失率非常高，說明產品整體沒有太大的問題，只是渠道策略錯了。維度交叉與使用者分層分析往往可以帶來真正有價值的業務洞察，而不是一個單薄的總體指標，總體指標只是告訴我們一個特徵，各維度的交叉和分層才是深度分析的關鍵點。
另外，還可以從產品優化、新使用者場景及轉化優化、使用者成長體系優化、流失使用者召回等方面業務特徵追索到解決方案。所以，資料分析在實際應用中不是隻告訴你一個巨集觀的指標，它同樣能很好地告訴你要怎麼做。
二、業務流程融入
我們常常看到，產品被各種各樣的內部需求方擺弄的停滯不前，很大程度上是因為產品團隊沒有自主權去做業務主導方面的能力提升。比如領導說，接下來做一個註冊場景支援一鍵註冊。領導提出這樣的需求，說明他認為這是件重要的事情，可是如果你能從現有的業務池中拿出能帶來更大價值點的事情，領導一定不會強求你去做一鍵註冊的事情。但是產品團隊缺少自主權，沒有辦法解決這樣的問題。
想要解決這個問題，可以有 2 個較好的思路。一個是引入使用者反饋，另一個是引入資料分析。老闆不懂使用者分析，但卻知道使用者很重要，同時對業務發展也有所訴求。所以使用者反饋和資料分析，常常是我們使用的兩個很核心的方法論。
我之前溝通過很多企業，有時候他們並不知道內部需求方提了哪些需求？做了哪些需求？沒做哪些需求？預期在什麼樣的時間點做？A B C 三個業務部門都提出來了很緊急的需求，業務人員在爭取需求資源的時候，就要 PK，其實這是很常見的方法。這並不是“擋需求”，而是讓需求更加有價值，當你論證需求與 PK 需求的時候，意味著你對需求的思考更充分，整體把控也會更好。
上圖是效果驗證常見的幾種方式，我今天分享一個大家比較關心的點——A/B 測試。A/B 測試其實就是為了判斷這件事情值得不值得做，以及是否對全量使用者做，所以第一，需要控制方法，第二，需要真正做出正確的決策。神策分析可以支援 A/B 測試的資料採集和對比分析 ，但本身沒有實現使用者分流體系，這其實已經是另外一個相對專業領域的知識，我們會在有明確應用價值的場景下實現，比如個性化推薦的產品就支援 A/B 測試。方法其實還是有很多的，各有特點，我覺得每家公司都要根據自己的情況與發展階段來制定效果驗證的策略。
另外一個非常重要的點——專案覆盤，也是神策資料的企業文化之一。覆盤的核心是讓你和團隊成員知道每次專案的真實效果，並不簡單的是為了跟老闆做彙報。比如我們的專案負責人由團隊裡面的小組長輪流承擔，專案上線後一個星期會完成資料上線的評估報告，讓團隊成員知道做的怎麼樣、有沒有達到預期目標，以及產品設計的 idea 有沒有被論證。
所以，專案覆盤會的核心有三個：
第一，專案資料表現宣講；
第二，專案過程覆盤；
第三，優化方案形成，優化方案一定要落實到具體負責人。
最後，關於專案迭代。一般專案迭代控制在兩週左右，在時間劃分上，兩週左右的專案算中型專案，一週左右的專案是小型專案。其中，中型專案有幾個核心環節：需求分析、設計及評審過程當中對設計方案的優化、基礎的可行性測試、灰度釋出，以及正式上線做專案覆盤。小型專案相對比較簡單，不會涉及需求分析的接入，不會單獨做系統分析，最終會有一個數據簡報輸出，哪怕是一個小型專案，我們也會評估覆盤最終的結果。
舉一個簡單的例子，某 App 的報錯率高達 20%，做了小版本的迭代後報錯率可以降到 5% 左右，因為我們把問題定義的非常明確，不同職能線的同事交叉完成這個專案，把它順利地迭代。當然這個 2 周並不是個金科玉律，各個團隊還是要根據自己的業務和團隊的情況進行探索，找到最適合自己團隊的節奏。
以上就是我今天的分享，感謝大家的聆聽。
更多幹貨和案例，可以關注“神策資料”和“使用者行為洞察研究院”公眾號瞭解~ 