網易鄭棟：數據採集與分析的那些事——從數據埋點到AB測試

05-13

4月8日晚，DTalk邀請到了網易互聯網分析產品、可視化 BI 產品的負責人—鄭棟老師，進行了一次關於《網易鄭棟：數據採集與分析的那些事第一彈: 數據篇》的主題分享。分享共兩個部分，第一部分是鄭棟老師分享關於數據採集與分析大家關心的問題，第二部分是Q&A互動環節。

鄭棟老師, 網易互聯網分析產品、可視化 BI 產品負責人。多年從事大數據技術相關工作，目前在網易管理互聯網分析、敏捷BI兩個數據分析產品線，在大數據技術、互聯網業務數據體系建設、團隊管理方面有豐富的經驗。負責過網易旗下多個業務及產品的數據體系建設工作，也有應用分析、營銷監測、用戶行為分析、可視化分析等多個數據產品的實戰落地經驗。

以下為鄭棟老師關於數據採集與分析的分享：

1.為什麼企業需要一套完善的用戶行為埋點和分析平台

產品初創期間，需要分析天使用戶的行為來改進產品，甚至從用戶行為中得到新的思路或發現來調整產品方向；產品 growth 過程，通過對用戶行為的多角度（多維）分析、對用戶群體的劃分以及相應行為特徵的分析和比較，來指導產品設計、運營活動，並對市場渠道效果進行評估。

配合上 A/B 試驗平台，可以加速產品的迭代，更快得到用戶的真實反饋。同時，這些數據沉澱下來，對業務的數據倉庫建設、數據智能應用等方面也能起到促進作用，比如做實時推薦，需要能更快獲得用戶儘可能多且明細的行為數據；做用戶分類、意願預測等機器學習業務，需要清洗過的規範化、結構化的數據做 training。

要能做用戶行為的分析，就需要有一套用戶行為數據採集、傳輸、處理、分析的基礎設施，而埋點和分析平台就是在做這件事。業界大多產品都是通過嵌入到多個終端的 SDK 來採集用戶行為數據，而後續的傳輸、處理等過程對需求方是透明的，這樣可以以很低的成本，把數據的採集、清洗、沉澱工作做掉，為企業節省成本，提升數據驅動的效率。

在分析平台上，用戶的行為定義會通過特定 Event 來標識，比如「buttonClick」, 「playMusic」等。通常這些事件，是開發人員通過調用 SDK 提供的 API 來設置的，除了確定事件的名稱外，還可以加入分析需要的自定義參數和取值，這個過程就是「埋點」工作。當然，還有一些工具/產品支持可視化埋點，這種方式不需要開發介入埋點，SDK 會自動去採集用戶在各個終端上的行為。

2.代碼埋點、可視化埋點和無埋點有哪些區別，在使用過程中該如何選擇？

可視化埋點是指開發人員除集成採集 SDK 外，不需要額外去寫埋點代碼，而是由業務人員通過訪問分析平台的圈選功能來「圈」出需要對用戶行為進行捕捉的控制項，並給出事件命名。圈選完畢後，這些配置會同步到各個用戶的終端上，由採集 SDK 按照圈選的配置自動進行用戶行為數據的採集和發送。

無埋點是指開發人員集成採集 SDK 後，SDK 便直接開始捕捉和監測用戶在應用里的所有行為，並全部發送到分析平台，不需要開發人員添加額外代碼。在分析時，業務人員通過分析平台的圈選功能來選出自己關注的用戶行為，並給出事件命名。之後便可以對特定用戶行為（事件）進行多維分析了。

可視化埋點和無埋點比較像，都不需要開發人員手工加代碼，也都需要業務人員進行所關注的用戶行為的圈選。兩者最大的不同是在用戶終端的表現上，可視化埋點只採集業務人員關注的用戶行為數據，而無埋點是會採集所有用戶的行為數據，通常情況下數據量後者比前者大很多。

也正是由於無埋點默認採集所有用戶行為數據，它能夠做到事件的回溯分析，即在業務人員新定義（圈選）事件後，就能去分析這個事件在前面一兩個月的數據情況，這也是可視化、代碼埋點支持不了的。但帶來的問題就是採集所有數據對應用的侵入會有些大，也會增大用戶端採集的數據量。當然，可以通過一些策略，比如 Wi-Fi 下才發緩解這些問題。

無埋點和可視化埋點很大一個缺陷在於它們都是通過採集 SDK 去監測應用上控制項的觸發事件（用戶對控制項的操作），當產品 UI 在版本升級過程發生變動，或者產品做了大的改版，一些行為的「埋點」會發生丟失。如控制項ID發生變化，而圈選的配置沒變，導致數據採集不到；或者和業務的實際需要發生不一致的變動，比如圈選控制項的作用發生了變化，但圈選配置沒改；這些問題會導致對產品某些方面的分析出現差錯，往往查起來還比較麻煩，在技術上完全解決也比較困難。

另外，可視化埋點和無埋點都針對的是客戶端數據採集，一些用戶行為數據在客戶端是採集不到的，或者客戶端採集的精準度不夠，比如支付，因為支付成功的判斷絕大多數場景都是在服務端做的，所以在客戶端做支付行為的埋點，誤差很大，這個時候就需要在服務端進行埋點。

我在業務選擇時給的建議是，在產品初期，產品形態還不太穩定、分析的複雜度還比較低的階段，採用無埋點或者可視化埋點，更快去做埋點，否則頻繁的產品改動，會讓開發人員大量時間花在瑣碎的埋點代碼維護上面。產品進入穩定期後，盡量採用代碼埋點方式，可以保證事件模型是穩定的，便於長期的數據監控、分析和數據沉澱。

3.實踐中做了些工作，來促進埋點工作的落地以便更好的維護和管理？

產品業務數據驅動的 workflow 往往是這樣的：

定義產品的階段性目標；
規劃和定義指標，包括產品、運營、市場的各項目標；
產品、運營等業務人員確定數據埋點需求；
開發人員進行埋點以及數據的上報等開發工作；
數據開發人員進行數據的清洗、寬表建設、指標計算等工作；
業務人員分析數據、發現產品問題或潛在機會；
繼續下一階段的產品、運營、市場等的改進工作。

用戶行為分析平台的目標就是將其中 4-6 階段的工作變得簡單和自動化，把開發人員解放出來去做更多對業務有價值的工作。而 1-3 部分的工作，看起來不複雜，基於業務現狀去定義指標，排出埋點需求，和開發人員確認好就完成了。但這塊從實踐上來看，很多企業或者業務都做的不夠好。

埋點事件數量迅速膨脹，團隊可能大部分人都不知道某些埋點是做什麼的；或者業務人員定義了埋點需求，但開發人員埋點做錯了，好久都沒發現，導致分析過程出現錯誤解讀，影響決策。

這塊有幾件事情可以做：

指標管理系統，用來維護指標依賴的數據表、欄位以及計算方式，來統一開發、分析和解讀過程的口徑。

埋點管理系統，用來管理埋點的元數據，包括事件 Event 的命名、自定義欄位含義和特定取值等規範定義，埋點在產品端的位置或觸發場景，埋點工作流等，作為業務人員、開發者、分析師溝通的橋樑和基準。
埋點測試和校驗系統，提供 debug 工具方便開發人員快速進行埋點調試，以及使用事件定義的規範要求，在線上對埋點數據進行校驗，儘早發現不符合規範的數據，提高埋點工作的效率和準確性。

匯總就是：元數據管理系統 + 測試和校驗工具

4.如何做好埋點工作和研發的協調和落地？

實踐中，很多開發人員不太願意做「埋點」的工作，覺得很瑣碎，而且隨著產品的發展，包袱有時候會越來越大，維護的工作量不小。

要讓埋點工作在研發比較好的落地，最能提升的地方還是在於如何簡化開發人員的工作，包括開發成本和溝通成本。

有完善的埋點管理系統，這樣研發端可以依據進行開發，減少「口口相傳」帶來的低效和返工，也能統一口徑和進度流程。有高效易用的埋點測試、校驗系統，開發人員可以快速進行埋點 debug，提高開發效率，也能讓業務方儘早介入需求校驗，而不是等應用真正發布後才去校驗，去發現問題。

當然，最好能和開發人員持續分享數據是如何促進業務的發展，讓大家明白這些工作的價值，才能更重視，更認真對待這部份工作。

5.埋點數據採集與企業數據資產建設怎樣更好的合作？

用戶行為分析平台在建設時，數據端會包含如下能力：

數據接入，要支持客戶端、Web、服務端等多終端的數據採集，如 iOS、Android、微信小程序等，以及各種數據源甚至三方服務的數據適配。
數據傳輸，在用戶規模和數據規模增長過程中，要能保證數據傳輸服務的高可用、以及採集數據在傳輸過程的及時性。
數據建模/存儲，要能實時的進行數據清洗、建模和存儲落地。

這些能力，在互聯網業務的數據資產建設過程中，尤其是用戶、流量、產品相關領域，能起到基礎設施的作用。規範的數據採集，加上高效的傳輸、建模能力，是企業業務數據資產有效建設的前提。

建模後的數據，可以作為數據倉庫底層（ODS 層）的寬表，和企業的其他業務數據整合，共同完善企業的數據資產建設。

另一方面，這些用戶端的結構化數據，加上實時建模和開放的能力，和機器學習演算法結合起來，無論是個性化推薦，還是精準營銷，又或是銀行、電商的風控，都可以發揮很大威力，為企業的智能驅動業務做好數據積累，掃清障礙。

拿 DMP （用戶畫像）建設舉個例子：

企業在建設自己的 DMP 庫的過程中，常常會從常規的人口屬性等准靜態類標籤，以及像消費能力等從自身業務積累或三方合作得到的通用類標籤入手。這些標籤往往是泛業務的，針對具體業務而言，很多時候會需要用戶畫像標籤更貼近業務，比如電商業務場景下的母嬰用戶、電子產品發燒友、化妝品品牌喜好用戶等。這些標籤和用戶的發掘，需要對用戶的行為進行深度分析來獲取，這個工作便可以藉助用戶行為分析平台的能力，如基於用戶行為模式和用戶業務屬性對用戶進行分群分析和比較，來發現和挖掘有價值的用戶標籤。

另一方面，用戶畫像的數據，也可以和分析平台進行整合和集成，提昇平台各分析模型對不同用戶群的洞見能力，讓分析和指標的比較更有針對性，提升數據對業務的促進能力。

6.埋點及分析平台和 A/B 試驗平台如何更好的互相促進？

A/B 測試產品是通過提供專業高效的試驗平台，幫助產品進行產品決策的驗證和分析。常規使用流程如下：

接入 SDK -> 創建試驗版本 -> 設置變數、以及優化指標 -> 調節試驗流量 -> 運行試驗 -> 實時監控數據進行效果評估 -> 正式發布

試驗平台和分析平台的 SDK 在很多功能上是重合的，在 SDK 實現上可以整合，減少業務應用接入太多 SDK 的負擔。

在數據採集、建模、分析層面，分析平台可以做為 A/B 試驗平台後端數據的承載，優化指標的效果評估就能覆蓋用戶的全量行為，無需業務及開發人員維護多個工具帶來的重複埋點定義和開發工作。另外，在分析平台積累的很多分析模型和指標，在 A/B 試驗平台直接可以選取使用，無需在試驗平台再進行設置，除減少業務人員工作外，還能保證統計口徑的一致。

反過來，A/B 試驗平台的一些對比試驗，以及特定灰度發布的用戶群，也能整合到分析平台，通過分群分析能力，將這些群體應用到各個分析模型進行針對性的分析，甚至試驗結束後，也能持續對這些用戶進行追蹤和分析，更好的洞察用戶。

7.如何打通產品多端的埋點數據？

這是個歸因的問題，一般提到帳號打通，就會有歸因的討論。

現在的分析產品在一般情況下，移動端會通過 SDK 生成唯一 ID 來標識用戶/設備。移動化發展早期，很多採集工具用過 mac address、IDFA、android_id、IMEI 等從移動操作系統可以獲取的設備軟硬體信息來標識設備，但隨著操作系統的發展，很多信息獲取介面要麼被封禁，要麼已經失去了精準性。反倒是一開始就通過自己生成的 ID 來標識用戶的工具，受到的影響不大，基本保持了用戶/設備標識的穩定。

但這種方式有個問題，在用戶卸載、重裝或者刷機後，ID 信息會丟失，導致生成新的用戶/設備 ID。

我們採用過 ID Mapping 的技術來做過 ID 的打通：對每個用戶生成一個虛擬 ID，對同一個用戶的多個設備和帳號進行映射，並綁定起來。

可以通過操作系統提供的一些穩定性稍差，但短時間還比較穩定的指標，如 iOS 的 IDFA，來做 mapping。
藉助分析產品的應用覆蓋率，如用戶是應用 A 和 B 的用戶，卸載並重新安裝 B 應用後，可以通過應用 A 的 ID 修復應用 B 的。
通過引入產品用戶帳號體系，來做綁定，這種方式穩定性最強，但非登錄匿名用戶的問題不好解決。
通過 IP、Wi-Fi 信息、機器型號、甚至地理位置進行 mapping，這種方式需要用戶授權更多數據獲取許可權，雖然是近似匹配，但當信息足夠多且發散（信息熵足夠大）時，也可以起到統一標識的作用。

通過這個虛擬 ID 實質上就打通了產品的多端數據。ID Mapping 體系的建設工作量不小，Mapping 後用戶標識如果需要發生調整，在基於事件的分析產品上需要對老數據進行重寫，比較複雜。所以對於一些強帳號體系的產品，可以退化到只用用戶帳號來做關聯，只有非登錄匿名用戶才用設備 ID 來標識，這往往是性價比比較高的方案。

推廣渠道歸因就方便了。

支持營銷效果評估的分析平台會要求產品在平台上生成推廣鏈接進行投放。用戶在點擊鏈接時，會從分析平台的域下做跳轉再到目標頁，這樣就可以藉助瀏覽器的 cookie 機制進行匹配，來對用戶來源進行歸因，但這種方式在移動端上面的表現不太好（iOS 已經取消了 SFSafariViewController 多應用共享 cookie 的支持）。除此之外，也可以採用 ID Mapping 提到的近似匹配技術，很多廠商聲稱的設備指紋技術大多也是這種，不太准，但定性分析是可以的。

歸因這塊，一些推廣渠道做了些工作，解決移動端不好溯源的問題：支持設備 ID 的回傳功能來方便產品歸因問題的解決。

產品方在投放鏈接的時候，遵照特定格式即可

渠道在用戶點擊廣告鏈接後，會把設備 ID 如 IDFA 或 IMEI 加到鏈接的內容裡面，用戶激活後便可以通過相應 ID 匹配來歸因。

以下是鄭棟老師回答提問部分的內容(節選）

Q1、「解解-產品-AI方向：我想了解目前說的這套方法，是有相關的產品在應用吧？那麼這個ID MAPPING除了較為複雜，還有沒有其他的缺陷？」

- - - - - - - - - - - - - - -

ID mapping 是蠻複雜的，但基本上要做覆蓋面比較大的用戶畫像建設，這個是必須要做的。

Q2、「王永濤@d?s: @鄭棟請問鄭老師，這種方法對於 iOS 和 android 均適用么？」

- - - - - - - - - - - - - - -

都適用的。

Q3、「水韓竹-政企-數據分析: 老師，可視化埋點是在原有的demo基礎上圈點嗎？」

- - - - - - - - - - - - - - -

UI 層面上的圈點都可以，只要 SDK 支持。

Q4、「 Ben: 老師，我在閱讀埋點相關資料時，有看到諸如如果埋點較多會導致產品響應速度變慢影響用戶體驗，請問一般什麼情況下會導致這種情況」

- - - - - - - - - - - - - - -

埋點一般不會，大多數都是做的非同步發送，數據量相對來說小很多，比如聽一首歌，打開一個上面詳情頁，就可以發幾千上萬條埋點數據了。慢的話，可能是 sdk 實現的不太好，比如 hook 了太多系統調用，或者本身應用就有問題。

Q5、「水韓竹-政企-數據分析: 埋點會涉及到時機和對應的參數，這些都怎麼來表示呢？」

- - - - - - - - - - - - - - -

埋點的參數要通過元數據管理起來，實際我們這邊很多業務的產品同學為了防止和開發理解不一樣，做到交互稿里了。

本文轉載自公眾號：DTalks

原文鏈接：【DTalk精華】網易鄭棟：數據採集與分析的那些事: 從數據埋點到AB測試

網易大數據：

網易猛獁 - 網易大數據|專業的私有化大數據平台

網易有數 - 網易大數據|專業的私有化大數據平台，可免費試用