用戶行為的深度追蹤——事件與埋點

一、什么是事件？

不同於傳統的頁面路徑跳轉追蹤，事件嘗試追蹤用戶在網站或APP上發生的每一個動作（包括瀏覽頁面）

• 什么是事件

  • 追蹤或記錄的用戶行為或業務過程（注冊賬號，登錄，觀看視頻，點贊，評論，關注等等）

  • 事件三要素

    • 操作（action):定義一個操作動作（如點擊、拖拽）
    • 參數/屬性：參數可以是任何和這個事件相關的屬性，包括觸發這個事件的（人、時間、地點、設備、操作的業務信息）
      • 舉例：
        • 對於一個“購買”類型的事件，則可能需要記錄的字段有：商品名稱、商品類型、購買數量、購買金額、 付款方式等；
        • 對於一個“搜索”類型的事件，則可能需要記錄的字段有：搜索關鍵詞、搜索類型等
        • 對於一個“點擊”類型的事件，則可能需要記錄的字段有：點擊 URL、點擊 title、點擊位置等
        • 對於一個“用戶注冊”類型的事件，則可能需要記錄的字段有：注冊渠道、注冊邀請碼等
        • 對於一個“用戶投訴”類型的事件，則可能需要記錄的字段有：投訴內容、投訴對象、投訴渠道、投訴方式等
        • 對於一個“申請退貨”類型的事件，則可能需要記錄的字段有：退貨金額、退貨原因、退貨方式等。

    • 屬性值：參數/屬性的值參

      • 舉例： 參數和值以kv形式存儲在json串中

          {"age": 13, "gender": "male", "photo filetype": "png"}

---

二、埋點

目前的埋點方式：
按埋點工具：代碼埋點、可視化埋點、‘無埋點’
按埋點位置：前段/客戶單埋點、后端/服務端埋點

1. 代碼埋點(客戶端)

• 原理

  • 要統計某頁面一個Button點擊事件次數。首先在APP或者界面初始化的時候，初始化埋點SDK，然后在這個Button事件發生時就調用SDK里面相應的方法，發送接口發送數據
  • App端為了避免浪費用戶的流量，一般情況下，都是將多條數據打包，並且等待網絡狀況良好以及應用處於前台時才壓縮上傳

• 優點

  • 控制精准: 可以非常精確地選擇什么時候發送數據
  • 自定義：隨意自定義屬性、自定義事件

• 不足

  • 人力成本高

    埋點地方過多，因為不同的版本驗證問題不同不易於管理。每一個控件的埋點都需要添加相應的手工代碼，不僅工作量大，而且限定了必須是技術人員才能完成

  • 版本更新的代價大，易造成埋點混亂

    每一次更新埋點方案，就意味着必須要修改代碼，然后通過各個渠道進行分發，一旦有相當多數量的用戶對新版的更新不感冒時，導致埋點代碼能夠采集到的數據也就得不到更新，前功盡棄,很難在實際日常運營中能夠及時依賴實時數據捕獲焦點做出應變

  • 數據傳輸的時效性和可靠性不好保證
    • 客戶端埋點的痛病
  • 支持的統計大多是簡單計數，無法完成完整的多維分析功能

• 應用場景和產品舉例

  • 場景：常用於簡單的pv統計，如網站pv、APP的DAU等宏觀數據
  • 第三方產品：umeng TalkingData Google Analytics

---

2. 可視化埋點（客戶端）

• 原理
  • 參考手游APP的做法，把核心代碼和配置、資源分開，在APP啟動的時候通過網絡更新配置和資源
  • 在虛擬的可視化界面，對支持的控件類型的實例，點擊配置事件(event)，然后發布，配置通過后端接口直接下發給APP，所有安裝有嵌入SDK的APP都會在啟動時或者定時獲取相應的配置。以后，真實的用戶使用時，點擊這個按鈕，就會發送事件到后端
  • 實現細節：
    1. 在嵌入了SDK的APP開啟可視化埋點模式，與后端聯通時，SDK會應后端的要求，定期（例如每秒）做一次截圖，而SDK在為App截圖的同時，會從keyWindow對象開始進行遍歷它的subviews()，得到當前視圖下所有 UIView、UIResponder對象的層級關系。對於屏幕上的任何一個UIView對象，如 Button、Textfield等它都有一條唯一的從keyWindow到它的路徑，這個路徑上每個節點，都由ClassName、它是父節點的第幾個subview、.text()等屬性的值等標識。相對於父節點的坐標、長寬高等可視化方面的信息，是作為這個節點的屬性存在。
    2. 服務端根據截屏和可視化信息來重新進行頁面渲染，並且根據控件的類型，來識別哪些控件是可以增加可埋點的，並且將之標識出來。
    3. 當使用者在后台的截屏畫面上點擊了某個可埋點的控件時，后台會要求使用者做一些事件關聯方面的配置，並且將配置信息進行保存和部署。
    4. SDK 在啟動或者例行輪詢時拿到這些配置信息，則會通過.addTarget:action:forControlEvents:接口，為每個關聯的控件添加的點擊或者編輯行為的監聽，並且在回掉函數里面調用 Sensors Analytics SDK 的接口發送相應事件的 track 信息。

event.png

• 優點

  • 可視化埋點很好地解決了代碼埋點的埋點代價大和更新代價大兩個問題。
  • • 新增埋點在所有版本生效，不存在老版本迭代問題（只要老版本app有嵌入sdk)
  • 不懂代碼的產品運營人員也可以通過后台可視化界面配置統計埋點並實時下發到客戶端生效

• 不足

  • 可視化埋點能夠覆蓋的功能有限的，目前並不是所有的控件操作都可以通過這種方案進行定制
  • 不能自定義設置事件屬性
    • 例如對於評論“提交”事件，並不能將評論的內容作為事件的屬性進行上傳
    • 在上傳事件時，就只能上傳SDK自動收集的設備、地域、網絡等默認屬性，以及一些通過代碼設置的全局公共屬性了
  • 數據傳輸的時效性和可靠性不好保證
    • 客戶端埋點的痛病

• 應用場景和產品

  • 場景：
    • 替代代碼埋點，支持產品、運營等非技術人員管理埋點
    • 活動/新功能快速上線迭代時的效果評估，可利用可視化埋點快速完成
  • 第三方產品： 諸葛io MixPanel 神策數據

---

3. 無埋點（全埋點）（客戶端）

Heap Analytics 作為最早提出這種方案提供商,早在2013年就已經推出了“無埋點”這個技術方案。后續的用戶行為分析的大佬Mixpanel也在去年中期推出同樣的服務，諸葛IO也借鑒了兩者，在國內最早正式推出了三大平台的無埋點分析方案，同時，國內也還有TalkingData的靈動分析和Growing IO提供了無埋點分析解決方案

• 原理

  • 在App中嵌入SDK，做統一的“全埋點”，將APP的操作盡量多的采集下來，然后通過界面配置的方式對關鍵行為進行定義，這樣便完成了所謂的“無埋點”數據采集
    1. 事先在產品上埋一個 SDK
    2. 通過可視化的方式，生成配置信息，也就是事件名稱之類的定義
    3. 將采集的數據按照配置重命名，進而就能做分析了

• 優點

  • 解決了數據“回溯”的問題
    • 例如，在某一天，突然想增加某個控件的點擊的分析，如果是可視化埋點方案，則只能從這一時刻向后收集數據，而如果是“無埋點”，則從部署 SDK 的時候數據就一直都在收集了
  • “無埋點”方案也可以自動獲取很多啟發性的信息，例如，“無埋點”可以告訴使用者這個界面上每個控件分別被點擊的概率是多大，哪些控件值得做更進一步的分析等等

• 缺點

  • 與可視化埋點一樣，“無埋點”依然沒有解決覆蓋的操作有限問題，不能靈活地自定義屬性
  • 數據傳輸的時效性和可靠性不好保證
    • 客戶端埋點的痛病
  • 由於所有的控件事件都全部搜集，可能會給服務器和網絡傳輸帶來更大的負載

• 與可視化埋點的區別

  • 可視化埋點先通過界面配置哪些控件的操作數據需要收集
  • “無埋點”則是先盡可能收集所有的控件的操作數據，然后再通過界面配置哪些數據需要在系統里面進行分析

• 應用場景和產品

  • 場景：和可視化埋點相同
  • 第三方產品：Heap Analytics Growing IO

---

4. Google Measurement Protocol

上述的三種埋點都是在客戶端埋點，都需要客戶端嵌入sdk
為避免浪費用戶流量，都需要定時或定量的批量打包發送數據

• 原理

  • 在需要埋點/追蹤事件的地方（客戶端或服務端）,以規定的格式/規范/協議，把相關的事件屬性信息以及相關字段通過HTTP請求發送到指定的接收服務器

• 優點

  • 實時發送數據，不存在數據延時
  • 將線上和線下行為聯系在一起
  • 可同時從客戶端和服務器發送數據

• 缺點

  • 需要手動在代碼中埋點
  • 考慮到用戶流量消耗問題，不可能把所有的用戶事件都埋點
  • 新的埋點需要發新版

---

5. 幾種埋點的典型使用場景對比

• 舉例：以電商APP的訂單結算頁面為例，當用戶點擊去結算按鈕

  • 可視化埋點與無埋點只能采集到用戶在某時某刻點擊了去結算
  • 客戶端單代碼埋點能采集到去結算訂單的金額，商品名稱、用戶等級等客戶端可以獲取的信息
  • 服務端代碼埋點可以采集到商品庫存、成本等其他關聯的信息

• 總結：

  • 可視化埋點使用和部署比較簡單，但數據獲取能力有限
  • 客戶端代碼埋點埋點復雜，能拿到在客戶端保存的信息
  • 服務端代碼埋點能獲取到事件以外的關聯屬性，但部署會影響線上業務代碼邏輯和架構，對於這種外圍信息，建議離線做join完成

埋點方式	數據時效	數據可靠(安全)	數據可回溯	埋點成本	對業務的影響	用戶流量開銷	新埋點是否對所有客戶端版本生效
傳統代碼埋點	X	X	X	X	X	X	X
可視化埋點	X	X	X	X	√	√	√
無埋點	X	X	X	√	√	√	√
Measurement Protocol	√	√	X	X	X	√	X

    數據可回溯是指當上新的事件埋點統計后，支持對歷史數據（埋點之前的日期）的統計，且不用回滾數據

---

6. 我們的選擇

A、可視化埋點/無埋點:
產品或技術對 活動/新功能快速上線迭代時的效果評估，可利用可視化埋點快速完成
具體采用哪種方案還要考慮客戶端代碼改動成本

B、參考Measurement Protocol數據采集和發送規范，根據業務定制化埋點

三、參考：

• 數據采集與埋點
• HEAP
• MIXPANEL
• 事件模型
• Google Measurement Protocol
• 埋點參數參考