中介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 协议