中介SaaS系統中統計模塊設計

SaaS系統中，統計是一個不可或缺的模塊；C端產品中，或許也會向用户展示一些數據，但僅限於展示用户本人在產品中的使用數據；例如keep中的用户鍛鍊時長統計，但這些並不是必需的統計數據。而對於B端的SaaS系統，由於用户數量多，業務性強，公司管理人員需要查看公司的數據狀況和員工的業務情況；所以SaaS系統中需要一個單獨的統計模塊，便於公司管理人員查看系統數據。

而SaaS系統由於行業和業務的不同，統計的數據維度和報表類型會有差異；而中介業務有其特別的業務流程和關注指標，所以SaaS系統中的統計模塊也和其他系統有很大的不同。

我將數據統計總結為三個層面：基礎數據統計、數據可視化、數據分析。

這篇文章我將分析一下中介SaaS系統的基礎數據統計——基礎數據統計，顧名思義，就是對系統中的數據做一些基礎的處理，進行分類整合；當然這也需要產品設計，並不是在PRD中撂下一句話就完事了。

基礎數據統計也需要確定報表類型、數據統計指標、數據更新方式、表格樣式。

01 確定報表類型

設計統計模塊的第一步是確定報表類型，即你需要展示哪些報表。只有確定好大致的報表框架後，才能在此基礎上確定需要統計的數據指標。

在中介SaaS系統中，基礎數據報表大致有兩種類型：運營數據報表、財務數據分析。

• 運營數據主要是房客源的數據以及圍繞房客源進行的業務動作。
• 財務數據主要是統計業績金額和成交單數等財務相關數據。

運營數據報表主要有綜合報表、房源總數、房源新增、房源業務、客源總數、客源新增、客源業務；財務數據報表主要統計業績金額和成交單量。

確定好了統計框架和報表類型，設計統計模塊的第二步是確定好需要統計哪些數據；產品經理要基於系統中當前存在的數據和公司管理者關注的指標，選擇出需要統計的數據指標。

02 選擇數據指標

上述報表框架下，按照數據類型來説，可以分為存量數據和增量數據。

• 存量數據指的是某一指定時間點上（多是當前最新時間），系統裏積累的結存數據；
• 增量數據是指一個時間段內，系統內增加的數據。

根據存量數據和增量數據的定義，我們可以將房源、客源、業務、合同、財務中的數據進行劃分，以此來設計不同類型的報表。

按照上述報表分類中，房源總數、客源總數為存量數據，房源新增、房源業務、客源新增、客源業務、業績統計、單量統計都是增量數據。

1. 存量數據

存量數據中主要統計截止當前最新時間，房客源的總數，以及不同情況的房客源的數量。

房客源作為中介公司最主要的資源和數據，管理者最關注公司目前的房客源數據情況；房源類別是二手房、新房、租房。雖然一般來説，中介公司主要的業務是二手房交易；但是隨着一二手聯動趨勢的加強，大部分中介公司並不會單一地只做一項業務，會兼顧二手房、新房的業務。

房源數據需要先統計房源總數、二手房總數、租房總數、新房總數，這樣管理者能夠快速瞭解公司目前的業務重心和房源類別佔比；再按照房源性質、類型、狀態、來源進行分類統計；當然，如果公司業務中，會特別關注房源的一些特項，例如老闆比較關注上傳了照片、VR、視頻的房源，也可以進行統計。

客源也是如此，選取客源的分類和標籤進行統計；因為目前大部分中介公司還是更注重房源的管理，所以一般來説，客源的指標沒有房源那麼多，統計的維度也會相對少一些；但是如果中介SaaS系統中的客源管理功能做的非常細緻，客源管理像CRM系統那樣非常精細，客源的統計指標也會非常多。

如果想通過數據來確定房客源總數的統計維度，可以在系統房客源列表的選項中進行埋點，統計出經紀人和管理員在日常查詢房客源時操作最頻繁的選項；通過埋點結果來輔助產品經理的調研結果，這樣會讓整個報表的結構更符合用户需求。

2. 增量數據

不同於房客源總數這類展示當前時間點現狀的存量數據，中介管理系統中增量數據主要是展示一段時間內的業務數據，同時還能具體展示每日/每月/每年的新增數據。

以房源新增報表為例，房源新增作為重要的資源獲取動作，報表主要是展示每日的房源新增數；故橫軸表頭為統計時間維度，查看不同時間段內員工每天的房源新增數。

房源新增的第一步是統計每日房源新增總數，但如果想統計地再詳細一點，可以通過豐富列表的篩選項來達到統計目的；例如，可以將房源類別（二手房/新房/租房）、類型（公盤/私盤）、狀態、錄入員工等選項作為統計維度；這樣在查看報表的時候，可以非常細緻地查看不同房源的新增情況。

例如上圖，房源的新增時間統計的顆粒度可以是日、月、年，管理員可以根據自己需要統計的時間段，查看時間段內每天新增的房源數。

如果中介公司非常重視某一類房源的業務，則也可以通過組合篩選進行針對性統計；客源新增的統計報表邏輯大致也是如此，只是實際情況中，客源會有一些自己特有的統計指標，例如客源等級等。

03 數據更新方式

談到數據統計報表，數據更新方式一定繞不開。

在設計報表時，就要先根據報表的類型，來確定數據更新方式；數據更新有兩種：實時更新、定時更新。

從產品的前台感觀來講，實時更新是數據每分每秒都在更新，就算你長時間停留在當前頁面不進行刷新操作，數據也會即時更新；在這種更新方式中，上傳數據多，數據處理壓力更大；但是有一些數據必須是實時性的，就一定要採用這種方式，例如水電量表，這是要實時上傳數據的。

但是在設計報表時，還是要提前先跟開發確認一下數據承載能力，不然的話在後續項目上線時，很容易出現問題。

定時更新數據是後台會在幾個小時（具體間隔時間可以定義）更新數據；如果用户在當前頁面停留了1個小時，就算這一個小時中數據量發生了很大的變化，但是如果沒有刷新頁面的話，報表中的數據還是1個小時前進入該頁面時的數據。

大部分統計報表數據不需要實時展示，再加上為了數據和系統的穩定性，多采用定時更新的方式；而中介SaaS系統的數據更是如此，新增房客源、新增業績和單量這些並不是操作比較頻繁的數據，所以採用定時更新毫無問題；但是為了提高用户體驗和儘可能地提高數據準確率，可以在技術條件允許的情況下將定時更新的間隔縮小一些。

04 表格樣式

從產品設計的角度來講，統計報表的設計工作量並不多，難度也不大；雖然主要是表格，但其中還是要注重一些設計細節。

1. 篩選項

篩選項的設計，首先需要考慮報表業務的特性，管理員會想篩選的哪些內容，以此為依據來選擇篩選項。

除了根據報表類型而定的特殊選項，統計報表中也會有一些通用的選項；例如時間選項和組織架構選項。大部分報表都有日期選項，主要是為了讓用户能夠自己選擇查看歷史時間段的數據；日期篩選的維度通常有日報/月報/年報，如果再詳細一點，還有周報/季報——這些時間節點都是用户可能會關注的數據時間點，大體上能滿足他們在篩選數據時的需求。

選擇日期範圍

選擇月份範圍

還有一種篩選是時間選項，但這種在報表中用的不太多，因為大多數數據統計的維度到“日”已經足夠了；當然也會有一些對時間要求很細緻的報表，會篩選到“時/分”的，這個時候就需要日期篩選和時間篩選進行組合查詢。

任意時間範圍

通用篩選項中，除了時間選項，組織架構選項也非常重要；如果説時間選項決定了可以統計哪些時間的數據，那組織架構選擇則決定了可以統計哪些人的數據；該選項需要按照SaaS系統客户的組織架構特性來進行設計，例如中介行業的組織架構通常是公司-區域-門店-小組-普通員工，那它的組織架構選項就是這幾個層級的組合。

按照上述篩選方式，最終展示的維度是員工，即篩選一個門店，報表會展示該門店下所有員工的數據。

這種只能查看員工數據的篩選方式過於固定且單一了，當用户是一個大集團且部門層級很多的話，很難按照層級來進行篩選，也很難展示層級之間的數據對比；選項中可以提供多種組織架構維度，讓用户可以根據自己的需求選擇“按公司/按區域/按門店/按小組/按員工”進行篩選；這樣既可以展示不同的組織層級數據，也方便用户對比不同層級間的業務數據。

篩選項可以説是最簡單的設計了，但是在設計時還是要多看看時下最新的一些控件，看看有哪些不錯的交互效果，這樣能讓報表模塊擺脱“陳舊感”，風格更新穎獨特。

舉個栗子，組織架構的篩選，最簡單地是把區域、門店、小組、員工這四個選項擺在一起，這樣也不是不行；只是如果篩選項過多的時候，會很佔地方且過於死板，交互性不好；但如果使用級聯篩選，組織結構的層級性更清晰了，用户的操作動作減少了，交互上也更方便了。

多個並列擺放

級聯選項

2. 表格設計

統計表格的設計並沒有太多的發揮空間，主要是要堅持“用户友好”理念，提高用户體驗。這需要在產品設計時注重細節，列高、列寬、隱形邏輯的展示等等；報表細節多考慮一分，用户在使用過程中的體驗會上升一大步。

表格設計中，要從用户的角度考慮多種因素：首先是列寬列高的確定，既要能夠完整地展示數據，又要讓用户能夠的視覺上感到很舒適；數據展示過於密集，用户很難清晰地查看報表。

其次是凍結窗格和縱橫滾動條，數據過多時，需要拖取滾動條來查看數據，這個時候就需要確定哪些窗格是需要固定的，才能方便用户對應數據；不然的話用户只能看到數字，不瞭解數字對應的是哪些指標。

最後是隱藏邏輯的提示，報表中些隱藏的邏輯，例如數據更新時間、數據指標的具體含義，這些都是用户不知道的，所以需要對用户進行提示；提示的方式要隱蔽但不能隱藏，提示的文字要言簡意賅且通俗易懂。

05 總結

基礎數據統計只是報表設計的第一步，但是基礎數據統計並不是簡單地將excel表格搬到系統中，其中還是需要設計和思考；只有做好基礎數據統計的表格，打好基礎，才能將報表統計的能力延伸到數據可視化、數據分析報表。

#專欄作家#

異彩，微信公眾號：一隻蝸牛慢慢跑，人人都是產品經理專欄作家。從事房產管理系統的產品工作，關注To C產品的交互設計、運營、結構設計和商業模式。在成為一名優秀的產品人的路上努力前行。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議