專案埋點的演進
概念
埋點，是對網頁、APP或後臺等應用程式進行資料採集的一種行為。通過埋點，可以採集使用者在應用中的行為，用於分析和優化產品的體驗，也可以為產品運營提供資料支撐。其中比較常見的指標比如PV、UV、DAU、時長、新增、頁面點選等，收集的資料一般為：
- 行為資料 ：時間、地點、使用者、互動的操作等
- 質量資料 ：App執行情況、瀏覽器載入情況、錯誤異常等
- 環境資料 ：手機型號、作業系統版本、運營商、網路環境、裝置資訊等
- 運營資料 ：PV、UV、點選量、日活、留存、渠道來源等
- 安全資料 ：3D感應、藍芽、感測器、電池電量、root資訊等
採集行為資料時，一般會在APP中新增相應程式碼，當用戶行為達到某種條件時，觸發上報（這兒由於策略原因，可能是非實時上傳到伺服器的）。而這個“新增程式碼”的過程我們稱之為“埋點”。一般埋點分為三種形式：
-
程式碼埋點：是指在某個事件發生時呼叫資料收集介面進行資料上報。例如研發按照產品/運營的需求或埋點文件，在Web頁面或App的原始碼裡新增行為上報的程式碼，當用戶的行為滿足某一個條件時，這些程式碼就會被執行，向伺服器上報行為資料。這種方案是最基礎的方案，每次增加或者修改資料上報的條件，都需要開發人員的參與，並且只能在下一個版本上線後才能看到效果。基本上所有的資料平臺都提供了這類資料上報的SDK，將行為上報的後臺伺服器介面封裝成了簡單的客戶端SDK介面。開發者可以通過嵌入這類SDK，在埋點的地方呼叫少量的程式碼就可以上報行為資料。
-
全埋點：指的是將Web頁面或App內產生的所有的、滿足某個條件的行為，全部上報到後臺伺服器。 例如把一個App中所有的按鈕點選都進行上報，然後由產品或運營去後臺篩選所需要的行為資料。這種方案的優點非常明顯，就是可以不用在新增或修改行為上報條件時，再找開發人員去修改埋點的程式碼。然而它的缺點也和優點一樣明顯，那就是上報的資料量比程式碼埋點大很多，裡面可能很多是沒有價值的資料。此外，這種方案更傾向於獨立去看待使用者的行為，而沒有關注行為的上下文，給資料分析帶來了一些難度。很多公司也提供了這類功能的SDK，通過靜態或者動態的方式， “Hook”了原有的App程式碼 ，從而實現了行為的監測，在資料上報時通常是採用累積多條再上報的方案來合併請求。
-
視覺化埋點：是指通過視覺化工具配置採集節點，在App或Web解析配置查詢節點，監聽節點產生的事件並上報。例如產品在Web頁面/App的介面上進行圈選，配置需要監測介面上哪一個元素，然後儲存這個配置，當App啟動時會從後臺伺服器獲得產品/運營預先圈選好的配置，然後根據這份配置查詢並監測App介面上的元素，當某一個元素滿足條件時，就會上報行為資料到後臺伺服器。有了暴力的全埋點技術方案，很容易聯想到按需埋點，視覺化埋點就是一種按需配置埋點的方案。現在也有一些公司提供了這類SDK，圈選監測元素時，有的是提供一個Web管理介面，手機在安裝並初始化了SDK之後，可以和管理介面連線，讓使用者在Web管理介面上配置需要監測的元素，有的是直接讓使用者在手機上圈選元素進行埋點。
優缺點
| 方式 | 優點 | 缺點 |
|---|---|---|
| 程式碼埋點 | 按需埋點、靈活精確。 | 需要開發人員參與成本高，新增或修改的只能在後續版本生效，業務入侵大。 |
| 全埋點 | 可回溯、對業務程式碼入侵較小。 | 上報資料量大、大部分都是無用的、篩選困難，方案對打包時間或效能有影響。 |
| 視覺化埋點 | 按需埋點，無需研發人員配置，可追溯歷史版本生效。 | 當介面結構發生改變時，圈選的元素可能生效；Android&iOS分平臺。 |
現在已經有多家SDK支援上述的埋點方式中的一種或全部，如Mixpanel、Sensorsdata、TalkingData、GrowingIO、Umeng Analytics等，其中 ofollow,noindex">Mixpanel 和 Sensorsdata 已經開源了。
資料採集的過程
一個典型的資料平臺，對於資料的處理一般包括以下幾個步驟：
採集步驟
除了以上還應有兩個部分： 確定需採集的資料、資料校驗 。
其中第一步是最核心的部分，資料準確性、豐富性、實時性，直接影響資料平臺的最終效果。
- 準確性 ：就是要保證埋點的正確，埋點事件是滿足產品和資料需求的，統計的口徑應該是和各方討論確定好的，這是最重要的。因為若是埋點錯誤了，一是相當於此次埋點是無效的，做了無用功，對於程式碼埋點只能等待下次迭代才能重新加上；二是也可能對之前的埋點資料造成影響。所以保證埋點的準確性是至關重要的。
- 豐富性 ：埋點是用於資料分析的，埋點元素要足夠豐富能滿足各種條件的資料分析。比如裝置資訊、手機型號、作業系統、渠道、運營商、網路環境、地理位置資訊、埋點事件資訊等。
- 實時性 ：儘量保證埋點資料的實時上傳，但是如果每一條資料就上報一次的話，上報介面的請求量會特別大。所以一般的策略是：APP啟動時上報、退出上報、滿足一定條數上報、時間間隔及提供立即上報介面。
另外，資料的傳輸過程也有一些需要注意的：
- 批量上傳 ：資料一般都是多條資料批量上傳的。
- 壓縮 ：為減少上傳的大小，一般採用GZIP進行壓縮。
- 加密 ：為保證資料的安全，一般會採用加密策略。
- 容錯 ：資料若是上傳失敗，要保存於資料庫中，避免丟失。
資料校驗的方式：
- 研發人員可以通過日誌校驗。
- 客戶端頁面顯示，將產生的埋點資料懸浮顯示；後端頁面顯示（抓包中轉、後端介面實時重新整理）。
- assert斷言欄位結構
前兩步是涉及到客戶端，後續一般在服務端處理，不做介紹。
我們專案埋點的演變
目前大多數專案還是採用的程式碼埋點，因為程式碼埋點能夠比較準確的統計使用者行為，而且如果埋點合理相較全埋點和視覺化較為簡單方便。目前我們所用的埋點方案也是經過多次迭代改進的。
早期的埋點
我們早期的埋點相對比較簡單，一般整合統計SDK（友盟、talkingdata等），按照相應SDK初始化，加入頁面的統計埋點。遇到一些複雜的業務，使用SDK的自定義埋點即可（比如友盟的計數和計算事件）。
這種方式的 好處 是，簡單方便，維護成本低，不需要自己定義統計的資料格式、上傳報文等，SDK中都封裝好了直接用即可。對一些小型不太負責的APP，個人覺得已經足夠了。
缺點是資料不透明，作為整合方無法獲得上傳報文。
peacock中的埋點統計（DMP）
- 中華萬年曆中廣告的統計，一般只統計廣告的view、click、loading、start等次數，現已廢棄。
- 啟動活躍上報(現已廢棄)、基於事件的日誌報文及規則。
- 自定義事件上報
上述的統計策略配合第三方SDK，基本能夠滿足我們目前的業務需求。但不夠完善，一是沒有獨立的SDK處理這部分邏輯（和peacock耦合），二是報文格式不統一（事件型和自定義型上傳報文和介面不一致），三是上報和儲存策略待優化（之前資料儲存於記憶體，滿足一定條件後上報，不成功則儲存於資料庫，這樣會有資料丟失風險）
Analytics SDK（參考自神策SDK原始碼）
基於新的採集協議，重構埋點文件，使埋點更完善方便。
優點
- 獨立的SDK，業務邏輯清晰，方便整合。
- 報文格式和上報介面統一，更簡單。
- 上報欄位更豐富，擴充套件防作弊欄位。
- 加入一些自動化的統計，包括APP啟動、退出及相應時長統計，頁面PV及時長、各種控制元件點選事件等。
- 優化上報策略，保證資料的及時性。（啟動、退出、異常退出、自定義上報條數、自定義上報時間間隔、立即上報等）
- 支援H5的埋點統計。
- 各種配置更靈活，上報地址、滿足上報條數、兩次上報時間間隔等
全埋點
原理上主要分為兩種方式：
參考文件：
視覺化埋點
原理：通過視覺化的工具編輯配置可採集的view，APP獲取並解析配置，找到view並hook事件上報資料。（當介面結構發生變化時，圈選的元素可能會失效）
Sensorsdata ，包含了Android、iOS、js、JAVA等多個版本的SDK
Mixpanel ，包含了Android、iOS、js、JAVA等多個版本的SDK
網易移動端資料收集和分析部落格打通APP和H5埋點
H5收集到資料後通過js方法回撥到APP內，APP會加上基礎引數和公共引數，然後上報資料。神策內打通APP和H5的埋點參考 連結 。
獨立SDK地址參見 git地址