BI系統建設

很早就想聊聊BI系統，這個并不是一個新概念，很多運營多年的廠商也早就已經有自己的BI系統。之前Funplus也在谷歌分享會上公開分享過BI的不同階段。

（來源：谷歌培訓）

每個公司對BI的理解和需求不同，相對應的開發優先級也自然會有所不同。個人心中理想化的BI除了以上投放方向的系統自動化之外，也還需要一些產品和運營側的數據分析，相對當前的業務給出數據預警和優化提示，同步幫助產品的進一步提升。這樣不僅僅是一個對市場投放有利的工具，同時也是一個對產品和運營有利的工具。幫助全面分析和預測后續趨勢，給出歷史對比數據，減少重復測試帶來的浪費，提高產品和活動的優化效率，為產品帶來全面的業務數據提升。

不過想要達到這個水平離不開公司對應業務部門的配合，和不斷優化，基于DMAIC方法對各板塊的業務進行不斷改善。

（來源：谷歌搜索關鍵詞DMAIC）

個人感受來說，BI的搭建尤其需要注意的是以下幾點：

對基礎業務數據要在整個公司層面有一個最根本的標準。

舉個最簡單的例子，有的公司對新增的定義是在新設備首次打開，有的公司新增定義是新增注冊用戶數。

不同的產品在基礎數據的定義上會有不同的要求，這個要求也可能會隨著不同的人員迭代產生理解上的誤差，所以非常建議在BI建設初期就規定要基礎業務數據的定義，并要求數據開發人員和業務人員充分理解不同定義下的數據概念，避免這方面誤解造成的溝通成本和需求處理成本。

如果隨著人員迭代，數據定義就有所變化，對于數據處理和后期業務使用來說效率也并不會很高。

從UA角度來說 ，就是各個平臺的API申請以及權限范圍，哪怕是廣告主，現在各個廣告平臺在數據權限申請上也特別嚴謹，不僅僅要求廣告主說明用途，同時在獲取次數等方面也有嚴格的限制；加上歸因平臺和廣告平臺以及內部數據來源對數據可能會有不同的歸因方式，在BI的設計和數據處理中就要求針對不同的歸因情況下都能有一個清晰的展現，也方便業務人員去對比不同場景下的數據情況。

例如AF的分天渠道來源數據，和廣告平臺API拉取匯總的分天渠道來源數據表，這兩個表的新增歸因不同，哪怕是一個指標也不能直接融合在一列中，對同一個指標的不同歸因情況要求都需要考慮到，更加自動的BI可能會根據用戶行為在偏向自家廣告主角度基礎上給出更可信的來源歸因。

還有一個方面就是對于批量化數據和需求的處理，比如說運營對于分批用戶的活動設置，投放端對于批量上傳的需求，實現這些需求能大大的提高人效節省很多人力成本，把更多的精力用來去做更有創造力和更需要思考的一些事情上。

批量上傳工具可以幫助跨平臺多國家多素材進行批量投放，一站式的投放管理和廣告托管工具，就節省了很多優化師上傳大量廣告和刷新廣告數據的時間，不僅可以讓素材測試變得高效化，更多的時間可以進行產品或者素材層面的創新。

所以自動化工具的不斷智能化也是需要BI系統不段進化的一個重要環節，也是最能直接幫助公司實現降本增效的一步。目前有部分公司是自研發，也有部分是利用第三方工具來實現的，未來這部分可能會開發的越來越智能化。

主要是指基于業務數據給出的一些個性化場景分析，最好是實現自動預警基礎業務數據并給出相關業務指標異常的調整建議。

比如說直播，直播的開播率看播率趨勢變化，以及在目前的發展周期下合理的預測范圍是多少，在超出或者低于這個范圍的時候給出提示，甚至給出合理的指標異常調整意見和進一步的數據影響范圍預測，自動優化數據和決策方案，幫助公司對應業務的的正常業務數據運行，根據不同的業務場景給出個性化的場景分析。

上面的例子中如果一家公司可能有好幾個直播類產品，不同的用戶群體和直播內容板塊，就需要BI進行不同內容的數據展現和分析，定制不同的產品事件點位方案也需要結合業務進行細節考慮。

更進一步的，如果和市場甚至平臺方業務緊密且體量足夠大的話，也會有反過來影響市場的地方，最簡單的例子就是各家都在某平臺增量的時候，外部競爭環境帶來的單價上漲，這個不是內部因素，而是市場變化導致的數據異常。BI需要不斷地去學習歷史數據并結合當前情況給出合理的變化分析以及決策判斷，這一點也很考驗產品本身的體量和算法能力，通常這部分也會和平臺方進行合作搭建功能。

上面提到的點肯定不是需要注意的所有內容，更多的細節就需要BI開發人員來配合實現，從業務層面來說，【定義-衡量-分析-提高-管理】的過程都需要在實際的案例中不斷得到提升。

一個好用的BI離不開團隊的共同維護，或者說全自動化的BI這個概念可能就像財富自由對于我們個人的概念一樣，存在于每個企業的心中，每個人自由的道路不一樣，不同企業的BI搭建也有不同的階段，有的企業BI是全自有部署和搭建，也有的借用API完成三方對接進行部分功能完善，不論哪種適用于當前的始終才是最好的。