數據採集與分析的那些事——從數據埋點到AB測試

1、爲何企業須要一套完善的用戶行爲埋點和分析平臺

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

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

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

在分析平臺上，用戶的行爲定義會經過特定事件來標識，好比 「buttonClick」，「playMusic」 等。一般這些事件是開發人員經過調用 SDK 提供的API來設置的，除了肯定事件的名稱外，還能夠加入分析須要的自定義參數和取值，這個過程就是「埋點」工做。固然，還有一些工具/產品支持可視化埋點，這種方式不須要開發介入埋點，SDK會自動採集用戶在各個終端上的行爲。

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

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

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

可視化埋點和無埋點比較像，都不須要開發人員手工加代碼，也都須要業務人員進行所關注的用戶行爲的圈選。二者最大的不一樣是在用戶終端的表現上，可視化埋點只採集業務人員關注的用戶行爲數據，而無埋點是會採集全部用戶的行爲數據，一般狀況下數據量後者比前者大不少。

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

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

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

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

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

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

一、定義產品的階段性目標；

二、規劃和定義指標，包括產品、運營、市場的各項目標；

三、產品、運營等業務人員肯定數據埋點需求；

四、開發人員進行埋點以及數據的上報等開發工做；

五、數據開發人員進行數據的清洗、寬表建設、指標計算等工做；

六、業務人員分析數據、發現產品問題或潛在機會；

七、繼續下一階段的產品、運營、市場等的改進工做。

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

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

這塊有幾件事情能夠作：

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

l 埋點管理系統，用來管理埋點的元數據，包括事件 Event 的命名、自定義字段含義和特定取值等規範定義，埋點在產品端的位置或觸發場景，埋點工做流等，做爲業務人員、開發者、分析師溝通的橋樑和基準。

l 埋點測試和校驗系統，提供 debug 工具方便開發人員快速進行埋點調試，以及使用事件定義的規範要求，在線上對埋點數據進行校驗，儘早發現不符合規範的數據，提升埋點工做的效率和準確性。

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

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

實踐中，不少開發人員不太願意作「埋點」的工做，以爲很瑣碎，並且隨着產品的發展，包袱有時候會愈來愈大，維護的工做量不小。

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

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

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

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

用戶行爲分析平臺在建設時，數據端會包含以下能力：

l 數據接入，要支持客戶端、Web、服務端等多終端的數據採集，如iOS、Android、微信小程序等，以及各類數據源甚至三方服務的數據適配。

l 數據傳輸，在用戶規模和數據規模增加過程當中，要能保證數據傳輸服務的高可用，以及採集數據在傳輸過程的及時性。

l 數據建模/存儲，要能實時的進行數據清洗、建模和存儲落地。

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

建模後的數據，能夠做爲數據倉庫底層（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，對同一個用戶的多個設備和賬號進行映射，並綁定起來。

l 能夠經過操做系統提供的一些穩定性稍差，但短期還比較穩定的指標，如iOS的IDFA，來作mapping。

l 藉助分析產品的應用覆蓋率，如用戶是應用A和B的用戶，卸載並從新安裝B應用後，能夠經過應用A的ID修復應用B的。

l 經過引入產品用戶帳號體系來作綁定，這種方式穩定性最強，但非登陸匿名用戶的問題很差解決。

l 經過IP、Wi-Fi信息、機器型號、甚至地理位置進行mapping，這種方式須要用戶受權更多數據獲取權限，雖然是近似匹配，但當信息足夠多且發散（信息熵足夠大）時，也能夠起到統一標識的做用。

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

推廣渠道歸因就方便了。

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

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

產品方在投放連接的時候，遵守特定格式便可，好比

https://xxx.com/aaaafD?idfa=_...

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

原文地址：https://sq.163yun.com/blog/ar...

做者：網易有數鄭棟。