資料採集與埋點簡介之 程式碼埋點、視覺化埋點與無痕埋點
博主做移動手機系統中的資料採集與埋點也有近兩年，那段時間內一方面是集中在具體的開發和問題細節處理，另外一方面則是在把採集系統適配到不同的平臺手機、平板、tv、車載的過程中，有Android和C++兩個版本。有一天見到了“神策資料”的這篇博文，發現總結得太好了，有點相見恨晚的感覺。這篇文章裡面闡述了一下資料採集的一些基本概念，介紹了一下程式碼埋點、視覺化埋點、無痕埋點，後端埋點，並根據這幾種埋點的適用場景闡述了一下博主的深刻的理解和認識。
1. 資料採集是核心問題
一個典型的資料平臺，對於資料的處理，是由如下的5個步驟組成的：
其中，我們認為，第一個步驟，也即資料採集是最核心的問題。資料採集是否豐富，採集的資料是否準確，採集是否及時，都直接影響整個資料平臺的應用的效果。
在我們手冊的典型場景的資料接入方案中，我們已經闡述了使用 Sensors Analytics 時，在確定資料採集方案時應該遵循的兩個基本原則：
- 優先在後端收集資料；
- 屬性儘可能採集全面。
雖然我們之前已經詳細描述過前端埋點的一些問題。例如，需要等待網路情況良好才能傳送資料，需要積攢一定的量才傳送資料，需要在本地暫存而本地暫存空間有限等一系列在資料傳輸性和資料可靠性上的一些問題。但是，前端埋點畢竟有一些後端採集資料所無法替代的地方，例如，分析前端介面設計是否合理，分析一些在與後端沒有互動的前端行為等，還是必須採用前端埋點方案的。前端埋點作為一個比較成熟並且被廣泛採用的資料接入手段，Sensors Analytics 也提供了一系列相應的解決方案。因此，在這裡，我們覺得有必要詳細介紹一下目前市面上主流的前端埋點方案的技術細節，並且結合我們的產品，來闡述我們對於這些埋點方案的一些看法。
2. 前端埋點技術介紹
目前常見的前端埋點技術，有三類：在某個控制元件操作發生時通過預先寫好的程式碼來發資料的程式碼埋點；通過視覺化介面配置控制元件操作與事件發生關係的視覺化埋點；先收集所有資料再在後端篩選需要分析的物件的“無埋點”。
下面，我們分別對這三種方案進行介紹，然後再闡述我們的觀點。
2.1 程式碼埋點
程式碼埋點出現的時間很早了，在 Google Analytics 年代，就已經出現了類似的方案了。目前，國內的主要第三方資料分析服務商，如百度統計、友盟、TalkingData 等都提供了這一方案。Sensors Analytics 也一樣提供了 iOS、Android、Web 等主流平臺的程式碼埋點方案。
它的技術原理也很簡單，在APP或者介面初始化的時候，初始化第三方資料分析服務商的SDK，然後在某個事件發生時就呼叫SDK裡面相應的資料傳送介面傳送資料。例如，我們想統計APP裡面某個按鈕的點選次數，則在APP的某個按鈕被點選時，可以在這個按鈕對應的 OnClick 函式裡面呼叫SDK提供的資料傳送介面來發送資料。
下面，我們看友盟提供的兩個例子。
第一個例子是在使用者的某個 Android APP 裡面，統計某個由 Activity 構成的頁面的訪問次數，下面是友盟官方給出的例子：
public void onResume() {
super.onResume();
MobclickAgent.onPageStart("SplashScreen"); //統計頁面(僅有Activity的應用中SDK自動呼叫，不需要單獨寫。"SplashScreen"為頁面名稱，可自定義)
MobclickAgent.onResume(this); //統計時長
}
public void onPause() {
super.onPause();
MobclickAgent.onPageEnd("SplashScreen"); // （僅有Activity的應用中SDK自動呼叫，不需要單獨寫）保證 onPageEnd 在onPause 之前呼叫,因為 onPause 中會儲存資訊。"SplashScreen"為頁面名稱，可自定義
MobclickAgent.onPause(this);
}
這個例子其實非常簡單，就是在 Activity 控制元件相應的觸發器函式裡面，呼叫友盟提供的介面統計資料即可。
第二個例子稍微複雜點，它不再是統計頁面訪問這樣一個預設的事件，而是統計一個自定義事件。例如，一個電商APP，在使用者點選“購買”按鈕時，想統計“購買”這個自定義事件的相應資訊，那麼，可以使用下面的程式碼：
HashMap<String,String> map = new HashMap<String,String>();
map.put("type","book");
map.put("quantity","3");
MobclickAgent.onEvent(mContext, "purchase", map);
必須說明的是，友盟歸根結底還是一個統計工具，並沒有提供完整的多維分析功能，姑且不算資料傳輸的時效性以及對自定義屬性上的各種限制，僅僅是為了統計某個數值，友盟還要單獨區分出“計數事件”和“計算事件”，這一點上，就遠遠不如 Sensors Analytics 的靈活了。
從上面這兩個例子可以看出，程式碼埋點的優點是一方面使用者控制精準，可以非常精確地選擇什麼時候傳送資料；同時使用者可以比較方便地設定自定義屬性、自定義事件，傳遞比較豐富的資料到服務端。
當然，程式碼埋點也有一些劣勢。首先，埋點代價比較大，每一個控制元件的埋點都需要新增相應的程式碼，不僅工作量大，而且限定了必須是技術人員才能完成；其次是更新的代價比較大，每一次更新埋點方案，都必須改程式碼，然後通過各個應用市場進行分發，並且總會有相當多數量的使用者不喜歡更新APP，這樣埋點程式碼也就得不到更新了；最後，就是所有前端埋點方案都會面臨的資料傳輸時效性和可靠性的問題了，這個問題就只能通過在後端收集資料來解決了。
2.2 視覺化埋點
從前端埋點到視覺化埋點其實是一個非常順理成章的演進。既然埋點代價大，每一個埋點都需要寫程式碼，那麼，就參考 Visual Studio 等一系列現代 IDE 的做法，用視覺化互動手段來代替寫程式碼即可；既然每次埋點更新都需要等待APP的更新，那麼，就參考現在很多手遊的做法，把核心程式碼和配置、資源分開，在APP啟動的時候通過網路更新配置和資源即可。
正是出於這種自然而然的做法，在國外，以 Mixpanel 為首的資料分析服務商，都相繼提供了視覺化埋點的方案，Mixpanel將之稱作為 codeless。而國內的 TalkingData、諸葛IO 等也都提供了類似的技術手段。 順帶一提，Sensors Analytics 在1.3版本的更新中，也已經給使用者提供視覺化埋點方案，以降低使用者的資料接入成本。
特別需要強調的是，Mixpanel 非常無私地開源了它們的iOS 和 Android 端的 SDK 的原始碼，我們在開發中也參考了它們的貢獻，並且也貢獻了一些 bug 的提交，非常感謝 Mixpanel 對整個領域的貢獻。
2.2.1 iOS 和 Android 平臺的視覺化埋點
下圖是演示一個簡單的 iOS SDK 使用 Mixpanel 的 codeless 埋點功能：
從這個介面可以看出，使用起來還是非常簡單的，點選某個支援的控制元件型別的例項，這個例子中是右上角的重新整理按鈕，然後在彈出的視窗中，設定點選這個按鈕是傳送 “Refresh” 事件。然後點選 Deploy 按鈕，把這個配置下發下去。那麼，所有安裝有嵌入了 Mixpanel 的 SDK 的這個 APP ，則都會在 APP 啟動時或者定時獲取相應的配置。以後，真實的使用者使用時，點選這個按鈕，就會真正地傳送 “Refresh” 事件到後端了。
下面我們以 iOS 端為例，進一步闡述視覺化埋點的實現細節。
在嵌入了 SDK 的 APP 開啟視覺化埋點模式，與後端聯通時，SDK 會應後端的要求，定期（例如每秒）做一次截圖，而 SDK 在為 App 截圖的同時，會從 keyWindow 物件開始進行遍歷它的subviews()，得到當前檢視下所有 UIView、UIResponder 物件的層級關係。對於螢幕上的任何一個UIView物件，如 Button、Textfield 等，它都有一條唯一的從 keyWindow 到它的路徑，這個路徑上每個節點，都由 ClassName、它是父節點的第幾個subview、.text()等屬性的值等標識。相對於父節點的座標、長寬高等視覺化方面的資訊，是作為這個節點的屬性存在。
服務端根據截圖和視覺化資訊來重新進行頁面渲染，並且根據控制元件的型別，來識別哪些控制元件是可以增加可埋點的，並且將之標識出來。
當使用者在後臺的截圖畫面上點選了某個可埋點的控制元件時，後臺會要求使用者做一些事件關聯方面的配置，並且將配置資訊進行儲存和部署。
SDK 在啟動或者例行輪詢時拿到這些配置資訊，則會通過.addTarget:action:forControlEvents:介面，為每個關聯的控制元件新增的點選或者編輯行為的監聽，並且在回掉函式裡面呼叫 Sensors Analytics SDK 的介面傳送相應事件的 track 資訊。
整個 iOS 端的埋點的流程圖，如下圖所示：
Android 端的視覺化埋點方案，與 iOS 端基本一致。
必須說明的是，上面描述的這一套視覺化埋點的配置方案，其實也可以讓開發者在 iOS 或者 Android 的視覺化 IDE 裡面完成，但是考慮到視覺化埋點主要面臨的是非技術人員，所以最終業內都採用了 Mixpanel 的這種後臺截圖操作的方案。
2.2.2 Web 端的視覺化埋點
Mixpanel 沒有提供 Web 端的視覺化埋點方案，在這裡，我們以 Sensors Analytics 的 Web 端視覺化埋點方案來舉例：
使用者在自己的網頁引入 Sensors Analytics 的 JavaScript SDK 程式碼後，從 Sensors Analytics 的後臺視覺化埋點管理介面跳轉到使用者的網站介面時，會自動進入到視覺化埋點模式。在這個模式下，使用者在網頁上點選任意 html元素時，Sensors Analytics 都會取到這個元素的url，層級關係等資訊來描述這個 html 元素，當使用者設定了這個元素和某個事件相關聯時，SDK 會把這些關聯資訊和客戶生成配置資訊，並且存放在 Sensors Analytics 提供的相應儲存位置。當真正的使用者以普通模式訪問這個網頁時，SDK 會自動載入配置資訊，從而在相應的元素被點選時，使用 Sensors Analytics 的資料傳送介面來 track 事件。
從上面我們介紹的視覺化埋點的方案可以看出，視覺化埋點很好地解決了程式碼埋點的埋點代價大和更新代價大兩個問題。但是，視覺化埋點能夠覆蓋的功能有限，目前並不是所有的控制元件操作都可以通過這種方案進行定製；同時，Mixpanel 為首的視覺化埋點方案是不能自己設定屬性的，例如，一個介面上有一個文字框和一個按鈕，通過視覺化埋點設定點選按鈕為一個“提交”事件時，並不能將文字框的內容作為事件的屬性進行上傳的，因此，對於視覺化埋點這種方案，在上傳事件時，就只能上傳 SDK 自動收集的裝置、地域、網路等預設屬性，以及一些通過程式碼設定的全域性公共屬性了；最後，作為前端埋點的一種方案，視覺化埋點也依然沒有解決傳輸時效性和資料可靠性的問題。
附帶一提，雖然 Mixpanel 比較早就推出了視覺化埋點方案，但是卻一直沒有重點宣傳，並且也並不是它們的推薦資料接入方案，這種做法也是與 Mixpanel 一直強調的 "Actions speak louder than page views." 是一致的。
2.3 “無埋點”
與視覺化埋點一樣，“無埋點”這個方案也出來的比較早，Heap作為一個第三方資料分析服務商，在2013年就已經推出了“無埋點”這個技術方案。而如果不侷限於第三方，百度在2009年就已經有了“點選猴子”這個技術，用無埋點的方案分析一個頁面各個元素的點選情況；在2011年，百度質量部也推出了一項內部服務，用以錄製安卓 App 的全部操作，並且進行回放，以便找出 App 崩潰的原因；而豌豆莢大約也在2013年左右，在自己的 App 內部，添加了對所有控制元件的操作情況的記錄。第三方資料分析服務GrowingIO 在2015年，也推出了類似於 Heap 的服務。
下圖是一個使用 Heap 的例子：
從介面上看，和視覺化埋點很像。而從實際的實現上看，二者的區別就是視覺化埋點先通過介面配置哪些控制元件的操作資料需要收集；“無埋點”則是先儘可能收集所有的控制元件的操作資料，然後再通過介面配置哪些資料需要在系統裡面進行分析。
“無埋點”相比視覺化埋點的優點，一方面是解決了資料“回溯”的問題，例如，在某一天，突然想增加某個控制元件的點選的分析，如果是視覺化埋點方案，則只能從這一時刻向後收集資料，而如果是“無埋點”，則從部署 SDK 的時候資料就一直都在收集了；另一方面，“無埋點”方案也可以自動獲取很多啟發性的資訊，例如，“無埋點”可以告訴使用者這個介面上每個控制元件分別被點選的概率是多大，哪些控制元件值得做更進一步的分析等等。
當然，與視覺化埋點一樣，“無埋點”依然沒有解決覆蓋的功能優先，不能靈活地自定義屬性，傳輸時效性和資料可靠性欠佳這幾個缺點。甚至由於所有的控制元件事件都全部蒐集，反而會給伺服器和網路傳輸帶來更大的負載。
2.4 各種不同採集方案的資料獲取能力的對比
在前面，我們已經介紹了程式碼埋點、視覺化埋點、“無埋點”三種前端埋點方案，而也強調了我們一直推薦在後端採集資料。因此，在這裡，我們覺得有必要比較一些視覺化埋點、程式碼埋點與後端採集資料三種方案在資料獲取能力上的差異，“無埋點”的資料獲取能力與視覺化埋點基本相當，在這裡不再單獨羅列。
我們以京東的一個訂單提交頁面為例來進行對比：
對於視覺化埋點，在這個地方，基本只能採集到某時某刻某人提交了一個訂單；對於前端程式碼埋點，則還能拿到訂單金額、商品名稱、使用者級別等在前端有記錄的一些資訊；而如果在後端接入資料，則還能拿到商品庫存、商品成本、使用者風險級別等只在後端有記錄的一些資訊。
由此可以看出，視覺化埋點雖然使用和部署比較簡單，但是在資料獲取能力上相比程式碼埋點還有一定的劣勢；而前端埋點天然的劣勢，則是拿不到在前端不儲存的資訊。這也是為什麼，我們一直推崇後端資料採集資料這一方案的重要原因。
3. 我們的觀點
Sensors Analytics 一貫認為，資料採集是構建資料平臺的核心要素。為了方便使用者採集資料，我們完全開放了全功能的資料接入 API，基於 API 封裝了程式碼埋點和視覺化埋點兩種前端接入方案，並且提供了 PHP、Java、Python 等常見後端語言的 SDK 以方便在後端接入資料，同時，為了滿足使用者匯入已有檔案或者格式化資料的需要，我們也封裝了 LogAgent、BatchImporter、FormatImporter 等各式匯入工具。同時為了降低使用者的安全方面的疑慮，並且回饋業內，我們的相關 SDK 的程式碼也在github上全部開源，視覺化埋點的具體實現的程式碼會隨著1.3版本的釋出 release，敬請期待。
我們認為，並不存在某種普遍完美的可以適應一切場景的資料接入方案，而是應該根據不同的產品，不同的分析需求，不同的系統架構，不同的使用場景，選擇最合適的一種接入方案。下面是一些典型的例子：
- 僅僅是分析UV、PV、點選量等基本指標，可以選擇程式碼埋點或者視覺化埋點等前端埋點方案；
- 精細化分析核心轉化流程，則可能需要利用後端 SDK 或者 LogAgent 接入後端日誌；
- 活動/新功能快速上線迭代時的效果評估，則可以利用視覺化埋點快速完成；
- 對客服服務質量的考核，或者不同快遞在不同省份運送不同品類產品的速度的比較，則需要使用後端 SDK 來對接第三方系統以便匯入資料。
一個產品首次使用 Sensors Analytics 時，初期採用視覺化埋點方案，快速完成部署，以便快速評估分析效果，做出快速決策；而對視覺化埋點得到的資料，在分析解讀後，再針對性地逐步採用其它資料採集方案，獲取更詳盡、更全面的資料分析結果。