报表的作用

• 监控业务，构建数据参考基线，数据要回答的两个问题：是多少？好不好？
• 数据反馈，为了扩大盘子、降本增效，技术、产品、运营等，投了很多人力物力做了很多事情，做完之后效果怎样？
• 数据预测，“接下来会怎样？”功能比较好的BI工具如Tableau和FineBI，可以根据历史指标趋势做出预测
• 从数据分析产品化的角度去理解，报表是固化高频数据需求的主要输出物，每天自动sql跑数的报表能极大减少数据分析师劳动量

报表的核心要素

趋势、细分、对比，简洁明了

指标体系构建的出发点

首先，关注整体概况，也就是看大盘，从业务关键指标(e.g.KPI)出发，再拓展到指标的变化趋势、是否达标、细分情况，从一个指标变成一套指标体系的核心是“拆解”，比如可以按照指标计算公式、业务转化环节、人货场细分等；

其次，关注“事件”，事件可以分为产品和用户。

最后，就是看“专项”，比如关注人货场中的某个主体或者某个主题。拿用户举例，可以考察用户规模(存量多少，进量多少，出量多少)以及来源渠道，可以考察用户生命周期的转化进展(e.g.参考AARRR)，还可以考察单客或细分客群的获客成本、生命周期价值等；

产品处于不同生命周期阶段关注的指标或者业务优先级不一样，所以有的指标虽然在报表中体现，但是优先级并不是那么高，此时可能更应该关注在长期目标下拆分出来的短期的目标及相对应的数据需求。

指标的衍生

目前可以考虑两种思路：

1.自上而下拆解

• 可以从业务环节入手，看不同的产品角色是如何在产品中一步一步往下走的，从用户视角出发，绘制用户地图，每一步走一下看看哪些关键行为节点，也可以从内部视角出发，看我们对于用户在产品上有哪些期待的行为或产出；
• 可以按照指标公式拆解，参考杜邦公式类似的思路，将指标一层一层细化；
• 时间、空间两个维度下都可以拆分；

2.自下而上组合

指标可以分为“维度”和“度量”两部分，度量是没有“修饰词”的数量、金额、长度等，加上场景等修饰词就是业务上的指标。

笔者参考“人货场”模型，将业务上的维度分为如下5种。

报表开发容易遇到的坑

1、伪报表需求

报表开发是为了解决高频看数据的需求的，一般不要把一次性或者偶发性的数据需求做成报表，花了很多时间做出来可能很少用到；

谈报表需求的时候还是要先沟通清楚需求方的意图。

2、指标口径不统一

不同的人做不同的报表，但是指标有交叉的时候，很容易遇到业务方拿某个数据问你为啥和另一个报表的数据对不上这样的情况。

3、报表冗余

这也是很常见的问题，多个报表出现了较大的overlap，但是每个报表的信息又不完整，一方面业务方看数据很累，另一方面，数据分析师维护报表的工作量也不小。

建议：

• 将一些在报表或者分析中高频用到的指标按用户或天这样的颗粒度建成中间表，后面要分析或者出报表的时候，就可以快速通过少数几张表输出数据，中间表最好能每天自动更新；
• 做好业务指标的主题规划，把不同的业务方关注的指标归类，然后组织成不同的指标体系，尽量在一张报表(或者一个页面)中呈现出来，这也是搞数据指标“体系”的原因。

4、报表的维护

报表的维护可以分为增、删、改3种情况。

“删”报表比较简单，如果是业务变动或者被其他报表替代等原因，报表下线就行，用不上的数据任务都要停掉，另一方面要做好对报表的生命周期管理。

报表的“增”和“改”就是要在原有报表基础上添加或者删除一些指标，或者调整指标的计算口径，改动的前提是要熟悉报表中的数据计算过程。

假设现在有一个用Excel做出来的报表，用了大量公式加上还有逻辑复杂的VBA，这样很难直观看到从最初的数据输入到最后的指标输出之间的计算过程，更不要说一步一步复原出来，类似这种“可逆向性”很差的工作后期维护就相当坑。

所以报表好维护的前提，首先是让没做这个报表的人也能轻易上手，从头到尾把数据流程跑通，提供必要的代码和文档说明，其次工具的选择也很重要，比如你很非主流，用Java把报表搞了出来，但是数据分析组的其他同事并不熟悉Java，这就是坑队友的行为。

报表工具的选择首先要保证团队协作的便利，其次是维护性和易用性等方面的考量。

懂IT的朋友可能会说，交给数据库啊mysql 、oracle，写两条SQL，借助数据库的运算性能就解决了。再不行，找程序员写代码，批量做报表，数据录入、图形化报表、甚至数据分析都可以交由程序开发，性能杠杠的。

那如果有报表工具，可以直接和数据库连接（数据导出+填入数据），也能连接各系统的业务数据，还能高效率批量做报表，展现，交互分析，可视化大屏，那就是我今天想说FineReport，作为纯Java编写的报表工具，在易用性方面真的是很Ok的。

我觉得我不用做过多的描述了，详见《腾讯IT男转行数据后感慨：没用过报表工具，别说自己懂报表 》。