一、什麼是事件？

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

• 什麼是事件
  • 追蹤或記錄的使用者行為或業務過程（註冊賬號，登入，觀看視訊，點贊，評論，關注等等）
  • 事件三要素
    • 操作（action):定義一個操作動作（如點選、拖拽）
    • 引數/屬性：引數可以是任何和這個事件相關的屬性，包括觸發這個事件的（人、時間、地點、裝置、操作的業務資訊）
      • 舉例：
        • 對於一個“購買”型別的事件，則可能需要記錄的欄位有：商品名稱、商品型別、購買數量、購買金額、 付款方式等；
        • 對於一個“搜尋”型別的事件，則可能需要記錄的欄位有：搜尋關鍵詞、搜尋型別等
        • 對於一個“點選”型別的事件，則可能需要記錄的欄位有：點選 URL、點選 title、點選位置等
        • 對於一個“使用者註冊”型別的事件，則可能需要記錄的欄位有：註冊渠道、註冊邀請碼等
        • 對於一個“使用者投訴”型別的事件，則可能需要記錄的欄位有：投訴內容、投訴物件、投訴渠道、投訴方式等
        • 對於一個“申請退貨”型別的事件，則可能需要記錄的欄位有：退貨金額、退貨原因、退貨方式等。
    • 屬性值：引數/屬性的值參

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

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

二、埋點

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

1. 程式碼埋點(客戶端)

• 原理

  • 要統計某頁面一個Button點選事件次數。首先在APP或者介面初始化的時候，初始化埋點SDK，然後在這個Button事件發生時就呼叫SDK裡面相應的方法，傳送介面傳送資料
  • App端為了避免浪費使用者的流量，一般情況下，都是將多條資料打包，並且等待網路狀況良好以及應用處於前臺時才壓縮上傳

• 優點

  • 控制精準: 可以非常精確地選擇什麼時候傳送資料
  • 自定義：隨意自定義屬性、自定義事件

• 不足

  • 人力成本高

    埋點地方過多，因為不同的版本驗證問題不同不易於管理。每一個控制元件的埋點都需要新增相應的手工程式碼，不僅工作量大，而且限定了必須是技術人員才能完成
    + 版本更新的代價大，易造成埋點混亂
    > 每一次更新埋點方案，就意味著必須要修改程式碼，然後通過各個渠道進行分發，一旦有相當多數量的使用者對新版的更新不感冒時，導致埋點程式碼能夠採集到的資料也就得不到更新，前功盡棄,很難在實際日常運營中能夠及時依賴實時資料捕獲焦點做出應變
    + 資料傳輸的時效性和可靠性不好保證
    * 客戶端埋點的痛病
    + 支援的統計大多是簡單計數，無法完成完整的多維分析功能

• 應用場景和產品舉例

  • 場景：常用於簡單的pv統計，如網站pv、APP的DAU等巨集觀資料

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 資訊。

• 優點

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

• 不足

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

• 應用場景和產品

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

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

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

• 原理

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

• 優點

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

• 缺點

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

• 與視覺化埋點的區別

  • 視覺化埋點先通過介面配置哪些控制元件的操作資料需要收集
  • “無埋點”則是先儘可能收集所有的控制元件的操作資料，然後再通過介面配置哪些資料需要在系統裡面進行分析

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

• 原理

  • 在需要埋點/追蹤事件的地方（客戶端或服務端）,以規定的格式/規範/協議，把相關的事件屬性資訊以及相關欄位通過HTTP請求傳送到指定的接收伺服器

• 優點

  • 實時傳送資料，不存在資料延時
  • 將線上和線下行為聯絡在一起
  • 可同時從客戶端和伺服器傳送資料

• 缺點

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

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

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

  • 視覺化埋點與無埋點只能採集到使用者在某時某刻點選了去結算
  • 客戶端單程式碼埋點能採集到去結算訂單的金額，商品名稱、使用者等級等客戶端可以獲取的資訊
  • 服務端程式碼埋點可以採集到商品庫存、成本等其他關聯的資訊

• 總結：

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

    資料可回溯是指當上新的事件埋點統計後，支援對歷史資料（埋點之前的日期）的統計，且不用回滾資料

6. 我們的選擇

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

B、參考Measurement Protocol資料採集和傳送規範，根據業務定製化埋點

三、參考：