《一週數據埋點之旅》第二天：埋點之前
0x00 前言
上一篇我們初識了埋點，介紹什麼是埋點、埋點的用途和埋點分類，那是不是馬上就可以開始設計埋點了，答案是否定的。在埋點設計之前還有很多工作要做。通過本篇的閱讀，你將對埋點之前的準備工作和埋點的流程有更加清晰的認識，本篇按順序介紹如下:
- 瞭解產品
- 梳理舊需求
- 梳理舊埋點
- 熟悉埋點流程
0x01 瞭解產品
所謂磨刀不誤砍柴工，埋點設計是和產品密切相關的，對產品熟悉可以極大的加快埋點設計的進度。瞭解產品可以從以下方面入手
- 瞭解產品的交互
自己親自下載安裝下負責的應用，隨意的操作點擊，將產品提供的功能服務都嘗試一遍，初步劃分出產品的幾大模組，建立初步的感知。
- 梳理產品的資訊流結構
在感知的基礎上，將產品的提供的功能抽象出幾個實體，然後畫出這些實體是如何隨著使用者的操作進行流動的，西什麼樣的形式展現的，提供了哪些交互入口。
- 瞭解產品的未來規劃
多個產品經理溝通下，詢問下產品目前的定位，近期的計畫，和未來的規劃，這些資訊可能暫時對你的幫助不大，但當你設計埋點的時候，這些資訊貴潛意識的影響你的設計方法，以更好的相容未來產品的改變。
0x02 梳理舊需求
埋點的很大一部分用途是為了做報表呈現當前產品的大盤狀態，比如整體的新增、活躍、留存、回流，以及各個功能模組的使用情況。通過對舊需求的梳理，你能明白產品關注哪些指標，是從哪些角度進行分解的，有哪些度量方式此外嘗試著將這些指標梳理成體系，比如哪些是技術指標，哪些是業務指標，哪些是故障指標等，對需求的梳理也是同樣的邏輯。
0x03 梳理舊埋點
根據作者的瞭解，絕大部分的公司都沒有埋點管理系統，大多都是以excel的方式進行管理，雖然excel管理也不是不可行，埋點的形式天然就具有表格的樣式，問題在於埋點人員對埋點管理的認識參差不齊，所以埋點文檔百花齊放，紛繁複雜，混亂不堪是常見的。但舊埋點的梳理是必不可少的，試著多向以前的埋點人員瞭解下，建立app上的交互和埋點文檔中事件的對應關係，對快速展開埋點工作大有裨益。
0x04 熟悉埋點流程
要做好一件事，必須知道其具體流程，埋點雖然聽起來簡單，其實也是一個系統性的工程，需要各方共同參與。以當前主流的前端代碼埋點為例，埋點牽涉到產品經理、資料產品經理、資料開發、業務開發、資料測試五個角色，在一些企業的設置中可能並沒有資料產品的角色，其角色就會有資料開發來兼任，此外很多的資料測試也是由業務測試來兼職的。但不管角色的多少還是兼職，埋點所遵循的流程改動並不大。埋點開發的通用流程如下圖所示：
角色職責
- 產品經理：輸出策劃文檔、統計需求(一般是以報表需求的形式呈現，也是資料產品埋點轉換的重要參考)
- 資料產品經理：負責進行埋點轉化，對埋點的完整性負責，其一般有兩個轉化參考點,一是策劃文檔，根據相應的改動增加相應的曝光、點擊等埋點事件，另一個參考就是報表需求文檔，通過完善已有的埋點(常見的有增加參數、增加參數值等)或者增加新的埋點來支撐報表需求。
- 資料開發：根據產品輸出的埋點轉化文檔，進行埋點設計，具體體現為埋點參數名、參數值、上報時機等，對埋點的準確性負責。業務開發：根據資料開發輸出的埋點設計文檔，根據回應的觸發時機，將事件相關的設計的附屬資訊按指定的格式進行上報，對埋點植入的正確性負責、對採集資料的完整性負責（漏掉一些上報時機是很常見的事）。資料測試：根據業務開發的上報，通過測試用例抓包的方式驗證資料的上報是否和埋點設計的一致，驗證一致後發起埋點驗收報告。
注意
- 產品提出統計需求的時候，需要用到哪些資料最好能先和開發溝通一下，是否能獲取到，可以極大的減少在埋點需求和設計評審時討論開發能否實現的耗時。
- 資料測試發起埋點驗收報告的時候，上報資料要經過篩選，只核驗本次埋點設計改動的地方，並見埋點設計的改動和上班資料的對應關係標注出來，可以極大的加快資料驗收的進度。（資料驗收目前還有很多的挑戰，比如我參數值的層級組合等，只能做簡單的自動化）
0x05 總結
本文對埋點之前的準備工作和埋點開發的流程做了簡要的介紹，需要強調的是埋點是一個系統工程，需要參與各方高效的協同，這也是提高埋點品質的前提。
數據科學系列文回顧：
十週入門數據分析系列文回顧：
關注數據君的臉書：
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。按贊我的臉書，會有豐富資料包贈送唷！