本文根據資深數據產品經理陳家崑《從 0 到 1 埋點體系指南》的分享內容整理。主要內容如下：
· 首次開荒指南
· 埋點體系迭代指南
· 體系落地指南
· 數據埋點實操案例
一、開荒
所謂開荒，指的是初次接觸埋點或神策的階段。
1.定位：一個容易忽視的儀式
關於埋點系統的定位，需要想清楚三個問題：
第一，有沒有清晰的認知，埋點系統所承擔的用途是什麼？
作爲業務埋點對接人，需要想清楚埋點系統所承擔的用途是什麼？它在整個公司業務體系中的定位是什麼？如果沒有對這個工具定位好，後續推廣使用及跨部門合作時，可能會產生衝突或者與其他工具的定位重複或矛盾。
第二，有沒有明確的需求，而不是“爲了埋點而埋點”。
在面臨具體埋點需求時，需要進一步明確它的使用價值是什麼、能爲業務解決什麼問題。在我過往接觸過的業務線中，有的爲了埋點而埋點，沒有想清楚具體該怎麼使用，這樣很容易造成大量垃圾數據。
尤其當用戶客羣較大時，對應的數據量也是非常兇猛的，常常令人措手不及，比如使用若干個月後，發現線上存儲空間不足，系統性能不夠等，這些問題的治理繁瑣又困難。
第三，有沒有明確的規劃？
在實際調動公司資源去落地構建埋點體系時，需要一定的節奏。因爲正常產品開發也需要遵循着這樣的原則，要進行一定的規劃。
總之，基於這三個問題，我們要考慮清楚定位。
2.把埋點體系作爲數據中臺或 BI 體系的重要組成部分
埋點系統和數據倉庫、分析體系、預警系統等子系統一樣，需要放入整個公司的業務體系和數據體系裏，方便統一規劃。
不得不說，神策的不可替代性很強。因爲埋點採集技術難度較大，如果沒有經驗的話，成本就比較高。
至於成爲整個數據體系有什麼樣的好處呢？
首先，可以把行爲數據作爲數據體系的一部分進行整合。
行爲數據，換一個角度看也是一種業務數據，這種數據在業務系統裏無法採集。建議把它作爲一個數據源，方便把整個用戶行爲數據關聯到業務或外部數據。
其次，可以把此時此刻的用戶數據特徵作爲屬性補充行爲數據。
整個數據體系中，有些數據在前端埋點時無法採集。比如在做某些優惠券邏輯時，只會傳一個 ID 到前端頁面上，實際再去埋點時，也只能拿到這些 ID 信息，其他無法採集。解決這個問題有很多辦法，但通過前端業務側解決的方式，通常風險比較大，因爲要考慮接口設計、性能及各種併發問題，如果把這些數據問題放在業務側，將會受到一定的阻力。
而如果通過數據側解決會相對容易，比如把 ID 採集回來後，它的優惠價格、歷史信息及其所承載的數據含義等信息，在數據側都可以直接關聯。
3.以項目視角看產品
之所以談到項目化，因爲埋點體系搭建既是一個產品規劃問題，也是一個項目管理問題。建議在開荒階段，就要把這個項目的過程籌備好。
接下來根據自己過往所經歷的項目籌建經歷，跟大家分享一些實操經驗。 
第一，樹立項目意識，因爲它既是一個產品規劃問題，也是一個項目管理問題。
第二，制定標準化流程，包括需求收集、討論、評審，到開發、測試、上線、迭代等，任何在前後端進行開發所需要經歷的過程，一個都不能缺少。
如果缺少了某個環節就容易產生大的問題，比如如果沒有測試，那數據質量就無法保證，一旦產生問題，如何修復大量的數據，如何補充屬性糾正問題，都是比較麻煩的事情。
第三，明確項目內外的角色和分工，以我過往項目經歷爲例，當時把來自不同的業務線的同事，比如客戶端、策略後臺算法、分析師等組成虛擬團隊，集中明確各自分工，這裏特別強調下技術和測試環節。
技術環節，建議項目相關的技術同學都要去熟悉相關文檔，如果不熟悉就直接上手操作，加上不同技術同事輪流去做，會很難沉澱下來一些方法論。
測試環節也一樣，如何使用埋點工具、如何在控制檯排查問題，測試同事都需要一定的時間去熟悉。可能只有經過兩次版本迭代後，纔會對整個流程熟悉，做到心裏有數。建議大家重點培養測試同學對數據問題的敏感性。只有保證整個測試環節的質量沒有問題，後續的分析算法的應用才能真正能發揮出價值。
第四，確認技術點，這裏需要注意一些細則，比如用戶 ID 是一對一的關聯，還是一對多的關聯？以電商公司爲例，涉及到買手機的場景時，很多用戶都是拿着舊手機買新手機，建議做成一對多的關係，因爲很多用戶拿來的舊手機基本不用了，如果成交，做成一對一關聯的話就會被誤認爲是兩個用戶。
第五，關於使用邊界或項目邊界問題，在日常做埋點時，經常會面臨不同的業務線同步進行，這時就需要明確各業務線的邊界。涉及到各業務線私有的東西，每條業務線自己負責，而涉及到公共的東西，需要大家一起去完善和維護。
第六，關於項目籌劃，建議把相關責任人用清單的方式列下來，明確各自責任，並且通過郵件等方式公開留底，後續再去推廣業務時會比較順暢。
4.需求整理最好前置
第一，埋點規劃。在對埋點需求進行規劃時，切忌一次性完成大量需求，最好對需求進行優先級排序處理，這樣有助於管理產品文檔，如果一次性處理幾百個埋點，加上涉及到跨部門協同，撰寫時難免會有紕漏，所以埋點規劃的節奏非常重要。
第二，用戶屬性。設計埋點時要考慮用戶屬性設計。設計用戶屬性時，需要遵循一個最基本的原則，就是通過事件分析系統、用戶標籤、用戶畫像系統計算出來的東西，就不要單獨上報埋點。
比如想要獲取用戶近幾日的消費單數，或是確認他是否爲 VIP 用戶，這些數據需求都可以通過事件計算出來。如果再單獨埋點，不但會浪費開發資源，而且上報來的結果遠不如整個系統內環計算來的靈活。
需要注意的是，下面兩個屬性非常值得埋。一個是靜態屬性，比如說用戶年齡、性別等，這些靜態屬性無法算出來，很有埋點的必要。另一個是通過算法和數據挖掘產生的挖掘標籤，也值得單獨埋點。
第三，瞭解預製屬性。建議大家多多通讀了解預製屬性，一方面是防止事件所採集的屬性，跟預製屬性有所重疊。
另一方面，通過預製屬性，可以瞭解各端的數據特性，比如小程序的特性如何，它在封閉環境裏可以返回哪些數據、不返回哪些數據？比如 H5 特性如何，客戶端特性如何等等。
第四，確定節點口徑。通常，一個事件會有很多下沉節點，比如某個按鈕的點擊事件，從用戶在 APP 層的點擊，到 APP 去請求應用接口，到服務器去確定接口，接到了請求後，到業務側後臺系統處理這個請求時是否成功，再到最後是否能把結果成功返回給客戶端。
因此，整理需求做事件設計時，一定要明確它的節點口徑，明確需要在什麼樣的層級採集。具體來看，一方面需要想清楚在哪個節點採集，另一方面也要看具體需求，在什麼樣的環境採集。通常來說，越靠近 APP 端，它所採集的事件越大，但可能對比業務端來說，它的準確性會相對較低。
二、迭代
完成了前面的基礎工作後，埋點體系經過 1-2 個版本後初見成效，這時開始面臨如何拓展使用，如何管理大量的數據需求的問題。同時，還伴隨着如下問題：隨着時間的推移埋點文檔越寫越多、越寫越亂；不清楚的埋點定義越來越多；相關項目人員離職，未做相關交接等。
1.事件分類
根據所要埋的事件類型進行分類很有必要，一方面方便對需求進行優先級確認，另一方面設計埋點時，不同類型的事件需要對應各自的方法。
（1）通用事件
對於通用的、泛化性的、活動等次要流程事件，可以進行抽象化處理。 比如，在日常工作中，經常遇到市場或活動運營同事提出某次活動的埋點需求，如果每次活動都單獨處理成一個事件，隨着時間的推移將會導致同類事件越積越多，不利於管理，因此對於這類相關的事件，需要進行抽象化的通用事件處理。
（2）邊緣事件
所謂邊緣事件，指的是零散的只查看點擊或瀏覽行爲的事件，比如 APP 端諸如設置、客服入口等功能按鈕。
處理此類事件，有兩種常見方法：
一種是做一個最基本的自定義事件容器，然後把相關按鈕名稱、所在頁面及其他零散東西抽象化後放進去。
另一種是手動糾正一些全埋點進行上報。之所以要手動糾正，是因爲前後端的技術架構不同，沒有辦法 100% 地適應全埋點，當全埋點數據出現未知或無法採集時，需要手動調 SDK，糾正所要採集的頁面。
2.事件管理方法
當處理的事件數量越來越多時，就需要進行相應的管理，具體方法如下 
第一，關於埋點系統的 WIKI 文檔一定要放到雲端留存，方便項目管理和及時查詢；
第二，爲了方便跨部門溝通和前後交接，埋點體系項目組成員在撰寫 WIKI 文檔時，最好明確出一套文檔規範，防止以各自形式撰寫，導致後續加入的人查看時摸不着頭腦；
第三，通過事件描述尋找頁面和翻查代碼來修補問題事件，方便解決歷史遺留問題；
第四，定期進行清點和梳理，具體可以在 admin 賬號裏進行系統診斷，定期地導出診斷報告，便於對不合理、低性價比事件及時進行清理。
3.問題排查技巧
問題排查這塊，主要講日常應用中常遇到的三個問題。
第一，數據一致性問題。當埋點系統收集的數據和業務端、BI 等系統數據節點或口徑不一致時，該如何處理？
比如，關於新用戶與老用戶的定義差異，當埋點所定義的概念和市場及運營端同事的口徑不同時，就會造成數據對不上的問題。如何應對這種情況呢？建議先跟運營或是對應的產品同事瞭解相關指標，它的口徑和節點是怎樣的，及時去修改屬性和描述，比如不要籠統地定義爲老用戶或新用戶，而是定義爲註冊用戶、認證用戶或下單用戶等。
第二，關於準確性挑戰。把埋點系統的數據與業務端、BI 端數據進行校對，基本上三個數據大體一致。當然也不排除三端同時出現數據錯誤，這需要根據實際情況進行糾正。
第三，關於未知和空數據。出現這種情況的原因有很多，但有一種情況我們可以提前避免，就是在事先設計和定義屬性時，一定要考慮到這個屬性的空狀態下該如何上報？是 0 還是空，具體如何處理需要提前考慮清楚。
4.多項目處理方法
如果同時接到多條業務線的埋點需求時，該如何選擇，是在一個項目裏埋多個應用，還是把它們隔離成不同的項目？如果做項目隔離，又涉及到從頭開始做的問題，成本較高，這時又該如何處理？
首先，用戶是最重要的基準，是否需要區分項目，取決於應用用戶的關聯性。
如果業務線之間沒有任何用戶關聯，這種情況就需要隔離處理，不僅數據和系統需要隔離，事件管理也需要隔離。比如涉及到屬性在命名上的衝突，或某些事件的衝突，會導致後面做埋點時，相同命名的屬性會報錯。 至於在實際處理時，是進行項目合併還是隔離，需要對數據互通與數據管理問題進行權衡。一方面是要考慮到數據隔離後，後續不便於做關聯分析，另一方面也要考慮到如果項目關聯過多，會導致管理難的問題，具體抉擇需要具體權衡。
5.巧用數據導入
數據導入作爲一個小工具，可以解決老用戶標註問題，及時補充老用戶數據。
在業務上線之後，通常那些在埋點之前已有的老用戶，會被錯誤地定義成新用戶，這時就可以通過數據導入工具，導入存量數據解決老用戶標註問題。
其次，通過這個工具，還可以修補因爲錯誤埋點而導致的數據問題。
最後，這個工具可以對數據維度表做有力的補充。比如採集來的訂單數據裏，有很多 ID、優惠券、活動等信息都沒有做關聯，這時通過數據導入工具，可以補充維護商品表信息，而不再需要額外地改造業務側數據。
三、如何落實應用？
1.推廣使用方法
推廣使用一般有三種方式：
第一，日常培訓，即對業務方的產品交付進行培訓講解。
第二，內部資料，編寫內部資料、說明手冊，有助於持續輸出。
第三，保持溝通，項目內外保持溝通，保證埋點的準確及迭代。
首先，這三個推廣方法息息相關，最好同時進行。
其次，所講的文檔要跟日常的培訓一一對應，考慮到產品相對複雜，加上人員迭代，在編寫內部資料時最好寫得詳細，這樣可以減少很多不必要的重複溝通。
最後，要和業務同事保持溝通，有助於後續更好地優化這套埋點體系。
2.渠道管理指南
說到渠道管理，通常大家都會通過渠道標識、活躍留存、漏斗等工具進行渠道評估。在實際應用過程中，不誇張的說，神策的渠道管理體系是我見過最好的一套管理體系。
過往遇到的其他關於用戶渠道管理體系，大多隻有一個渠道標識。如果可能，建議大家還是儘量通過多維度的渠道標識規則，完善現有體系。比如某用戶從新浪微博來，這是一層渠道標識，那它具體從微博的哪個活動來的呢，就可以再去打一層渠道標識。
另外，通過分析渠道的用戶數據表現可以瞭解重要的用戶屬性，從而賦能業務。
比如，通過渠道數據可以宏觀地看到從微博活動過來的用戶有什麼特徵？同時可以細分微博活動效果，比如某個賬號或某次活動具體效果如何？再比如，從抖音來的用戶和從微博來的用戶各有哪些不同的特質，它們的轉化率有何差異？根據這些分析結果，不斷完善市場投放思路。
3.小工具使用技巧
這部分主要講一些實用小工具，它們可以幫助我們更好地使用神策。 第一，廉價存儲，當業務積累了大量的事件數據後，通常會發現集羣存儲線上熱數據存儲空間滿了，這時要及時進行冷數據分離，多歷史數據進行歸檔。因爲它的查詢頻次較低，日常價值也不大。
第二，數據導入工具之前已經做過詳細介紹，這裏不再重複贅述。
第三，關於 JDBC，當我們把 BI 側的行爲數據和用戶數據需要進行關聯時，可以考慮通過 JDBC 直連把數據拉出來進行分析。
最後，重點分享 MQ 的妙用。在後端埋點時，會遇到一個很大的問題：當在集羣上去部署 Log 服務時，如果服務沒起來，落到集羣上的數據無法上報的，這會導致數據丟失。這種情況對於後端埋點上報可以說是一個災難性的問題。那需要怎麼解決呢？
其實如果企業內部有微服務體系的話，建議把後端埋點做成一個獨立的微服務，然後再去總線抓所有的事件，定義註冊用戶、訂閱用戶下單等。同時這樣做還有一個好處，就是我們從用戶側收集來的數據訂單可以和 BI 側、數據側進行更詳實的關聯，這相當於在入庫之前做了進一步的數據處理。
此外，神策系統裏的 Kafka 等應用也支持功能迭代。比如訂閱用戶的啓動事件、訂閱 VIP 用戶的啓動事件、訂閱用戶的下單事件等，都可以通過神策系統導出來。
四、數據埋點實操案例
最後，分享一個我之前做的項目，一個實操案例。
1.什麼是 GBDT？
之前業務方有過這樣一個需求：點擊過哪些事件的用戶，比較有可能成爲下單用戶？中間嘗試了很多分析辦法，但我最終選擇通過數據挖掘，通過 GBDT 來找答案。
什麼是 GBDT？簡言之就是：Gradient Boosting Decision Tree。這裏不詳細展開相關定義。本質上，它解決的就是找到那些擁有某些特徵的用戶，就應該是業務的下單用戶，然後再把這個模型套進來，從而找到那些最終沒有下單的用戶。
選擇 GBDT 其實有兩個原因：
第一，特徵清晰。這種方式便於特徵工程的處理，通過它可以很簡易獲取清晰的特徵。通過埋點系統可以對相關數據進行提取，甚至大概有一些 Python 基礎就可以完成。
第二，泛化性強，對新數據的適應性強，適用於較爲複雜的行爲數據特徵作爲樣本。在埋點上用這個模型，性價比非常高，可以解決很多回歸問題。
2.具體實踐流程
首先，進行特徵構建。比如對已下單的用戶，根據過往的運營經驗和策略進行特徵構建：比如他是否點擊過網點、是否關注過促銷活動、在活動頁面瀏覽了時間多長、所在地區、在什麼樣的地方打開等。
然後，把符合這些特徵完成下單的用戶拿出來，最終找到模型權重進行訓練和評估。
最後，再把這個模型去套入現有線上數據進行相關預測，方便對用戶進行召回或進一步分析流失原因。
比如，通過算法模型可以快速地找到某些完全符合這些下單特徵的用戶，比如他瀏覽的時間足夠長、他關注過活動等，他具備歸納出的下單特徵但卻沒有下單，就可以進一步分析流失的原因。同時還可以分析哪些特徵對用戶下單決策影響最大。