前言
本系列的技術文章不涉及實現細節，僅探討實現思路。由于數據倉庫不僅僅是一個理論概念，其數據質量等原則包含了大量的技術實現細節，因此從數據采集開始，到數據處理，至最終的數據展現，都需要進行原理上和實現上的思路分析，才能保證最終數據倉庫理論的完整實現。另外，需要強調的是，本系列文章非原創，是筆者多年從業經歷的一種思路整理，對于日常理解數據倉庫的實現有著很大的幫助，因而用到了非常多其他文章的引用，并介紹很多業界的好用工具及優秀做法。
一、技術路線圖
二、Web端日志采集的業務概述
Web端數據采集主要通過三種方式實現：服務器日志、URL解析及JS回傳，詳情如下：
- 服務器日志 ，指Web服務器軟件，例如Httpd、Nginx、Tomcat等自帶的日志，例如Nginx的access.log日志等。
- URL解析 ，指訪問服務器時，將URL信息及攜帶的參數進行解析后，上傳服務器，例如訪問百度首頁：https://www.baidu.com/s?ie=utf-8&wd=你好，我們可以獲得本次訪問的word為“你好”。
- JS回傳 ，指在Web頁面上添加的各類統計插件，通過在頁面嵌入自定義的JAVAscript代碼來獲取用戶的訪問行為(比如鼠標懸停的位置，點擊的頁面組件等)，然后通過Ajax請求到后臺記錄日志。
瀏覽器的日志采集種類可以分為兩大類：
- 頁面瀏覽日志 ：別名為“展現日志”；指當一個頁面被瀏覽器加載時所采集的日志，該類型為最基礎的互聯網日志，也是PV及UV統計的基礎。
- 頁面交互日志 ：別名為“點擊日志”；指當頁面加載和渲染完成后，用戶可以在頁面上執行的各類操作，以便量化感知用戶的興趣點。
除此之外，還有一些針對特定場合統計的日志，例如頁面曝光時長日志、用戶在線操作監控等，但原理都基于上述兩類日志，只是在統計上有所區分。
Web端重要指標主要包括三個部分：
- 頁面瀏覽 ：PV、UV、IP、跳出率、平均訪問時長、轉化次數等。
- 頁面交互 ：搜索詞、控件點擊、頁面跳轉等。
- 其他 ：轉化路徑分析、設備分析、訪客分析、系統環境、地域分布等。
三、Web端日志采集流程
目前典型的網頁訪問過程是以瀏覽器請求、服務器響應并返回所請求的內容為主，主要傳輸html文檔，瀏覽器和服務器之間的通信普遍遵守HTTP協議，并逐漸過渡到最新的HTTP2.0版本。一次典型的訪問過程由如下幾部分組成：
- 用戶在瀏覽器中點擊網頁鏈接。
- 瀏覽器在執行時，會解析用戶請求內容，并按照HTTP協議中約定的格式將其轉化為一個 HTTP請求 發送出去。
- 服務器按照業務邏輯處理本次請求，并按照 HTTP協議規定 的格式，將響應結果返回瀏覽器。
- 瀏覽器收到服務器相應內容，并將其按照文檔規范展現給用戶。
在實際的處理過程中，前三步是無法采集用戶的瀏覽日志，采集主要在第四步，也就是瀏覽器解析文檔時才能進行。因此可以很自然的想得到，HTML文檔中適當位置增加一個日志采集節點，當瀏覽器解析到這個節點時，便會發出一個特定的HTTP請求到日志采集服務器，日志采集服務器接收到請求時，便可以確定瀏覽器已經成功接收和打開了頁面。目前業界常見的日志采集方案，只是在實現的細節上有所不同，原理都是相通的。
但只統計頁面流浪是不能滿足業務需求的，很多場合下用戶的具體行為特征也需要采集，因為往往會在特定的位置添加一個JS空間，當用戶在頁面上執行某個行為時，便會觸發一個異步請求，按照約定的格式向日志服務器發送點擊、等待、報錯等交互行為。
四、Web端日志的清洗和預處理
在大部分場合下，直接收到的日志不能提供給下游使用，只能作為ODS基礎日志進行保存，由于大數據平臺的半結構化特征要求，需要進行一些修正，轉化為DWD基礎日志才可以使用，具體原因有如下幾種：
- 反作弊、反爬蟲、反攻擊要求 ：由于Web端日志是互聯網行業大數據分析的基礎數據源，在實際業務場景下，往往會包含比例不小的惡意攻擊行為，例如流量作弊、爬蟲抓取、流量攻擊等，導致日志相關統計指標發生明顯的偏差。為此需要進行日志合法性的校驗，并由專門的團隊來處理相關攻擊，這是一個長期而艱苦的過程。
- 數據項修正 ：為了保證后續日志應用的統計口徑統一，往往需要對日志中一些公用且重要的數據值做歸一、標準化處理或反向補正。例如用戶登錄后，需要對登錄前的日志做身份信息回補、例如當金額信息因為部分原因出現負值時，需要人工進行補正操作，等等。
- 無效數據剔除 ：在很多情況下，因為業務變更等原因，會導致采集到的非常多的無意義數據，在特定統計情況下會干擾最終指標的實現。要知道，很多運營對于哪怕一個百分點都要扣的非常仔細，如果發現因為一些無效數據導致KPI發生了偏差，結果會非常不妙。為了避免此類異常的發生，需要定時更新處理代碼，以處理掉已經不需要的統計日志。
- 日志隔離分發 ：如果團隊規模變得非常龐大時，很多數據，例如實際金額等，就不可能全部對外公開了，需要走特殊的采集流程，以保障數據的安全和隱私。
五、漏斗模型簡介
Web端的分析經常用到的模型為：漏斗模型。這里介紹漏斗模型，對于理解一些常見的統計方式有比較好的幫助，例如淘寶SPM體系，當你熟悉和了解之后，會發現它真的很好用。
漏斗模型全稱為“ 搜索營銷效果轉化漏斗 ”，對應了企業搜索營銷的各個環節，反映了從展現、點擊、訪問、咨詢，直到生成訂單過程中的客戶數量及流失。從最大的展現量到最小的訂單量，這個一層層縮小的過程表示不斷有客戶因為各種原因離開，對企業失去興趣或放棄購買。可以說，互聯網商業價值的體現，與漏斗模型有著直接的關聯關系，因此也是一系列技術實現及數據分析的重點。
漏斗模型是一個線性流程，從開始到結束，用戶在每一個環節，都會產生流失，就像漏斗一樣。以電商為例，最常見漏斗模型就是：瀏覽/搜索-加購-下單-支付-復購，因此對于統計數據而言，找出用戶購買一個商品的搜索過程，來反思用戶的行為，就顯得十分有必要。數據人要做的工作，就是整理出路徑中各個環節的數據，考慮用戶流失的因素，進行對應的優化，或者通過縮短用戶路徑來優化產品體驗。其實不論在電商平臺、招聘平臺、廣告平臺等常見的互聯網業務模式中，漏斗模型始終是數據分析工作的重點。這里通過一個圖來理解漏斗模型的商業價值：
但說實話，很多公司在數據統計上，可能并沒有這么強的需求來搭建一個完整的平臺，也有很多公司想從不同的地方來看一看自己的數據是否準備，這 時 大家都會選擇google GA來進行統計或者是對比數據。 公司的統計往往是兩條線，一條是自有線的統計，另一條便是發給Google GA來進行對比分析。 因此在統計平臺的功能設置上，經常要與Google GA對標，因此數據倉庫不僅是一個過程的搭建，還有很多固有的業務邏輯在其中。
六、淘寶SPM碼
漏斗模型比較優秀的應用案例為 淘寶SPM碼 。查看淘寶網頁的源代碼會經常看到http://detail.tmall.com/item.htm?id=XXX&& spm=2014.123456789.1.2 這樣的例子，這是淘寶提供的SPM是淘寶社區電商業務（xTao）為外部合作伙伴（外站）提供的一套跟蹤引導成交效果數據的解決方案。簡單說來， SPM編碼 是一種 用來跟蹤頁面模塊位置的編碼，標準spm編碼由4段組成，采用a. b.c.d的格式（建議全部使用數字），其中：
- a代表站點類型 ，對于xTao合作伙伴（外站），a為固定值，a=2014。
- b代表外站ID （即外站所使用的TOP Appkey），比如您的站點使用的TOP appkey=123456789，則b=123456789。
- c代表b站點上的頻道ID ，比如是外站某個團購頻道，某個逛街頻道，某個試用頻道等。
- d代表c頻道上的頁面ID ，比如是某個團購詳情頁，某個寶貝詳情頁，某個試用詳情頁等。
完整的SPM四位編碼能標識出某網站中某一個頻道的某一個具體頁面。比如xTao合作伙伴（a=2014）中某個外站appkey為123456789（b=123456789），頻道ID為1（c=1），頁面ID為2（d=2），那么spm=2014.123456789.1.2，就唯一標識外站123456789的頻道1上的頁面2，從這個頁面點擊出去的鏈接，后面都應該攜帶spm=2014.123456789.1.2的參數串。這樣，通過這個編碼，我們就能唯一的定位到一個url是由外站中哪個具體頁面點擊生成的。
因為spm編碼本身是有層次的，因此，我們可以：
- 單獨統計spm的a部分 ，我們可以知道某一類站點的訪問和點擊情況，以及后續引導和成交情況。
- 單獨統計spm的a.b部分 ，我們可以用來評估某一個站點的訪問和點擊效果，以及后續引導和成交情況。
- 單獨統計spm的a.b.c部分 ，我們可以用來評估某一個站點上某一頻道的訪問和點擊效果，以及后續引導和成交情況。
- 單獨統計spm的a.b.c.d部分 ，我們可以用來評估某一個頻道上某一具體頁面的點擊效果，以及后續引導和成交情況。
基于SPM可以得到的效果統計指標：
- PV ：通過指定spm編碼引導到寶貝詳情頁面的PV。
- UV ：通過指定spm編碼引導到寶貝詳情頁面的UV。
- 支付寶成交人數 ：通過指定spm編碼引導到寶貝詳情頁面的用戶當天對同店商品的支付寶成交人數。
- 轉化率 =支付寶成交人數/UV，代表通過指定spm編碼引導的用戶最終轉化為購買用戶的比率。
七、客戶端日志采集
與網頁日志對應的，是手機應用為基礎的客戶端日志，由于早期手機網絡通訊能力較差，因而SDK往往采用 延遲發送 日志的方式，也就是將日志統計在本地，然后選擇在Wifi環境下上傳，因而往往會出現統計數據延遲的情況。現如今網絡環境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯網，因而很多統計能夠做到實時統計。
客戶端的日志統計主要通過SDK來完成，根據不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據類型的不同，可以分為 頁面事件 （類比頁面瀏覽）和 控件點擊事件 （類比頁面交互）。
頁面事件的統計主要統計如下三類信息：
- 設備及用戶的基本信息 ，例如IMEI、用戶賬號等。
- 被訪問頁面的信息 ，例如商品ID、瀏覽店鋪等。
- 訪問的路徑信息 ，例如上一個頁面來源等。
與Web日志采集類似的是，交互日志的采集同樣無法規定統一的采集內容，除了記錄基本的設備信息和用戶信息外，很多統計的方式是可以由業務方自定義統計的，也就是根據業務需求的不同，產品在配置平臺上自定義一個統計項，下次SDK更新時便可以加入統計項，自主看到統計內容，便于自動化的管理運維。但在每個事件上，會提供一些額外的統計信息，例如事件名稱、事件時長、事件屬性、事件頁面等。
八、客戶端日志的聚合
由于事件的統計涉及到很多參數，基本上是一個行為能夠產生一條日志，不僅客戶端會產生大量的記錄數據，對于服務端的接收通常會產生很大的流量負擔。因此統計SDK往往會有聚合和壓縮的功能，對于一些展現場景，可以適當的合并日志，以減少數據量。例如在淘寶等APP中，一次商品頁的瀏覽會產生上百條日志，從下游分析的角度來看，只需要知道哪些內容被曝光了即可，因此完全可以在一條日志中記錄曝光的ID，而無需每個都統計一遍。
還有一種場景，因為APP存在回退的情況，因此在訪問路徑的分析中，往往會產生干擾統計，因此在統計時需要添加一些特殊的標識，來鑒別該行為是否屬于回退行為。
九、統計SDK
市面上最常見的，如 友盟 、Talkingdata、百度統計、騰訊云分析、GA等第三方統計服務提供商，也誕生了很多在某些分析方面更加專一、深入的統計服務商，比如諸葛io、growingio、神策等，看自己需求進行配置。
十、唯一設備標識符
在客戶端的相關統計中，如何鑒定一個用戶是非常難的，因為網頁有統一的Cookie來進行識別，但客戶端并沒有。歷史上， IMEI、IMSI、mac地址 、蘋果禁用之前的UDID，都可以用，但由于用戶自我保護意識的提高及系統的升級，很多基本的設備信息都難以獲取到了，Android也進行了設備信息獲取的限制。對于單個App的公司來說，識別唯一用戶并不是難事，但對于多App的公司來說，這一點就尤為重要，也這是業界難題。
十一、H5與Native的統一
App有兩種類型，一種是純 Native 的App，另一種是既有Native，也有 H5 頁面嵌入的App，目前大部分的App都是兩者兼有的狀況。Native頁面的數據統計主要通過SDK進行，但H5頁面的數據統計還是基于瀏覽器的頁面日志來進行，由于采集方式的不同，很多情況下兩個頁面互相跳轉時，便無法還原用戶訪問路徑，對于數據的統計分析產生很嚴重的影響。解決的思路有兩種，一種是Native日志歸攏到H5日志中，另一種是H5日志歸攏到Native日志中，但綜合考慮，歸攏到Native日志更為合理，因為SDK能夠采集更為全面的日子信息。具體實現方式上，可以在H5頁面中嵌入JS代碼，通過調用WebView框架中的JSBridge接口，來實現參數的傳入，并由統計SDK進行日志的封裝。當然方法不是萬能的，有其他的好方式也可以嘗試。
十二、大促保障
大促保障指在雙十一等類似場景下，流量短時間內保障的情況，需要對系統進行一定的改造。在高并發場景下，從數據的埋點采集，到日志服務器的收集，再到數據傳輸，再到數據的分析和統計，任何一個環節出現問題，大促保障就是失效的。由于日志處理的鏈路非常長，因此可以通過限制流量、消息隊列削弱峰值、異步處理、內存緩沖、擴展服務等方式進行，在日志采集環節中，可以通過延遲非核心日志上傳的方式，優先處理核心日志，以保障統計效果。在天貓雙十一中，可以經常看到暫停部分服務的通知，便是這種方式的實現。
