說起網際網路、電商的資料分析，更多的是談應用案例，如何去實踐資料化管理運營。而這裡，我們要從技術角度分享關於資料的技術架構乾貨，如何應用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、微信的應用，都是從這個系統裡出去的，能實現聚合一個企業的所有資料，在一個系統裡面進行展示。

應用案例

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