說起互聯網、電商的數據分析，更多的是談應用案例，如何去實踐數據化管理運營。而這裡，我們要從技術角度分享關於數據的技術架構乾貨，如何應用BI。

原文是雲猴網BI總經理王衛東在帆軟大數據上的演講，以下是整理的文字稿。

在電商領域，我們一般認為所有的數據都可以分為四大類型，流量、銷量、商品和會員，這也是最基礎的報表需求。

流量部分，可以分為受訪、點擊、搜索、來源等等。這些流量信息運用的重點在於一些廣告包括一些產品的改版以及搜索引擎的相關信息展示。雖然這方面百度、GA可以給你提供這方面的信息，但未必能完成一個企業的所有需求。

銷量部分，會分為銷售、補貼、渠道、支付、地域等等。但對於這些信息，領導更關注流量有多少，銷量有多少，然後投入是多少，哪個渠道帶來的銷量是最多的，轉化率是最高的，目標客戶重點在什麼區域。但是對於我們的實際運營，我們還要繼續往下細鑽，需要對商品和會員的信息挖掘得更加細緻。

商品部分，會涉及到的品類、庫存、毛利、動銷和轉化，一般電商商品的品類大多會分為三級，但也會往下細分到四級，他需要細化到每個品類的轉化率，哪個更高？以及在每一個品類裡面哪一個商品的動銷率最高，哪種的商品的轉化率是最高，因為你需要實時調整和改變。對於會員來講，還要了解其註冊情況、復購情況、活躍度以及喜好和流失等等。所有的這些就構成了我們的常規基礎報表。

關於BI，包含3個階段。第一階段是常規的報表製作階段，第二階段是數據分析，這裡的數據分析並不是現有數據的陳述，那是歷史數據沒有太大意義，不能幫助預測。而數據的價值恰恰在於預測而不是陳述，所以這些信息我們會用來風控。

在電商領域會有這樣幾個風控需求，流量異常，轉化異常和訂單異常。那這樣的風控是怎麼做的呢？比如流量異常，加入我們設定的日常流量是30萬的PV，某天突然間小於30萬了，那就可以設一個閾值說我的流量小於30萬了，這個稱之為預警。

然後講一下統計學上的一些操作。第一種稱之為UCL，在統計學裡面稱之為質量控制圖。在這個圖裡，所有的流量都含有一定的趨勢，可以去判斷一個數據的出錯，與歷史信息產生的異常。一般來講，產生的絕大多數數據會滿足質量分布，98%的數據所處的範圍區間會在均值加上兩倍標準差的概率之內。為什麼要做這樣一個模型呢？以前我們沒有運用這個模型之前，運營部門經常會跟老闆報告這一天流量、銷量是多少，當問及為什麼下降的時候無從解釋，數據是否超出了可控範圍無從知曉。有了這樣一個模型就很好解決了。

風控之後還有其他需求比如用戶畫像-推薦。用戶畫像是基本投放的前提條件，只有先做用戶畫像才能有推薦系統。推薦系統之外還有一個底價系統，底價系統是用來監控對方的價格數據以及提取商品賣點。

所有這些之後，如果要建設一個BI系統，該如何選型呢？免費？收費?還是自建？這裡據一些實際例子，做個對比。

免費統計

比如免費的流量統計，百度、GA都是免費的統計工具，接入很快，埋入代碼就行，但是無法聯通H5，APP，數據也不能連入資料庫。其次，免費的工具無法解決銷量會員商品數據問題，處於企業自身數據安全的問題，包括企業的BI系統，外網是無法訪問的。

其次，廣告渠道的數據不準確，他的統計一定虛高，所以這一塊需要第三方的參照。而且每家計算標準不一，數據差異大。

收費平台

收費平台介入快，成本相對較低，但數據的私密性較差，多數據源的聚合有難度，每一個埠的唯一識別問題很難去定義。自定義程度也不高，因為它是做通用化的，行業細化不夠，溝通成本較高。

自建平台

最大的有點在於自定義程度高，數據更為精細，可以為多數據的聚合和鑽取，但缺點就在於建設周期長，人才很難找。

選型建議

這也是我們為什麼找帆軟這個企業來做第三方的工具，因為相關人員的成本很高，所以這方面工具的選型建議找專業的來做。避免被業務人員的需求帶著跑，而是利用工具去引導。

其次，我們一直認為數據的實時性和準確性很重要，用於風控和預測，而帆軟報表FineReport的自定義程度可以讓非專業人員也能著手做。最後一點，數據的可視化採用編程代價最小，這一點FineReport在數據可視化方面是很不錯的。

系統架構

這是目前我們公司的系統架構

首先是兩個數據，用戶行為數據和業務數據。商品會員交易庫存這一方面是業務數據，這些業務數據多數存儲在my sql資料庫里。埋點系統里的渠道數據分為兩端，PC和H5的採集很簡單，用腳本組件進行採集，這是通用的。但App就需要打制組件。

拿到數據以後會往flume裡面去，到flume里直接取到之後，上面會搭一層隊列，因為如果單純依靠flume的話，系統會卡死，因為flume經常出現卡頓現象，也就是說你去控制他的一些監控腳本的話也是沒意義的，因為有時候他的內存卡住了，資源佔用，他依然在那動。所以搭建這個隊列有個好處，第一，走的是消費者模式；第二，裡面有位置信息，一旦出現數據錯亂可以回補。

這些數據，我們首先要滿足實時性問題，我們採用的是ES。利用ES做實時查詢能解決很多問題，這也是我們原來做大數據的時候經常說給到對方企業採購時，你會發現前期沒問題，但越做到後面我們一直說做數據倉要分主題，包括說做Cube之類的，這些都沒有意義，當數據量達到一定層級以後，依然很慢。

然後是我們的BI系統。所有BI系統都是在展現層和應用層，展現層可以選擇FineReport、echart、excel，這個根據企業的情況去定義。但如果企業沒有專業的人員， FineReport是你最好的選擇，如果用別的話，後期維護成本很高。在BI系統裡面不光是做展示你還需要做介面的，這個信息設施需要做介面推送給第三方，包括剛才PC、H5、微信的應用，都是從這個系統里出去的，能實現聚合一個企業的所有數據，在一個系統裡面進行展示。

應用案例

電商裡面存在很多黃牛黨的事兒。但我們做活動的目的是讓用戶享受到實惠，所以在提交訂單的時候會有一個過程，並不是立即審核通過的，但這個過程必須很短，要考慮到訂單轉化的問題。如下圖，左邊是後台系統的展示，這是疑似刷單名單的截圖展示。流程是這樣的，用戶提交完訂單以後，會有一個模型檢測，這個模型檢測是純機器，從模型檢測再到專家知識。如果在模型檢測中符合會到名單里去，否則會進入到專家支持，專家支持完了以後如果認為是正常訂單，才能到支付階段，否則的話都會到疑似名單，到時候再人工判斷。

喜歡這篇文章嗎？歡迎分享按讚，給予我們支持和鼓勵！