這些都是本文作者在數據分析這條路上踩過的坑，作者進行復盤與反思，供大家學習與參考。。
數據是產品的寶藏，數據分析就是產品設計中，挖寶藏的過程。
「數據分析指導產品設計」的這一整套流程，可能是產品經理在產品設計中最享受的部分了。而數據分析的基礎就是數據源，數據源一般分為兩部分：一部分叫用戶行為數據，主要在APP的前後端埋點；另一部分，叫業務數據，一般存儲在後臺數據庫。
這兩種數據，會隨著用戶的操作，源源不斷地產生。
比如：
筆者打開了某寶準備買一把鍵盤，搜索之後，瀏覽了3頁商品，在某一頁商品的詳情裡看到了鍵盤排行榜的入口。然後，發現排名第一的正是自己這款鍵盤，於是選型號、加入購物車，最後和本在購物車裡的一箱屈臣氏蘇打水一起下單、支付，完成購買。
這一整套流程，筆者跳轉了8個頁面，進行了8次點擊操作，觸發了n次信息流曝光，完成了一次電商線上購物流程，包括購物車收藏、訂單確認、訂單支付等三個階段流程。
在這個流程中，前後端埋點會按時上報，在極少量損失的情況下，上傳到服務器並存儲在埋點數據表裡。同時，筆者的訂單、交易、錢包、會員等相關數據，也因為這次交易的發生，做了相應的變化。
APP的產品經理，通過分析筆者這類用戶的行為數據，得出了以下結論：
- 用戶查看排行榜後，80%選擇對排行第一的產品進行下單購買，15%選擇購買排名第二的產品，其它5%沒有發生購買。（行為數據分析）。
- 筆者在後臺被打上了高級用戶標籤，這種用戶人數佔活躍用戶數的30%，但貢獻了60%的交易額，同時這個標籤群體的退貨率不到2%。（業務數據分析）。
- 84%的用戶在商品列表頁翻頁時，最多翻到4頁就選擇跳出，而最多翻頁的用戶，剔除極端異常數據後，一般是翻到10頁左右。通常搜索結果在10頁以上且發生購買的情況下，前五頁商品被下單的概率高達88%。（行為數據、業務數據結合分析）。
於是，產品經理依照分析結論，按照產品優先級，在下一個迭代中加入了「排行榜展示及詳情維度策略優化」等需求，上線後新版本排行榜購買率提升1%，GMV同比新增0.02%。
以上就是數據分析指導產品設計的理想流程，但要實現這種設計流程，可能需要整個研發團隊的傾力協作去做好數據體系的搭建。這個過程往往費時費力，且有很多坑。
筆者總結了搭建數據體系過程中的三大常見難點，即：
- 埋點流程及體系
- 數據報表及後臺
- 數據監控及可視化
接下來我們將依次詳述。
一、埋點流程及體系
埋點是數據分析的底層設施。
但埋點不是憑空出現的，埋點往往是研發同事一個個做上去的，是有一定開發量的。同時，也需要大量的測試人力來驗證；否則，一兩個數據指標埋點錯亂的話，後續的後果不堪設想。
那麼有開發量，就代表有需求。
埋點的需求，一般來說是隨頁面需求走的；也就是說，通常不單單要做需求方案評審，還要做埋點評審。由數據產品經理，對每次有頁面變更需求的埋點文檔進行評審。
埋點文檔，一般是隨需求文檔，由需求提出的產品經理來撰寫，形式不限。但主要目的是能夠標註清楚每一個點位的位置、上報邏輯、上報字段參數。
通常有頁面跳轉關係的，叫頁面埋點。即筆者點擊商品列表頁的商品圖片，進入商品詳情頁，此時APP就要上報這個埋點，假設編號為P02。
這個埋點的意思是，筆者從編號為P01的列表頁，通過點擊商品圖片，跳轉到編號為P02的詳情頁。同時，上報字段包括商品的參數good_id。
這時通過上報的埋點數據，我們可以知道筆者從哪個頁面去到了哪個頁面，又查看了哪個商品，從哪個入口進行下一步操作。
而APP內不單單有頁面跳轉，還有同一頁面的操作和信息的曝光。
當筆者在購物車頁面時，發現自己之前添加了一把鍵盤，但是沒有今天看到的喜歡，於是在購物車頁面選取那個鍵盤進行了刪除。這個時候，就需要上報事件埋點，並攜帶被刪除商品的good_id及加入購物車時間等參數，假設埋點編號為C01。也就是說，在購物車頁面（假設為P03）下，有N個事件。其中，刪除事件的埋點編號為C01，上報時攜帶了刪除商品信息等字段。
在曝光方面，筆者在瀏覽商品列表時，並沒有把第三頁的商品看完，只看到了前三個，還有後3個沒有曝光在筆者的手機屏幕上。於是，在筆者手機屏幕停下的時候，一次曝光埋點被上報了，這次上報的商品信息僅包括3個商品，並不包括此頁面還沒有曝光的後三個。
以上我們分別講述了：埋點文檔，以及埋點文檔包括的頁面埋點、點擊事件埋點和曝光事件埋點。
通過規範埋點流程、定義埋點需求、完善埋點系統的方式，才能建立起一個APP進行用戶行為數據分析的必要底層數據基礎。
二、數據報表及後臺
和埋點需求一起確認的，應該還有報表需求，因為兩者是相輔相成的。
埋點是報表分析的基礎，而報表分析提供了埋點的思路和方向。一個產品功能往往承載了指標提升的任務，比如上面說到的排行榜，可能是為了拉昇下單轉化率。
而該目標是否實現，是要靠數據報表來體現的。比如為了衡量排行榜的產品價值，我們可以搭建一個時間維度的報表，字段諸如：排行榜入口曝光量、排行榜引流其它商品量、排行榜跳轉購物車量、排行榜直接購買量等。
只要產品核心價值不變，往往上述需要定期分析的數據指標就不會變。這個時候，做成報表就會節省很多重複工作，也更加方便跟產品之外的人來彙報，或發定期報表給關聯方進行知會。
但報表並不是數據分析的全部，還有部分無法固化下來的內容。比如，短期運營活動的數據、ABtest的數據、其它維度的靈活數據分析等。
短期運營活動的數據很好理解，一般都週期較短，可能加工成報表的開發時間比活動時間都長，故臨時手工支持即可。ABtest也一樣，有專門的ABtest分析系統，且動作偏過程化，沒有定論，不建議體現在報表中。
而其它靈活維度的數據分析，比如新增事件、位置調整等，就需要埋點分析後臺來支持，待方案穩定落地後，再逐步提需求到報表中。
一般的數據分析後臺，比如天眼、神策等，這種平臺已經把常用的分析方法和功能沉澱下來了。接入APP後，產品經理可以在管理後臺快速上手進行分析。
具體的分析維度，要根據目標來定。比如內部產品，可能不需要看留存等數據，更多需要關注漏斗轉化和性能，而C端產品，留存分析就重要一些。
三、數據監控及可視化
除了分析，監控和可視化也是很重要的。
數據監控指的是，要定期跑一些數據看看，有沒有異常情況發現。比如，每小時跑一下排行榜打開的數據，如果排行榜人均打開次數10次左右，而某天有個別用戶單日打開100次，那可能是異常數據，要追查原因了。看看是統計問題，還是機器刷量，再對症下藥來解決。
可視化通常是在報表基礎上，更進一步的表現形式。
通常可視化有幾種：表達一串操作的衰減情況時，通常採用漏斗模型；表達功能用量或關鍵數據時，通常採用線裝狀趨勢圖，來表達增減趨勢情況；分析渠道佔比或其它橫向類比時，往往採用餅狀圖，這些都是最基本的可視化形態。
更高級的可視化應用有很多，比如我見過的有動線系統。
動線起源於商業地產：在商場中，某一個顧客從入口到逛街到購買到出口的全流程，他行動的線路，就叫顧客動線。
依據對動線的分析，商場的每一個門店、每一個樓梯、每一個收銀臺的位置設置都有講究的，能夠最大化用戶體驗，最大化購物轉化率。
同樣，在APP中用戶也存在一定動線。比如用戶同樣完成一個購買行為，可能是通過列表頁-詳情頁-購物車-付款的動線，也可能是通過活動頁-詳情頁-直接下單-付款的動線。
如果能夠把這些動線通過可視化的方式展示出來，我們就可以看出動線之間的關係，以及每條動線的優劣勢，從而跳脫出現有功能，而從整體規劃這個流程的最優動線。
類似的可視化手段還有熱力圖，可以看到用戶在某一個頁面的點擊情況，從而分析出用戶的真實操作和我們產品設計的視覺引導之間的關係。如果存在偏差，可以有目的性地來調整視覺和交互。
總結
數據分析，是有範圍和目的性的；也就是說，一個團隊要先有數據指導產品設計的需求，才能培養起全員的意識，才能建立起數據分析和埋點的機制，才能建設好底層埋點等設施。
埋點的方式，根據頁面和場景的不同，採用最合適的方法，其核心是業務目標或用戶行為目標的反饋，要從產品價值進行梳理。
通過報表、監控和可視化，能夠洞察到產品運行中的機會點和優化點，逐步走向最優。
如果你作為一個產品經理，想做好團隊的數據分析工作，就從以上幾項入手吧。
#專欄作家#
筆者先生，微信公眾號：產品之術，人人都是產品經理專欄作家。金融業資深產品經理，對職涯規劃與個人發展有豐富經驗，產品涉獵廣泛，ERP、金融領域較多。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
