移動應用要如何埋點上傳才能收集更多數據？
【 作者簡介：刈刀（ 程君杰 ） ， 曾就職于阿里巴巴移動事業部，數據技術專家。主要負責業務數據分析挖掘系統架構和設計，包括大規模數據采集、分析處理、數據挖掘、數據可視化、高性能數據服務等。】
1.簡介
最近同事在總結關于業界各種埋點技術，在此基礎上，結合之前我的一些經驗和想法，講講數據的生產和采集。
很早之前，也就是當年的PC時代，由于受限于存儲和計算能力， 大家一般很少用日志來分析業務。 而是在業務邏輯里，將業務需要分析的數據事先寫入到庫里， 針對庫的數據進行統計分析。 所以之前做OLAP， 需要很高級的硬件支持， 大家都去IOE等買昂貴的服務器來做數據倉庫以及進行數據分析。 由于成本的問題， 我們拿到的數據是很少的， 所以進行統計分析和挖掘所得到的收益微乎其微。
隨著 Hadoop 的興起， 分布式文件系統和分布式計算大大降低了存儲成本和計算成本， 使得我們現在用日志分析業務成為了可能。
2.數據
對于移動端的App來說， 分析的數據大致上都可以分為倆種， 一種是 在線數據 ，一種是 離線數據 。 在線數據， 即App后端服務所產生的日志數據，例如服務接口的性能數據， 服務接口的調用及其參數等， 通過服務端的日志數據， 我們不但可以統計服務接口的性能指標，還可以針對具體的業務邏輯，做相關的分析，一些常見的App分析指標如新增，活躍，累計，留存等，也都可以通過服務日志來統計出來。
對應的離線數據即是App客戶端本身產生的數據， 這種情況一般是發生在客戶端不調用底層服務的情況下，需要了解用戶在客戶端的行為，就需要用到離線數據。 離線日志一般記錄用戶在客戶端的具體行為，如用戶在客戶端的拖動，上下滾動，翻頁等不涉及到后端服務的操作，以及App本身的崩潰行為產生的數據， 都可以被記錄， 一般的，記錄的內容包括事件類型，控件編號，控件屬性及相關參數，事件時間等。
3.在線日志
在線日志，一般來講，有兩種：
- web 服務器的配置化log(如Nginx, apache等web服務器的access.log) 這一類日志不需要用戶自己做實現， 只需要開啟web服務器的相關日志功能，即可完成日志記錄。
- 應用服務器的log 一般包括應用服務器的配置化log 以及 用戶自定義的log。 用戶自定義log包括用戶通過相關日志組件自己的debug, waring ,error, info等級別的日志。 這一類日志沒有固定的格式，完全有用戶自行控制。在線日志一般會伴隨業務直接產生在相關的業務服務器上(web服務器日志產生在web服務器上)，但是有的時候，為了將相關服務的監控日志與業務分析日志分離，會將業務日志直接記錄在一臺獨立的日志服務器上。
4.離線日志
離線日志，一般也有兩種：
- 客戶端的行為日志 ：用戶在操作App的時候，產生的行為，都可以記錄下來。 行為日志一般是用來研究用戶使用習慣， 分析應用的使用熱度的。 同時可以結合客戶端異常日志來分析異常原因。
- 客戶端的異常日志： 用來監控客戶端異常原因， 幫助解決相關問題。
5.埋點及上傳
不管是在線日志，還是離線日志，我們首先都要確認 在什么地方記錄日志 ， 于是我們就引入了 埋點 的概念。 通俗的講，在正常業務代碼邏輯上， 添加記錄日志的代碼， 都叫做埋點。 但是一般的，埋點只用來描述客戶端日志記錄。
由于在線日志是直接產生在服務器端， 日志采集工具可以直接從含有日志的服務器上采集日志數據到相應的文件系統， 所以不存在日志上傳的問題。但是對于離線日志來說， 數據是產生在客戶端的， 所以上傳機制必須考慮。
6.離線日志上傳機制
業界采用的離線日志上傳機制如下:
- 服務端提供日志記錄接口，當客戶端有事件時，直接調用日志記錄接口將日志記錄在服務器端。
- 服務端提供日志上傳接口， 客戶端先將日志暫存客戶端本地，當達到一定的大小，網絡環境允許的情況下， 通過上傳接口，將日志文件打包壓縮后上傳。
第一種上傳方式， 時效性方面有一定的保障 ， 在網絡環境允許的情況下，能及時的將信息記錄到服務器， 但是當埋點較多時，記錄日志產生的流量會很大 ，占據很大的帶寬，給用戶帶來損失。 同時， 前端的某些行為，如在某個activity停留時間等也無法通過這種在線的方式捕獲。 還有一個重要的問題是， 由于客戶端數據沒有暫存機制， 當網絡暫時無法使用時， 日志記錄接口無法正常調用， 所有的日志也就隨之丟失。 第二種方式， 在時效性上較差 ，因為它需要等待數據累計到一定程度，或者網絡允許的情況下，如在wifi情況下，才發送， 但是占用的帶寬相對較小， 對客戶端動作的捕獲較為靈活。
7.埋點的三種方案
1 、傳統埋點：
開發者直接在客戶端埋點
- 優點： 開發者可以隨意的在任何地方添加埋點。
- 缺點： 成本高，每次埋點的增刪改都需要發版，很難控制。啟明星現在采用的就是傳統的埋點方式， 由于之前沒有統一的規劃， 相關頁面的同一個按鈕，不同的版本功能不同， 但卻埋了同一個點， 造成統計比較混亂。之后我們引入了埋點下發平臺，雖然一定程度上緩解了這種問題，但是由于其靈活性以及主觀性， 問題依然無法避免。
2、可視化埋點
由于傳統埋點的一系列問題， 自然而然的就產生了可視化埋點的方案， 用可視化交互的手段來代替寫代碼，將核心代碼和配置，資源分開， 在App啟動是通過網絡更新配置和資源來實現埋點功能。
可視化埋點的大體流程如下：
- 首先埋點服務平臺與埋點客戶機做關聯， 包括客戶機包含的埋點模塊掃描當前整個客戶端頁面的控件，形成控件樹，并將當前頁面截圖，發送給埋點服務端平臺；
- 埋點服務端平臺接收到截圖和控件樹數據后，在服務端重新繪制App界面，通過可視化交互的方式，給當前頁面需要埋點的控件上添加事件，添加完畢后，形成配置文件， 并發布上線；
- 裝有埋點模塊的所有客戶端，接收到配置文件并解析， 根據配置為頁面中相關的控件添加監聽事件， 當這些控件出發事件時記錄日志。
其中有很多細節的地方需要注意：
- 可視化埋點也需要考慮不同版本之間埋點的差異；
- 可視化埋點在分發埋點配置文件的時候，會有延遲或者丟失的情況， 有的客戶端有可能收不到或者很久才能收到配置文件，這樣埋點的時效性會大打折扣。
3 、無埋點
所謂的無埋點，其實也就是全埋點， 它和可視化埋點很像， 可視化埋點是根據埋點配置來收集數據，而無埋點方案則是盡可能的收集所有控件的操作數據。 實現原理也很簡單， 客戶端添加掃描代碼， 為每個掃描到的控件添加監聽事件。 當事件被觸發后，記錄日志。
其實我想，大家對此也不陌生，比如很早之前，對PC站點的統計， 各大分析平臺，都需要在網頁<head></head>之間添加一段js代碼。 其實那段js代碼， 就是我們現在提到的無埋點的掃描代碼。
這里強調一下， 由于可視化埋點是在需要的時候才埋點， 所以它并不能回溯事件，也就是說，我們只能統計需求提出后，埋點開始的所有的數據，埋點之前的數據我們是拿不到的。 而無埋點方案， 在開始埋點的時候，所有的數據已經都被記錄了， 所以它可以查看之前的數據 (這里的之前也是相對與提統計需求的時間，而不是相對于埋點的時間)， 也就是說它可以做回溯。 而這種回溯是建立在大量存儲要求的基礎上的。
8.總結
不管是哪種解決方案，我們的目的只有一條，就是盡可能多的收集需要的數據， 所以在實際操作過程中， 我們可以根據具體情況，多種方案相結合使用。
來自：https://www.sdk.cn/news/4919