作者：網易有數鄭棟。
一、為什麼企業需要一套完善的使用者行為埋點和分析平臺
產品初創期間，需要分析天使使用者的行為來改進產品，甚至從使用者行為中得到新的思路或發現來調整產品方向；產品成長過程，通過對使用者行為的多角度（多維）分析、對使用者群體的劃分以及相應行為特徵的分析和比較，來指導產品設計、運營活動，並對市場渠道效果進行評估。
配合上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+款雲產品！
更多網易研發、產品、運營經驗分享請訪問網易雲社群。
相關文章：
【推薦】 爬蟲開發python工具包介紹 （1）
【推薦】 試水新的Angular4HTTPAPI