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

埋點

先談談埋點吧——用戶行為分析的數(shù)據(jù)來源（通俗些就是格式化，以表格形式展示的目標日志數(shù)據(jù)）。

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

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

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

How

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

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

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

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

好了，再細說一下埋點采集與數(shù)據(jù)上報：

1. 頁面采集（Page）

用戶每打開新頁面都會上報一次頁面訪問記錄（重新打開同一頁面也會再次上報）。該條記錄上報的內(nèi)容是前端預先設(shè)定（有上報需求來源于業(yè)務側(cè)），通常由頁面上報名稱和其它通用上報字段組成。通用上報字段因為是共有字段，我們最后一起說。來看看頁面上報名稱的設(shè)計，我的心得是：千萬！不要！讓前端自己決定！ 如果你希望你的數(shù)據(jù)來源一團漿糊? Whatever

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

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

2. 按鈕采集（Button）

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

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

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

3. 輸入框采集（Input）

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

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

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

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

4. 列表曝光采集（Expose）

簡單講就是給用戶看到了哪些元素。因為智能匹配或著死規(guī)則匹配的普及。每個分類的客戶都會被給到企業(yè)認為合適的行為路徑（哪一類的用戶被推薦哪一類的產(chǎn)品，跳轉(zhuǎn)哪一個頁面早已被商家安排的明明白白 ）。

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

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

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

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

#附上通用字段：

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

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

Why

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

夾個How much：因為成本賊高，真正開始為業(yè)務賦能和變現(xiàn)，需要一定時間（與人才、投入等因素相關(guān)）的迭代才能走上正軌。

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

（1）數(shù)倉大

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

（2）精準化

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

（3）查詢效率高

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

2. 為啥需要設(shè)計埋點規(guī)則和上報規(guī)范

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

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

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

稀爛的埋點上報會出現(xiàn)兩個結(jié)果：

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

戰(zhàn)士上戰(zhàn)場，數(shù)據(jù)源都是錯的，還分析個錘子。

（4）統(tǒng)一指標口徑，避免同一指標多個統(tǒng)計結(jié)果。

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

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

綜上

1. 規(guī)則及早地制定和實施，并絕對不輕易更改?！馕吨鴶?shù)據(jù)缺失或是老數(shù)據(jù)難以復用，當然你可以喊研發(fā)一次性按新規(guī)則刷個幾年的數(shù)據(jù)，如果算法得當，還能保證80%數(shù)據(jù)真實，可用。
2. 各部門嚴格按照規(guī)則實施，不管是老數(shù)據(jù)或是新需求?！@一點很重要，也是坑最多的地方。各部門有各部門的角度、理解，數(shù)據(jù)上報也不是業(yè)務核心行為。

僅個人觀感，如有謬誤，麻煩指正。

作者：范十八，公眾號：半仙范十八

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

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