數據採集技術簡介

前言

本系列的技術文章不涉及實現細節，僅探討實現思路。由於數據倉庫不僅僅是一個理論概念，其數據質量等原則包含了大量的技術實現細節，因此從數據採集開始，到數據處理，至最終的數據展現，都需要進行原理上和實現上的思路分析，才能保證最終數據倉庫理論的完整實現。另外，需要強調的是，本系列文章非原創，是筆者多年從業經歷的一種思路整理，對於日常理解數據倉庫的實現有著很大的幫助，因而用到了非常多其他文章的引用，並介紹很多業界的好用工具及優秀做法。

一、技術路線圖

二、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進行日誌的封裝。當然方法不是萬能的，有其他的好方式也可以嘗試。

十二、大促保障

大促保障指在雙十一等類似場景下，流量短時間內保障的情況，需要對系統進行一定的改造。在高並發場景下，從數據的埋點採集，到日誌伺服器的收集，再到數據傳輸，再到數據的分析和統計，任何一個環節出現問題，大促保障就是失效的。由於日誌處理的鏈路非常長，因此可以通過限制流量、消息隊列削弱峰值、異步處理、內存緩衝、擴展服務等方式進行，在日誌採集環節中，可以通過延遲非核心日誌上傳的方式，優先處理核心日誌，以保障統計效果。在天貓雙十一中，可以經常看到暫停部分服務的通知，便是這種方式的實現。