資深數(shù)據(jù)產(chǎn)品經(jīng)理：如何從0到1構建埋點體系

本文根據(jù)資深數(shù)據(jù)產(chǎn)品經(jīng)理陳家崑《從 0 到 1 埋點體系指南》的分享內容整理。主要內容如下：

• 首次開荒指南

• 埋點體系迭代指南

• 體系落地指南

• 數(shù)據(jù)埋點實操案例

一、開荒

所謂開荒，指的是初次接觸埋點或神策的階段。

1.定位：一個容易忽視的儀式

關于埋點系統(tǒng)的定位，需要想清楚三個問題：

第一，有沒有清晰的認知，埋點系統(tǒng)所承擔的用途是什么？

作為業(yè)務埋點對接人，需要想清楚埋點系統(tǒng)所承擔的用途是什么？它在整個公司業(yè)務體系中的定位是什么？如果沒有對這個工具定位好，后續(xù)推廣使用及跨部門合作時，可能會產(chǎn)生沖突或者與其他工具的定位重復或矛盾。

第二，有沒有明確的需求，而不是“為了埋點而埋點”。

在面臨具體埋點需求時，需要進一步明確它的使用價值是什么、能為業(yè)務解決什么問題。在我過往接觸過的業(yè)務線中，有的為了埋點而埋點，沒有想清楚具體該怎么使用，這樣很容易造成大量垃圾數(shù)據(jù)。

尤其當用戶客群較大時，對應的數(shù)據(jù)量也是非常兇猛的，常常令人措手不及，比如使用若干個月后，發(fā)現(xiàn)線上存儲空間不足，系統(tǒng)性能不夠等，這些問題的治理繁瑣又困難。

第三，有沒有明確的規(guī)劃？

在實際調動公司資源去落地構建埋點體系時，需要一定的節(jié)奏。因為正常產(chǎn)品開發(fā)也需要遵循著這樣的原則，要進行一定的規(guī)劃。

總之，基于這三個問題，我們要考慮清楚定位。

2.把埋點體系作為數(shù)據(jù)中臺或 BI 體系的重要組成部分

埋點系統(tǒng)和數(shù)據(jù)倉庫、分析體系、預警系統(tǒng)等子系統(tǒng)一樣，需要放入整個公司的業(yè)務體系和數(shù)據(jù)體系里，方便統(tǒng)一規(guī)劃。

不得不說，神策的不可替代性很強。因為埋點采集技術難度較大，如果沒有經(jīng)驗的話，成本就比較高。

至于成為整個數(shù)據(jù)體系有什么樣的好處呢？

首先，可以把行為數(shù)據(jù)作為數(shù)據(jù)體系的一部分進行整合。

行為數(shù)據(jù)，換一個角度看也是一種業(yè)務數(shù)據(jù)，這種數(shù)據(jù)在業(yè)務系統(tǒng)里無法采集。建議把它作為一個數(shù)據(jù)源，方便把整個用戶行為數(shù)據(jù)關聯(lián)到業(yè)務或外部數(shù)據(jù)。

其次，可以把此時此刻的用戶數(shù)據(jù)特征作為屬性補充行為數(shù)據(jù)。

整個數(shù)據(jù)體系中，有些數(shù)據(jù)在前端埋點時無法采集。比如在做某些優(yōu)惠券邏輯時，只會傳一個 ID 到前端頁面上，實際再去埋點時，也只能拿到這些 ID 信息，其他無法采集。解決這個問題有很多辦法，但通過前端業(yè)務側解決的方式，通常風險比較大，因為要考慮接口設計、性能及各種并發(fā)問題，如果把這些數(shù)據(jù)問題放在業(yè)務側，將會受到一定的阻力。

而如果通過數(shù)據(jù)側解決會相對容易，比如把 ID 采集回來后，它的優(yōu)惠價格、歷史信息及其所承載的數(shù)據(jù)含義等信息，在數(shù)據(jù)側都可以直接關聯(lián)。

3.以項目視角看產(chǎn)品

之所以談到項目化，因為埋點體系搭建既是一個產(chǎn)品規(guī)劃問題，也是一個項目管理問題。建議在開荒階段，就要把這個項目的過程籌備好。

接下來根據(jù)自己過往所經(jīng)歷的項目籌建經(jīng)歷，跟大家分享一些實操經(jīng)驗。

第一，樹立項目意識，因為它既是一個產(chǎn)品規(guī)劃問題，也是一個項目管理問題。

第二，制定標準化流程，包括需求收集、討論、評審，到開發(fā)、測試、上線、迭代等，任何在前后端進行開發(fā)所需要經(jīng)歷的過程，一個都不能缺少。

如果缺少了某個環(huán)節(jié)就容易產(chǎn)生大的問題，比如如果沒有測試，那數(shù)據(jù)質量就無法保證，一旦產(chǎn)生問題，如何修復大量的數(shù)據(jù)，如何補充屬性糾正問題，都是比較麻煩的事情。

第三，明確項目內外的角色和分工，以我過往項目經(jīng)歷為例，當時把來自不同的業(yè)務線的同事，比如客戶端、策略后臺算法、分析師等組成虛擬團隊，集中明確各自分工，這里特別強調下技術和測試環(huán)節(jié)。

技術環(huán)節(jié)，建議項目相關的技術同學都要去熟悉相關文檔，如果不熟悉就直接上手操作，加上不同技術同事輪流去做，會很難沉淀下來一些方法論。

測試環(huán)節(jié)也一樣，如何使用埋點工具、如何在控制臺排查問題，測試同事都需要一定的時間去熟悉。可能只有經(jīng)過兩次版本迭代后，才會對整個流程熟悉，做到心里有數(shù)。建議大家重點培養(yǎng)測試同學對數(shù)據(jù)問題的敏感性。只有保證整個測試環(huán)節(jié)的質量沒有問題，后續(xù)的分析算法的應用才能真正能發(fā)揮出價值。

第四，確認技術點，這里需要注意一些細則，比如用戶 ID 是一對一的關聯(lián)，還是一對多的關聯(lián)？以電商公司為例，涉及到買手機的場景時，很多用戶都是拿著舊手機買新手機，建議做成一對多的關系，因為很多用戶拿來的舊手機基本不用了，如果成交，做成一對一關聯(lián)的話就會被誤認為是兩個用戶。

第五，關于使用邊界或項目邊界問題，在日常做埋點時，經(jīng)常會面臨不同的業(yè)務線同步進行，這時就需要明確各業(yè)務線的邊界。涉及到各業(yè)務線私有的東西，每條業(yè)務線自己負責，而涉及到公共的東西，需要大家一起去完善和維護。

第六，關于項目籌劃，建議把相關責任人用清單的方式列下來，明確各自責任，并且通過郵件等方式公開留底，后續(xù)再去推廣業(yè)務時會比較順暢。

4.需求整理最好前置

第一，埋點規(guī)劃。在對埋點需求進行規(guī)劃時，切忌一次性完成大量需求，最好對需求進行優(yōu)先級排序處理，這樣有助于管理產(chǎn)品文檔，如果一次性處理幾百個埋點，加上涉及到跨部門協(xié)同，撰寫時難免會有紕漏，所以埋點規(guī)劃的節(jié)奏非常重要。

第二，用戶屬性。設計埋點時要考慮用戶屬性設計。設計用戶屬性時，需要遵循一個最基本的原則，就是通過事件分析系統(tǒng)、用戶標簽、用戶畫像系統(tǒng)計算出來的東西，就不要單獨上報埋點。

比如想要獲取用戶近幾日的消費單數(shù)，或是確認他是否為 VIP 用戶，這些數(shù)據(jù)需求都可以通過事件計算出來。如果再單獨埋點，不但會浪費開發(fā)資源，而且上報來的結果遠不如整個系統(tǒng)內環(huán)計算來的靈活。

需要注意的是，下面兩個屬性非常值得埋。一個是靜態(tài)屬性，比如說用戶年齡、性別等，這些靜態(tài)屬性無法算出來，很有埋點的必要。另一個是通過算法和數(shù)據(jù)挖掘產(chǎn)生的挖掘標簽，也值得單獨埋點。

第三，了解預制屬性。建議大家多多通讀了解預制屬性，一方面是防止事件所采集的屬性，跟預制屬性有所重疊。

另一方面，通過預制屬性，可以了解各端的數(shù)據(jù)特性，比如小程序的特性如何，它在封閉環(huán)境里可以返回哪些數(shù)據(jù)、不返回哪些數(shù)據(jù)？比如 H5 特性如何，客戶端特性如何等等。

第四，確定節(jié)點口徑。通常，一個事件會有很多下沉節(jié)點，比如某個按鈕的點擊事件，從用戶在 APP 層的點擊，到 APP 去請求應用接口，到服務器去確定接口，接到了請求后，到業(yè)務側后臺系統(tǒng)處理這個請求時是否成功，再到最后是否能把結果成功返回給客戶端。

因此，整理需求做事件設計時，一定要明確它的節(jié)點口徑，明確需要在什么樣的層級采集。具體來看，一方面需要想清楚在哪個節(jié)點采集，另一方面也要看具體需求，在什么樣的環(huán)境采集。通常來說，越靠近 APP 端，它所采集的事件越大，但可能對比業(yè)務端來說，它的準確性會相對較低。

二、迭代

完成了前面的基礎工作后，埋點體系經(jīng)過 1-2 個版本后初見成效，這時開始面臨如何拓展使用，如何管理大量的數(shù)據(jù)需求的問題。同時，還伴隨著如下問題：隨著時間的推移埋點文檔越寫越多、越寫越亂；不清楚的埋點定義越來越多；相關項目人員離職，未做相關交接等。

1.事件分類

根據(jù)所要埋的事件類型進行分類很有必要，一方面方便對需求進行優(yōu)先級確認，另一方面設計埋點時，不同類型的事件需要對應各自的方法。

（1）通用事件

對于通用的、泛化性的、活動等次要流程事件，可以進行抽象化處理。

比如，在日常工作中，經(jīng)常遇到市場或活動運營同事提出某次活動的埋點需求，如果每次活動都單獨處理成一個事件，隨著時間的推移將會導致同類事件越積越多，不利于管理，因此對于這類相關的事件，需要進行抽象化的通用事件處理。

（2）邊緣事件

所謂邊緣事件，指的是零散的只查看點擊或瀏覽行為的事件，比如 APP 端諸如設置、客服入口等功能按鈕。

處理此類事件，有兩種常見方法：

一種是做一個最基本的自定義事件容器，然后把相關按鈕名稱、所在頁面及其他零散東西抽象化后放進去。

另一種是手動糾正一些全埋點進行上報。之所以要手動糾正，是因為前后端的技術架構不同，沒有辦法 100% 地適應全埋點，當全埋點數(shù)據(jù)出現(xiàn)未知或無法采集時，需要手動調 SDK，糾正所要采集的頁面。

2.事件管理方法

當處理的事件數(shù)量越來越多時，就需要進行相應的管理，具體方法如下

第一，關于埋點系統(tǒng)的 WIKI 文檔一定要放到云端留存，方便項目管理和及時查詢；

第二，為了方便跨部門溝通和前后交接，埋點體系項目組成員在撰寫 WIKI 文檔時，最好明確出一套文檔規(guī)范，防止以各自形式撰寫，導致后續(xù)加入的人查看時摸不著頭腦；

第三，通過事件描述尋找頁面和翻查代碼來修補問題事件，方便解決歷史遺留問題；

第四，定期進行清點和梳理，具體可以在 admin 賬號里進行系統(tǒng)診斷，定期地導出診斷報告，便于對不合理、低性價比事件及時進行清理。

3.問題排查技巧

問題排查這塊，主要講日常應用中常遇到的三個問題。

第一，數(shù)據(jù)一致性問題。當埋點系統(tǒng)收集的數(shù)據(jù)和業(yè)務端、BI 等系統(tǒng)數(shù)據(jù)節(jié)點或口徑不一致時，該如何處理？

比如，關于新用戶與老用戶的定義差異，當埋點所定義的概念和市場及運營端同事的口徑不同時，就會造成數(shù)據(jù)對不上的問題。如何應對這種情況呢？建議先跟運營或是對應的產(chǎn)品同事了解相關指標，它的口徑和節(jié)點是怎樣的，及時去修改屬性和描述，比如不要籠統(tǒng)地定義為老用戶或新用戶，而是定義為注冊用戶、認證用戶或下單用戶等。

第二，關于準確性挑戰(zhàn)。把埋點系統(tǒng)的數(shù)據(jù)與業(yè)務端、BI 端數(shù)據(jù)進行校對，基本上三個數(shù)據(jù)大體一致。當然也不排除三端同時出現(xiàn)數(shù)據(jù)錯誤，這需要根據(jù)實際情況進行糾正。

第三，關于未知和空數(shù)據(jù)。出現(xiàn)這種情況的原因有很多，但有一種情況我們可以提前避免，就是在事先設計和定義屬性時，一定要考慮到這個屬性的空狀態(tài)下該如何上報？是 0 還是空，具體如何處理需要提前考慮清楚。

4.多項目處理方法

如果同時接到多條業(yè)務線的埋點需求時，該如何選擇，是在一個項目里埋多個應用，還是把它們隔離成不同的項目？如果做項目隔離，又涉及到從頭開始做的問題，成本較高，這時又該如何處理？

首先，用戶是最重要的基準，是否需要區(qū)分項目，取決于應用用戶的關聯(lián)性。

如果業(yè)務線之間沒有任何用戶關聯(lián)，這種情況就需要隔離處理，不僅數(shù)據(jù)和系統(tǒng)需要隔離，事件管理也需要隔離。比如涉及到屬性在命名上的沖突，或某些事件的沖突，會導致后面做埋點時，相同命名的屬性會報錯。

至于在實際處理時，是進行項目合并還是隔離，需要對數(shù)據(jù)互通與數(shù)據(jù)管理問題進行權衡。一方面是要考慮到數(shù)據(jù)隔離后，后續(xù)不便于做關聯(lián)分析，另一方面也要考慮到如果項目關聯(lián)過多，會導致管理難的問題，具體抉擇需要具體權衡。

5.巧用數(shù)據(jù)導入

數(shù)據(jù)導入作為一個小工具，可以解決老用戶標注問題，及時補充老用戶數(shù)據(jù)。

在業(yè)務上線之后，通常那些在埋點之前已有的老用戶，會被錯誤地定義成新用戶，這時就可以通過數(shù)據(jù)導入工具，導入存量數(shù)據(jù)解決老用戶標注問題。

其次，通過這個工具，還可以修補因為錯誤埋點而導致的數(shù)據(jù)問題。

最后，這個工具可以對數(shù)據(jù)維度表做有力的補充。比如采集來的訂單數(shù)據(jù)里，有很多 ID、優(yōu)惠券、活動等信息都沒有做關聯(lián)，這時通過數(shù)據(jù)導入工具，可以補充維護商品表信息，而不再需要額外地改造業(yè)務側數(shù)據(jù)。

三、如何落實應用？

1.推廣使用方法

推廣使用一般有三種方式：

第一，日常培訓，即對業(yè)務方的產(chǎn)品交付進行培訓講解。

第二，內部資料，編寫內部資料、說明手冊，有助于持續(xù)輸出。

第三，保持溝通，項目內外保持溝通，保證埋點的準確及迭代。

首先，這三個推廣方法息息相關，最好同時進行。

其次，所講的文檔要跟日常的培訓一一對應，考慮到產(chǎn)品相對復雜，加上人員迭代，在編寫內部資料時最好寫得詳細，這樣可以減少很多不必要的重復溝通。

最后，要和業(yè)務同事保持溝通，有助于后續(xù)更好地優(yōu)化這套埋點體系。

2.渠道管理指南

說到渠道管理，通常大家都會通過渠道標識、活躍留存、漏斗等工具進行渠道評估。在實際應用過程中，不夸張的說，神策的渠道管理體系是我見過最好的一套管理體系。

過往遇到的其他關于用戶渠道管理體系，大多只有一個渠道標識。如果可能，建議大家還是盡量通過多維度的渠道標識規(guī)則，完善現(xiàn)有體系。比如某用戶從新浪微博來，這是一層渠道標識，那它具體從微博的哪個活動來的呢，就可以再去打一層渠道標識。

另外，通過分析渠道的用戶數(shù)據(jù)表現(xiàn)可以了解重要的用戶屬性，從而賦能業(yè)務。

比如，通過渠道數(shù)據(jù)可以宏觀地看到從微博活動過來的用戶有什么特征？同時可以細分微博活動效果，比如某個賬號或某次活動具體效果如何？再比如，從抖音來的用戶和從微博來的用戶各有哪些不同的特質，它們的轉化率有何差異？根據(jù)這些分析結果，不斷完善市場投放思路。

3.小工具使用技巧

這部分主要講一些實用小工具，它們可以幫助我們更好地使用神策。

第一，廉價存儲，當業(yè)務積累了大量的事件數(shù)據(jù)后，通常會發(fā)現(xiàn)集群存儲線上熱數(shù)據(jù)存儲空間滿了，這時要及時進行冷數(shù)據(jù)分離，多歷史數(shù)據(jù)進行歸檔。因為它的查詢頻次較低，日常價值也不大。

第二，數(shù)據(jù)導入工具之前已經(jīng)做過詳細介紹，這里不再重復贅述。

第三，關于 JDBC，當我們把 BI 側的行為數(shù)據(jù)和用戶數(shù)據(jù)需要進行關聯(lián)時，可以考慮通過 JDBC 直連把數(shù)據(jù)拉出來進行分析。

最后，重點分享 MQ 的妙用。在后端埋點時，會遇到一個很大的問題：當在集群上去部署 Log 服務時，如果服務沒起來，落到集群上的數(shù)據(jù)無法上報的，這會導致數(shù)據(jù)丟失。這種情況對于后端埋點上報可以說是一個災難性的問題。那需要怎么解決呢？

其實如果企業(yè)內部有微服務體系的話，建議把后端埋點做成一個獨立的微服務，然后再去總線抓所有的事件，定義注冊用戶、訂閱用戶下單等。同時這樣做還有一個好處，就是我們從用戶側收集來的數(shù)據(jù)訂單可以和 BI 側、數(shù)據(jù)側進行更詳實的關聯(lián)，這相當于在入庫之前做了進一步的數(shù)據(jù)處理。

此外，神策系統(tǒng)里的 Kafka 等應用也支持功能迭代。比如訂閱用戶的啟動事件、訂閱 VIP 用戶的啟動事件、訂閱用戶的下單事件等，都可以通過神策系統(tǒng)導出來。

四、數(shù)據(jù)埋點實操案例

最后，分享一個我之前做的項目，一個實操案例。

1.什么是 GBDT？

之前業(yè)務方有過這樣一個需求：點擊過哪些事件的用戶，比較有可能成為下單用戶？中間嘗試了很多分析辦法，但我最終選擇通過數(shù)據(jù)挖掘，通過 GBDT 來找答案。

什么是 GBDT？簡言之就是：Gradient Boosting Decision Tree。這里不詳細展開相關定義。本質上，它解決的就是找到那些擁有某些特征的用戶，就應該是業(yè)務的下單用戶，然后再把這個模型套進來，從而找到那些最終沒有下單的用戶。

選擇 GBDT 其實有兩個原因：

第一，特征清晰。這種方式便于特征工程的處理，通過它可以很簡易獲取清晰的特征。通過埋點系統(tǒng)可以對相關數(shù)據(jù)進行提取，甚至大概有一些 Python 基礎就可以完成。

第二，泛化性強，對新數(shù)據(jù)的適應性強，適用于較為復雜的行為數(shù)據(jù)特征作為樣本。在埋點上用這個模型，性價比非常高，可以解決很多回歸問題。

2.具體實踐流程

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

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

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

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

• 中國最有錢大學排行，誰是最有錢的大學？

• 智能推薦七大玩法場景化解讀和效果評估體系
  

• 【新鮮】大數(shù)據(jù)學習資料包（6月版本）