[[182943]]

作為系列文章的第三篇，本文將重點探討數(shù)據(jù)采集層中的用戶行為數(shù)據(jù)采集系統(tǒng)。這里的用戶行為，指的是用戶與產(chǎn)品UI的交互行為，主要表現(xiàn)在Android App、iOS App與Web頁面上。這些交互行為，有的會與后端服務通信，有的僅僅引起前端UI的變化，但是不管是哪種行為，其背后總是伴隨著一組屬性數(shù)據(jù)。對于與后端發(fā)生交互的行為，我們可以從后端服務日志、業(yè)務數(shù)據(jù)庫中拿到相關(guān)數(shù)據(jù);而對于那些僅僅發(fā)生在前端的行為，則需要依靠前端主動上報給后端才能知曉。用戶行為數(shù)據(jù)采集系統(tǒng)，便是負責從前端采集所需的完整的用戶行為信息，用于數(shù)據(jù)分析和其他業(yè)務。

舉個例子，下圖所示是一次營銷活動(簡化版)的注冊流程。如果僅僅依靠后端業(yè)務數(shù)據(jù)庫，我們只能知道活動帶來了多少新注冊用戶。而通過采集用戶在前端的操作行為，則可以分析出整個活動的轉(zhuǎn)化情況：海報頁面瀏覽量—>>點擊”立即注冊”跳轉(zhuǎn)注冊頁面量—>>點擊“獲取驗證碼”數(shù)量—>>提交注冊信息數(shù)量—>>真實注冊用戶量。而前端用戶行為數(shù)據(jù)的價值不僅限于這樣的轉(zhuǎn)化率分析，還可以挖掘出更多的有用信息，甚至可以與產(chǎn)品業(yè)務結(jié)合，比如筆者最近在做的用戶評分系統(tǒng)，便會從用戶行為中抽取一部分數(shù)據(jù)作為評分依據(jù)。

在早期的產(chǎn)品開發(fā)中，后端研發(fā)人員每人負責一個攤子，雖然也會做些數(shù)據(jù)采集的事情，但是基本上只針對自己的功能，各做各的。通常做法是，根據(jù)產(chǎn)品經(jīng)理提出的數(shù)據(jù)需求，設(shè)計一個結(jié)構(gòu)化的數(shù)據(jù)表來存儲數(shù)據(jù)，然后開個REST API給前端，用來上報數(shù)據(jù);前端負責在相應的位置埋點，按照協(xié)商好的數(shù)據(jù)格式上報給后端。隨著業(yè)務的發(fā)展，這樣的做法暴露了很多問題，給前后端都帶來了混亂，主要表現(xiàn)在：前端四處埋點，上報時調(diào)用的API不統(tǒng)一，上報的數(shù)據(jù)格式不統(tǒng)一;后端數(shù)據(jù)分散在多個數(shù)據(jù)表中，與業(yè)務邏輯耦合嚴重。

于是，我們考慮做一個統(tǒng)一的用戶行為數(shù)據(jù)采集系統(tǒng)，基本的原則是：統(tǒng)一上報方式、統(tǒng)一數(shù)據(jù)格式、數(shù)據(jù)集中存儲、盡可能全量采集。具體到實現(xiàn)上，歸納起來主要要解決三個問題：

采什么。搞清楚需要什么數(shù)據(jù)，抽象出一個統(tǒng)一的數(shù)據(jù)格式。

前端怎么采。解決前端如何有效埋點、全量采集的問題。

后端怎么存。解決數(shù)據(jù)集中存儲、易于分析的問題。

采什么

用戶在前端UI上的操作，大多數(shù)表現(xiàn)為兩類：***類，打開某個頁面，瀏覽其中的信息，然后點擊感興趣的內(nèi)容進一步瀏覽;第二類，打開某個頁面，根據(jù)UI的提示輸入相關(guān)信息，然后點擊提交。其行為可以歸納為三種：瀏覽、輸入和點擊(在移動端，有時也表現(xiàn)為滑動)。其中，瀏覽和點擊是引起頁面變化和邏輯處理的重要事件，輸入總是與點擊事件關(guān)聯(lián)在一起。

因此，瀏覽和點擊便是我們要采集的對象。對于瀏覽，我們關(guān)注的是瀏覽了哪個頁面，以及與之相關(guān)的元數(shù)據(jù);對于點擊，我們關(guān)注的是點擊了哪個頁面的哪個元素，與該元素相關(guān)聯(lián)的其他元素的信息，以及相關(guān)的元數(shù)據(jù)。頁面，在Android與IOS上使用View名稱來表示，在Web頁面上使用URL(hostname+pathname)來表示。

元素，使用前端開發(fā)中的UI元素id來表示。與元素相關(guān)聯(lián)的其他元素信息，指的是與“點擊”相關(guān)聯(lián)的輸入/選擇信息，比如在上面的注冊頁面中，與“提交”按鈕相關(guān)聯(lián)的信息有手機號、驗證碼、姓名。元數(shù)據(jù)，是指頁面能提供的其他有用信息，比如URL中的參數(shù)、App中跳轉(zhuǎn)頁面時傳遞的參數(shù)等等，這些數(shù)據(jù)往往都是很重要的維度信息。

除了這些頁面中的數(shù)據(jù)信息，還有兩個重要的維度信息：用戶和時間。用戶維度，用來關(guān)聯(lián)同一用戶在某個客戶端上的行為，采用的方案是由后端生成一個隨機的UUID，前端拿到后自己緩存，如果是登錄用戶，可以通過元數(shù)據(jù)中的用戶id來關(guān)聯(lián);時間維度，主要用于數(shù)據(jù)統(tǒng)計，考慮到前端可能延遲上報，前端上報時會加上事件的發(fā)生時間(目前大多數(shù)正常使用的移動端，時間信息應該是自動同步的)。

綜合起來，將前端上報的數(shù)據(jù)格式定義如下。uuid、event_time、page是必填字段，element是點擊事件的必填字段，attrs包含了上述的元數(shù)據(jù)、與元素相關(guān)聯(lián)的其他元素的信息，是動態(tài)變化的。

而針對不同客戶端的不同事件，通過不同的REST API來上報，每個客戶端只需調(diào)用與自己相關(guān)的兩個API即可。

前端怎么采

整理好數(shù)據(jù)格式和上報方式后，前端的重點工作便是如何埋點。傳統(tǒng)的埋點方式，就是在需要上報的位置組織數(shù)據(jù)、調(diào)用API，將數(shù)據(jù)傳給后端，比如百度統(tǒng)計、google analysis都是這樣做的。這是最常用的方式，缺點是需要在代碼里嵌入調(diào)用，與業(yè)務邏輯耦合在一起。近幾年，一些新的數(shù)據(jù)公司提出了“無埋點”的概念，通過在底層hook所有的點擊事件，將用戶的操作盡量多的采集下來，因此也可以稱為“全埋點”。這種方式無需嵌入調(diào)用，代碼耦合性弱，但是會采集較多的無用數(shù)據(jù)，可控性差。經(jīng)過一番調(diào)研，結(jié)合我們自己的業(yè)務，形成了這樣幾點設(shè)計思路：

hook底層的點擊事件來做數(shù)據(jù)上報，在上報的地方統(tǒng)一做數(shù)據(jù)整理工作。

通過UI元素的屬性值來設(shè)置是否對該元素的點擊事件上報。

通過UI元素的屬性值來設(shè)置元素的關(guān)聯(lián)關(guān)系，用于獲取上述的“與元素相關(guān)聯(lián)的其他元素的信息”。

我們首先在Web的H5頁面中做了實踐，核心的代碼很簡單。***，在頁面加載時綁定所有的click事件，上報頁面瀏覽事件數(shù)據(jù)。第二，通過user_action_id屬性來表示一個元素是否需要上報點擊事件，通過user_action_relation屬性來聲明當前元素被關(guān)聯(lián)到哪個元素上面，具體代碼實現(xiàn)不解釋，很簡單。

上述代碼可以嵌入到任何HTML頁面，然后只要在對應的元素中進行申明就好了。舉個例子，

后端怎么存

數(shù)據(jù)進入后臺后，首先接入Kafka隊列中，采用生產(chǎn)消費者模式來處理。這樣做的好處有：***，功能分離，上報的API接口不關(guān)心數(shù)據(jù)處理功能，只負責接入數(shù)據(jù);第二，數(shù)據(jù)緩沖，數(shù)據(jù)上報的速率是不可控的，取決于用戶使用頻率，采用該模式可以一定程度地緩沖數(shù)據(jù);第三，易于擴展，在數(shù)據(jù)量大時，通過增加數(shù)據(jù)處理Worker來擴展，提高處理速率。

除了前端上報的數(shù)據(jù)內(nèi)容外，我們還需要在后端加入一些其他的必要信息。在數(shù)據(jù)接入Kafka隊列之前，需要加入五個維度信息：客戶端類型(Web/Android/IOS)、事件類型(瀏覽/點擊)、時間、客戶端IP和User Agent。在消費者Worker從Kafka取出數(shù)據(jù)后，需要加入一個名為event_id的字段數(shù)據(jù)，具體含義等下解釋。因此，***存入的數(shù)據(jù)格式便如下所示：

再來看event_id的含義。前端傳過來的一組組數(shù)據(jù)中，通過page和element可以區(qū)分出究竟是發(fā)生了什么事件，但是這些都是前端UI的名稱，大部分是開發(fā)者才能看懂的語言，因此我們需要為感興趣的事件添加一個通俗易懂的名稱，比如上面的數(shù)據(jù)對應的事件名稱為“在海報頁面中注冊”。將page+element、事件名稱進行關(guān)聯(lián)映射，然后將相應的數(shù)據(jù)記錄id作為event id添加到上述的數(shù)據(jù)中，方便后期做數(shù)據(jù)分析時根據(jù)跟event id來做事件聚合。做這件事有兩種方式：一種是允許相關(guān)人員通過頁面進行配置，手動關(guān)聯(lián);一種是前端上報時帶上事件名稱，目前這兩種方式我們都在使用。

***，來看看數(shù)據(jù)存儲的問題。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在存儲數(shù)據(jù)時，采用的是行列二維結(jié)構(gòu)來表示數(shù)據(jù)，每一行數(shù)據(jù)都具有相同的列字段，而這樣的存儲方式顯示不適合上面的數(shù)據(jù)格式，因為我們無法預知attrs中有哪些字段數(shù)據(jù)。象用戶行為數(shù)據(jù)、日志數(shù)據(jù)都屬于半結(jié)構(gòu)化數(shù)據(jù)，所謂半結(jié)構(gòu)化數(shù)據(jù)，就是結(jié)構(gòu)變化的結(jié)構(gòu)化數(shù)據(jù)(WIKI中的定義)，適合使用NoSQL來做數(shù)據(jù)存儲。我們選用的是ElasticSearch來做數(shù)據(jù)存儲，主要基于這么兩點考慮：

Elasticsearch是一個實時的分布式搜索引擎和分析引擎，具有很強的數(shù)據(jù)搜索和聚合分析能力。

在這之前我們已經(jīng)搭建了一個ELK日志系統(tǒng)，可以復用Elasticsearch集群做存儲，也可以復用Kibana來做一些基礎(chǔ)的數(shù)據(jù)分析可視化。

Elasticsearch的使用方法可以參考Elasticsearch使用總結(jié)一文，這里不做過多講解。使用Elasticsearch來做數(shù)據(jù)存儲，最重要的是兩件事：建立Elasticsearch的映射模板、批量插入。Elasticsearch會根據(jù)插入的數(shù)據(jù)自動建立缺失的index和doc type，并對字段建立mapping，而我們要做的創(chuàng)建一個dynamic template，告訴Elasticsearch如何自動建立，參考如下。批量插入，可以通過Elasticsearch的bulk API輕松解決。