Tracking（埋點）?

Tracking?

​ Tracking，僅從字面上就有追蹤、跟蹤之意。在實際應用當中，埋點是爲了滿足能夠跟蹤並記錄用戶行爲過程與結果而產生的技術方法。

1、 埋點數據的流水線

​ 當用戶在客戶端發生交互（Active）時，會運行相應的請求指令，向服務器發出 Http request。其中運行的代碼當中，我們就會隱式的載入埋點代碼，通常爲.js，這也是數據蒐集的源頭和最爲關鍵的一步。通過.js代碼我們蒐集客戶端的數據，併發送到我們的後端（Backend），寫入日誌（Log）當中。這時數據的蒐集工作基本完成，如果想要進一步支持業務，那麼ETL工程師就要發揮更大的作用。通過對原始日誌的抽取（Extract）、轉換（Transform）、加載（Load）工作寫入數據庫（Database）當中。當業務需要數據支持時，按照業務邏輯取出，並稍加處理就可交付給業務人員。這就是數據在用戶>>收集>>存儲>>業務生產線的生命過程。

2、埋點的設計原則

​ 埋點設計和系統設計在一定程度上非常相似。在滿足不同的業務需求的同時，易於管理和使用也非常重要。保證埋點的業務性 、複用性、一致性、只增不減性具有重要意義。

2.1 業務性

​ 埋點，說到底就是爲了支持業務而生。若僅僅是爲了獲取數據去做埋點，這將沒有絲毫價值。這就要求，在設計埋點時，應該事先與需求方溝通業務邏輯與業務需求，使得獲取數據能夠滿足邏輯的同時，更好的支持業務。這裏的需求方，不僅僅包括需要優化產品的產品部門，需要內容排期推薦的內容部門，還包括渠道部門和用戶部門等。舉個栗子，對於一款閱讀型產品的點贊功能，產品經理會更關心讓用戶使用點讚的體驗，內容部門就會在意於哪一款內容更容易讓用戶點贊。這就要求在做埋點時，規劃好數據收集的顆粒度，使得收集的數據即不冗餘，也不會數到用時方恨少。

2.2 複用性

​ 複用性，主要表現在，應用的功能調用在一定程度上是重複出現的，區別僅在於用戶場景上的不一致。舉個栗子，在未登錄的狀態下，使用bilibili內容下的轉發、評論、點贊、關注功能時，均會觸發登錄事件。這時需要獲取的事件屬性，比如，content_id、up_id…基本一致，只需要添加一個origin來區分用戶場景就能夠滿足需要。這將會給後期的BI建設提供很大的便利，業務上也足夠清晰，埋點文檔的維護也較爲容易。

2.3 一致性

​ 一致性，常出現在命名的問題上。一方面，在於Android、IOS、Quick App、H5小程序多平臺開發，帶來UI上的設計差異，文案差異，導致前端顯示不一致；另一方面，在於人員的流動，部門的差異上。雖然這是一個小問題，但是會帶來很大的困擾，除非你願意去努力區分：卡片式閱讀器和章節閱讀浮層的關係；簽約與非簽約、商務與非商務、獨家與非獨家的關係。

2.4 只增不減性

​ 埋點的設計，通常是伴隨着產品的迭代而迭代，這就意味着有新功能會上線，有舊功能被刪除。當新功能上線時，我們首先考慮複用性，若只是在用戶場景上做出改動，建議首先做的是修改原有打點，而不是重新添加；若現存埋點無此類功能，謹慎添加的同時，依舊考慮到功能的複用性。舊的功能被刪除，表示此處的埋點在新版中已無法收集數據，但是舊版依然在使用。此處的做法應該標識出此類埋點，並告知相關人員在相應幾個版本後不必花費精力再來維護，以節約資源。

3、埋點的設計規範

​ 採集日誌，力求將一個事件敘述清楚。我們使用5W2H框架：

日誌框架
Who	What	Why（不常用,例，用戶支付失敗的原因）	Where	When
How	How much（用以度量）

​ 點擊事件中，我們需要設計一套通用的模板，用以標識，這個用戶在什麼時間什麼地點通過什麼方式做了什麼事。其中，除了通用屬性外，我們需要向特定的事件，標記特定的屬性（extra_info）進行度量。

模板：

點擊事件	發送時機需明確
字段名稱	字段類型	字段解釋	框架
session_id	string	回話唯一ID	Who
user_id	string	用戶註冊ID（匿名處理）	Who
device_id	string	設備ID	Who
platform	string	操作系統	Where
sys_version	string	操作系統版本	Where
device_model	string	設備廠商	Where
app_version	string	應用版本	Where
source_id	string	渠道包ID	Where
wifi	bool	WIFI環境	Where
network_type	string	網絡類型	Where
ip_addr	string	設備IP	Where
screen_height	int	屏幕高度	Where
screen_width	int	屏幕寬度	Where
event_time	string	觸發時間戳	When
event_id	string	事件ID,特定屬性	What
extra_info	string(json)	附加信息	Why、How、How much

​ 同樣的，頁面日誌要相對簡單。除了需要考慮當前頁面的特定屬性（extra_info）外，基本不需要考慮觸發時機上報的問題。

頁面日誌模板：

頁面事件	離開當前頁面時發送
字段名稱	字段類型	字段解釋	框架
session_id	string	回話唯一ID	Who
user_id	string	用戶註冊ID	Who
device_id	string	設備ID	Who
platform	string	操作系統	Where
sys_version	string	操作系統版本	Where
device_model	string	設備廠商	Where
app_version	string	應用版本	Where
source_id	string	渠道包ID	Where
wifi	bool	WIFI環境	Where
network_type	string	網絡類型	Where
ip_addr	string	設備IP	Where
screen_height	int	屏幕高度	Where
screen_width	int	屏幕寬度	Where
start_time	string	進去頁面的時間	When
end_time	string	離開頁面的時間	When
refer_page_name	string	頁面前驅	What
page_name	string	當前頁面	What
to_page_name	string	頁面後繼	What
extra_info	string(json)	附加信息	Why、How、How much

4、埋點事件的觸發上報時機

​ 事件上報的時機，通常包含前端觸發就上報、前端觸發並得到後臺響應後上報兩種。區別就在於，需不需要與後臺產生交互。

4.1 前端觸發就上報

​ 一言以蔽之，用戶觸發 了該事件就進行採集，不需要等待後臺的響應結果。常見的點擊操作，比如，切換tab、點擊轉發按鈕…這類操作當中，我們通常只考慮用戶是否參與，用戶是否使用。這種上報時機是蒐集數據中最常用的。

4.2 前端觸發並得到後臺響應後上報

​ 這種上報機制，相較於第一種，前端會等待後臺數據庫回傳操作結果後，經由前端上報。這時，我們不僅僅需要知道用戶操作了什麼，還需要知道用戶操作的結果。最常見的場景，就是我們在計算觸發支付到支付成功的轉化率時，總是要知道支付結果的，這種情況勢必要等待後臺處理結果回傳。

5、埋點工作在企業中的執行流程

​ 埋點，從需求到實踐需要多部門的合作，才能保證其有效性和精準性。

5.1 需求的拆析與確認

​ 數據需求的來源，往往並不侷限於產品經理，凡是關心用戶行爲與質量的部門通常都可以劃分到需求方。通常，我們首先梳理產品邏輯，用戶會在哪些場景下觸發需求方的指定動作，這個動作可以是單一動作，也可以是聯動動作；其次，設定評估指標，這是業務增長的核心；最後，設置指標相關事件、以及相關屬性，完備採集數據。

​ 舉個栗子，電商類的業務部門想要發掘有潛力的商品。埋點的同學就基於商品曝光–商品詳情–加入購物車–商品購買做了一個漏斗模型，並與之確認。在這裏就需要埋點對業務敏感，理解每一個環節的數據意義。比如，商品的曝光和推薦位是有關的，那麼，在埋點時，需要添加來源屬性，告訴業務人員，用戶是從哪裏來的；從商品首圖到商品詳情頁，就與配圖的質量有很大關係，也就要添加圖片編號，標識當前放置了那一張圖片？與之相似，在添加購物車、商品購買時，商品有什麼活動，有多大的優惠等等，我們都需要採集到。業務後期，不管是做用戶畫像，還是個性化推薦，這一部分都是用的到的。所以保持業務熟練的同時，儘量保持對數據技術的熱忱，在埋點時大有裨益。

5.2 多部門協作

​ 需求方：作爲需求的第一提出方，必須明確需求的業務邏輯。反覆確認，埋點不重不漏，屬性詳盡；

​ 接口：埋點中的屬性的絕大部分數據，均需要接口的支持。在埋點開發的過程中，確保接口數據能夠滿足需求；

​ 研發：這是埋點動作的直接實施部門。在對接時，應與之明確埋點的業務邏輯。以免在面對不確定的需求時，盲目埋點，或者面對開發實現成本高的需求直接跳過，導致上線的數據與需求不一致；

​ 測試：確保所有的採集需求的正確性與完整性。

​ 研發：這是埋點動作的直接實施部門。在對接時，應與之明確埋點的業務邏輯。以免在面對不確定的需求時，盲目埋點，或者面對開發實現成本高的需求直接跳過，導致上線的數據與需求不一致；

​ 測試：確保所有的採集需求的正確性與完整性。