與數(shù)據(jù)倉(cāng)庫(kù)合作近一年，愛(ài)恨情仇不必說(shuō)，本文僅復(fù)盤(pán)整理所學(xué)所得，希望我與讀者能從中得到收獲與啟發(fā)。

埋點(diǎn)

先談?wù)劼顸c(diǎn)吧——用戶行為分析的數(shù)據(jù)來(lái)源（通俗些就是格式化，以表格形式展示的目標(biāo)日志數(shù)據(jù)）。

戰(zhàn)士上戰(zhàn)場(chǎng)，莫得子彈 就是一個(gè)死——分析者是戰(zhàn)士，數(shù)據(jù)就是子彈，埋點(diǎn)就像制造子彈的機(jī)床。

就我所知，目前大部分企業(yè)獲取用戶行為大數(shù)據(jù)最好的方式就是在各終端設(shè)置埋點(diǎn)。目前使用的是全埋點(diǎn)的策略——也就是終端框架內(nèi)，所有可交互的元素在觸發(fā)時(shí)都會(huì)被采集。

（好像5W一下子都有了）

How

采集元素目前主要分為四大類：頁(yè)面采集（Page）[彈窗的彈出也可以歸類為頁(yè)面元素上報(bào)]、按鈕采集（Button）、輸入框采集（Input）、列表曝光采集（Expose）。

所有希望數(shù)據(jù)入庫(kù)的事業(yè)部，必須嚴(yán)格按照上報(bào)入庫(kù)流程與格式，傳入數(shù)據(jù)，并給出相應(yīng)注釋。

這是目前整個(gè)大數(shù)據(jù)側(cè)埋點(diǎn)入庫(kù)的基本框架，他對(duì)所有事業(yè)部都一視同仁，保證了行為數(shù)據(jù)入庫(kù)的規(guī)則性（覺(jué)得此處用“規(guī)范”，力度欠缺）。

規(guī)則性這個(gè)定義，在我的職業(yè)（還有學(xué)習(xí)，生活）生涯中真的很重要，很重要，很重要。特別是對(duì)數(shù)倉(cāng)這樣一個(gè)承載各方海量數(shù)據(jù)，且經(jīng)常出現(xiàn)跨系統(tǒng)關(guān)聯(lián)的載體來(lái)說(shuō)，嚴(yán)格遵循入庫(kù)規(guī)則是重中之重，否則就是一場(chǎng)災(zāi)難。

好了，再細(xì)說(shuō)一下埋點(diǎn)采集與數(shù)據(jù)上報(bào)：

1. 頁(yè)面采集（Page）

用戶每打開(kāi)新頁(yè)面都會(huì)上報(bào)一次頁(yè)面訪問(wèn)記錄（重新打開(kāi)同一頁(yè)面也會(huì)再次上報(bào)）。該條記錄上報(bào)的內(nèi)容是前端預(yù)先設(shè)定（有上報(bào)需求來(lái)源于業(yè)務(wù)側(cè)），通常由頁(yè)面上報(bào)名稱和其它通用上報(bào)字段組成。通用上報(bào)字段因?yàn)槭枪灿凶侄危覀冏詈笠黄鹫f(shuō)。來(lái)看看頁(yè)面上報(bào)名稱的設(shè)計(jì)，我的心得是：千萬(wàn)！不要！讓前端自己決定！ 如果你希望你的數(shù)據(jù)來(lái)源一團(tuán)漿糊? Whatever

頁(yè)面ID上報(bào)結(jié)構(gòu)：A_B_C_D：用這種層級(jí)下劃線連接的方式，定義上報(bào)ID，就很清晰。如：page_id = BUSA_acp_home

定義：A業(yè)務(wù)線下，頁(yè)面上報(bào)類，首頁(yè) 的頁(yè)面上報(bào)。

2. 按鈕采集（Button）

用戶每點(diǎn)擊一個(gè)按鈕都會(huì)上報(bào)一個(gè)按鈕點(diǎn)擊記錄。該條記錄上報(bào)的內(nèi)容是前端預(yù)先設(shè)定（有上報(bào)需求來(lái)源于業(yè)務(wù)側(cè)），通常由頁(yè)面上報(bào)名稱和其它通用上報(bào)字段組成。

按鈕ID上報(bào)結(jié)構(gòu)：btn_id = BUSB_acb_{prod/other/outer}_Alist#1_Productid 我仍然在用的一種按鈕上報(bào)方式，體驗(yàn)不錯(cuò)。

定義：B業(yè)務(wù)線下，按鈕上報(bào)類，{商品類，功能類，對(duì)外導(dǎo)流類 三種按鈕類型 選其一}，按鈕嵌在A列表的第二個(gè)位置（智能推薦，千人千面，此處僅代表單個(gè)用戶的情形），按鈕的產(chǎn)品號(hào)。

3. 輸入框采集（Input）

記錄用戶在文本框輸入的任何信息和動(dòng)作。包括你與意中人交流時(shí)時(shí)，反復(fù)斟酌句讀，辭藻，躊躇猶豫的矛盾心理，在此處都能記錄得明明白白。

輸入框上報(bào)結(jié)構(gòu)：1：我稀飯你很久嚕，做我女朋友中不?/2：我稀飯你很久嚕 /3：一起吃個(gè)飯吧 / 4：你在做什么？你到家了嘛

——直男聊天案例? 定義：首先輸入了1，刪除部分輸入后到2，增加輸入到3，4等等。

連帶你的初始輸入，刪除，撤回……曲折的心路歷程還有總輸入時(shí)間，都會(huì)被記錄且細(xì)化到毫秒級(jí)。所以不要再質(zhì)疑企業(yè)能獲取你的生日/身份證號(hào)/密碼等信息，數(shù)據(jù)安全真的全靠自覺(jué)（以及草票）。

4. 列表曝光采集（Expose）

簡(jiǎn)單講就是給用戶看到了哪些元素。因?yàn)橹悄芷ヅ浠蛑酪?guī)則匹配的普及。每個(gè)分類的客戶都會(huì)被給到企業(yè)認(rèn)為合適的行為路徑（哪一類的用戶被推薦哪一類的產(chǎn)品，跳轉(zhuǎn)哪一個(gè)頁(yè)面早已被商家安排的明明白白 ）。

列表曝光上報(bào)結(jié)構(gòu)：按鈕ID，所在列表，所在頁(yè)面以及其它通用上報(bào)字段。

定義：頁(yè)面下曝光了哪些列表，這些列表中又展示了哪些按鈕元素，分別在第n個(gè)位置。

5. 能采集到的東西肯定不限于此（Other）

能采集到的東西肯定不限于此（Other），終端位置，APP版本，終端內(nèi)其它APP。。。只有你想不到~

#附上通用字段：

1. 上報(bào)/采集時(shí)間
2. 來(lái)源業(yè)務(wù)線
3. 來(lái)源終端 APP/微信/官網(wǎng)
4. 來(lái)源渠道
5. 經(jīng)緯度，等等。

這個(gè)業(yè)務(wù)側(cè)可以根據(jù)業(yè)務(wù)需求增加多個(gè)，個(gè)性化很強(qiáng)的上報(bào)，放在同一個(gè)json格式的字段即可。

Why

tips：上面說(shuō)的一些東西應(yīng)該是對(duì)大數(shù)據(jù)自研比較看重的公司，才會(huì)考慮到的事情，使用三方BI服務(wù)或者對(duì)數(shù)據(jù)監(jiān)控，分析要求一般的企業(yè)may不用care這個(gè)。

夾個(gè)How much：因?yàn)槌杀举\高，真正開(kāi)始為業(yè)務(wù)賦能和變現(xiàn)，需要一定時(shí)間（與人才、投入等因素相關(guān)）的迭代才能走上正軌。

1. 為啥需要數(shù)倉(cāng)

（1）數(shù)倉(cāng)大

目前的發(fā)展態(tài)勢(shì)是業(yè)務(wù)方對(duì)數(shù)據(jù)的需要量越來(lái)越大，品類越來(lái)越多，追溯的時(shí)間越來(lái)越長(zhǎng)。如果你要求后端同學(xué)把每天上千萬(wàn)條（勿杠）的用戶記錄存在MYSQL庫(kù)中，且需要保存三年以上，不僅你的線上會(huì)土崩瓦解，開(kāi)發(fā)同學(xué)也會(huì)砍死你。恰巧數(shù)倉(cāng)放得下。它能相對(duì)精準(zhǔn)，盡可能長(zhǎng)的存貯所有數(shù)據(jù)（有價(jià)值，無(wú)價(jià)值，還未被意識(shí)到有價(jià)值）成為企業(yè)的數(shù)據(jù)資源，為業(yè)務(wù)賦能，數(shù)據(jù)分析、挖掘提供數(shù)據(jù)基礎(chǔ)。

（2）精準(zhǔn)化

格式化的存貯并展現(xiàn)海量數(shù)據(jù)，并明確數(shù)據(jù)與數(shù)據(jù)之間，表與表之間的關(guān)聯(lián)血緣。同一個(gè)商品的進(jìn)出貨，成本，利潤(rùn)，物流，評(píng)價(jià)，購(gòu)買者，購(gòu)買者的年齡，愛(ài)好，收入以及他的前世今生，如果設(shè)計(jì)有度，理論上都是能夠?qū)崿F(xiàn)的。

（3）查詢效率高

不管是SQL還是成熟的?數(shù)據(jù)產(chǎn)品，都可以高效率高指向性的獲取所需要數(shù)據(jù)，取數(shù)或者做報(bào)表（數(shù)據(jù)可視化應(yīng)該也算報(bào)表，雖然不太想承認(rèn)）

2. 為啥需要設(shè)計(jì)埋點(diǎn)規(guī)則和上報(bào)規(guī)范

（1）打通跨部門(mén)，業(yè)務(wù)線的數(shù)據(jù)通道，避免數(shù)據(jù)孤島的形成。——多部門(mén)結(jié)合用戶上下游數(shù)據(jù)，進(jìn)行數(shù)據(jù)分析或流量分發(fā)，共享時(shí)需要用戶完整的行為路徑、標(biāo)簽等數(shù)據(jù)。如果從一開(kāi)始就有相同的或相近的上報(bào)規(guī)則，后面的方案實(shí)施水到渠成。

（2）統(tǒng)一上報(bào)規(guī)范，避免重復(fù)造輪子，以及混亂數(shù)據(jù)造成的資源緊張。—— 一個(gè)上報(bào)大類只需要設(shè)計(jì)一個(gè)表結(jié)構(gòu)，明確且只需用戶付出一次認(rèn)知成本，維護(hù)成本也很有限。如果n個(gè)業(yè)務(wù)部有n個(gè)頁(yè)面上報(bào)，如果大數(shù)據(jù)側(cè)有一個(gè)需求迭代，就需要改五次。

（3）盡可能保證上報(bào)數(shù)據(jù)的純凈，易識(shí)別，邊界明確易獲取。——不管是使用SQL還是代碼獲取數(shù)據(jù)，本質(zhì)上都是挑選符合規(guī)則（呵 規(guī)則又出現(xiàn)了）的數(shù)據(jù)，結(jié)構(gòu)化輸出。

稀爛的埋點(diǎn)上報(bào)會(huì)出現(xiàn)兩個(gè)結(jié)果：

• a）大量的特殊處理? ?取一個(gè)簡(jiǎn)單的列表按鈕點(diǎn)擊你需要? case X?when 條件A ?then a?when 條件B?then b ……..end。
• b）你再怎么寫(xiě)單獨(dú)處理的規(guī)則，都取不出相對(duì)純凈的數(shù)據(jù)。核心轉(zhuǎn)化計(jì)算錯(cuò)誤，誤導(dǎo)業(yè)務(wù)側(cè)做出錯(cuò)誤的決策。

戰(zhàn)士上戰(zhàn)場(chǎng)，數(shù)據(jù)源都是錯(cuò)的，還分析個(gè)錘子。

（4）統(tǒng)一指標(biāo)口徑，避免同一指標(biāo)多個(gè)統(tǒng)計(jì)結(jié)果。

直接舉個(gè)栗子：運(yùn)營(yíng)側(cè)統(tǒng)計(jì)的日活和產(chǎn)品側(cè)統(tǒng)計(jì)的日活，最后結(jié)果相差頗大。細(xì)查發(fā)現(xiàn)是查了兩張不同的表，數(shù)據(jù)差異其實(shí)是合理的，但按理說(shuō)：兩者差異最起碼應(yīng)該小于3%。細(xì)細(xì)查發(fā)現(xiàn)，指標(biāo)口徑定義會(huì)有些許差異，一方定義了已注冊(cè)用戶的獨(dú)立用戶號(hào)User_id，一方統(tǒng)計(jì)了獨(dú)立設(shè)備號(hào)Device_id，因?yàn)椴糠謽I(yè)務(wù)并非強(qiáng)登錄，所以結(jié)果相差頗大。

所以同一個(gè)指標(biāo)名稱，同一個(gè)指標(biāo)定義，同一個(gè)取數(shù)邏輯? 這樣就不會(huì)被發(fā)現(xiàn)出了紕漏了。

綜上

1. 規(guī)則及早地制定和實(shí)施，并絕對(duì)不輕易更改。——迭代意味著數(shù)據(jù)缺失或是老數(shù)據(jù)難以復(fù)用，當(dāng)然你可以喊研發(fā)一次性按新規(guī)則刷個(gè)幾年的數(shù)據(jù)，如果算法得當(dāng)，還能保證80%數(shù)據(jù)真實(shí)，可用。
2. 各部門(mén)嚴(yán)格按照規(guī)則實(shí)施，不管是老數(shù)據(jù)或是新需求?！@一點(diǎn)很重要，也是坑最多的地方。各部門(mén)有各部門(mén)的角度、理解，數(shù)據(jù)上報(bào)也不是業(yè)務(wù)核心行為。

僅個(gè)人觀感，如有謬誤，麻煩指正。

作者：范十八，公眾號(hào)：半仙范十八

本文由 @小春EX?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議