数据分析师避不开的问题:如何体系化地开发报表?
报表体系的构建是数据分析师的日常工作,也是面试中高频考察的问题。虽然很多数据分析师都会做报表,但不代表报表是有体系的,尤其是面向不同业务场景、不同的业务方要看不同的数据指标时,报表容易变得过于分散、产生大量数据冗余、或者数据分析师额外增加了很多重复劳动。
如何构建报表体系呢?
- 关注的指标得有,能较全面地用数据描述相应的业务主题;
- 指标计算准确,数据经得起业务的验证;
- 层次合理(通常是“总-分,先主要后次要”结构),符合看报表的思维路径;
- 维度丰富,便于从细类上了解指标的组成以及定位指标变化所对应的环节;
其次,数据分析师作为“报表供应链”中的上游,需要关注的是在满足数据需求的基础上还要能做到:
- 报表要方便管理;
- 能高效输出报表;
综合业务方和数据分析师的视角,报表的体系化不仅体现在“前端”的展示,而且也要在“后台”做好表结构和指标的设计。
关于报表的“前端”展示,推荐阅读公众号“木东居士”连载的系列文章:
本文重点在于“后台”报表基础数据。如果报表指标设计更体系化,可以参考如下思路:
- 明确报表主题及核心指标;
- 在空间上拆解核心指标;
- 在时间维度上进行对比;
以下分述。
e.g. 如果主题是“收入”,那么就会涉及收入有哪些来源、影响收入有哪些因素、收入的变化趋势、是否能达成本周期的KPI等;
e.g. 如果关注用户增长,则可以梳理有哪些用户分类、AARRR各环节各有什么关键指标、与用户增长相关的产品或运营活动效果及ROI如何等等;
e.g. 如果关注渠道或流量入口,则会看渠道质量相关的流量、转化率、用户价值、引流单客成本、ROI等指标;
e.g. 如果主题是商品,则会关注进销存等环节,在商品上可以按品类、等级、价格、用户、成分、产地、工艺等属性进行分类,然后监控商品的采购、库存、调拨、上架、销售、促销、等环节。
该场景下关注的核心指标或者KPI是啥?
影响这些核心指标的因素有哪些?
该业务场景下涉及哪些环节?
业务方看数据或用数据的思路是怎样的?
2. 在空间上拆解核心指标
细化成分和结构,将一个关键指标展开成一张表(加权求和公式),有两类方法:
- 自上而下的公式拆解(从业务出发);
- 自下而上的“维度-计量”组合(从数据出发)
2.1 自上而下的公式拆解
通常业务指标都可以拆分成加权公式,需要用到“加法”的地方就拆分成“行”或者不同的分组,用到“乘法”的地方则拆分成“列”或者业务环节等。
- “行”的展开就是指业务分组的颗粒度,比如可以从用户分类、业务分类、商品分类、渠道终端等进行划分,在数据表中通常对应为“维度”;
- “列”的展开则依赖于对主干业务环节(通常存在转化率)的拆分,或者基于“连乘公式”,在数据表中对应“指标”;
拆分之后便于我们知晓不同的业务成分(终端、渠道、用户群等)以及不同业务环节(通常存在转化率关系)对整体指标的贡献情况。
同时,对比各细类分组或业务环节,也方便区分业务表现好的分组(高于均值),哪些分组则拖了后腿,以及哪些分组在哪些业务环节上还有提升空间(细类之间可看做互为竞品),在运营和产品上更容易找到发力点。
反之,将不同的维度和计量组合也能生成新的指标。
e.g. 在时间维度上可以考虑小时、日、周、月等颗粒度,可对应衍生出小时活跃用户数、DAU、WAU、MAU。再纳入用户属性,则可以继续衍生出新客DAU、老客DAU等,
关于“维度-计量”的详述更多参考
维度可以划分为用户、产品、事件、时间、地点5类,参考下图
3. 在时间维度上进行对比
指标波动的异常点定位,常涉及到数据分析中的归因任务;
不同时间范围及颗粒度下的指标趋势或周期变化;
3.1 指标波动的异常点定位
在业务所需要的足够细的颗粒度上对两段时间进行维度匹配的点对点的指标对比(将上面拆分得到的表进行“点对点”地相减,见下图),就能将变化量Δ在更细的颗粒度上进行拆分,指标波动出现在什么细类或业务环节就能一目了然。
空间结构性变化,即组成成分的变化,比如用户结构、渠道流量分布等;
时间结构性变化,和业务的周期性有关,比如线下零售行业,理论上来说排除法定节假日、调休日、促销日等“非正常”交易日后,一周内各天的交易占比是相对稳定的。
最近一年内每个月的支付成功率;
最近一个月每天的新客数量;
最近一周内每天各小时的活跃用户数;
代码规范可以参考这篇文章;
主要3点:命名规范,版式整洁,注释详细。
3. 建表,这里是指分析师为了便于分析或者报表开发而创建的中间表。中间表和报表通常是1对多的映射关系,也就是一张中间表可以出多个报表,这样的好处是避免分析师重复建表,集中精力维护几张核心的中间表就能满足很大一部分业务场景。
区分维度、指标,数据表要有好的扩展性,维度上的颗粒度要足够细,如果你设计的中间表结构不能用Excel透视表来进行各种翻转操作及衍生各种次级指标,那么表结构的扩展性就可能还有问题;
时间颗粒度要足够细,比如通常按天的统计,那么可以向上覆盖按周、月、年等的统计,就不用为了计算不同时间颗粒度的指标单独建表了;
注意动态属性的匹配,比如匹配用户属性做统计分析时,用户当时的行为要和当时的属性匹配,这个也是之前笔者常会遇到的错误之一;
存储的数据范围视业务而定,比如业务上通常只关注近6个月内的数据变化,那么建表的时候放最近6个月的数据进去就行,全量更新通常不是最佳选择,业务上高频使用的数据范围其实不大,要尽可能节省计算资源和存储资源。
本文主要内容就是这些,《报表开发》系列前两篇文章如下:
- (需求篇)