本文根據資深數據產品經理陳家崑《從 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.具體實踐流程

首先，進行特征構建。比如對已下單的用戶，根據過往的運營經驗和策略進行特征構建：比如他是否點擊過網點、是否關注過促銷活動、在活動頁面瀏覽了時間多長、所在地區、在什么樣的地方打開等。

然后，把符合這些特征完成下單的用戶拿出來，最終找到模型權重進行訓練和評估。

最后，再把這個模型去套入現有線上數據進行相關預測，方便對用戶進行召回或進一步分析流失原因。

比如，通過算法模型可以快速地找到某些完全符合這些下單特征的用戶，比如他瀏覽的時間足夠長、他關注過活動等，他具備歸納出的下單特征但卻沒有下單，就可以進一步分析流失的原因。同時還可以分析哪些特征對用戶下單決策影響最大。

以上就是我的分享，希望能夠對大家產生一些啟發，謝謝大家！

???

【更多內容】

• 有數 ≠ 用數，來看數據應用在 E 寵如何“跑業務”

• 浙商銀行攜手神策數據，數字化轉型提升客戶體驗

• 簽約丨神策數據攜手百麗國際，專注品牌零售行業數字化未來

▼?點擊”閱讀原文“，下載演講 PPT

總結

以上是生活随笔為你收集整理的资深数据产品经理陈家崑：如何从 0 到 1 构建埋点体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。