报表体系的构建是数据分析师的日常工作，也是面试中高频考察的问题。虽然很多数据分析师都会做报表，但不代表报表是有体系的，尤其是面向不同业务场景、不同的业务方要看不同的数据指标时，报表容易变得过于分散、产生大量数据冗余、或者数据分析师额外增加了很多重复劳动。
如何构建报表体系呢？
在回答这个问题前，我们先切换到业务方的视角——业务方是报表的使用者，所以报表好不好用，首先应该是从业务方的需求来看的：
- 关注的指标得有，能较全面地用数据描述相应的业务主题；
- 指标计算准确，数据经得起业务的验证；
- 层次合理(通常是“总-分，先主要后次要”结构)，符合看报表的思维路径；
- 维度丰富，便于从细类上了解指标的组成以及定位指标变化所对应的环节；
其次，数据分析师作为“报表供应链”中的上游，需要关注的是在满足数据需求的基础上还要能做到：
- 报表要方便管理；
- 能高效输出报表；
综合业务方和数据分析师的视角，报表的体系化不仅体现在“前端”的展示，而且也要在“后台”做好表结构和指标的设计。
关于报表的“前端”展示，推荐阅读公众号“木东居士”连载的系列文章：
- 《七天数据可视化之旅》第一天 数据可视化过程
- 《七天数据可视化之旅》第二天：数据图表的选择(上)
- 《七天数据可视化之旅》第三天：数据图表的选择(中)
- 《七天数据可视化之旅》第四天：数据图表的选择(下)
- 《七天数据可视化之旅》第五天：常用图表对比
- 《七天数据可视化之旅》第六天：提升可视化效果的Tips
- 《七天数据可视化之旅》第七天：可视化设计实战-数据大屏
本文重点在于“后台”报表基础数据。如果报表指标设计更体系化，可以参考如下思路：
- 明确报表主题及核心指标；
- 在空间上拆解核心指标；
- 在时间维度上进行对比；
以下分述。
1. 明确报表主题及核心指标
报表的核心可能是关注某个KPI，或者“人货场”中的某个要素，这些都可以称作报表的主题，报表的任务之一就是用具有层次结构的多个相关联的指标来对某个业务主题做“画像”。
e.g. 如果主题是“收入”，那么就会涉及收入有哪些来源、影响收入有哪些因素、收入的变化趋势、是否能达成本周期的KPI等；
e.g. 如果关注用户增长，则可以梳理有哪些用户分类、AARRR各环节各有什么关键指标、与用户增长相关的产品或运营活动效果及ROI如何等等；
e.g. 如果关注渠道或流量入口，则会看渠道质量相关的流量、转化率、用户价值、引流单客成本、ROI等指标；
e.g. 如果主题是商品，则会关注进销存等环节，在商品上可以按品类、等级、价格、用户、成分、产地、工艺等属性进行分类，然后监控商品的采购、库存、调拨、上架、销售、促销、等环节。
不同的业务场景，不同的业务主题，关键指标不一样，使用的报表结构也会有所差异，不过整体的思路基本差不多：
- 该场景下关注的核心指标或者KPI是啥？
- 影响这些核心指标的因素有哪些？
- 该业务场景下涉及哪些环节？
- 业务方看数据或用数据的思路是怎样的？
梳理好上述4个问题，基本就能明确报表主题下需要哪些指标以及展示的结构。
2. 在空间上拆解核心指标
细化成分和结构，将一个关键指标展开成一张表(加权求和公式)，有两类方法：
- 自上而下的公式拆解(从业务出发)；
- 自下而上的“维度-计量”组合(从数据出发)
2.1 自上而下的公式拆解
通常业务指标都可以拆分成加权公式，需要用到“加法”的地方就拆分成“行”或者不同的分组，用到“乘法”的地方则拆分成“列”或者业务环节等。
- “行”的展开就是指业务分组的颗粒度，比如可以从用户分类、业务分类、商品分类、渠道终端等进行划分，在数据表中通常对应为“维度”；
- “列”的展开则依赖于对主干业务环节(通常存在转化率)的拆分，或者基于“连乘公式”，在数据表中对应“指标”；
拆分之后便于我们知晓不同的业务成分(终端、渠道、用户群等)以及不同业务环节(通常存在转化率关系)对整体指标的贡献情况。
同时，对比各细类分组或业务环节，也方便区分业务表现好的分组(高于均值)，哪些分组则拖了后腿，以及哪些分组在哪些业务环节上还有提升空间(细类之间可看做互为竞品)，在运营和产品上更容易找到发力点。
2.2 自下而上的“维度-计量”组合
指标都可以拆分为维度、计量两个部分。
e.g. DAU可以拆分成维度(日、活跃) 计量(用户数)，其中“活跃”则是由具体的用户行为来定义的，比如登陆、浏览、访问过首页等
反之，将不同的维度和计量组合也能生成新的指标。
e.g. 在时间维度上可以考虑小时、日、周、月等颗粒度，可对应衍生出小时活跃用户数、DAU、WAU、MAU。再纳入用户属性，则可以继续衍生出新客DAU、老客DAU等，
关于“维度-计量”的详述更多参考报表开发(指标篇)。
维度可以划分为用户、产品、事件、时间、地点5类，参考下图
计量则分为基本计量和复合计量，这两个词是笔者取的名称，可以理解为：基本计量就是最原始的那类数据指标，比如重量、金额、计数(PV、UV等)；复合计量就是利用基本计量进行二次计算得到的数据指标，比如转化率、客单价、PV/UV、DAU/MAU之类，复合计量指标的名称里面通常带有统计含义的词，比如“均”、“最大小”、“率”、“比”等关键词。
自上而下的公式拆解是从业务角度出发，而自下而上的“维度-计量”组合则是从数据的角度出发，对维度和计量进行排列组合可以衍生出各种指标(但不是所有衍生出来的指标都具有业务意义，要筛选的)，来对“自上而下拆解”得到的指标进行查漏补缺。
当然，这些最小颗粒度的维度和计量不仅仅可以用在报表设计中，也可以用到数据挖掘或分析任务等场景。
3. 在时间维度上进行对比
基于第2步的拆分，进而在时间维度上对比，以定位变化和趋势：
- 指标波动的异常点定位，常涉及到数据分析中的归因任务；
- 不同时间范围及颗粒度下的指标趋势或周期变化；
3.1 指标波动的异常点定位
业务上通常会有同比、环比(通常是指标变化趋势具有明显的周期性时)，当日或者昨日的数据对比近几天数据等情况(指标通常没有明显的周期性或者整体平稳时)，这个时候常会出现的分析任务就是对于指标的变化量Δ进行归因，而归因的第一步是需要定位问题所在。
在业务所需要的足够细的颗粒度上对两段时间进行维度匹配的点对点的指标对比(将上面拆分得到的表进行“点对点”地相减，见下图)，就能将变化量Δ在更细的颗粒度上进行拆分，指标波动出现在什么细类或业务环节就能一目了然。
这里要特别说明一点“结构性变化”，假设某个业由 a, b, c 3个部分组成，根据业务经验发现3个部分的占比是相对稳定或者变化很缓慢的——即 a : b : c 是相对稳定的数值，假设昨天同比之前的数据3个组别发生的变化量分别为Δa、Δb、Δc，单看不同分组的变化量可能看不出什么问题——变化趋势可能相同(都上升、下降或持平)，看似“风平浪静”，其实“暗潮汹涌”—— a Δa : b Δb : c Δc 可能已经发生变化(成分相对稳定，但也有突然改变的时候)。如果业务上存在不同成分占比相对稳定的情况，建议监控各自占比的变化——设3组各自的占比为ra、rb、rc (ra rb rc =1)，对应的占比变化量为Δra、Δrb、Δrc，从“占比变化量”中更容易发现业务结构性的改变，比如业务中有时候会发现新老客占比的突然变化(虽然同比、环比看新老客的绝对数量都是上涨的)。
结构性变化分为两类：
- 空间结构性变化，即组成成分的变化，比如用户结构、渠道流量分布等；
- 时间结构性变化，和业务的周期性有关，比如线下零售行业，理论上来说排除法定节假日、调休日、促销日等“非正常”交易日后，一周内各天的交易占比是相对稳定的。
如果数据存在“周期模式”，且周期内在时间分布上相对稳定，也得小心潜藏的变化。
e.g. 某业务主要在PC端开展，周末的时候访客流量会大幅下降，但是周末流量相对于工作日的流量比例相对稳定，但是最近两个周末的数据出现了问题——虽然访客数同比或者环比都有提升，不过周末的活跃量比例下降了，如下图所示，如果周末的活跃量相对于工作日的比例不变，则应该是橙色的“预期”值，为什么周末的“相对活跃度”比之前更低了呢？是工作日的运营的广度和力度加大了么？还是调整了工作日和周末的运营节奏？或者周末的流量跑到“需求替代场景”了？
3.2 不同时间范围及颗粒度下的指标趋势或周期变化
不同业务场景下关注的时间范围及颗粒度存在差异。比如：
- 最近一年内每个月的支付成功率；
- 最近一个月每天的新客数量；
- 最近一周内每天各小时的活跃用户数；
所以，报表底层数据表设计时要考虑在时间维度上要具有扩展性，通常建议以最高频使用场景下的最小颗粒度为准，比如业务上通常都是关注日、周、月，那么最小颗粒度就是日(可以向上覆盖周、月、年等)。
对指标的变化量Δ归因通常关注的短期(近期)的数据变化，放宽时间范围，当我们看业务整体的发展情况时，就要看核心指标的长期趋势。通常要预测业务指标、制定或拆分KPI时会关注业务的长期趋势，比如增长率如何，每周、月、季度的交易比例如何等。
上面“结构性变化”中提到了“数据周期模式”发生的变化在这部分是要特别注意的，监控数据的时间范围不仅要考虑近邻的几个完整周期，还要考虑周期内存在的某种“相对固定”的模式，读者朋友可以自行思考下如果要对具有周期模式的数据设置告警阈值，需要怎么操作？
完成上述3个步骤后，报表就能基本覆盖“对比、细分、溯源”的常见需求了，报表上的数据不仅能“描述”业务场景，也能进行一定程度的“归因”。当然要继续深挖的话，还是有很多工作可以做的，比如自动归因、指标预测等。
最后，补充说一下报表的管理，主要是3方面：
1. 代码，这里主要针对SQL代码：
- 代码规范可以参考编程代码规范这篇文章；
- 主要3点：命名规范，版式整洁，注释详细。
2. 文档，报表从需求提出到上线到后期维护都要在文档上记录，比如报表的编号、中文名称、报表类型、主要指标、底层数据表名称、需求方、上线日期、上线平台、当前状态、更改记录等，通常建议将这些信息记录到wiki以便于在线协作，更多可以参考报表开发(需求篇)。
3. 建表，这里是指分析师为了便于分析或者报表开发而创建的中间表。中间表和报表通常是1对多的映射关系，也就是一张中间表可以出多个报表，这样的好处是避免分析师重复建表，集中精力维护几张核心的中间表就能满足很大一部分业务场景。
关于建表需要说明几点：
- 区分维度、指标，数据表要有好的扩展性，维度上的颗粒度要足够细，如果你设计的中间表结构不能用Excel透视表来进行各种翻转操作及衍生各种次级指标，那么表结构的扩展性就可能还有问题；
- 时间颗粒度要足够细，比如通常按天的统计，那么可以向上覆盖按周、月、年等的统计，就不用为了计算不同时间颗粒度的指标单独建表了；
- 注意动态属性的匹配，比如匹配用户属性做统计分析时，用户当时的行为要和当时的属性匹配，这个也是之前笔者常会遇到的错误之一；
- 存储的数据范围视业务而定，比如业务上通常只关注近6个月内的数据变化，那么建表的时候放最近6个月的数据进去就行，全量更新通常不是最佳选择，业务上高频使用的数据范围其实不大，要尽可能节省计算资源和存储资源。
