數據報表設計流程一：構建分析體系

1、面向業務結果的分析
b端產品經理不同于c端，業務是一切產品設計的核心，必須圍繞業務進行產品設計。首先要明確分析目的，并進行業務診斷，最重要的是打通分析鏈路。
例如要分析利潤曲線，與利潤相關的數據有利潤率、在架率、產品種類、報價策略、市場行情變動等。
根據公司具體業務不同，明晰哪些是需要重點關注的，哪些是可以暫時擱置的，特別是要跟業務團隊多溝通協調，共同商議出一個分析框架。
一般可采用枚舉法，列舉可能干擾到核心業務數據所有因素，再一一排查。

2、面向生產過程的分析
公司不僅要求分析業務結果等業務強相關數據，生產過程關系到每個人的工作效率和工作成果是否達標，生產過程同時也是對人員kpi的考核。
如對銷售的拜訪客戶數、銷售線索獲取數量、簽單客戶數，貢獻利潤占比等，對客服的工單處理數量、客戶評分、分鐘會話數量等，該部分分析主要根據使用者的操作記錄產生數據。

數據報表設計流程二：定義觀察指標
1、進行維度下鉆
定義好分析框架后，要進一步確定觀察指標，主要是對觀察維度進行拆分，逐漸細化，只有在更精細的維度分析數據才最有可能得到準確的答案。
比如在架率又可細分為日間在架率和夜間在架率，還可繼續細化為某某產品在架率，甚至可以細化到業務員王二在日間12:33誤操作某交易量極大的產品，造成利潤損失。這樣就打通了從業務結果——生產過程的分析鏈條。
又比如報價策略有可細化為具體sku的報價問題，該數據又可關聯到上游供應商近期內價格調整頻繁，而報價策略未結合該特點導致該產品報價過高/過低。
維度細化的過程中，可能會逐漸拆分為一級指標、二級指標……n級指標，但并非拆分中的每一個維度都要作為觀察指標。是否作為報表使用要結合公司業務特點并且和業務部門多次溝通協調達成共識。
在維度下鉆的過程中確定哪些維度是需要進行統計的，哪些是不需要用到的。

2、統一數據口徑
數據口徑指的是對于數據的定義，如果系統內部統計口徑不一致，就會導致業務分析出錯。如果不對數據口徑進行清晰的定義，開發人員在調用數據時可能會直接采用已有的口徑，這個已有統計口徑不一定符合當前數據指標的需要。
產品人員應該單獨書寫一份關于數據口徑的定義的文檔，并上傳至系統內部的文檔共享系統，方便業務人員隨時查閱。如果系統允許，盡可能與業務部門達成共識，形成一套標準的數據口徑。

3、定義統計頻次
確定好需要統計的數據維度形成觀察指標后，要對觀察指標分類處理，有些指標屬于關鍵性因素，有些指標屬于次要因素。有些指標單位時間內產生的數據波動較大，統計頻次可能要到分鐘級。而有些指標數據波動較小，可能一天只有幾次變動，統計頻次可設定為小時級。
數據報表設計流程三：設計呈現形式
一開始的呈現形式以簡單、好調整為主，不必急于線上化，也不必追求酷炫的交互效果。嚴格遵循mvp原則，用最小功能集合去迭代產品。

報表在設計初期必然面臨指標的頻繁調整，以及數據不準確，統計范圍需要變更等種種問題。初期可采用系統定時通過郵件發送報表，報表的形式可以是一張簡單的excel表格，這樣先試用一段時間，確定要分析的數據字段、監控指標等沒有問題后，再著手進行線上化的設計。
確認好線下的報表迭代優化完畢后，設計線上化的方案，一般考慮以下幾個方面：

默認查詢時間，統計具有延時的特點，有些數據統計必須等待訂單完成才能納入統計范圍，比如默認查詢時間定為t-6至t-2
排序規則，默認按照哪一項數據排序
篩選項設置，哪些數據選項需要篩選
統計項設置，哪些數據需要合并統計
其他極端情況考慮，數據極限值，最大時間范疇，取數為空時的處理等等

數據報表設計流程四：復盤報表設計
報表線上化固然有其優點，方便、快捷，效率高。但是也存在一些弊端，比如不夠靈活，excel表格可以方便做成各種你想要的數據透視表，而線上只能固定其中的幾種。線下還可以采用任何關聯要素利用vlookup進行匹配，線上則已經固化了分析指標。

因此，產品上線一段時間后，要及時復盤功能是否好用，是否得到認可。
使用率：可通過數據埋點看該項功能的使用率，使用率不夠要和業務部門溝通問題，及時迭代優化
觀察是否實現最初想要得到的目的，分析鏈路上是否還存在障礙
用戶滿意度: 與業務部門溝通，看使用過程中有什么不方便的地方，效率方面是否還可以得到提升