本文以公司自建的運營分析系統(tǒng)為討論對象，對系統(tǒng)的產品架構設計及技術方案選型進行了分析以及要點說明。

目前市面上關于流量分析的產品已經(jīng)做到非常標準化了，如GrowingIO、諸葛IO、神策數(shù)據(jù)等，通用的用戶分析、轉化分析、留存分析等功能已經(jīng)非常完善了，但是在公司實際應用過程中，運營人員總會有各種個性化的需求是市面上通用功能無法滿足的。也是基于這個原因，不少公司會自建運營分析系統(tǒng)，本文會詳細描述下之前我所在的公司運營分析系統(tǒng)的產品架構設計及技術方案選型，希望能夠給到各位一些參考。

一、現(xiàn)狀和問題

1.1 埋點方案重構

我們公司埋點方案做得早，最早的時候只有代碼埋點，而且PC/M和APP的埋點上報方式不同：APP端是使用appsflyer實現(xiàn)的【事件級】上報機制，PC/M端是基于頁面【元素級】上報機制。

這兩者有什么區(qū)別？

簡單來說，事件是有業(yè)務含義的，比如【首頁廣告位點擊事件】，指的是用戶在網(wǎng)站首頁點擊“XX廣告位”圖片的行為，這樣上報上來的數(shù)據(jù)是可以直接指導分析的；

頁面元素的上報是冷冰冰的元素采集，同樣是廣告位點擊，頁面元素上報會通過在廣告欄位的代碼埋點對每個廣告圖的點擊、曝光等行為進行上報，在分析【首頁廣告位點擊事件】時，分析師需要找到首頁–廣告位–廣告圖、取其中的點擊行為數(shù)據(jù)進行分析。

也就是說【事件級】是組裝好的業(yè)務數(shù)據(jù)，【元素級】是未組裝的數(shù)據(jù)，【元素級】雖然很靈活，但在數(shù)據(jù)應用的效率、存儲成本、業(yè)務接受度上，【事件級】都要更優(yōu)。

目前GrowingIO、神策數(shù)據(jù)等廠商都使用【事件級】的埋點方案作為分析系統(tǒng)的基礎，要打造運營分析系統(tǒng)，首先第一步就要改造埋點方案。

1.2? 產品架構規(guī)劃

此前由于運營部門已經(jīng)購買了GrowingIO，因此提到IT的需求都是一些零散的個性化需求，簡單來說就是個性化報表，主要特點是：業(yè)務邏輯復雜+開發(fā)周期長，業(yè)務體驗特別差。

因為都是零散的個性化需求，缺少了對【邏輯層】的規(guī)劃，所以報表都是直接從【數(shù)據(jù)層】開發(fā)落地到【應用層】。

系統(tǒng)產品架構規(guī)劃如下圖所示：

因此，我們認為運營分析系統(tǒng)的功能建設有兩個重點：

1. 邏輯層：事件管理要與業(yè)務數(shù)據(jù)解耦，支持多租戶（滿足不同站點或業(yè)務模塊的事件邏輯隔離）
2. 應用層：事件分析是GrowingIO中使用率超過80%的功能，是用戶分群及其他分析功能的基礎

二、建設方案及計劃

2.1? 埋點方案的選擇

目前常用的埋點方案有三種，代碼埋點、可視化埋點以及全埋點（也叫無埋點）。

關于這三者之間的區(qū)別在不少的文章中都有過闡述，這里用一個商超的例子做說明。

假如網(wǎng)站就是一個大型商超，那么有三種方式可以獲取用戶數(shù)據(jù)：

第一種，在需要監(jiān)控的店鋪內、貨柜上安置攝像頭，可以完整監(jiān)控用戶在店鋪停留了多久、瀏覽哪些品類、試用哪些產品等等詳細的用戶行為；

第二種，在商超中各個主道、樓道位置預留攝像頭監(jiān)控位，當需要監(jiān)控特定主道或樓道時打開攝像頭開關就可以記錄商超用戶行為軌跡，雖然無法記錄用戶在店鋪內都具體瀏覽了什么買了什么東西，但可以知道用戶沿著哪個方向進行購物、進入了哪些店鋪、每個店鋪的人流量等；

第三種，還是預留攝像頭監(jiān)控位，但是每個攝像頭都是開啟狀態(tài)，全年無休地監(jiān)控每個主干道和樓道的人流情況；

以上三種，分別對應的就是代碼埋點、可視化埋點及全埋點。

如果說商超是網(wǎng)站，那商超里的店鋪就是實際產生的業(yè)務交易行為。

• 代碼埋點的優(yōu)勢明顯，它能夠獲取到店鋪內的業(yè)務交易行為以及行為雙方的交易媒介、交易細節(jié)等，缺點是店鋪數(shù)量多、埋點成本高；
• 可視化埋點的優(yōu)點在于靈活、低成本，根據(jù)需要分析的具體問題再打開“攝像頭”，缺點是無法獲取交易的細節(jié)；
• 全埋點對比可視化埋點，優(yōu)勢是全量獲取了商超用戶的購物行為，事后根據(jù)用途再調取監(jiān)控視頻，缺點是無法獲取交易細節(jié)，并且冗余了很多用不上的“監(jiān)控視頻”。

三種埋點方式的優(yōu)劣勢總結如下：

根據(jù)以上的例子說明，可以想見最高效合理的方案應該是“代碼埋點”+“全埋點”/“可視化埋點”，通過全埋點或可視化埋點進行網(wǎng)站整體的流量分析、再通過代碼埋點重點分析個別頁面的業(yè)務細節(jié)。

在評估了數(shù)據(jù)量以及成本等因素之后，我們選擇的是在現(xiàn)有代碼埋點的基礎上再開發(fā)一套全埋點，用以支撐運營高頻且非固化的埋點需求（例如活動、社區(qū)等頁面）。

2.2? 技術方案選型

技術選型的內容比較細也比較乏味，這里只是簡單闡述一下。

事件分析的方案在我們立項之初討論了兩套，一種是基于全量基礎數(shù)據(jù)的內存計算（選型為presto），這個方案簡單粗暴，瓶頸在于服務器內存，同時一旦數(shù)據(jù)量過大、并發(fā)過多，都會造成前端用戶體驗很差；

另一種是基于kylin的預計算，優(yōu)點是固化查詢維度數(shù)量后基于構建后的數(shù)據(jù)cube查詢效率非?？欤秉c是存儲了大量冗余數(shù)據(jù)、不支持維度太多的場景。

基于GrowingIO的使用情況調研，我們認為用戶的分析維度不會太多，最終選擇更加穩(wěn)定kylin預計算方案，整體技術架構如下：

結語

關于代碼埋點、全埋點、數(shù)據(jù)分析的方案還有很多細節(jié)可以展開進行分享，由于篇幅原因這次就先總體介紹一下，下次有機會再將里面的細節(jié)展開跟大家做分享，希望大家對于文章內容中存在疑問、錯誤的地方也予以指正，對看到這里的各位表示由衷感謝。

本文由 @LinKiD 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議