產品經理必會:可視化數據流量地圖
Hi,各位看官老爺,我們又見面了,在這里祝各位新年快樂(*^▽^*)? ,首先在前三篇文章中我們已經將數據從定義>部署>收集>匯總四個步驟已經做了詳盡的討論,本篇將繼續基于前三篇的基礎之上,以實例討論數據可視化的價值。
了解產品的“健康”狀況嗎?
故事的主人公:X君登場,buling buling
X君深知對一個PM來說數據分析的重要性,通過數據監控產品的健康狀況更是重中之重,工作中X君會拿出大量的時間來分析查詢各個埋點事件,試圖通過埋點事件的查詢,匯總,分析能夠對數據有清楚的了解與認知,從而對產品的“健康”狀況有一個清晰的把控,并樂此不疲的把埋點數據從頭至尾看了一遍又一遍,卻自始至終沒有意識到自己犯的幾個錯誤,直至某天與領導的一段對話:
Leader:“讓你了解移動端的數據情況,你了解的咋樣了”
X君:“都了解好了,數據天天看,Android和iOS 都看完了”
Leader:“首頁環比上月各個入口的流量有啥變化嗎”
X君:“X入口的流量漲了”
Leader:“那對頻道內其他模塊有影響嗎?”
X君:“額….這個…額….我想想…”
中間省去1000字…
后來X君對這件事情進行復盤,發現犯了兩個很大的錯誤!
第一就是“以戰術上的勤奮代替戰略上的懶惰”,以為只要把所有埋點從頭到尾都看上幾遍就能了解產品,了解產品的“健康”狀況,實則不然。
第二就是“盲人摸象”的錯誤,只了解了每個點,卻沒有把點連成線,不能整體分析,自然無法回答Leader提的對頻道內其他模塊的影響這個問題。
向別人分享、展示數據高效嗎?
產品經理在日常的工作中會對接各種各樣的角色,或是向領導匯報、或是向運營同事分享數據、或是向產品線上的UED童鞋、開發童鞋、測試童鞋講解戰況,讓每一個環節都清楚明白的知道自己做的每一個需求的價值,等等。
其中如何向別人快速有效的傳達的數據會成為一個主要的問題—時間效率問題。因為在向同事展示數據時少則一個頁面,多則一個頻道,而每個頁面中涉及的埋點數量與頁面的重要性是正相關的。
當統計完一個頁面的埋點后,可能少則4張表格,多則7,8張表,密密麻麻的會非常多,當向每一個角色解釋時就需要花費一定的時間,我們假設向一個角色解釋數據需要1小時,每個角色拿到數據后消化也需要1小時,如果共計需要向3個角色解釋的話,則需要3+3=6小時的時間。無疑嚴重的降低了產品線的工作效率。
復盤時數據依據從哪來?
小到一個需求需要復盤其成功與失敗的原因,從而獲得經驗在下次做的更好,大到在季度或者年度的工作總結以及其他需要時需要對產品的整體數據情況進行復盤,從而對產品迭代的路徑上對各個頻道下各個模塊的數據變動有一個清晰的認知,首先第一個問題就是:
數據從哪里獲?。?/p>
難道我們要對各個頻道涉及的所有埋點全部重新跑一遍?
難道我們要對所有的數據進行一個整體的分析?這樣會有結論嗎?
基于以上背景,針對文中提到的三類問題,提出解決方案:“流量地圖”,通過“流量地圖”利用數據可視化的方式使產品對流量的整體變化情況有一個清晰的認知,簡單且高效的解讀數據。其次當向領導以及產品線各個環節解釋數據時,別人可輕易的對數據的變動有一個直觀的了解,不需要花大量的時間來整理解讀數據,節省時間。再次“流量地圖”可作為文檔按照功能、時間的維度進行歸類存檔放在企業公有云中,當任何有涉及到查詢、復盤等需求時,可直接分享鏈接給別人,不再需要跟別人單獨的解釋,節省雙方的時間,從而達到提升雙方工作效率的目的。
解決方案:
什么是“流量地圖”?
在討論“流量地圖”之前首先需要介紹以下名詞:
UV(Unique Visitor)
是指通過互聯網訪問、瀏覽這個網頁的自然人。訪問您網站的一臺電腦客戶端為一個訪客。00:00-24:00內相同的客戶端只被計算一次。
PV(Page View)
即頁面瀏覽量或點擊量,用戶每一次對網站中的每一個網頁訪問均被記錄1次PV,用戶對同一個頁面的多次訪問,訪問量累計,用以衡量網站用戶訪問的網頁數量。
“流量地圖”是基于埋點數據之上的上層應用,即通過數據埋點首先將對應時間周期內的數據取出,其次根據每一個埋點取出的數據情況取平均值(均值或者中位數),并將每一個埋點數據算出的平均值對應到頁面上,并使用標注的方式可視化出來,最終形成易讀的,易于分享的可視化的數據圖—“流量地圖”。
怎么做“流量地圖”?
下面我們通過實例來對“流量地圖”做進一步的討論。
例如要針對首頁的數據情況做一張“流量地圖”,如下圖所示:
通過觀察我們可以得出首頁的功能點:
- 掃一掃功能
- 搜索功能
- 消息中心功能
- Banner圖片
- 業務導流入口功能
- 新聞頭條功能
- 金融產品推薦功能
根據已知的功能點,從點擊事件總表和曝光事件總表摘取查詢數據所需的埋點,整理匯總成新表,如圖所示:
然后我們將埋點一一的輸入數據后臺,根據需求選擇數據周期(本例中使用的時間周期為月度),例如向后臺輸入的是功能“掃一掃”的事件ID:c_app_bank_Qrcode,得出如圖所示結果:
根據數據周期內的數據波動情況找出事件PV的平均數,本例中使用均值當成平均數,即57800.
得出的結果根據事件與產品的對應關系,標注在原型圖上,并計算當前入口功能的流量占整個首頁流量的百分比,便于后面整體分析。其他功能點以此類推,最終整理得出如下所示可視化流量地圖。
注釋:圖中PV數據以及占比僅做展示,并非真實數據以及百分比。
依次邏輯,可根據實際的需求選擇性的做幾個重要頻道的流量地圖,或者根據需求針對全站進行全站自上而下涉及所有頁面的流量地圖,以做后期分析的基礎參考。
當完成流量地圖后,良好的目錄存檔習慣,可幫助后期工作中復盤時更加高效的查找文件。本汪在之前的工作中就因為沒有形成良好的存檔規范,覺得分類建文檔很浪費時間,考慮邏輯的分層結構等等,吃過虧,隨著時間的推移,工作中的各種文件越來越多,每次查找歷史文件時都會浪費少則半個小時多則半天的時間來回憶查找文件的路徑位置,非常浪費時間。良好的存檔規范雖然在開始時可能會浪費你5分鐘或者10分鐘的時間,但請相信我,現在花費的5分鐘在將來會幫你節省成倍的時間成本!下圖所示分類以供各位參考:
總結:
本文詳細討論了如何利用數據埋點將數據加工成可視化的圖表—“流量地圖”,并利用可視化的數據圖表解決以下三個問題:
- 整體監控產品的“健康”狀態,及時發現問題,調整迭代方向的問題。
- 高效的向別人(兄弟部門或者部門領導)直觀簡單的展示數據情況,效率的問題。
- 對產品的數據波動情況存檔,后期復盤作為基礎參考的問題。
寫到這里,文章已經將近尾聲,僅以本文期望能夠幫助大家在日常工作中針對業務中的特定問題的解決提供一些思路。各位看官可根據自身實際情況靈活應對!
以上我說的都是錯的,只有適合你的才是正確的!
相關閱讀
本文由 @Aaron 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
寫得好!
兄弟你是招行的?
一口氣看完了四篇文章,必須贊,最近也是剛接觸數據以及數據埋點,不得不說看完后幫助很大,看有段時日沒更新了,期待下一篇。但…….同時有一個問題,愈發不解,那就是雄兔腳撲朔,雌兔眼迷離;雙兔傍地走,安能辨我是雄雌?
入坑數據產品,可以加微信請教嗎
c_app_bank_Qrcode事件表中PV和UV 哪個值能反映掃一掃功能的點擊次數呢?
自己看用UV,給領導匯報用PV
機智啊
哈哈哈哈哈哈哈哈哈哈哈
希望還有持續更新,受益匪淺
很贊的文章!實用性強
系列4篇文章都看了,很棒,深入淺出,淺顯易懂。希望后續能有更深入的分析,加油!
受教了
666~流量地圖根據數據大小有顏色深淺的區分就更好啦,類似熱力圖 一點小小建議哈~
??美美噠
可視化 應該主要還是自動生成數據報表吧
很有收獲。還有后續的文章嗎?
感謝這位看官的認可,后續不定期更新,敬請期待
文章的寫很好