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

1、什麼是事件？

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

• 什麼是事件

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

  • 事件三要素

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

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

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

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

---

2、埋點

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

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數據採集和發送規範，根據業務定製化埋點

3、參考：

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