作為系列文章的第三篇，本文将重點探讨資料采集層中的使用者行為資料采集系統。這裡的使用者行為，指的是使用者與産品ui的互動行為，主要表現在android app、ios app與web頁面上。這些互動行為，有的會與後端服務通信，有的僅僅引起前端ui的變化，但是不管是哪種行為，其背後總是伴随着一組屬性資料。對于與後端發生互動的行為，我們可以從後端服務日志、業務資料庫中拿到相關資料;而對于那些僅僅發生在前端的行為，則需要依靠前端主動上報給後端才能知曉。使用者行為資料采集系統，便是負責從前端采集所需的完整的使用者行為資訊，用于資料分析和其他業務。
舉個例子，下圖所示是一次營銷活動(簡化版)的注冊流程。如果僅僅依靠後端業務資料庫，我們隻能知道活動帶來了多少新注冊使用者。而通過采集使用者在前端的操作行為，則可以分析出整個活動的轉化情況：海報頁面浏覽量—>>點選”立即注冊”跳轉注冊頁面量—>>點選“擷取驗證碼”數量—>>送出注冊資訊數量—>>真實注冊使用者量。而前端使用者行為資料的價值不僅限于這樣的轉化率分析，還可以挖掘出更多的有用資訊，甚至可以與産品業務結合，比如筆者最近在做的使用者評分系統，便會從使用者行為中抽取一部分資料作為評分依據。
在早期的産品開發中，後端研發人員每人負責一個攤子，雖然也會做些資料采集的事情，但是基本上隻針對自己的功能，各做各的。通常做法是，根據産品經理提出的資料需求，設計一個結構化的資料表來存儲資料，然後開個rest api給前端，用來上報資料;前端負責在相應的位置埋點，按照協商好的資料格式上報給後端。随着業務的發展，這樣的做法暴露了很多問題，給前後端都帶來了混亂，主要表現在：前端四處埋點，上報時調用的api不統一，上報的資料格式不統一;後端資料分散在多個資料表中，與業務邏輯耦合嚴重。
于是，我們考慮做一個統一的使用者行為資料采集系統，基本的原則是：統一上報方式、統一資料格式、資料集中存儲、盡可能全量采集。具體到實作上，歸納起來主要要解決三個問題：
<b>采什麼。搞清楚需要什麼資料，抽象出一個統一的資料格式。</b>
<b>前端怎麼采。解決前端如何有效埋點、全量采集的問題。</b>
<b>後端怎麼存。解決資料集中存儲、易于分析的問題。</b>
<b>采什麼</b>
使用者在前端ui上的操作，大多數表現為兩類：第一類，打開某個頁面，浏覽其中的資訊，然後點選感興趣的内容進一步浏覽;第二類，打開某個頁面，根據ui的提示輸入相關資訊，然後點選送出。其行為可以歸納為三種：浏覽、輸入和點選(在移動端，有時也表現為滑動)。其中，浏覽和點選是引起頁面變化和邏輯處理的重要事件，輸入總是與點選事件關聯在一起。
是以，浏覽和點選便是我們要采集的對象。對于浏覽，我們關注的是浏覽了哪個頁面，以及與之相關的中繼資料;對于點選，我們關注的是點選了哪個頁面的哪個元素，與該元素相關聯的其他元素的資訊，以及相關的中繼資料。頁面，在android與ios上使用view名稱來表示，在web頁面上使用url(hostname+pathname)來表示。
元素，使用前端開發中的ui元素id來表示。與元素相關聯的其他元素資訊，指的是與“點選”相關聯的輸入/選擇資訊，比如在上面的注冊頁面中，與“送出”按鈕相關聯的資訊有手機号、驗證碼、姓名。中繼資料，是指頁面能提供的其他有用資訊，比如url中的參數、app中跳轉頁面時傳遞的參數等等，這些資料往往都是很重要的次元資訊。
除了這些頁面中的資料資訊，還有兩個重要的次元資訊：使用者和時間。使用者次元，用來關聯同一使用者在某個用戶端上的行為，采用的方案是由後端生成一個随機的uuid，前端拿到後自己緩存，如果是登入使用者，可以通過中繼資料中的使用者id來關聯;時間次元，主要用于資料統計，考慮到前端可能延遲上報，前端上報時會加上事件的發生時間(目前大多數正常使用的移動端，時間資訊應該是自動同步的)。
綜合起來，将前端上報的資料格式定義如下。uuid、event_time、page是必填字段，element是點選事件的必填字段，attrs包含了上述的中繼資料、與元素相關聯的其他元素的資訊，是動态變化的。
而針對不同用戶端的不同僚件，通過不同的rest api來上報，每個用戶端隻需調用與自己相關的兩個api即可。
<b></b>
<b>前端怎麼采</b>
整理好資料格式和上報方式後，前端的重點工作便是如何埋點。傳統的埋點方式，就是在需要上報的位置組織資料、調用api，将資料傳給後端，比如百度統計、google analysis都是這樣做的。這是最常用的方式，缺點是需要在代碼裡嵌入調用，與業務邏輯耦合在一起。近幾年，一些新的資料公司提出了“無埋點”的概念，通過在底層hook所有的點選事件，将使用者的操作盡量多的采集下來，是以也可以稱為“全埋點”。這種方式無需嵌入調用，代碼耦合性弱，但是會采集較多的無用資料，可控性差。經過一番調研，結合我們自己的業務，形成了這樣幾點設計思路：
hook底層的點選事件來做資料上報，在上報的地方統一做資料整理工作。
通過ui元素的屬性值來設定是否對該元素的點選事件上報。
通過ui元素的屬性值來設定元素的關聯關系，用于擷取上述的“與元素相關聯的其他元素的資訊”。
我們首先在web的h5頁面中做了實踐，核心的代碼很簡單。第一，在頁面加載時綁定所有的click事件，上報頁面浏覽事件資料。第二，通過user_action_id屬性來表示一個元素是否需要上報點選事件，通過user_action_relation屬性來聲明目前元素被關聯到哪個元素上面，具體代碼實作不解釋，很簡單。
上述代碼可以嵌入到任何html頁面，然後隻要在對應的元素中進行申明就好了。舉個例子，
<b>後端怎麼存</b>
資料進入背景後，首先接入kafka隊列中，采用生産消費者模式來處理。這樣做的好處有：第一，功能分離，上報的api接口不關心資料處理功能，隻負責接入資料;第二，資料緩沖，資料上報的速率是不可控的，取決于使用者使用頻率，采用該模式可以一定程度地緩沖資料;第三，易于擴充，在資料量大時，通過增加資料處理worker來擴充，提高處理速率。
除了前端上報的資料内容外，我們還需要在後端加入一些其他的必要資訊。在資料接入kafka隊列之前，需要加入五個次元資訊：用戶端類型(web/android/ios)、事件類型(浏覽/點選)、時間、用戶端ip和user agent。在消費者worker從kafka取出資料後，需要加入一個名為event_id的字段資料，具體含義等下解釋。是以，最後存入的資料格式便如下所示：
再來看event_id的含義。前端傳過來的一組組資料中，通過page和element可以區分出究竟是發生了什麼事件，但是這些都是前端ui的名稱，大部分是開發者才能看懂的語言，是以我們需要為感興趣的事件添加一個通俗易懂的名稱，比如上面的資料對應的事件名稱為“在海報頁面中注冊”。将page+element、事件名稱進行關聯映射，然後将相應的資料記錄id作為event id添加到上述的資料中，友善後期做資料分析時根據跟event id來做事件聚合。做這件事有兩種方式：一種是允許相關人員通過頁面進行配置，手動關聯;一種是前端上報時帶上事件名稱，目前這兩種方式我們都在使用。
最後，來看看資料存儲的問題。傳統的關系型資料庫在存儲資料時，采用的是行列二維結構來表示資料，每一行資料都具有相同的列字段，而這樣的存儲方式顯示不适合上面的資料格式，因為我們無法預知attrs中有哪些字段資料。象使用者行為資料、日志資料都屬于半結構化資料，所謂半結構化資料，就是結構變化的結構化資料(wiki中的定義)，适合使用nosql來做資料存儲。我們選用的是elasticsearch來做資料存儲，主要基于這麼兩點考慮：
elasticsearch是一個實時的分布式搜尋引擎和分析引擎，具有很強的資料搜尋和聚合分析能力。
在這之前我們已經搭建了一個elk日志系統，可以複用elasticsearch叢集做存儲，也可以複用kibana來做一些基礎的資料分析可視化。
使用elasticsearch來做資料存儲，最重要的是兩件事：建立elasticsearch的映射模闆、批量插入。elasticsearch會根據插入的資料自動建立缺失的index和doc type，并對字段建立mapping，而我們要做的建立一個dynamic template，告訴elasticsearch如何自動建立，參考如下。批量插入，可以通過elasticsearch的bulk api輕松解決。
<b>作者：mr-bruce來源：36大資料</b>
點選檢視：<b></b>
<a href="https://yq.aliyun.com/articles/73497" target="_blank">創業公司如何做資料分析（一）開篇</a>
<a href="https://yq.aliyun.com/articles/73618" target="_blank">創業公司如何做資料分析（二）營運資料系統</a>
<a href="https://yq.aliyun.com/articles/73698" target="_blank">創業公司如何做資料分析（四）elk日志系統</a>
<a href="https://yq.aliyun.com/articles/73762" target="_blank">創業公司如何做資料分析（五）微信分享追蹤系統</a>
<a href="https://yq.aliyun.com/articles/73818" target="_blank">創業公司如何做資料分析（六）資料倉庫的建設</a>