在本文，作者描繪了一個理想的數據BI系統應該長成的樣子。你是這樣的么？enjoy~

在日常工作中，無論是to C還是to B的產品汪，都需要面臨一個問題，那就是在業務發展到一定規模的時候，由于林林總總的原因，譬如出于安全性考慮，亦或是業務場景愈加復雜等等，市面上的第三方數據分析平臺或者自家的平臺已經無法滿足業務發展的需求，這時候，就要著手搭建一個強力的BI工具，以適應高速發展的業務。

而一個好用的工具，將會解放生產力，極大的提高工作效率。加持了這個增益buff的運營和分析師們，將會如虎添翼，向你展示什么叫地表最強戰斗力。

就算沒有KPI的壓力，那試想下，運營小姐姐因為你一手設計的出色BI系統而驚喜時，作為產(dan)品(shen)汪的你，是不是有機會……咳~

在進行產品設計前，先花點篇幅來講講數據在從產生到消亡（歸檔）的生命周期中需要經歷哪些階段吧。

圖：圖片來自網絡，侵刪

數據采集

數據來源分兩塊，一塊是內部數據，一塊是外部數據。對于to B的業務，內部數據多為業務數據，譬如零售業的供應鏈倉儲以及GMV的細分數據等，金融業的交易流水和風控模型(風控模型也包含了用戶行為數據)等，對于to C的業務或產品，除了基礎的流量數據、業務數據外還會有用戶行為數據等。這類內部數據的獲取較為基礎，常規的CS/BS的接口數據交互即可完成數據采集，對于C端產品，比較重要的是用戶行為數據的采集，這里就需要做好數據埋點的工作，細化到每個事件的節點。

這里拿微信舉例，從安裝，啟動，登錄/注冊的前期行為到聊天，公眾號閱讀，朋友圈查看等后期行為，不同流程的事件線會共用一些數據埋點。

一個用戶從喚醒app開始，記錄一系列的操作節點，帶上序號和時間戳，就可以完善的記錄用戶行為日志，不過這類技術的問題就不深入探究，看研發團隊怎么選擇技術方案了。下面臆造一條行為組的日志信息。

先拋開數據加密的問題，這串日志的意思是下午13:40:03，ID為498161的用戶，通過點擊ID為164618的推送主動將app被喚醒，此時生成該條行為組信息的ID為341325，喚醒后按照推送給到的參數打開app進入微信tab頁面，也就是首頁，接下來停留了約4秒后，進行了拖拽操作，手指拖拽區間從x:334,y:130到x:560,y:363的位置，然后暫停了大概2s以后，點擊了坐標x:634,y:30的位置，這個位置的目標是一欄ID為76316的對話信息，停留了約2秒后，點擊頁面中的輸入框，過了約10秒鐘，輸入框失去焦點，此時輸入框的內容為‘\u8001\u54e5\u53ef\u4ee5\u7684’（這里是Unicode，假裝加密了：），與此同時按下了發送按鈕。到了這里，這一系列的流程就已經完成了，收到好友信息的推送提醒了用戶，用戶做出了回應，并進行一系列的操作，完成了回復。

那么，這樣一組信息數據有什么意義呢？

在微信5.3.1的版本新特性中，新增了一個這樣的功能：可以撤回兩分鐘內發出的最后一次消息。

圖：微信5.3.1新特性

對于這個特性，筆者進行了簡單的思考：

1. 只考慮用戶需求，不考慮商業需求。
2. 這個操作多為撤回者的需求。
3. 假設數據統計出一般用戶從收到消息和看到消息的時間應該是在10s~30min，假設前兩分鐘有60%的用戶已經閱讀了消息。
4. 對想要撤回消息的用戶進行研究，發現撤回者出于保密、失誤、反悔或其它原因想要撤回消息，那這個準許反悔時間大概是90s，為了容錯，將容錯時間擴大一定的范圍。
5. 出于對被撤回者體驗的考慮，再壓縮這個撤回的時間，避免用戶閱讀了消息，消息卻被撤回，造成閱讀者的不適。這個時間設定在120s。

上述的數值都為猜測，進行‘撤回’這一的功能設計前，需要通過數據來對用戶行為進行研究分析，可以量化的數據為功能設計提供了衡量的標準，并在功能實現后進行數據反饋，從而修正功能設計。

為了簡潔的表達，上文的日志信息只展示行為日志，缺少了客戶端和服務端響應或監聽這些行為的日志，從一開始app被喚醒，服務器就和app建立了數據傳輸，接收第一條請求時就錄入了請求的終端信息，像設備型號，地理位置等等，一般來說app被喚醒的推送也會帶有喚起方的渠道標記等信息。除了那些輸入法開發商們，敲擊鍵盤的行為選擇不采集，因為對于絕大多數產品而言這類行為價值不是很大，還有一點就是，因為系統的權限限制，可能采集不到這類數據。

關于這類日志的采集，只要在需求的范圍內，采集地越詳細越好，這樣可以精準的定位問題，是技術支持、運營策略，還是產品設計上的問題。在一些web類應用中也見到過每次拖動或點擊就記錄行為并回傳給服務器的，這類高頻的傳輸方式能夠保障數據的完整性，但在高并發時會對服務器造成一定的壓力，產品汪可在需求評審會上提出此類需求和顧慮，提前讓研發團隊了解到這種業務場景，并出具應對的方案，下文講述數據處理時會順帶概述一些技術的方案。

內部數據都是自家的，只要權限允許，那就可以進行增刪改查的操作，但外部的數據大多不公開，需要購買，有些甚至無處購買，且外部數據的結構不一，在進行數據歸類的時候可能會造成一些困擾。對于那些能買的到的數據，往往需要進行數據清洗。

2015年號稱互聯網消費金融的元年，相關產業蓬勃發展。銀行系、電商巨頭以及一些傳統企業陸續進軍這個市場，這些巨頭們手里掌握這充足的數據，足已支撐起一個較為全面合理的風控系統。但對于那些新入局的互聯網團隊，就沒這么充足的數據源去搭建其風控系統，這時候，這些團隊就需要從市場上‘專業’從事大數據服務的公司手頭購買數據。然而，這些都是經過二道販子，三道販子甚至不知道幾手了的數據了，每一層中間商為了盈利，往數據里面兌水，一些互金巨頭為了干擾市場，也會對其中的數據進行加工并借殼售賣，到了這些使用數據的團隊手里時，這些充斥著垃圾的數據能有效利用的可能不到一成。而清洗這些數據，需要花費的成本將無限大。一個用戶風控模型的迭代修正，至少需要走完一個消費-還貸的周期，這中間需要的時間成本不是一般的團隊所能接受的。

對于那些買不到，但又可見的前端數據，就可以通過爬蟲的方式進行采集。爬蟲的歷史比較悠久，自第一個搜索引擎誕生已經過去了近三十年，而最早出現的爬蟲卻沒有明確的說法，唯一可以知道的是自主機web時代開始的。而發展到現在，爬蟲技術及其社區已經枝繁葉茂了，從近幾年流行的python到最好的語言php，以及C語言系都可以拿來寫爬蟲。一般爬蟲的原理都是構造請求，向目標服務器請求相關內容。數據本身就是一個相對敏感的點，有些數值類的數據往往是一個公司的命脈，為了遏制爬蟲來采集數據，公司一般會設計不同的機制來反爬蟲。譬如常規的服務器判斷請求頭部的UA和Referer，對cookie和驗證碼的驗證，對IP訪問次數的限制，通過對CDN標識的判別。還有一些前端的限制的方法，比如用JS動態加載數據以及一些能加大解析頁面難度的做法。

比較成熟的就是一些前后端結合的方法，比如前文所講的用戶行為記錄，再通過用戶模型算法找出爬蟲的特征，從而進行封殺。對于爬蟲，大多數網站還是比較寬容的，或者說，沒有一個萬全之策來分辨真實用戶和爬蟲，因為誤傷率一直是個繞不過去的坎。關于如何應對反爬蟲機制，感興趣的觀眾老爺可以繞道去攜程技術中心的公眾號看看，作為各類爬蟲教程的目標網站，攜程對Anti-Crawler這個課題還是有些心得的。

圖：某公眾號的前端反爬蟲策略

數據處理

一般來說，涉及的數據的存儲處理，不在產品崗的只能范圍內。但是產品汪么需要明確數據調用的需求，以便DB開發設計合理的技術架構。按照數據所在的生命周期，或者數據被調用的頻率，可以將其分為四個等級，活躍數據、休眠數據、沉默數據和歸檔數據。這里拿電商的訂單周期作為范本解釋。

• 活躍數據：這里的活躍數據一般指的是需求確定需要長期存儲的數據。不包括那些存儲在緩存里，在短時間會過期的數據。用戶確認提交訂單后，一直到確認收貨，這個期間的訂單的數據會以高頻率被訪問，用戶、商家、平臺、物流等多方角色需要查看這條數據，以確保這個訂單完成。
• 休眠數據：休眠數據被訪問的頻率一般。訂單走完正常的周期，已經超過退換貨的期限時，可能因為保修，統計分析等情況任會被調用。
• 沉默數據：這類數據被訪問的頻率相對較低，在常規處理和存儲后，已經將需要長期調用的內容存儲到其它數據庫表中作為活躍數據使用，此時源數據將進入沉默階段，一般只在周期性的統計時會被調用。在分析季度商品銷售情況時，需要翻出這筆訂單來詳細的分析。
• 歸檔數據：歸檔數據指的是已經被處理提取重要內容的源數據，為了數據完整性，對源數據進行歸檔處理，歸檔的意義不光是指備份數據，數據需要在生命周期的各個階段做好備份工作。歸檔的另一個意義是壓縮數據結構，保障核心數據能夠被快速響應。

在日常工作中，數據的等級界限也許不會這么明確，具體還得看需求的情況。

數據應用

講完了數據的產生到歸檔，相信觀眾老爺心中對這個BI數據系統的搭建已經有一個整體的規劃了，下面筆者將描述在筆者心中，一個理想的數據BI系統，應該是長成什么樣子的？

圖：產品架構

后臺的在進行有關數據的操作時，都可以選擇進行GUI和SQL的操作。下文的所有功能只描述GUI狀態下的使用，不描述SQL狀態下的使用。保留SQL功能的原因有以下幾點，就像Bash會比GUI界面發生意外的概率小很多一樣，純SQL操作比GUI操作來的穩定，而且數據開發更樂意去使用SQL。這種保險設計可以在產品迭代的過程中，實現一些因為不常用而缺失的功能。

下面按照操作流程，講講各模塊的功能。

數據管理

在生產環境中，業務數據，流量數據或著其他數據的元數據已經產生，存儲在數據庫，這部分數據稱之為「數據源」，這個功能的頁面稱之為「數據源管理」，整個后臺對數據源的唯一的權限只有讀取(select)，不然誤操作造成損失，這口鍋真不好分，直觀的看，好像是操作者的失誤，再深一步講，是技術規范的缺失，但追究到底，還是產品設計的缺陷，所以，權限切記控制到只讀。用戶(運營，數據分析師，數據工程師皆稱為用戶)可以讀取數據源庫表中的元數據，并存儲到數據庫，這部分被提煉過的數據稱之為「數據集」。許多數據需要每日定時或者按照其它周期進行處理，譬如那些避開服務器并發的時段的數據統計，這種數據的錯峰處理大多放在凌晨或者其他服務空閑的時段，為了節省用戶的精力和防止疏漏，這種周期性的點控式的任務就顯得很有意義，但是單個任務沒法滿足對復雜數據的處理需求，借用MySQL的事件調度器(Scheduler)和觸發器(Trigger)的設計理念，將這些任務連接在一起，讓它們按照指定條件依次執行，從而實現按照序列處理數據結構和數據內容的任務環。數據集操作生成的庫表的增刪改查權限控制在初始化時，默認只開放給用戶自己，若有需求，后期可以在權限管理中配置。

業務報表

在完成了對數據的處理后，數據還只是純粹的單一結構的內容，干巴巴的數據難以直觀地觀察，所以數據可視化這一功能必不可少。市面上優秀的開源前端框架有很多，這里推薦兩款——AntV和Echarts。這兩塊框架能夠滿足絕大多數業務場景，尤其推薦Echarts，給某度開源如此良心之作打call，Echarts中gallery社區的作品堪稱驚艷，如果這個框架能將性能再繼續優化下去，那就是做數據可視化的不二之選。關于AntV的話，友商都說Ant Design可能是開創了UI組件庫的先河，組件的視覺、交互設計和前端的融合可謂是相當讓人佩服。在實現上使用了較為先進的框架，主要還是React實現，好在今年八月，Angular版本的總算發布了。不過框架歸框架，研發同學選擇技術方案是他們的權利，產品汪在進行后臺設計時可以參考AntV，這樣可以讓你少走很多彎路。業務報表設計功能可以達到高度自定義，可以對業務報表的菜單、頁面布局進行設計。在進行圖表設計時可以選擇豐富圖表類型，從常規的折線圖、柱狀圖和餅圖等到不同領域常用的圖表，譬如K線圖，漏斗圖，關系圖等。然后再給圖表填充數據，按照規則給圖表入參，與此同時對該表報的展示對象進行用戶選擇。這種高度自由的操作方式，看似會增加研發的周期和成本，但這種設計實際上將會解放研發同學。在后期產品迭代成型后，用戶自主使用數據生成報表，而不是常規進行需求-開發的周期，從而讓研發同學將更多精力放在核心技術上而不是業務上。所以綜上所述，這種設計不光是功能上的設計，而且還是一種成本轉移的設計。

實時監控

該模塊分兩個主要功能，一個是概覽功能，一個是異常預警。概覽頁面就是業務報表的Dashboard，唯一的差別就是這里的數據多為實時數據，所以不贅述，如果希望這個門面能好看點，那就單獨拿出來，作為一個獨立的功能需求進行設計開發。關于異常預警模塊，很多時候名不副實，預警意義在于預測當某個數值達到臨界點時進行報警操作，但這種預警機制的算法可能會復雜，難以制定產品需求邏輯。所以在實際設計中，警報觸發的條件可以配置多個，按照執行周期輪詢，觸發時進行短信或者郵件等推送操作，和數據源管理一樣要注意的是庫表名稱的日期變量和事件環的設定。

權限管理

在講整個產品設計中，一直在強調權限的管理，不是筆者話多，這個關系到數據安全的問題還是得注意下的。數據庫的權限控制應當從服務器、數據庫到特定表，關于控制到特定的列甚至存儲過程，雖然MySQL有這個功能，但好像常規的權限真的沒必要控制到這么精細。當然，對于數據結構和數據內容的增刪改查權限還是有必要做權限控制的。最后，加上基本的操作日志的展示，用以查錯問責皆可。

講到這里筆者也就將整個產品設計的思路敘述完成了，觀眾老爺可能會覺得沒有圖解，過于抽象不好理解。但其實，筆者是故意沒放圖例的，因為擔心放了原型后，會誤導讀者進行雷同的產品設計，故而只敘述核心功能，不做視覺和交互上的表現。如有哪里看不懂的或有歧義的可以向筆者公眾號提問，筆者會抽時間回復的。

企業在業務早期用第三方的平臺服務是高性價比的選擇，但也要考慮到后期數據遷移的問題。第三方平臺為了最大化平臺的價值，不可避免的設計通用的產品結構和服務體系，以兼容更多業務場景，但這樣一來就不能適配企業一些特殊的業務需求。最重要的是，自家的數據的一系列操作都在別人家的服務器上運行，這個數據安全的問題是塊心病。今年年中時，作為菜鳥物流的創始成員之一的順豐，受到菜鳥集團的一波突襲，這已然不是站隊的問題了，從IaaS到SaaS，一大撂數據的處理和傳輸都是經過別人家的基礎設施，在信息主權這個問題上，一旦發生了糾紛，那處理起來一個頭兩個大。前陣子開完的人大常會上，新修訂了反不正當競爭法，也許有希望改善這個問題。畢竟對于企業而言，還是希望將更多的精力投入到業務經營上，而不是進行一些糟心的商戰。不過好在市場上已經有越來越多的數據服務供應商已經可以提供私有化部署，加上個性化的功能設計在一定程度上可以解決企業的業務需求。

究竟是自建BI系統還是用第三方的平臺，其實，在觀眾老爺心中已經有答案了。

圖：數據服商

文中產品設計參考了Dataworks和QuickBI的功能，如果觀眾老爺有興趣可以試用下，只是這個價格有點不太美麗(高級版的功能健全，基礎版的功能閹割太多了)。

筆者才學疏淺，若觀眾老爺有什么高見，還請猛烈拍磚。

作者：水果籃子，公眾號：老楊陪你來說事兒

本文由 @水果籃子 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 unsplash