上一篇文章所说的报表开发，更准确的表述应该叫“报表开发流程”，即报表开发的需求处理流程。本文主要讲一下报表设计时需要关注的指标体系。

本文主要讨论报表指标设计的主要思路：

1 报告目的

抛开报告最终的呈现形式，报告并不是为了把数据弄得很酷，也不只是一张“表格”，你不妨把报告看作是另一种形式的PPT报告（少点文字，多点数据），这样就能理解报告的核心是“讲故事”，而不是“展示数据”。

假设您正在经营一家网上商店，您可能会关心以下信息：

今天有多少人进店，有多少人下了订单，平均顾客消费是多少，销售额是多少？

为了知道数据反映出来的业务是好还是坏，还需要找到一个“参考点”来进行对比，比如：

接下来，您可能会想到一些增加商店交易量的方法，例如：

a.购买广告服务，为商店带来更多新顾客；

b. 发现热门产品并促进用户活跃度，以促进店铺其他产品的销售；

c.组织各种活动增加成交，比如促销活动、N件商品8折、满额抽奖、随机福袋等；

d.根据价值对用户进行细分，然后进行针对性运营，比如对新客户首单给予优惠，设置店铺会员，对不同等级的会员给予不同的折扣等；

上述四个想法都需要额外的成本，你需要数据来确定额外的钱是否值得：

a.店铺的人群结构是怎样的？哪些广告渠道和店铺目标人群的契合度高？不同的广告渠道质量参差不齐，尝试一些渠道后，可能需要挑选几个进行长期合作，所以需要评估渠道的质量；

b. 哪些产品销量最好、单件利润最高？新顾客喜欢买什么？老顾客喜欢买什么？

c.这些活动真的改善了交易吗？比如投入产出比是多少，人均净利润是多少，不同产品对不同活动的响应效果如何？

d. 各人群成交表现是否有所提升？新客转化率是否有所提升？平均订单金额是否有所提升？老客复购频次是否有所提升？流失率是否有所下降？

报告可以在一定程度上回答上述问题。“业务问题导向”的报告需要注意以下几点：

在传达报告要求时也需要注意这些点。

一旦明确了报告所要解决的业务问题，那么问题对应的指标也会有一个限定的范围。

例如该报告用于评估渠道的质量，所以我们需要查看与之相关的指标，例如流量、费用、转化率、产生的收入等。

比如关注新客的留存，横向对比不同产品、不同运营策略的效果，纵向对比不同时间进入的新客留存率是否有较大差异，然后对比留存效果好的场景，找出留存率高的因素，作为后续的备用策略。

比如你想关注产品转化，可能需要看产品链接中关键页面的访问转化漏斗、停留时间、跳出率等；

2 报告结构

一份报告可以看作是多个指标的结构化组织，并以适当的形式展现出来。

指标是报表的“原材料”，需要按照业务逻辑进行组织。注意事项：

2.1 业务逻辑导向

业务逻辑导向，即用指标还原业务场景，报告内容在指标顺序上应与业务认知保持一致。即数据的呈现应有先后顺序，一般先呈现总量，后呈现具体量，重要核心数据优先。在转换过程中，建议“从头到尾”，先关注当前，后关注历史，先关注主要成分，后关注次要成分。

比如我们首先关注新老客户的分布，那么新老客户对应的指标就应该排在最前面；

比如在转化率方面，要有序还原相关主品链接；

2.2 从宏观到微观

产品生命周期 > 用户生命周期 > 产品转化流程

图片来源：

不同的产品周期关注的指标不同，例如：

比产品生命周期更细化的层面是用户生命周期与产品流程。上一篇从入门到放弃（从亲身经历谈用户生命周期）提到过，不同用户生命周期的用户，其行为模式是不同的（这也意味着给产品带来的收益不同）。在这个思路下，我们更应该考虑如何引导用户从低价值状态走向高价值状态（例如用户激励体系、运营活动、提供金钱折扣等）。

在产品流方面，我们需要知道不同用户在使用产品时的典型路径，用户在产品中是如何做决策的，哪些行为指标能体现用户的决策偏好。了解用户是产品和运营“直接引导”用户的前提（通常对于to C产品很有效）。通常我们关注的是用户的使用门槛是否降低了，用户决策是否更加流畅，用户的需求最终是否得到满足，体验如何。

2.3 从整体到细节

分割的目的主要是为了比较和诊断。

常见的细分方式有两种：

切分的粒度当然是越细越好，通常业务诊断需要的最小粒度就可以了。

经过细分之后，原本代表整体的数值可以按照换算过程或者乘以倍数进行水平扩展，也可以按照不同的子类别进行垂直扩展，从而形成一个表格（如下图所示）。

报告呈现的另一个问题是可视化。以下是一些推荐的书籍：

3. 指标解构

分解该指标的方法有两种：

3.1 自上而下的方法

自上而下的方法涉及两个重要主题：

将模糊的业务概念量化、定义，分解关键指标；

对模糊业务概念进行量化定义，就是“操作性定义”的过程。

操作性定义又称可操作性定义，是一种基于可观察、可测量、可操作的特性来定义变量含义的方法。即从具体的行为、特性、指标等角度来描述变量的运行情况，将抽象的概念转化为可观察、可测试的内容。操作性定义本质上是对研究变量的操作流程和测量指标进行详细描述。在实证研究中，操作性定义尤为重要，是研究是否具有价值的重要前提。操作性定义

例如，如果我们要定义“价格敏感型客户”，我们可以考虑这类用户的关键行为：

“操作定义”能力要求分析师熟悉业务和用户，能够很好地将业务语言“翻译”成技术语言，让模糊的业务指标更好地映射到数据指标。

对于“自上而下”的指标分析，有两种常见的思维方式：

3.1.1 计算公式分析

常见的形式有两种：连续乘法和加权组合。

乘法公式中经常涉及到转换率。

例如GMV=访客数量*订单转化率*支付成功率*入仓转化率*客单价

例如，活动实际参与人数=目标用户数*活跃率*认领率*可用率*使用率

以现场派发优惠券活动为例，首先确定一定数量的目标人群，然后发送推送消息或短信通知（或活动信息只对这一类人群的用户可见）。筛选出来的第一批用户就是“目标用户”，但即使用户收到了通知，也未必会去访问商品。中间还有一层“主动转化率”，真正来的用户未必对这个活动感兴趣，如果感兴趣的用户会获得优惠，那就涉及到“领券率”。有些优惠券是有门槛的（比如满100减10），但并不是所有用户都会达到优惠券的门槛，有的用户会去购买，有的用户不会，所以还有一个满足使用条件的“可用率”。满足可用条件才会用？不一定。 比如，用户到收银台付款的时候，手里有优惠券，但是此时有其他的“竞品折扣”（而且通常折扣是不叠加的），比如在收银台使用XXX信用卡的折扣等等。一些对价格敏感的用户甚至发现，就算在这个平台使用优惠券，还是不如在另一个平台便宜，然后就直接放弃订单了。

注：分析活动转化时，需要区分“用户发起”和“平台自动化”活动。因为有些活动是平台直接将优惠券发放到用户账户，所以不存在“收款”动作和对应的“收款率”。

加权组合涉及到细化的类别，比如各个渠道贡献的访问流量，不同类型用户带来的交易占比等。

例如平均订单价值 =

，这里c代表产品i的数量，p代表产品i的价格。如果想提高平均订单价值，可以参考此公式，调整产品价格，增加单品销量，扩大产品品类等。

在价格调整方面，可以针对不同人群、不同地区制定不同的价格，或者提供不同的产品“版本”（每个版本都有差异化的服务），比如印象笔记个人付费版就有“标准账户”和“高级账户”。

截图自官网

如果想鼓励用户多买，可以参考下图

3.1.2 产品工艺

产品流可以简单理解为典型用户使用产品时所走的典型路径。

有三个方面需要注意：

产品的主要业务类型是什么？目标用户是C端还是B端？销售的是什么产品和服务？比如京东上的生活用品、电器，唯品会上的衣服美妆产品，国美上家电，还有豆瓣、知乎等资讯平台； 产品的用户角色有哪些？比如出行平台上的角色可以分为司机和乘客，电商平台上的角色可以分为卖家和买家，资讯平台上的角色可以分为生产者、传播者、消费者等； 不同用户角色使用产品的流程是怎样的？比如出行平台和外卖平台上供需双方的运作流程明显不同；

在整理流程图的时候，要注意一些关键元素，可以参考《商业模式画布》（如下图），也可以在百度上用关键字“业务逻辑图”搜索图片，案例很多，由于版权问题，这里就不贴出示例流程图了。

注：精益数据分析还提供了常见商业模式的流程图。

商业模式画布

除此之外，还可以通过结合之前的分析经验、咨询产品和运营人员、对数据波动归因的整理发现、阅读其他人的分析文章等方式寻找其他影响因素。

影响因素可分为可控性和稳定性两个维度。

针对不同类型影响因素的应对策略（仅供参考）：

3.2 自下而上的方法

这是作者总结的方法，类似搭积木，把基础指标组装成指标体系。

常见的分析指标都是由“维度”和“测量”两部分组成，“维度”可以理解为分类变量或者标签，“测量”则是统计值（“维度”也可以看作是“测量”的修饰语），例如：

当然，“复合指标”也可以拆解，例如：

整理常用指标后，基本维度（）为：

五个维度简称“4WP”，可以理解为“标签”，维度之间可以组合成新的维度，维度与测量之间也可以组合成共同的分析指标。

基本测量()：

基本测量通过组合运算或在时间维度上衍生出“复合测量”：

总结一下，自下而上的方法就是“4WP-H”（H代表维度，How Much/Many）。这种方法的好处是：

4WP

下面解释每个维度的含义。

时间

地方

用户是谁

产品“外部”的用户标签，即不依赖于产品的用户属性。

产品内的用户标签是指基于业务对用户进行角色划分。

活动内容

如上图所示，事件包括两类：

产品

产品可以看作是“人-货-地”模型中的“货”。不过，除了“货”，这个维度还包括产品的页面设计和配套服务：

时间、地点、用户、事件、产品五个维度得到的标签大多可以运用在“用户画像”或者用户标签中，维度下的细分要结合实际业务场景，以上细分维度仅供参考。

最后补充一下个人对报告开发的几点想法。

报告开发的三个层次：

第一阶段是需求处理。类似上面报表开发部分提到的，很多时候业务方已经有了明确的报表格式或者字段，报表开发方通常按照需求来做就可以了。但是这样可能会带来问题，比如如果一个业务对接了多个分析师，开发的报表之间数据有重叠，就可能会造成数据计算和存储资源的浪费，甚至会出现口径不一致（比如指标名称相同但计算方式不同）的情况，导致业务方无所适从。

第二阶段是数据整合。为了解决多人开发的“多乱”报表问题，可以考虑的解决方案是维护少量的中间宽表，分析师使用统一口径，统一数据管理。这些中间表覆盖了业务分析（无论是数据分析还是报表开发）的高频场景，直接调用这些中间表的效率会高很多（常用的维度和度量都在里面，不需要二次计算）。另外，一些中间表可以作为用户标签表（这样数据就可以直接推送到运营平台调用），省去了很多重复工作。

第三阶段是“自由”定制，将报表需求分为“主动”和“被动”两类，之前的报表开发更多是“被动”模式（或者说“处理”模式），在“被动”模式下，大部分报表开发工作都是由数据分析师来完成的。

在“主动”模式下，业务方接入报表系统，报表系统提供友好的交互页面，通过拖拽（类似操作数据透视表）即可构建自己的报表（无需编写代码），报表可定时分享和推送。分析师负责维护指标的口径和生命周期，也负责培训业务方如何使用报表平台。底层数据则由ETL同事负责，根据不同的分析主题构建底层数据宽表。简单来说，报表前端由业务方操作，中层由分析师规划主题、赋予指标口径，底层由ETL同事开发。

附：本文思维导图

报表开发需求可以参考这篇文章报表开发