资深数据产品经理陈家崑:如何从 0 到 1 构建埋点体系
本文根據資深數據產品經理陳家崑《從 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 构建埋点体系的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 直播预告丨如何用 A/B 测试做好一场页
- 下一篇: 基于神策用户画像,在线教育企业线索标签体