埋點本身現在已經有太多的集成解決方案，神策、諸葛IO、GIO，但是在實踐的過程中仍然還是會碰都很多問題，這些問題都是躺過的坑。

01

梳理當前業務，未來業務發展問題，目的是給埋點預留空間

① 業務兼容的問題

前期規范執行之后，后續隨著業務的拓展，已有數據字段滿足不了業務的分析需求；

② 產品兼容的問題

埋點從應用端來區分，web/ios/android，小程序，公眾號，然后還要區分一下是否是原生，還是H5，新老版本之間肯定會帶來一些模塊化的差異；

③ 前后端埋點不一致的問題

前端請求服務端的數據大多是存在binlog里面的，數據日志同步解析的過程里面可能會存在丟包的可能性，數倉的穩定性也會影響數據質量；后端服務信息存儲的數據是存在mysql，表字段結構化，分多表存儲，需要靠主鍵進行關聯，有大量的ETL過程。兩者之間可能因為數據清洗、處理、實時技術等原因，造成數據差異化；

③ 自埋點和第三方應用統計口徑的問題

自埋點一般都會定義一個唯一id作為區分用戶的標志，但是第三方是缺少用戶屬性信息的判斷，一般會以設備號uuid/imse，或者IP地址段、mac地址段作為區分標志，從而造成統計數據上的差異化，對于留存分析、轉化分析、流失分析需要用到明細數據的場景，可兼容性不是很友好；

④ 埋點開發技術執行不到位的問題

絕大多數情況下我們說埋點，一般都是說前端埋點，前端開發工程師在做埋點的時候又多是人為埋點，在開發過程中，會造成部分信息冗余、重復、記錄不完整的情況存在；

⑤ 多產品之間的模塊差異化問題

埋點不能夠只有一套標準規范，多生態應用下，業務繁瑣，在產品、技術的架構上有明顯的差異，不同的產品、模塊、坑位、點擊事件的定義也可能有一定的區別，這時候可能需要根據場景劃分不同的埋點標準；

⑥ 自定義埋點信息的鍵對設計問題

往往會在埋點里面增加一個json的字段（bdata），在埋點的時候寫入自定義的業務信息進行場景識別，譬如活動id、業務信息、用戶快照的基本信息等，不同開發寫入的自定義字段格式可能會有差異；

02

埋點應用場景，對應初期埋點預留

基于業務分析框架，梳理常規分析案例中需要用到的埋點數據集，核心指標必須要有埋點；

基于算法模型框架，梳理算法所需要構建的數據特征需要用到的字段信息；

基于業務訴求，梳理非常規，當前沒需求未來有應用場景的字段信息；

舉個例子，譬如供需匹配、資源調度、智能選址，所對應的幾個信息主體分別是：用戶需求方、用戶供給方、商品信息、時間信息、空間信息、行為信息、業務信息；

03

標簽預留場景，反推埋點預留

基于用戶畫像的標簽建設，需要考慮畫像的多層屬性，社會屬性、基本屬性、市場屬性、交易屬性、行為屬性等，通過畫像篩選人群的時候，可能需要通過數據模型建立用戶分層的過程，所需要用到的輔助數據；

基于智能運營的標簽建設，運營策略、活動、方案的數據需求收集，哪些標簽需要用到埋點中的信息；

基于營銷系統的標簽建設，涉及到渠道分配、廣告投放、點擊預測等，可能需要對曝光、點擊、轉化進行全鏈路的埋點建設，或者基于某一個產品使用鏈路，埋點數據要完備；

標簽管理，沒有一套產品來支撐，多標簽你怎么對外提供；海量的標簽，又要怎么做標簽管理；

04

后面做推薦抓到核心指標，前期做埋點預設

推薦算法中需要用到的數據特征中包含哪些數據指標，其中埋點的部分所需要的數據格式是怎樣的；

推薦算法的設計方案，基于用戶、基于物品、協同過濾、基于規則、基于融合模型，不同的方案下，對數據底層的要求可能也會有一定的差異；

05

數倉庫表的開發成本

埋點數據落到數倉后，需要預先建立哪些表，如何做埋點數據的分層；

畢竟埋點的數據體量是非常大的，TB級數據的存儲本身就是一個比較大的成本，再加上調度系統、計算資源、運行性能等方面，就需要數倉團隊在一開始就要把數據模型提前建立好，做好ods層到dw層、ads層的劃分，維度和事實之間的建設；

06

數倉性能，時間問題（hive）

因為埋點數據的體量問題，落表的時候，一定會存在大量的冗余字段，如果集群資源比較緊張，對于常規數據的統計、計算都會帶來性能上的問題；

在數據團隊的架構中，有對外提供數據應用服務，對于數據的實時計算就有一定的要求，什么場景下應該是T+1，什么場景下應該是偽實時，避免數據調度任務影響前臺應用產出；

07

產品全埋點還是分塊埋點？分塊兒埋點的話有什么響應機制？應用措施？

全埋點和分模塊埋點，直接的影響是數據存儲成本的問題，作為一個數據分析，這也是不得不考慮的問題，如果數據結構優化不做好，每年浪費的存儲成本可能會是百萬級的消耗。隨著周期的增加，成本浪費會更嚴重。

所以說，企業數據的分析，不僅局限在數據本身，而應該是全面的剖析，多場景的結合。凡事都不簡單，如果簡單為什么那么多人都沒有做成功，只不過是層次還到而已。

- EOF -

推薦閱讀 點擊標題可跳轉

1、萬字長文說透分布式鎖

2、pandas 與 GUI 界面的超強結合，爆贊！

3、面試，MySQL 搞透這 20 道就穩了

看完本文有收獲？請轉發分享給更多人

推薦關注「數據分析與開發」，提升數據技能

點贊和在看就是最大的支持

原文標題：干貨分享：埋點實踐過程中碰到的坑點集合

文章出處：【微信公眾號：數據分析與開發】歡迎添加關注！文章轉載請注明出處。

埋點本身現在已經有太多的集成解決方案，神策、諸葛IO、GIO，但是在實踐的過程中仍然還是會碰都很多問題，這些問題都是躺過的坑。

01

梳理當前業務，未來業務發展問題，目的是給埋點預留空間

① 業務兼容的問題

前期規范執行之后，后續隨著業務的拓展，已有數據字段滿足不了業務的分析需求；

② 產品兼容的問題

埋點從應用端來區分，web/ios/android，小程序，公眾號，然后還要區分一下是否是原生，還是H5，新老版本之間肯定會帶來一些模塊化的差異；

③ 前后端埋點不一致的問題

前端請求服務端的數據大多是存在binlog里面的，數據日志同步解析的過程里面可能會存在丟包的可能性，數倉的穩定性也會影響數據質量；后端服務信息存儲的數據是存在mysql，表字段結構化，分多表存儲，需要靠主鍵進行關聯，有大量的ETL過程。兩者之間可能因為數據清洗、處理、實時技術等原因，造成數據差異化；

③ 自埋點和第三方應用統計口徑的問題

自埋點一般都會定義一個唯一id作為區分用戶的標志，但是第三方是缺少用戶屬性信息的判斷，一般會以設備號uuid/imse，或者IP地址段、mac地址段作為區分標志，從而造成統計數據上的差異化，對于留存分析、轉化分析、流失分析需要用到明細數據的場景，可兼容性不是很友好；

④ 埋點開發技術執行不到位的問題

絕大多數情況下我們說埋點，一般都是說前端埋點，前端開發工程師在做埋點的時候又多是人為埋點，在開發過程中，會造成部分信息冗余、重復、記錄不完整的情況存在；

⑤ 多產品之間的模塊差異化問題

埋點不能夠只有一套標準規范，多生態應用下，業務繁瑣，在產品、技術的架構上有明顯的差異，不同的產品、模塊、坑位、點擊事件的定義也可能有一定的區別，這時候可能需要根據場景劃分不同的埋點標準；

⑥ 自定義埋點信息的鍵對設計問題

往往會在埋點里面增加一個json的字段（bdata），在埋點的時候寫入自定義的業務信息進行場景識別，譬如活動id、業務信息、用戶快照的基本信息等，不同開發寫入的自定義字段格式可能會有差異；

02

埋點應用場景，對應初期埋點預留

基于業務分析框架，梳理常規分析案例中需要用到的埋點數據集，核心指標必須要有埋點；

基于算法模型框架，梳理算法所需要構建的數據特征需要用到的字段信息；

基于業務訴求，梳理非常規，當前沒需求未來有應用場景的字段信息；

舉個例子，譬如供需匹配、資源調度、智能選址，所對應的幾個信息主體分別是：用戶需求方、用戶供給方、商品信息、時間信息、空間信息、行為信息、業務信息；

03

標簽預留場景，反推埋點預留

基于用戶畫像的標簽建設，需要考慮畫像的多層屬性，社會屬性、基本屬性、市場屬性、交易屬性、行為屬性等，通過畫像篩選人群的時候，可能需要通過數據模型建立用戶分層的過程，所需要用到的輔助數據；

基于智能運營的標簽建設，運營策略、活動、方案的數據需求收集，哪些標簽需要用到埋點中的信息；

基于營銷系統的標簽建設，涉及到渠道分配、廣告投放、點擊預測等，可能需要對曝光、點擊、轉化進行全鏈路的埋點建設，或者基于某一個產品使用鏈路，埋點數據要完備；

標簽管理，沒有一套產品來支撐，多標簽你怎么對外提供；海量的標簽，又要怎么做標簽管理；

04

后面做推薦抓到核心指標，前期做埋點預設

推薦算法中需要用到的數據特征中包含哪些數據指標，其中埋點的部分所需要的數據格式是怎樣的；

推薦算法的設計方案，基于用戶、基于物品、協同過濾、基于規則、基于融合模型，不同的方案下，對數據底層的要求可能也會有一定的差異；

05

數倉庫表的開發成本

埋點數據落到數倉后，需要預先建立哪些表，如何做埋點數據的分層；

畢竟埋點的數據體量是非常大的，TB級數據的存儲本身就是一個比較大的成本，再加上調度系統、計算資源、運行性能等方面，就需要數倉團隊在一開始就要把數據模型提前建立好，做好ods層到dw層、ads層的劃分，維度和事實之間的建設；

06

數倉性能，時間問題（hive）

因為埋點數據的體量問題，落表的時候，一定會存在大量的冗余字段，如果集群資源比較緊張，對于常規數據的統計、計算都會帶來性能上的問題；

在數據團隊的架構中，有對外提供數據應用服務，對于數據的實時計算就有一定的要求，什么場景下應該是T+1，什么場景下應該是偽實時，避免數據調度任務影響前臺應用產出；

07

產品全埋點還是分塊埋點？分塊兒埋點的話有什么響應機制？應用措施？

全埋點和分模塊埋點，直接的影響是數據存儲成本的問題，作為一個數據分析，這也是不得不考慮的問題，如果數據結構優化不做好，每年浪費的存儲成本可能會是百萬級的消耗。隨著周期的增加，成本浪費會更嚴重。

所以說，企業數據的分析，不僅局限在數據本身，而應該是全面的剖析，多場景的結合。凡事都不簡單，如果簡單為什么那么多人都沒有做成功，只不過是層次還到而已。

責任編輯：haq