蘇寧使用者行為採集體系的演變
1. 前言
在當今這個網際網路時代，人們在網上進行工作、消費、娛樂、社交等行為所花費的時間越來越長，在網際網路中、每時每刻都會產生海量的使用者行為資料。對各大網際網路公司而言，便捷、準確、全面地採集使用者行為資料，並用以支撐經營分析、改善使用者體驗，已經日趨重要。近年來，蘇寧業務規模高速增長，已覆蓋了零售、金融、文創、體育、物流等多個業態，在2017年大促期間、僅蘇寧易購業務便是實現了銷售額7秒破億的記錄。在資料經營的戰略下，蘇寧大資料中心資料採集團隊正逐步建立標準、通用的的海量使用者行為採集方案，服務於多業態、多業務場景，並致力為蘇寧大資料體系打下堅實的資料基礎。本文主要介紹蘇寧使用者行為採集體系的發展歷程，同時分享蘇寧在日誌採集上的部分經驗和探索過程。
2. 早期的行為日誌採集方案介紹
2.1. 基於蘇寧易購業務的日誌採集方案
與各大電商網站類似，蘇寧的使用者行為採集體系是在蘇寧易購PC版的基礎上發展起來的。早期，我們提供了基於PC瀏覽器頁面的使用者行為採集方案，為蘇寧易購網站採集頁面瀏覽、點選事件等基本日誌，支撐基礎的網站分析（如網站來源分析、頁面訪問量分析、站內頁面來源去向分析、站內訪問路徑分析、頁面元素點選量分析等）。隨著網站業務場景的日趨完善和網站分析的逐步細化，我們與分析人員共同定義了諸如曝光、搜尋、註冊、購買等各種型別的頁面事件日誌，以滿足各類特定場景下的資料分析需求。
在移動網際網路高速發展和智慧手機廣泛普及的背景下，我們也提供了面向手機瀏覽器頁面和手機App的使用者行為採集方案。手機App的日誌採集沿用了瀏覽器頁面的日誌分類模式，即基礎的頁面瀏覽日誌和各種型別的頁面事件日誌，並新增了其特有的App啟動日誌。至此，蘇寧使用者行為採集體系初具雛形，但仍主要面向蘇寧易購業務。
2.2. 日誌採集的實現方案簡介
2.2.1. 瀏覽器頁面日誌採集
與業界的網頁日誌採集方案相同，蘇寧的瀏覽器網頁日誌採集工作是由開發人員植入頁面html文件中的一段JS指令碼完成的，在文中，我們將這個JS指令碼稱為“採集JS”。
頁面瀏覽日誌，採集JS會自動在普通頁面（與單頁面進行區分）載入完成時觸發該日誌的引數採集和日誌上報，即僅需將採集JS正常植入頁面html文件即可，無需額外的人工干預。頁面瀏覽日誌是計算頁面PV、UV、跳出率、轉化率等一系列指標的基礎，是網站分析中最為重要的日誌。考慮到頁面日誌採集，尤其是站外投放著陸頁日誌採集的準確性，我們要求頁面將採集JS在頁面頭部引用，並儘可能地將其載入時序提前。同時，我們將“頁面dom文件樹載入完成”作為頁面載入完成的判斷節點，這在網站頁面圖片日益豐富的當下，是很有必要的。
對於單頁面的頁面瀏覽日誌，考慮到其頁面間的跳轉並不會重新載入頁面，即無法自動觸發頁面瀏覽日誌的採集，故該場景下、需暴露特定的傳參方法供頁面呼叫、以實現手動觸發頁面訪問日誌的採集，這也是業界普遍的做法。
頁面事件日誌，採集JS暴露了多種傳參方法供頁面呼叫，在頁面呼叫這些傳參方法時會觸發特定事件日誌的引數採集和日誌上報。考慮到頁面事件型別極高的多樣性，我們將頁面事件劃分為了通用事件和自定義事件。通用事件包含曝光、點選、搜尋、註冊、購買等覆蓋場景較多且日誌量較大的事件型別，用以滿足同類業務通用的分析需求，我們為每一類通用事件均提供了特定的傳參方法（即呼叫點選事件的傳參方法、僅會觸發點選事件日誌的採集和上報）；而自定義事件則支援業務方根據具體的業務場景自行定義（我們提供了自定義事件的管理後臺，供業務人員註冊事件名稱和需要採集的引數等資訊），以滿足個性化的分析需求，我們為自定義事件提供了統一的傳參方法，呼叫該方法時須傳入“事件型別”這一引數，用以區分不同的自定義事件。上述的各類事件傳參方法，須在使用者觸發對應的互動行為時呼叫。因此，我們要求頁面前端開發人員將呼叫事件傳參方法的採集程式碼植入目標頁面、並與對應的互動行為進行繫結，這便是俗稱的“埋點”。
日誌欄位，無論是頁面瀏覽日誌還是頁面事件日誌，我們均定義了標準的日誌格式，主要包含採集時間、訪客&會員資訊、瀏覽器資訊、頁面引數和事件引數，這些欄位資訊主要來源於瀏覽器cookie、頁面全域性變數和頁面傳參，而對於頁面瀏覽日誌和頁面事件日誌，也僅有事件引數相關欄位存在差異，其餘部分均相同。標準的日誌格式，對於後續的ETL工作，將提供極大的便利，這也是我們所提倡的。
2.2.2. 手機App日誌採集
對於手機App的日誌採集，行業中主要有兩種方案，即“App自行採集引數、拼接日誌、完成上報”和“App整合特定的採集SDK，由採集SDK來完成日誌的採集和上報”。蘇寧採用的是第二種更加普遍的方案，同時提供了Android和IOS兩版SDK供各App整合，各App需在啟動時完成採集SDK的初始化。
如上文所述，我們將手機App的日誌分為啟動日誌、頁面瀏覽日誌、頁面事件日誌三類。同時，我們也對手機App端定義了標準的日誌格式，主要包含採集時間、訪客&會員資訊、裝置資訊、頁面引數和事件引數，這些欄位資訊主要來源於SDK主動獲取或介面傳參。與瀏覽器頁面日誌類似，手機App端的三大類日誌，僅有頁面引數和事件引數存在差異，其餘部分均相同。
啟動日誌，採集SDK自動根據App的生命週期來判斷App的啟動和退出，無需人工干預。單獨採集啟動日誌可以更準確地計算使用者的啟動時長，為分析人員提供準確的資料支援。
頁面瀏覽日誌，目前手機App採集頁面瀏覽日誌主要通過客戶端呼叫介面來實現，而業界也主要有兩種方案，即“頁面進入時呼叫介面，傳送日誌”和“頁面進入和頁面離開時均呼叫介面，在頁面離開時傳送日誌”。蘇寧採用的是第二種方案，即頁面進入和頁面離開介面須成對呼叫，並支援在頁面離開介面中傳入需要額外採集的頁面引數（如商品編碼、搜尋關鍵詞、活動ID等）。該方案能夠極大地提升計算頁面停留時長的準確性和便捷性。
頁面事件日誌，與瀏覽器採集JS類似，採集SDK提供了多種傳參介面供App呼叫，在呼叫這些傳參介面時會觸發特定事件日誌的引數採集和日誌上報。在手機App端，我們同樣將頁面事件劃分為了通用事件和自定義事件，其劃分方式和事件的管理方式與瀏覽器端完全一致。
2.2.3. 日誌上報策略
移動客戶端（iOS/Android）採集SDK原有的採集日誌上報方案是，客戶端初始化採集SDK時會設定統一的上報時間間隔。在設定的時間間隔內，SDK採集到的使用者行為日誌都會暫存在客戶端快取內，到了上報時間點，採集SDK會將快取內的所有型別日誌進行合併、並上報到服務端統一的日誌接收介面。大促期間，當流量峰值到達預警閥值的時，只能採用比較粗暴的降級方案。
採集方案設計之初，基於當時的業務場景，將移動端的日誌型別分為啟動日誌、訪問日誌、註冊日誌、搜尋日誌、訂單日誌和自定義日誌。隨著近幾年業務發展和變化，歸類到自定義型別的日誌越來越多，日誌量也越來龐大（尤其是曝光日誌），尤其在大促期間日誌量陡增十幾倍的情況下，就會導致了下游處理自定義日誌時需要消耗越來越多的資源和時間，導致資料延遲也越來越大，對下游的資料產品造成很大影響。
2.3. 小結
本部分簡單介紹了早期蘇寧使用者行為採集方案的設計思路和實現方案。而在業務範圍不斷擴張、前端&客戶端技術不斷更新、業務場景不斷豐富的過程中，原有方案也暴露出了諸多問題，如“Hybrid應用中H5和Native日誌打通”、“手動埋點工作量過於繁重”等等。在下一部分中，我們將著重介紹近兩年蘇寧使用者行為日誌採集方案演進過程中的經驗。
3. 蘇寧使用者行為日誌採集方案的演進和探索
3.1. 更多業態&更多終端
更多業態，早期的使用者行為採集主要面向蘇寧易購單一業務，在資料採集的實踐過程中，頁面事件日誌型別的劃分均基於電商業務，例如購買事件日誌、商品加入購物車日誌、商品庫存日誌等等；頁面瀏覽日誌、頁面事件日誌中涉及的埋點內容及其規範，也都是基於電商業務制定的。隨著近年來蘇寧業務近年來的極速增長，蘇寧使用者行為採集方案逐步覆蓋了蘇寧金融、PP視訊、PP體育、龍珠直播、蘇寧拼購、蘇寧小店、蘇寧推客、紅孩子母嬰等數十個網站和App，這對於埋點規範的制定是一個不小的挑戰。視訊直播類業務，會重點關注使用者播放視訊的行為；O2O類業務，會重點關注使用者的定位資訊；金融類業務，會重點關注使用者的開戶、查詢基金理財產品等行為。而隨著業務場景的不斷豐富，不同型別的業務場景也在進行著融合，例如電商App中逐步融入了視訊直播功能、遊戲功能。在此背景下，制定一個可拓展的埋點規範 顯得尤為重要，特別是對於業務型別高速擴張的網際網路公司。
在分析電商類的使用者行為資料時，往往會關注商品編碼、店鋪編碼、訂單編碼等資訊，並在埋點時將多個常用引數按照固定的規則拼接為一個字串。這種方案在業務型別相對固定時，有著規則清晰、報文簡潔等優勢，但在業務型別越來越多、需要採集的業務引數也越來越多時，就會顯得力不從心。因此，在做頁面引數、事件引數埋點時，我們制定了 kv 鍵值對（key=value ）格式的埋點規範 ，該方案擴充套件性強，可根據具體業務定義個性化的引數key、根據實際需求增減埋點中kv鍵值對的數量。kv鍵值對在日誌中的存在形式，可以是常規的json格式、也可以是帶分隔符的字串形式。
更多終端，早期的使用者行為採集方案僅面向瀏覽器頁面和手機App，隨著業務的發展，我們也逐步上線了面向PC桌面客戶端，面向各種小程式（微信、百度等），面向智慧電視App，面向智慧硬體的使用者行為採集方案。我們將PC桌面客戶端、小程式、智慧電視App、智慧硬體視為不同的終端。目前這些終端的使用者行為採集方案均與手機App相仿，均提供專用的JS或SDK採集使用者行為資料，JS和SDK中均暴露了多樣化的傳參介面，供業務方呼叫、觸發特定日誌的採集和上報。
3.2. H5與native日誌打通
採集更多業態和終端的資料，可以幫助資料分析人員更好的理解使用者行為、勾勒出完整的蘇寧使用者畫像，其好處顯而易見、但是也帶來了諸多挑戰，例如H5與native的日誌打通。
Hybrid App是目前主流的手機App型別，其中既有native頁面、也有內嵌的H5頁面。按照早期的採集方案，native頁面上的頁面瀏覽日誌、頁面事件日誌均由採集SDK採集和上報，而內嵌H5頁面是在App的內建瀏覽器中開啟的、故H5頁面的日誌均由採集JS採集和上報。由於採集方案不同，上報日誌的格式、欄位內容和接收伺服器都是不同的，這對後續分析使用者在App中完整的訪問路徑帶來了諸多不便。目前行業中有兩種主流方案來解決native頁面和內嵌H5頁面日誌隔離的問題。
方案1，native頁面和App內嵌H5頁面採用不同的採集方案，雖然可以正常的計算各個頁面的PV、UV、點選量等基本指標，但在還原使用者在App中的完整行為時，會存在問題。故而可以利用瀏覽器cookie來存放一些標識欄位，這種標識欄位可以是使用者的身份標識、也可以是裝置唯一ID等可以準確匹配native頁面日誌的資訊，App的開發人員可以很容易地將這些資訊寫入內建瀏覽器的cookie中。在JS採集內嵌H5頁面的各種日誌時，只需要獲取cookie中的特定標識並拼入日誌欄位，在後續處理資料時，即可通過上述特定標識將內嵌H5頁面的日誌與native頁面的對應日誌做關聯，繼而解決資料隔離的問題。
方案2，上述方案具有便捷的特性，但後續的計算成本較高，且往往會出現H5頁面的來源頁丟失的問題。故而蘇寧使用者採集使用的方案如下
- H5頁面載入採集JS後，由採集JS判斷H5頁面的執行環境是手機瀏覽器還是特定App，這裡可以根據瀏覽器的ua或navigator中的特定標識進行判斷，這個標識可以由App寫入、也可以由採集SDK寫入；
- 若H5頁面是在手機瀏覽器中開啟的，則JS採集日誌所需欄位資訊並直接向服務端上報傳送頁面日誌；
- 若H5頁面是在特定App中開啟的，則JS採集日誌所需欄位資訊、並呼叫與採集SDK約定並由SDK提供的介面，將欄位資訊通過介面傳給採集SDK，這裡需通過移動混合開發中常用的JsBridge來實現JS與App的資訊互通；
- 採集SDK獲取到採集JS傳入的欄位資訊，識別日誌型別、並將欄位資訊解析&拼接為對應的App日誌格式，而後通過呼叫SDK內部的介面實現日誌的上報。
該方案可以實現SDK上報內嵌H5頁面的所有日誌，較好地解決了H5與native日誌打通時會遇到的諸多問題。同時，為了後續分析的便利，我們也建議為App與瀏覽器頁面相關日誌中的頁面引數、業務引數制定標準、統一的埋點規範。
H5與native日誌打通的問題，其實不光在Hybrid App中出現，在各類小程式、PC桌面客戶端中均會遇到同樣的問題，而其解決方案其實與Hybrid App中所使用的方案是基本相同的。目前蘇寧內部各App均使用了相同的使用者行為採集方案，在實現H5與native日誌打通時，幾乎所有的工作均由資料採集團隊完成，無需前端、客戶端開發人員介入。同時，日誌格式的打通，也極大地節約了後續的計算資源。
3.3. 埋點無痕化
在使用者行為採集的長期實踐過程中，常常會遇到一個顯著的問題。埋點，尤其是頁面點選事件&元素曝光事件相關的埋點，需要開發人員將監測程式碼加在每一個監測點上，還需要保證這些程式碼跟監測點一一對應，這是一個龐大而繁瑣的工作，且很容易出現錯誤或是遺漏。因此，業界一直有著埋點無痕化的訴求，常見的概念有“無埋點、全埋點、視覺化埋點”，而蘇寧使用者行為採集團隊在埋點無痕化上也嘗試了諸多探索、積累了許多經驗，目前我們將最終使用的方案稱為全埋點方案。
點選事件無痕採集，頁面元素的點選事件埋點，一直是無痕埋點實踐中的重點。在開發人員為頁面點選事件做手動埋點時，寫入的埋點內容核心是每一個頁面互動元素的ID，這個ID可以是一串數字、也可以是具有字面意義的一個字串，每一個元素的ID在當前頁面中全域性唯一，同時需要在配置後臺為每一個元素ID命名。無痕埋點的核心思想就是頁面互動元素的ID無痕化，無需開發人員手動寫入（省去了人工碼程式碼的步驟，也極大地減少了出錯的可能），同時又可保證唯一。頁面互動元素的唯一ID，這在瀏覽器網頁和手機App中都很容易找到，譬如html文件中每一個dom元素的xpath或css選擇器、又如App原生控制元件的控制元件路徑，我們統一稱之為元素路徑。採集JS和採集SDK自動監聽到頁面中互動元素的點選事件後，獲取對應的元素路徑，將之拼入點選日誌並上報，這就是最初版本的點選事件無痕化採集方案，事實上我們也完整地經歷了這一初始階段。關於自動監聽頁面互動元素的點選事件，前端或客戶端開發人員習慣稱其為hook點選事件，在網頁端、Android端、IOS端均有對應的實現方法，在此就不再贅述。
點選事件視覺化配置，根據上述方案採集到的點選日誌，可以計算出每一個頁面中各個元素路徑對應的點選量，但事實上元素路徑是幾乎無法直接被資料分析人員（產品經理、運營人員或專業的資料分析人員）所理解的。故而，僅僅是點選事件無痕採集還無法體現出其價值，還需要搭配視覺化配置（以及點選資料視覺化展示）。我們將視覺化配置的核心思想總結為所見即所得，即將採集到的元素路徑還原到真實頁面中去，與頁面中實際存在的互動元素進行繫結，讓元素路徑以一個極易理解的形式呈現給資料分析人員。
實現點選事件視覺化配置的方案對於瀏覽器網頁和App略有差異，但都需要一個專用的視覺化配置後臺。
對於html頁面，前端開發人員可以直接根據xpath（或css選擇器）定位到頁面中的一個dom元素，並修改對應dom元素的樣式、如在該元素上新增蒙層效果或修改背景顏色，這些效果都是在特定後臺介面中實現的、並不會影響真實使用者的體驗。如下圖所示，資料分析人員可以直觀地瞭解到每一個元素路徑對應到頁面中的哪個位置。在此基礎上，可以為元素命名、也可以將元素的點選量視覺化地展示在頁面中。
對於App中native頁面的點選事件視覺化配置，業界主要有兩種方案。一種是直接在手機上對App進行視覺化配置；另一種是將手機螢幕中的內容投射到電腦螢幕上（在專用的後臺中展示），在配置後臺進行視覺化配置。綜合考慮了使用者體驗和方案的通用性，我們採用了第二種方案，該方案可以極小的成本、快速支援任意App接入點選事件無痕採集和視覺化配置。我們在實踐過程中，採用瞭如下方式
- 啟動需要視覺化配置點選資料的App，通過特殊手勢（掃碼亦可），可以開啟採集SDK的截圖功能；
- 採集SDK對前臺執行的App內容進行截圖，將圖片傳送給服務端，同時遍歷出螢幕範圍內的所有控制元件資訊，獲取控制元件的路徑、座標、尺寸，一併傳送給服務端；
- 配置後臺從服務端獲取到截圖圖片和控制元件資訊後，在介面上繪製出當前App的頁面、並在每一個控制元件的位置上新增邊框效果（蒙層效果亦可）；
- 由於點選事件無痕採集方案採集了控制元件路徑、後臺介面開發人員即可將其對應的點選量資料還原到真實頁面中、同時亦可實現視覺化地為每一個控制元件路徑進行命名。
在點選事件無痕採集、視覺化配置的實踐過程中，仍有不少需要注意的細節，例如點選元素對應的業務引數如何事件無痕採集、如何快速地為一批元素/控制元件進行命名、在出現App頁面控制元件複用時如何確保控制元件路徑的唯一性和準確性等等，在探索&解決這些細節問題的過程中在此就不再贅述。
與點選事件相同，我們對瀏覽器網頁中元素曝光事件的無痕化採集方案也進行了實踐，該方案實現了自動監聽頁面圖片元素的曝光並採集相關統計資訊的效果。由於曝光日誌具有日誌量大、併發量大的特性，在開發過程中我們將重點放在了降低效能損耗上，並取得了不錯的效果。在曝光日誌的內容上，我們也做到了欄位資訊與點選事件一致，故而在點選事件無痕採集的基礎上，可以不再需要重複配置，並快速實現資料視覺化展示。
3.4. 日誌安全
針對日誌的加密方案，我們充分考慮了對稱加密和非對稱加密各自的優缺點：對稱加密加密與解密使用的是同樣的金鑰，所以速度快，但由於需要將金鑰在網路傳輸，所以安全性不高；非對稱加密使用了一對金鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。雖然非對稱加密很安全，但是和對稱加密比起來，它非常的慢，所以還是要用對稱加密來傳送報文，但對稱加密所使用的金鑰可以通過非對稱加密的方式傳送出去。流程如下：
（1） APP端首先生成了一個隨機數作為對稱金鑰。
（2） APP端向服務端請求公鑰。
（3） 服務端將帶版本號的公鑰傳送給APP端。
（4） APP端使用該版本的公鑰將自己的對稱金鑰加密。
（5） APP端將加密後的對稱金鑰（帶上公鑰版本號）傳送給服務端。
（6） 服務端使用對應版本號的私鑰解密得到APP端的對稱金鑰。
（7） APP端與服務端可以使用對稱金鑰來對溝通的內容進行加密與解密了。
3.5. 日誌傳輸
通過後臺的採集管理平臺給不同App個性化地配置上報地址和各型別日誌的上報時間間隔，App初始化採集SDK之後，SDK即呼叫上報配置介面，後臺根據請求中appKey返回對應App的配置資訊，SDK根據獲取到的配置引數進行日誌上報。
原有的移動客戶端SDK日誌上報只通過時間間隔這種單一策略來控制日誌上報的週期，通過實踐我們發現這種策略存在風險，如果使用者在很短的時間裡（尤其在大促期間）進行了了大量行為操作，就會導致上報時合併出來的請求體過長，從而導致上傳失敗。針對這種場景，我們增加了按日誌條數上報的策略，如果快取中的日誌條數達到閥值，也會觸發日誌上報。目前這種時間間隔+日誌條數相結合的上報策略能夠更靈活更有效地支撐線上日漸複雜的採集場景，也是業界普遍採用的方案。
原有的移動客戶端所有日誌型別是合併在一起上報到服務端，再由服務端根據日誌型別進行分流落地，考慮到蘇寧使用者行為日誌的規模和複雜度，我們決定把日誌分流從服務端向客戶端遷移，從而降低了服務端日誌處理過程中的分支判斷消耗，並作為後續的計算資源調配的前提，提高資源利用效率。另外，日誌在移動客戶端分流也為大促降級方案的優化提供了必要的條件，大促降級方案實現了從原有簡單粗暴的一刀切到現有的根據日誌的重要程度進行相應的延時上報和分叢集上報，達到了各型別日誌互不影響的目的。
4. 總結
考慮到文章篇幅問題，本文僅介紹了蘇寧使用者行為採集團隊在制定埋點規範、H5與native日誌打通、埋點無痕化、日誌傳輸與日誌安全上的一些探索過程和經驗，其餘如跨終端、業態打通使用者標識，大促期間的日誌分流等實踐經驗，將會在後續的文章中進行分享。當然，使用者行為採集方案的種種探索和提升，都是以解決使用者（資料分析人員、埋點實施人員、下游資料產品）痛點、提升資料質量為出發點的，而在公司不同的發展時期，我們需要優先考慮並解決的問題也不盡相同。作為使用者行為資料分析、資料應用的底層支撐部分，蘇寧的使用者行為採集體系也在緊跟業務發展和行業技術發展的腳步，不斷更新迭代，致力於更簡單、更準確、更全面的使用者行為採集方案，為蘇寧大資料體系打下堅實的資料基礎。
作者簡介
許夏駿，蘇寧易購 IT 總部大資料中心主要負責人之一。多年大資料行業背景，數學、統計學專業畢業，主導蘇寧行為資料採集產品的設計和研發。蘇寧行為資料採集產品服務於蘇寧全產業上百個App、網站、小程式和其他智慧硬體產品，為各條線提供完善的流量資料分析解決方案，併為各條線的資料化經營提供穩定的支撐。