前端-埋點-理念-通識-淺談

本文將所有以Q&A的形式來進行描述

Q1：爲何須要埋點？

1. 採集用戶瀏覽次數
2. 採集用戶交互行爲
3. 採集商品曝光...

先別管採集了什麼，重點就是採集二字

Q2： 採集來有什麼用啊？

1. 前端：上報用戶行爲啊！
2. 前端：產品說要這些啊！
3. 公司：服務於大數據業務！

思考埋點，不該從前端角度出發，但怎麼就和大數據業務扯上關係了呢？

Q3： 什麼是大數據業務？

• 上圖是一個標準的大數據業務的上下游
• 能夠看到數據採集是第一環節

但何時開始準備採集呢？

Q4：何時須要埋點？

1. 一款新產品規劃完成須要看數據時
2. 某個功能改版規劃完成須要看數據時
3. 想看兩個方案A\B對比數據時
4. 想看活動H5頁面數據時
5. 將內容投放到第三方但願看到引流效果時
6. 想看某個廣告位曝光數據時
7. 前端：產品要看隔壁老王昨天...

重點：

1. 埋點不該該是產品需求
2. 應該是前端的平常工做之一
3. no data no bb，不管是後期的覆盤，仍是明確業務價值，仍是用來反懟產品，都是一把神器

Q5：埋點該採集點什麼？

1. 前端：公司有現成的sdk，我只要知道api就好了啊
2. 前端：產品想啥姿式就啥姿式唄
3. 大數據：小朋友才作選擇，我全都要
   1. 數據採集是否豐富
   2. 採集的數據是否準確
   3. 採集是否及時

從大數據層面，對埋點數據的要求分爲

1. 基礎層（sdk來解決）
2. 業務層（基於sdk，由前端開發來解決）

ok，又來了一個概念sdk

Q6：什麼是sdk？

1. 就是一段js，沒什麼出奇的：

   1. 全局事件監聽
   2. 暴露一些方法，供業務方調用

2. 通常sdk的理論基礎：

   1. who：行爲背後的人，具備哪些屬性
   2. when：何時觸發的這個行爲？
   3. where：事件發生的地點，城市地區甚至GPS
   4. what：描述用戶所作的事件的具體內容
   5. How：用戶進行事件的方式

3. 通常sdk的採集內容：

   1. 頁面瀏覽數據
   2. 用戶點擊數據
   3. 頁面加載性能
   4. JS報錯
   5. 接口出錯上報
   6. 自定義測速

重點：SDK採集數據 = 用戶行爲數據 + 前端健康度分析

Q7：sdk還有分類？

埋點是基於sdk，那找個sdk一把梭不就行了嗎？

然而，並不行，由於平臺不用，sdk也不一樣，分爲：

1. Web
2. 移動端（IOS/Android）
3. 小程序（微信、支付寶、百度）
4. App第三方框架（RN,Flutter,Weex)

因此，想要埋仍是要case by case的去看，什麼業務平臺，用什麼sdk

Q8：那市面上有什麼現成的sdk嗎？

1. 自主研發（大公司的必經之路）
2. 百度統計（免費）
3. TalkingData（收費）
4. GrowingIo（全埋點）
5. Google Analytics（免費）
6. Mixpanel（可視化埋點）
7. 友盟（收費）
8. 神策（收費）

分析上面的產品，多了幾個關鍵詞：

1. 免費
   1. 功能不夠強大
   2. 或等着你買服務
2. 收費
   1. 全套解決方案
   2. 價格貴
3. 全埋點
4. 可視化埋點

爲何會有全埋點、可視化埋點這些分類呢？

這要從埋點存在的問題提及

Q9：埋點存在的問題？

埋點，最low也最簡單的方式，就是在代碼裏直接寫上埋點代碼，而後隨着時間，埋點問題就會爆發

1. 埋點代碼與業務代碼寫在一塊兒，若是埋點代碼遠多於業務代碼，形成閱讀困難
2. 埋點代碼書寫複雜，複雜度大於業務代碼，成爲開發者的一個大負擔。
3. 業務代碼改動後，埋點代碼也須要相應的改動
4. 埋點代碼不能支持新業務，須要新業務新增埋點

媽蛋，想一想都頭疼啊，不過仍是須要仔細思考一下，埋點的痛點是：

1. 代碼埋點工做量大
2. 埋點出錯致使的數據問題，修復週期長（須要發版）
3. 同一業務在多端多平臺狀況下容易發生埋點口徑不一致

Q10：埋點痛點的解決方案？

想要解決埋點痛點，須要從兩個方面入手：

1. 多埋點方案組合
2. 埋點平臺化、系統化

又來了新概念，多埋點方案是啥？埋不就好了，怎麼還要有這麼多方案？

Q11：那埋點究竟有多少種方案？

隨着時間的發展，埋點存在4種方案：

1. 代碼埋點
2. 可視化埋點
3. 無埋點
4. 後端埋點

Q12：什麼是代碼埋點？

1. 概念：所謂的代碼埋點就是在你須要統計數據的地方植入N行代碼，統計用戶的關鍵行爲。
2. 優勢：
   1. 使用者控制精準，能夠很是精確地選擇何時發送數據
   2. 使用者能夠比較方便地設置自定義屬性、自定義事件，傳遞比較豐富的數據到服務端。
3. 缺點：
   1. 埋點代價比較大
      • 每個控件的埋點都須要添加相應的代碼，不只工做量大，並且限定了必須是技術人員才能完成；
   2. 更新代價比較大
      • 每一次更新，都須要更新埋點方案，而後經過各個應用市場進行分發，並且有的用戶還不必定更新，這樣你就獲取不到這批用戶數據。
   3. 數據傳輸的實效性，網絡緣由
   4. 數據不可回溯

Q13：什麼是可視化埋點？

1. 概念：利用可視化交互手段，經過可視化界面配置控件操做與事件操做發生關係。

2. 優勢：

   1. 可視化埋點解決了代碼埋點埋點代價大的問題。
      1. 手動埋點到不侵入代碼
      2. 學習成本低
      3. 統一採集技術，提供標準化埋點實現
      4. 所配即所得
      5. 埋點流程簡化
   2. 可視化埋點解決了代碼埋點更新代價比較大的問題。
      1. 埋點配置獨立發佈

3. 缺點：

   1. 可視化埋點可以覆蓋的功能有限，目前並非全部的控件操做均可以經過這種方案進行定製；
   2. 數據不可回溯

Q14：什麼是無埋點？

無埋點也叫全埋點

1. 概念：用戶展示界面元素時，經過控件綁定觸發事件，事件被觸發的時候系統會有相應的接口讓開發者處理這些行爲。
2. 優勢：
   1. 可視化展現界面
   2. 技術門檻低，使用部署簡單
   3. 用戶友好性強
   4. 數據可回溯
3. 缺點：
   1. 不能靈活地自定義屬性，行爲記錄信息少
   2. 傳輸實效性和數據可靠性欠佳
   3. 因爲全部的元素數據都收集，傳輸壓力大，會給數據傳輸和服務器帶來較大的壓力。

Q15：什麼是後端埋點？

1. 概念：在後端採集數據，例如採集後端的日誌。
2. 優勢：後端採集數據到分析系統中則是經過內網進行傳輸，這個階段不存在安全和隱私性問題。同時，內網傳輸基本不會由於網絡緣由丟失數據，因此傳輸的數據能夠很是真實地反應用戶行爲在系統中的真實體現
3. 缺點：缺乏用戶交互行爲數據，須要與前端埋碼相結合

Q16：那究竟該用哪一種埋點呢？

Q17：有哪些適用的埋點場景嗎？

Q18：埋點平臺化，系統化又是什麼？

前面瞭解的只是埋點方案的不一樣，但事實上，想要把埋點實施好，還須要系統層面的解決方案，應包含：

1. 埋點規範
   1. 埋點規範代碼生成平臺
2. 埋點管理
   1. 註冊埋點，添加、刪除埋點
   2. 埋點可視化
3. 埋點驗證
   1. 測試埋點平臺，可生成報告
4. 埋點發布
   1. 獨立的埋點發布平臺
5. 埋點監控
   1. 埋點數據迴流
   2. 埋點錯誤上報

這些內容，須要平臺化來支撐，也是各大公司埋點部門在作的事情，同時也是行業上這些數據公司生存的土壤。