数据采集与分析的那些事——从数据埋点到AB测试
作者：網易有數鄭棟。
一、為什么企業需要一套完善的用戶行為埋點和分析平臺
產品初創期間，需要分析天使用戶的行為來改進產品，甚至從用戶行為中得到新的思路或發現來調整產品方向；產品成長過程，通過對用戶行為的多角度（多維）分析、對用戶群體的劃分以及相應行為特征的分析和比較，來指導產品設計、運營活動，并對市場渠道效果進行評估。
配合上A/B試驗平臺，可以加速產品的迭代，更快得到用戶的真實反饋。同時，這些數據沉淀下來，對業務的數據倉庫建設、數據智能應用等方面也能起到促進作用，比如做實時推薦，需要能更快獲得用戶盡可能多且明細的行為數據；做用戶分類、意愿預測等機器學習業務，需要清洗過的規范化、結構化的數據做 訓練。
要想做用戶行為的分析，就需要有一套用戶行為數據采集、傳輸、處理、分析的基礎設施，而埋點和分析平臺就是在做這件事。業界大多產品都是通過嵌入到多個終端的 SDK 來采集用戶行為數據，而后續的傳輸、處理等過程對需求方是透明的，這樣可以以很低的成本，完成數據的采集、清洗、沉淀工作，為企業節省成本，提升數據驅動的效率。
在分析平臺上，用戶的行為定義會通過特定事件來標識，比如 “buttonClick”，“playMusic” 等。通常這些事件是開發人員通過調用 SDK 提供的API來設置的，除了確定事件的名稱外，還可以加入分析需要的自定義參數和取值，這個過程就是“埋點”工作。當然，還有一些工具/產品支持可視化埋點，這種方式不需要開發介入埋點，SDK會自動采集用戶在各個終端上的行為。
?
二、代碼埋點、可視化埋點和無埋點有哪些區別，在使用過程中該如何選擇？
可視化埋點是指開發人員除集成采集SDK外，不需要額外去寫埋點代碼，而是由業務人員通過訪問分析平臺的圈選功能來“圈”出需要對用戶行為進行捕捉的控件，并給出事件命名。圈選完畢后，這些配置會同步到各個用戶的終端上，由采集SDK按照圈選的配置自動進行用戶行為數據的采集和發送。
無埋點是指開發人員集成采集SDK后，SDK便直接開始捕捉和監測用戶在應用里的所有行為，并全部發送到分析平臺，不需要開發人員添加額外代碼。在分析時，業務人員通過分析平臺的圈選功能來選出自己關注的用戶行為，并給出事件命名。之后便可以對特定用戶行為（事件）進行多維分析了。
可視化埋點和無埋點比較像，都不需要開發人員手工加代碼，也都需要業務人員進行所關注的用戶行為的圈選。兩者最大的不同是在用戶終端的表現上，可視化埋點只采集業務人員關注的用戶行為數據，而無埋點是會采集所有用戶的行為數據，通常情況下數據量后者比前者大很多。
也正是由于無埋點默認采集所有用戶行為數據，它能夠做到事件的回溯分析，即在業務人員新定義（圈選）事件后，就能去分析這個事件在前面一兩個月的數據情況，這也是可視化、代碼埋點支持不了的。但帶來的問題就是采集所有數據對應用的侵入會比較大，也會增大用戶端采集的數據量。當然，這可以通過一些策略，比如Wi-Fi下才發來緩解這些問題。
無埋點和可視化埋點都存在一個較大的缺陷，它們都是通過采集SDK去監測應用上控件的觸發事件（用戶對控件的操作），當產品UI在版本升級過程中發生變動，或者產品做了大的改版，一些行為的“埋點”會發生丟失。如控件ID發生變化，而圈選的配置沒變，導致數據采集不到；或者和業務的實際需要發生不一致的變動，比如圈選控件的作用發生了變化，但圈選配置沒改；這些問題會導致對產品某些方面的分析出現差錯，往往查起來還比較麻煩，在技術上完全解決也比較困難。
另外，可視化埋點和無埋點都針對的是客戶端數據采集，一些用戶行為數據在客戶端是采集不到的，或者客戶端采集的精準度不夠，比如支付，因為支付成功的判斷絕大多數場景都是在服務端做的，所以在客戶端做支付行為的埋點，誤差很大，這個時候就需要在服務端進行埋點。
在業務選擇時，建議在產品初期，產品形態還不太穩定、分析的復雜度還比較低的階段，采用無埋點或者可視化埋點，更快去做埋點，否則頻繁的產品改動，會讓開發人員大量時間花在瑣碎的埋點代碼維護上面。產品進入穩定期后，盡量采用代碼埋點方式，可以保證事件模型是穩定的，便于長期的數據監控、分析和數據沉淀。
?
三、實踐中做了些工作，來促進埋點工作的落地以便更好的維護和管理？
產品業務數據驅動的 workflow 往往是這樣的：
1、定義產品的階段性目標；
2、規劃和定義指標，包括產品、運營、市場的各項目標；
3、產品、運營等業務人員確定數據埋點需求；
4、開發人員進行埋點以及數據的上報等開發工作；
5、數據開發人員進行數據的清洗、寬表建設、指標計算等工作；
6、業務人員分析數據、發現產品問題或潛在機會；
7、繼續下一階段的產品、運營、市場等的改進工作。
用戶行為分析平臺的目標就是將其中4-6階段的工作變得簡單和自動化，把開發人員解放出來去做更多對業務有價值的工作。而1-3部分的工作，看起來不復雜，基于業務現狀去定義指標，排出埋點需求，和開發人員進行確認后就完成了。但這塊從實踐上來看，很多企業或者業務都做的不夠好。
埋點事件數量迅速膨脹，團隊可能大部分人都不知道某些埋點是做什么的；或者業務人員定義了埋點需求，但開發人員埋點做錯了，好久都沒發現，導致分析過程出現錯誤解讀，影響決策。
這塊有幾件事情可以做：
l? 指標管理系統，用來維護指標依賴的數據表、字段以及計算方式，來統一開發、分析和解讀過程的口徑。
l? 埋點管理系統，用來管理埋點的元數據，包括事件 Event 的命名、自定義字段含義和特定取值等規范定義，埋點在產品端的位置或觸發場景，埋點工作流等，作為業務人員、開發者、分析師溝通的橋梁和基準。
l? 埋點測試和校驗系統，提供 debug 工具方便開發人員快速進行埋點調試，以及使用事件定義的規范要求，在線上對埋點數據進行校驗，盡早發現不符合規范的數據，提高埋點工作的效率和準確性。
匯總就是：元數據管理系統 + 測試和校驗工具。
?
四、如何做好埋點工作和研發的協調和落地 ？
實踐中，很多開發人員不太愿意做“埋點”的工作，覺得很瑣碎，而且隨著產品的發展，包袱有時候會越來越大，維護的工作量不小。
要讓埋點工作在研發比較好的落地，最能提升的地方還是在于如何簡化開發人員的工作，包括開發成本和溝通成本。
有完善的埋點管理系統，這樣研發端可以依據進行開發，減少“口口相傳”帶來的低效和返工，也能統一口徑和進度流程。有高效易用的埋點測試、校驗系統，開發人員可以快速進行埋點debug，提高開發效率，也能讓業務方盡早介入需求校驗，而不是等應用真正發布后才去校驗，去發現問題。
當然，最好能和開發人員持續分享數據是如何促進業務的發展，讓大家明白這些工作的價值，才能更重視，更認真對待這部份工作。
?
五、埋點數據采集與企業數據資產建設怎樣更好的合作？
用戶行為分析平臺在建設時，數據端會包含如下能力：
l? 數據接入，要支持客戶端、Web、服務端等多終端的數據采集，如iOS、Android、微信小程序等，以及各種數據源甚至三方服務的數據適配。
l? 數據傳輸，在用戶規模和數據規模增長過程中，要能保證數據傳輸服務的高可用，以及采集數據在傳輸過程的及時性。
l? 數據建模/存儲，要能實時的進行數據清洗、建模和存儲落地。
?
這些能力，在互聯網業務的數據資產建設過程中，尤其是用戶、流量、產品相關領域，能起到基礎設施的作用。規范的數據采集，加上高效的傳輸、建模能力，是企業業務數據資產有效建設的前提。
建模后的數據，可以作為數據倉庫底層（ODS層）的寬表，和企業的其他業務數據整合，共同完善企業的數據資產建設。
另一方面，這些用戶端的結構化數據，加上實時建模和開放的能力，和機器學習算法結合起來，無論是個性化推薦，還是精準營銷，又或是銀行、電商的風控，都可以發揮很大威力，為企業的智能驅動業務做好數據積累，掃清障礙。
拿DMP（用戶畫像）建設舉個例子：
企業在建設自己的DMP庫的過程中，常常會從常規的人口屬性等準靜態類標簽，以及像消費能力等從自身業務積累或三方合作得到的通用類標簽入手。這些標簽往往是泛業務的，針對具體業務而言，很多時候會需要用戶畫像標簽更貼近業務，比如電商業務場景下的母嬰用戶、電子產品發燒友、化妝品品牌喜好用戶等。這些標簽和用戶的發掘，需要對用戶的行為進行深度分析來獲取，這個工作便可以借助用戶行為分析平臺的能力，如基于用戶行為模式和用戶業務屬性對用戶進行分群分析和比較，來發現和挖掘有價值的用戶標簽。
另一方面，用戶畫像的數據，也可以和分析平臺進行整合和集成，提升平臺各分析模型對不同用戶群的洞見能力，讓分析和指標的比較更有針對性，提升數據對業務的促進能力。
?
六、埋點及分析平臺和 A/B 試驗平臺如何更好的互相促進？
A/B測試產品是通過提供專業高效的試驗平臺，幫助產品進行產品決策的驗證和分析。常規使用流程如下：
接入 SDK -> 創建試驗版本 -> 設置變量、以及優化指標 -> 調節試驗流量 -> 運行試驗 -> 實時監控數據進行效果評估 -> 正式發布
試驗平臺和分析平臺的SDK在很多功能上是重合的，在SDK實現上可以整合，減少業務應用接入太多SDK的負擔。
在數據采集、建模、分析層面，分析平臺可以作為 A/B 試驗平臺后端數據的承載，優化指標的效果評估就能覆蓋用戶的全量行為，無需業務及開發人員維護多個工具帶來的重復埋點定義和開發工作。另外，在分析平臺積累的很多分析模型和指標，在A/B試驗平臺直接可以選取使用，無需在試驗平臺再進行設置，除減少業務人員工作外，還能保證統計口徑的一致。
反過來，A/B試驗平臺的一些對比試驗，以及特定灰度發布的用戶群，也能整合到分析平臺，通過分群分析能力，將這些群體應用到各個分析模型進行針對性的分析，甚至試驗結束后，也能持續對這些用戶進行追蹤和分析，更好的洞察用戶。
?
七、如何打通產品多端的埋點數據？
這是個歸因的問題，一般提到賬號打通，就會有歸因的討論。
現在的分析產品在一般情況下，移動端會通過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=__IDFA__&imei=__IMEI__
渠道在用戶點擊廣告鏈接后，會把設備ID如IDFA或IMEI加到鏈接的內容里面，用戶激活后便可以通過相應ID匹配來歸因。
?
網易有數是網易旗下的企業級大數據可視化分析平臺，可點擊免費試用。
網易云免費體驗館，0成本體驗20+款云產品！
更多網易研發、產品、運營經驗分享請訪問網易云社區。
相關文章：
【推薦】?4月第4周業務風控關注 | 網絡犯罪經濟每年1.5萬億美元 GDP居全球第12位
【推薦】?ThreeJs 基礎入門
【推薦】?“代碼變更覆蓋率”在后端測試中的實踐
轉載于:https://www.cnblogs.com/zyfd/p/9761760.html
總結
以上是生活随笔為你收集整理的数据采集与分析的那些事——从数据埋点到AB测试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： BZOJ2648: SJY摆棋子
- 下一篇： 软工作业3—词频统计