自建運營分析系統:埋點&運營分析產品設計

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

自建运营分析系统:埋点&运营分析产品设计

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

一、現狀和問題

1.1 埋點方案重構

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

這兩者有什麼區別?

簡單來說,事件是有業務含義的,比如【首頁廣告位點擊事件】,指的是用戶在網站首頁點擊“XX廣告位”圖片的行為,這樣上報上來的數據是可以直接指導分析的;

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

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

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

1.2 產品架構規劃

此前由於運營部門已經購買了GrowingIO,因此提到IT的需求都是一些零散的個性化需求,簡單來說就是個性化報表,主要特點是:業務邏輯複雜+開發週期長,業務體驗特別差。

因為都是零散的個性化需求,缺少了對【邏輯層】的規劃,所以報表都是直接從【數據層】開發落地到【應用層】。

系統產品架構規劃如下圖所示:

自建运营分析系统:埋点&运营分析产品设计

因此,我們認為運營分析系統的功能建設有兩個重點:

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

二、建設方案及計劃

2.1 埋點方案的選擇

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

關於這三者之間的區別在不少的文章中都有過闡述,這裡用一個商超的例子做說明。

假如網站就是一個大型商超,那麼有三種方式可以獲取用戶數據:

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

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

第三種,還是預留攝像頭監控位,但是每個攝像頭都是開啟狀態,全年無休地監控每個主幹道和樓道的人流情況;

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

如果說商超是網站,那商超裡的店鋪就是實際產生的業務交易行為。

  • 代碼埋點的優勢明顯,它能夠獲取到店鋪內的業務交易行為以及行為雙方的交易媒介、交易細節等,缺點是店鋪數量多、埋點成本高;
  • 可視化埋點的優點在於靈活、低成本,根據需要分析的具體問題再打開“攝像頭”,缺點是無法獲取交易的細節;
  • 全埋點對比可視化埋點,優勢是全量獲取了商超用戶的購物行為,事後根據用途再調取監控視頻,缺點是無法獲取交易細節,並且冗餘了很多用不上的“監控視頻”。

三種埋點方式的優劣勢總結如下:

自建运营分析系统:埋点&运营分析产品设计

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

在評估了數據量以及成本等因素之後,我們選擇的是在現有代碼埋點的基礎上再開發一套全埋點,用以支撐運營高頻且非固化的埋點需求(例如活動、社區等頁面)。

2.2 技術方案選型

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

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

另一種是基於kylin的預計算,優點是固化查詢維度數量後基於構建後的數據cube查詢效率非常快,缺點是存儲了大量冗餘數據、不支持維度太多的場景。

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

自建运营分析系统:埋点&运营分析产品设计

結語

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

題圖來自Unsplash,基於CC0協議


分享到:


相關文章: