[[182943]]

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

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

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

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

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

前端怎么采。解決前端如何有效埋點(diǎn)、全量采集的問(wèn)題。

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

采什么

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

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

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

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

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

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

前端怎么采

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

hook底層的點(diǎn)擊事件來(lái)做數(shù)據(jù)上報(bào)，在上報(bào)的地方統(tǒng)一做數(shù)據(jù)整理工作。

通過(guò)UI元素的屬性值來(lái)設(shè)置是否對(duì)該元素的點(diǎn)擊事件上報(bào)。

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

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

上述代碼可以嵌入到任何HTML頁(yè)面，然后只要在對(duì)應(yīng)的元素中進(jìn)行申明就好了。舉個(gè)例子，

后端怎么存

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

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

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

***，來(lái)看看數(shù)據(jù)存儲(chǔ)的問(wèn)題。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在存儲(chǔ)數(shù)據(jù)時(shí)，采用的是行列二維結(jié)構(gòu)來(lái)表示數(shù)據(jù)，每一行數(shù)據(jù)都具有相同的列字段，而這樣的存儲(chǔ)方式顯示不適合上面的數(shù)據(jù)格式，因?yàn)槲覀儫o(wú)法預(yù)知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來(lái)做數(shù)據(jù)存儲(chǔ)。我們選用的是ElasticSearch來(lái)做數(shù)據(jù)存儲(chǔ)，主要基于這么兩點(diǎn)考慮：

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

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

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