中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

埋點

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

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

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

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

How

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

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

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

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

好了，再細說一下埋點采集與數據上報：

1. 頁面采集（Page）

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

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

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

2. 按鈕采集（Button）

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

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

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

3. 輸入框采集（Input）

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

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

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

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

4. 列表曝光采集（Expose）

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

列表曝光上報結構：按鈕ID，所在列表，所在頁面以及其它通用上報字段。

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

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

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

#附上通用字段：

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

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

Why

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

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

1. 為啥需要數倉

（1）數倉大

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

（2）精準化

格式化的存貯并展現海量數據，并明確數據與數據之間，表與表之間的關聯血緣。同一個商品的進出貨，成本，利潤，物流，評價，購買者，購買者的年齡，愛好，收入以及他的前世今生，如果設計有度，理論上都是能夠實現的。

（3）查詢效率高

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

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

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

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

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

稀爛的埋點上報會出現兩個結果：

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

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

（4）統一指標口徑，避免同一指標多個統計結果。

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

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

綜上

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

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

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

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

題圖來自Unsplash，基于CC0協議