埋點(diǎn)實(shí)踐過程中遇到的一些問題

埋點(diǎn)本身現(xiàn)在已經(jīng)有太多的集成解決方案，神策、諸葛IO、GIO，但是在實(shí)踐的過程中仍然還是會(huì)碰都很多問題，這些問題都是躺過的坑。

01

梳理當(dāng)前業(yè)務(wù)，未來業(yè)務(wù)發(fā)展問題，目的是給埋點(diǎn)預(yù)留空間

① 業(yè)務(wù)兼容的問題

前期規(guī)范執(zhí)行之后，后續(xù)隨著業(yè)務(wù)的拓展，已有數(shù)據(jù)字段滿足不了業(yè)務(wù)的分析需求；

② 產(chǎn)品兼容的問題

埋點(diǎn)從應(yīng)用端來區(qū)分，web/ios/android，小程序，公眾號(hào)，然后還要區(qū)分一下是否是原生，還是H5，新老版本之間肯定會(huì)帶來一些模塊化的差異；

③ 前后端埋點(diǎn)不一致的問題

前端請(qǐng)求服務(wù)端的數(shù)據(jù)大多是存在binlog里面的，數(shù)據(jù)日志同步解析的過程里面可能會(huì)存在丟包的可能性，數(shù)倉(cāng)的穩(wěn)定性也會(huì)影響數(shù)據(jù)質(zhì)量；后端服務(wù)信息存儲(chǔ)的數(shù)據(jù)是存在mysql，表字段結(jié)構(gòu)化，分多表存儲(chǔ)，需要靠主鍵進(jìn)行關(guān)聯(lián)，有大量的ETL過程。兩者之間可能因?yàn)閿?shù)據(jù)清洗、處理、實(shí)時(shí)技術(shù)等原因，造成數(shù)據(jù)差異化；

③ 自埋點(diǎn)和第三方應(yīng)用統(tǒng)計(jì)口徑的問題

自埋點(diǎn)一般都會(huì)定義一個(gè)唯一id作為區(qū)分用戶的標(biāo)志，但是第三方是缺少用戶屬性信息的判斷，一般會(huì)以設(shè)備號(hào)uuid/imse，或者IP地址段、mac地址段作為區(qū)分標(biāo)志，從而造成統(tǒng)計(jì)數(shù)據(jù)上的差異化，對(duì)于留存分析、轉(zhuǎn)化分析、流失分析需要用到明細(xì)數(shù)據(jù)的場(chǎng)景，可兼容性不是很友好；

④ 埋點(diǎn)開發(fā)技術(shù)執(zhí)行不到位的問題

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

⑤ 多產(chǎn)品之間的模塊差異化問題

埋點(diǎn)不能夠只有一套標(biāo)準(zhǔn)規(guī)范，多生態(tài)應(yīng)用下，業(yè)務(wù)繁瑣，在產(chǎn)品、技術(shù)的架構(gòu)上有明顯的差異，不同的產(chǎn)品、模塊、坑位、點(diǎn)擊事件的定義也可能有一定的區(qū)別，這時(shí)候可能需要根據(jù)場(chǎng)景劃分不同的埋點(diǎn)標(biāo)準(zhǔn)；

⑥ 自定義埋點(diǎn)信息的鍵對(duì)設(shè)計(jì)問題

往往會(huì)在埋點(diǎn)里面增加一個(gè)json的字段（bdata），在埋點(diǎn)的時(shí)候?qū)懭胱远x的業(yè)務(wù)信息進(jìn)行場(chǎng)景識(shí)別，譬如活動(dòng)id、業(yè)務(wù)信息、用戶快照的基本信息等，不同開發(fā)寫入的自定義字段格式可能會(huì)有差異；

02

埋點(diǎn)應(yīng)用場(chǎng)景，對(duì)應(yīng)初期埋點(diǎn)預(yù)留

基于業(yè)務(wù)分析框架，梳理常規(guī)分析案例中需要用到的埋點(diǎn)數(shù)據(jù)集，核心指標(biāo)必須要有埋點(diǎn)；

基于算法模型框架，梳理算法所需要構(gòu)建的數(shù)據(jù)特征需要用到的字段信息；

基于業(yè)務(wù)訴求，梳理非常規(guī)，當(dāng)前沒需求未來有應(yīng)用場(chǎng)景的字段信息；

舉個(gè)例子，譬如供需匹配、資源調(diào)度、智能選址，所對(duì)應(yīng)的幾個(gè)信息主體分別是：用戶需求方、用戶供給方、商品信息、時(shí)間信息、空間信息、行為信息、業(yè)務(wù)信息；

03

標(biāo)簽預(yù)留場(chǎng)景，反推埋點(diǎn)預(yù)留

基于用戶畫像的標(biāo)簽建設(shè)，需要考慮畫像的多層屬性，社會(huì)屬性、基本屬性、市場(chǎng)屬性、交易屬性、行為屬性等，通過畫像篩選人群的時(shí)候，可能需要通過數(shù)據(jù)模型建立用戶分層的過程，所需要用到的輔助數(shù)據(jù)；

基于智能運(yùn)營(yíng)的標(biāo)簽建設(shè)，運(yùn)營(yíng)策略、活動(dòng)、方案的數(shù)據(jù)需求收集，哪些標(biāo)簽需要用到埋點(diǎn)中的信息；

基于營(yíng)銷系統(tǒng)的標(biāo)簽建設(shè)，涉及到渠道分配、廣告投放、點(diǎn)擊預(yù)測(cè)等，可能需要對(duì)曝光、點(diǎn)擊、轉(zhuǎn)化進(jìn)行全鏈路的埋點(diǎn)建設(shè)，或者基于某一個(gè)產(chǎn)品使用鏈路，埋點(diǎn)數(shù)據(jù)要完備；

標(biāo)簽管理，沒有一套產(chǎn)品來支撐，多標(biāo)簽?zāi)阍趺磳?duì)外提供；海量的標(biāo)簽，又要怎么做標(biāo)簽管理；

04

后面做推薦抓到核心指標(biāo)，前期做埋點(diǎn)預(yù)設(shè)

推薦算法中需要用到的數(shù)據(jù)特征中包含哪些數(shù)據(jù)指標(biāo)，其中埋點(diǎn)的部分所需要的數(shù)據(jù)格式是怎樣的；

推薦算法的設(shè)計(jì)方案，基于用戶、基于物品、協(xié)同過濾、基于規(guī)則、基于融合模型，不同的方案下，對(duì)數(shù)據(jù)底層的要求可能也會(huì)有一定的差異；

05

數(shù)倉(cāng)庫(kù)表的開發(fā)成本

埋點(diǎn)數(shù)據(jù)落到數(shù)倉(cāng)后，需要預(yù)先建立哪些表，如何做埋點(diǎn)數(shù)據(jù)的分層；

畢竟埋點(diǎn)的數(shù)據(jù)體量是非常大的，TB級(jí)數(shù)據(jù)的存儲(chǔ)本身就是一個(gè)比較大的成本，再加上調(diào)度系統(tǒng)、計(jì)算資源、運(yùn)行性能等方面，就需要數(shù)倉(cāng)團(tuán)隊(duì)在一開始就要把數(shù)據(jù)模型提前建立好，做好ods層到dw層、ads層的劃分，維度和事實(shí)之間的建設(shè)；

06

數(shù)倉(cāng)性能，時(shí)間問題（hive）

因?yàn)槁顸c(diǎn)數(shù)據(jù)的體量問題，落表的時(shí)候，一定會(huì)存在大量的冗余字段，如果集群資源比較緊張，對(duì)于常規(guī)數(shù)據(jù)的統(tǒng)計(jì)、計(jì)算都會(huì)帶來性能上的問題；

在數(shù)據(jù)團(tuán)隊(duì)的架構(gòu)中，有對(duì)外提供數(shù)據(jù)應(yīng)用服務(wù)，對(duì)于數(shù)據(jù)的實(shí)時(shí)計(jì)算就有一定的要求，什么場(chǎng)景下應(yīng)該是T+1，什么場(chǎng)景下應(yīng)該是偽實(shí)時(shí)，避免數(shù)據(jù)調(diào)度任務(wù)影響前臺(tái)應(yīng)用產(chǎn)出；

07

產(chǎn)品全埋點(diǎn)還是分塊埋點(diǎn)？分塊兒埋點(diǎn)的話有什么響應(yīng)機(jī)制？應(yīng)用措施？

全埋點(diǎn)和分模塊埋點(diǎn)，直接的影響是數(shù)據(jù)存儲(chǔ)成本的問題，作為一個(gè)數(shù)據(jù)分析，這也是不得不考慮的問題，如果數(shù)據(jù)結(jié)構(gòu)優(yōu)化不做好，每年浪費(fèi)的存儲(chǔ)成本可能會(huì)是百萬級(jí)的消耗。隨著周期的增加，成本浪費(fèi)會(huì)更嚴(yán)重。

所以說，企業(yè)數(shù)據(jù)的分析，不僅局限在數(shù)據(jù)本身，而應(yīng)該是全面的剖析，多場(chǎng)景的結(jié)合。凡事都不簡(jiǎn)單，如果簡(jiǎn)單為什么那么多人都沒有做成功，只不過是層次還到而已。

- EOF -

推薦閱讀 點(diǎn)擊標(biāo)題可跳轉(zhuǎn)

1、萬字長(zhǎng)文說透分布式鎖

2、pandas 與 GUI 界面的超強(qiáng)結(jié)合，爆贊！

3、面試，MySQL 搞透這 20 道就穩(wěn)了

看完本文有收獲？請(qǐng)轉(zhuǎn)發(fā)分享給更多人

推薦關(guān)注「數(shù)據(jù)分析與開發(fā)」，提升數(shù)據(jù)技能

點(diǎn)贊和在看就是最大的支持

原文標(biāo)題：干貨分享：埋點(diǎn)實(shí)踐過程中碰到的坑點(diǎn)集合

文章出處：【微信公眾號(hào)：數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

埋點(diǎn)本身現(xiàn)在已經(jīng)有太多的集成解決方案，神策、諸葛IO、GIO，但是在實(shí)踐的過程中仍然還是會(huì)碰都很多問題，這些問題都是躺過的坑。

01

梳理當(dāng)前業(yè)務(wù)，未來業(yè)務(wù)發(fā)展問題，目的是給埋點(diǎn)預(yù)留空間

① 業(yè)務(wù)兼容的問題

前期規(guī)范執(zhí)行之后，后續(xù)隨著業(yè)務(wù)的拓展，已有數(shù)據(jù)字段滿足不了業(yè)務(wù)的分析需求；

② 產(chǎn)品兼容的問題

埋點(diǎn)從應(yīng)用端來區(qū)分，web/ios/android，小程序，公眾號(hào)，然后還要區(qū)分一下是否是原生，還是H5，新老版本之間肯定會(huì)帶來一些模塊化的差異；

③ 前后端埋點(diǎn)不一致的問題

前端請(qǐng)求服務(wù)端的數(shù)據(jù)大多是存在binlog里面的，數(shù)據(jù)日志同步解析的過程里面可能會(huì)存在丟包的可能性，數(shù)倉(cāng)的穩(wěn)定性也會(huì)影響數(shù)據(jù)質(zhì)量；后端服務(wù)信息存儲(chǔ)的數(shù)據(jù)是存在mysql，表字段結(jié)構(gòu)化，分多表存儲(chǔ)，需要靠主鍵進(jìn)行關(guān)聯(lián)，有大量的ETL過程。兩者之間可能因?yàn)閿?shù)據(jù)清洗、處理、實(shí)時(shí)技術(shù)等原因，造成數(shù)據(jù)差異化；

③ 自埋點(diǎn)和第三方應(yīng)用統(tǒng)計(jì)口徑的問題

自埋點(diǎn)一般都會(huì)定義一個(gè)唯一id作為區(qū)分用戶的標(biāo)志，但是第三方是缺少用戶屬性信息的判斷，一般會(huì)以設(shè)備號(hào)uuid/imse，或者IP地址段、mac地址段作為區(qū)分標(biāo)志，從而造成統(tǒng)計(jì)數(shù)據(jù)上的差異化，對(duì)于留存分析、轉(zhuǎn)化分析、流失分析需要用到明細(xì)數(shù)據(jù)的場(chǎng)景，可兼容性不是很友好；

④ 埋點(diǎn)開發(fā)技術(shù)執(zhí)行不到位的問題

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

⑤ 多產(chǎn)品之間的模塊差異化問題

埋點(diǎn)不能夠只有一套標(biāo)準(zhǔn)規(guī)范，多生態(tài)應(yīng)用下，業(yè)務(wù)繁瑣，在產(chǎn)品、技術(shù)的架構(gòu)上有明顯的差異，不同的產(chǎn)品、模塊、坑位、點(diǎn)擊事件的定義也可能有一定的區(qū)別，這時(shí)候可能需要根據(jù)場(chǎng)景劃分不同的埋點(diǎn)標(biāo)準(zhǔn)；

⑥ 自定義埋點(diǎn)信息的鍵對(duì)設(shè)計(jì)問題

往往會(huì)在埋點(diǎn)里面增加一個(gè)json的字段（bdata），在埋點(diǎn)的時(shí)候?qū)懭胱远x的業(yè)務(wù)信息進(jìn)行場(chǎng)景識(shí)別，譬如活動(dòng)id、業(yè)務(wù)信息、用戶快照的基本信息等，不同開發(fā)寫入的自定義字段格式可能會(huì)有差異；

02

埋點(diǎn)應(yīng)用場(chǎng)景，對(duì)應(yīng)初期埋點(diǎn)預(yù)留

基于業(yè)務(wù)分析框架，梳理常規(guī)分析案例中需要用到的埋點(diǎn)數(shù)據(jù)集，核心指標(biāo)必須要有埋點(diǎn)；

基于算法模型框架，梳理算法所需要構(gòu)建的數(shù)據(jù)特征需要用到的字段信息；

基于業(yè)務(wù)訴求，梳理非常規(guī)，當(dāng)前沒需求未來有應(yīng)用場(chǎng)景的字段信息；

舉個(gè)例子，譬如供需匹配、資源調(diào)度、智能選址，所對(duì)應(yīng)的幾個(gè)信息主體分別是：用戶需求方、用戶供給方、商品信息、時(shí)間信息、空間信息、行為信息、業(yè)務(wù)信息；

03

標(biāo)簽預(yù)留場(chǎng)景，反推埋點(diǎn)預(yù)留

基于用戶畫像的標(biāo)簽建設(shè)，需要考慮畫像的多層屬性，社會(huì)屬性、基本屬性、市場(chǎng)屬性、交易屬性、行為屬性等，通過畫像篩選人群的時(shí)候，可能需要通過數(shù)據(jù)模型建立用戶分層的過程，所需要用到的輔助數(shù)據(jù)；

基于智能運(yùn)營(yíng)的標(biāo)簽建設(shè)，運(yùn)營(yíng)策略、活動(dòng)、方案的數(shù)據(jù)需求收集，哪些標(biāo)簽需要用到埋點(diǎn)中的信息；

基于營(yíng)銷系統(tǒng)的標(biāo)簽建設(shè)，涉及到渠道分配、廣告投放、點(diǎn)擊預(yù)測(cè)等，可能需要對(duì)曝光、點(diǎn)擊、轉(zhuǎn)化進(jìn)行全鏈路的埋點(diǎn)建設(shè)，或者基于某一個(gè)產(chǎn)品使用鏈路，埋點(diǎn)數(shù)據(jù)要完備；

標(biāo)簽管理，沒有一套產(chǎn)品來支撐，多標(biāo)簽?zāi)阍趺磳?duì)外提供；海量的標(biāo)簽，又要怎么做標(biāo)簽管理；

04

后面做推薦抓到核心指標(biāo)，前期做埋點(diǎn)預(yù)設(shè)

推薦算法中需要用到的數(shù)據(jù)特征中包含哪些數(shù)據(jù)指標(biāo)，其中埋點(diǎn)的部分所需要的數(shù)據(jù)格式是怎樣的；

推薦算法的設(shè)計(jì)方案，基于用戶、基于物品、協(xié)同過濾、基于規(guī)則、基于融合模型，不同的方案下，對(duì)數(shù)據(jù)底層的要求可能也會(huì)有一定的差異；

05

數(shù)倉(cāng)庫(kù)表的開發(fā)成本

埋點(diǎn)數(shù)據(jù)落到數(shù)倉(cāng)后，需要預(yù)先建立哪些表，如何做埋點(diǎn)數(shù)據(jù)的分層；

畢竟埋點(diǎn)的數(shù)據(jù)體量是非常大的，TB級(jí)數(shù)據(jù)的存儲(chǔ)本身就是一個(gè)比較大的成本，再加上調(diào)度系統(tǒng)、計(jì)算資源、運(yùn)行性能等方面，就需要數(shù)倉(cāng)團(tuán)隊(duì)在一開始就要把數(shù)據(jù)模型提前建立好，做好ods層到dw層、ads層的劃分，維度和事實(shí)之間的建設(shè)；

06

數(shù)倉(cāng)性能，時(shí)間問題（hive）

因?yàn)槁顸c(diǎn)數(shù)據(jù)的體量問題，落表的時(shí)候，一定會(huì)存在大量的冗余字段，如果集群資源比較緊張，對(duì)于常規(guī)數(shù)據(jù)的統(tǒng)計(jì)、計(jì)算都會(huì)帶來性能上的問題；

在數(shù)據(jù)團(tuán)隊(duì)的架構(gòu)中，有對(duì)外提供數(shù)據(jù)應(yīng)用服務(wù)，對(duì)于數(shù)據(jù)的實(shí)時(shí)計(jì)算就有一定的要求，什么場(chǎng)景下應(yīng)該是T+1，什么場(chǎng)景下應(yīng)該是偽實(shí)時(shí)，避免數(shù)據(jù)調(diào)度任務(wù)影響前臺(tái)應(yīng)用產(chǎn)出；

07

產(chǎn)品全埋點(diǎn)還是分塊埋點(diǎn)？分塊兒埋點(diǎn)的話有什么響應(yīng)機(jī)制？應(yīng)用措施？

全埋點(diǎn)和分模塊埋點(diǎn)，直接的影響是數(shù)據(jù)存儲(chǔ)成本的問題，作為一個(gè)數(shù)據(jù)分析，這也是不得不考慮的問題，如果數(shù)據(jù)結(jié)構(gòu)優(yōu)化不做好，每年浪費(fèi)的存儲(chǔ)成本可能會(huì)是百萬級(jí)的消耗。隨著周期的增加，成本浪費(fèi)會(huì)更嚴(yán)重。

所以說，企業(yè)數(shù)據(jù)的分析，不僅局限在數(shù)據(jù)本身，而應(yīng)該是全面的剖析，多場(chǎng)景的結(jié)合。凡事都不簡(jiǎn)單，如果簡(jiǎn)單為什么那么多人都沒有做成功，只不過是層次還到而已。

責(zé)任編輯：haq