前文报表开发准确应该说是“报表开发的流程”，即报表开发的需求处理流程，本文关注点在于设计报表时需要关注的指标体系。
本文主要讨论报表指标设计的主要思路：
Why 明确报表的用途，谁看？对方关心什么？对方怎么使用数据？
What 报表的结构，指标结构有哪些注意事项？
How 指标拆解的方法，分为“自上而下”和“自下而上”两种方法；
1 报表的用途
抛开报表的最终呈现形式，报表并不是要让数据看起来很酷炫，或者看起来只是“表”。不妨把报表看成PPT报告的另一种形式(文字比较少，数据会相对更多)，这样就能理解报表的核心是“讲故事”，而不是“秀数据”。
假设你现在运营一家网络店铺，那么你可能关心的信息有：
今天进店多少人，有多少人下单，客单价多少，销售额多少；
为了知道数据上反映的业务好坏，你还需要找到“参照点”来对比，比如：
你想知道过去一个月每天的交易趋势如何，这样可以判断今天的店铺交易是上升还是下降，如果交易发生波动，你想知道是周期性现象，还是说进店客流减少或者商品库存不足等；
即使发现交易上升也不能放松警惕，你还想知道竞争对手们的境况如何，可能隔壁老王家的店铺交易甩了你好几条大街，找到和“竞品”的差距后，你更清晰地了解自己处于市场中的什么位置；
接下来，你可能会想一些办法来提升店铺交易，比如：
a. 购买广告服务，为店铺带来更多的新客；
b. 发掘爆品，促进用户的活跃，以带动店里的其他商品销售；
c. 搞各类活动来提升交易，比如搭配促销、N件8折、满额抽奖、随机福袋等；
d. 按照价值高低对用户细分，然后针对性地运营，比如新客首单优惠，设立店铺会员，不同等级的会员优惠力度不同等；
上面4个想法都需要额外增加成本，你需要数据来判断多花的钱是否值得：
a. 店铺的人群结构如何，哪些广告渠道和店铺的目标人群吻合度高，不同广告渠道的质量参差不齐，试过一些渠道后，你可能还需要从中挑选几个长期合作，那么你需要评估渠道的质量；
b. 哪几个商品销量最好、单品的利润高？新客喜欢买什么？老客喜欢买什么？
c. 这些活动真的对交易带来提升了么？比如投入产出比如何，人均净利润如何，不同商品在不同活动上的响应效果如何？
d. 每类人群的交易表现是否有提升？新客转化率提升了？客单价提升了？老客复购频率增加了？流失减少了？
报表在一定程度上可以回答上面的问题，以“业务问题导向”的报表需要关注一下几点：
谁看报表数据？不同的职能、不同的业务线KPI也不一样，关注的点也不一样。
对方关心什么？部门老大、产品、运营等关注的数据的维度和颗粒度是不一样的，比如产品可能会关注哪个产品环节转化有问题？ABTest结果表明哪种方案更好，如果全量放量能提升多少KPI？
数据用来做啥？有人关心业务进展，有人关心活动效果，有人关心产品流程等，常见的关心问题比如——现在做得如何？距离目标多远？有没有什么做得不到位的地方？提升KPI的方案效果如何？
这几点也是在报表需求沟通时需要注意的。
明确了报表要解决的业务问题，那么问题对应的指标也就有了限定范围。
e.g. 报表用来评估渠道质量，那么就要看哪些指标与其相关，流量、费用、转化率、带来的收入等
e.g. 关注新客的留存，横向看不同产品和运营策略的效果对比，纵向看不同时期进入的新客留存率是否存在较大的差异，然后对标留存效果好的场景，找出留存率高的因素，后期可以作为备用策略；
e.g. 关注产品的转化，可能要看产品环节上关键页面的访问转化漏斗、停留时间、跳出率等；
2 报表的结构
报表可以看做多个指标有结构的组织，并以适当的形式进行展示。
指标是报表的“原料”，需要利用这些”原料“按业务逻辑组织起来，需要注意的点：
业务逻辑导向，报表关注的问题不同，选取的指标和结构就不一样，而不同的“故事”，呈现的逻辑也不一样；
从宏观到微观，产品生命周期 > 用户生命周期 > 产品转化流程，不同产品周期下关注的指标不一样，产品的转化流程是最细节的；
指标要有”总-分“结构，先报告整体情况，再报告细类情况；
2.1 业务逻辑导向
业务逻辑导向是指用指标还原业务场景，同时报表在内容上要在指标顺序上和业务的认知保持一致。也就是说在数据的呈现上要有优先级：一般先总后分，重要的核心数据排前面，转化流程中建议“从头到尾”，先关注当前再关注历史，先关注主要成分再关注次要成分。
e.g. 我们优先关注的是新老客的分布，那么对应新老客的指标应该是靠前的;
e.g. 涉及到转化率的时候要按顺序还原相关的主要产品环节；
2.2 从宏观到微观
产品生命周期 > 用户生命周期 > 产品转化流程
图片来自：https://marketing-insider.eu/product-life-cycle-stages/
不同的产品周期关注的指标不同，比如：
引入期，在于导入种子用户验证产品价值和业务模式，产品上关注产品价值是否切合用户需求，产品设计上是否有硬伤，运营上更关注“留存”(留存不好的情况下，拉新再多也会“漏掉”)
成长期，在于扩大用户规模，前期用户留存情况好，运营上注重拉新和活跃；
成熟期，收割时刻，提升用户的变现，拓展产品的边界，扩大业务范围和用户黏性，尽可能延长产品生命周期和用户生命周期。
衰退期，市场环境已经发生变化，这个时候不仅要看内部情况，还要关注市场的竞品，如果大家的数据都往下掉，说明市场正在萎缩，成熟期的产品是“现金牛”，衰退期的产品是“瘦狗”，可能需要开发新的产品，把旧有的用户导入到新的产品中。
比产品生命周期更细化的层级是用户生命周期和产品流程，如前文从入门到放弃(从个人经历谈用户生命周期)所述，不同用户生命周期下的用户有不同的行为模式(也意味着带给产品的收益不同)，在这种思路下更多地要考虑怎么引导用户从低价值状态进入高价值状态(e.g.用户激励体系，运营活动，提供金额优惠等)。
在产品流程上，我们需要知道不同用户使用产品的典型路径是怎样的，用户在产品中如何决策，哪些行为指标可以反映出用户的决策偏好。对用户的理解是产品和运营“定向引导”用户的前提(通常对to C类的产品有效)。通常关注是否降低了用户的使用门槛、让用户更顺利地决策、最终是否满足用户需求以及体验如何。
2.3 从整体到细分
细分的目的主要是对比和诊断。
细分的常见两种方式：
转化环节上的细分，类似鱼骨图那样对主干环节拆分为枝干，再细拆，通常产品分析上用得更多；
并列分组(可以嵌套)，类似于“MECE”原则，将整体数据拆分为不重叠的细类，各细类之和即为整体，比如用户拆分为新客老客(或者按会员等级、用户价值、年龄段、地区等用户属性)，来源终端可以分为app\web\wap等(或者不同的广告渠道)。细分的维度可以参考本文第3.2节中提到的“4WP”(用户、时间、地点、事件、产品5个维度)。
细分的颗粒度并不是越细越好，通常满足业务诊断所需的最小颗粒度即可。
经过细分，原来表示整体的一个数值，可以在横向上按转化流程或者乘法因子进行展开，或者纵向上按不同的细类展开，这样就成了一张表(如下图)。
另一个关于报表展示的问题是可视化，这里推荐一些书籍：
用图表说话:麦肯锡商务沟通完全工具箱，Gene Zelazny，清华大学出版社，主要内容讲商务场景下选用什么图表，以及优化方案；
数据之美:一本书学会可视化设计，Nathan Yau，中国人民大学出版社；
鲜活的数据:数据可视化指南，Nathan Yau，人民邮电出版社；
Storytelling with Data: A Data Visualization Guide for Business Professionals，Cole Nussbaumer Knaflic(中译本为：用数据讲故事)；
写给大家看的设计书，Robbin Williams，人民邮电出版社
Excel图表之道，刘万祥，电子工业出版社，工具不重要，方法更重要，学习优秀的商业图表(经济学人等期刊杂志)也是可视化精进的方式之一；
3 指标的拆解
指标的拆解分为两种方法：
自上而下的方法，基于业务和数据的理解，对自变量X和因变量Y(KPI)下操作性定义；
自下而上的方法，类似于搭积木一样，将基本的指标组装成指标体系；
3.1 自上而下的方法
自上而下的方法涉及到两个重要的课题：
对模糊的业务概念进行量化定义；
对关键指标的拆解；
对模糊的业务概念进行量化定义就是“操作性定义”的过程。
操作性定义，又称操作定义，是根据可观察、可测量、可操作的特征来界定变量含义的方法。即从具体的行为、特征、指标上对变量的操作进行描述，将抽象的概念转换成可观测、可检验的项目。从本质上说，下操作性定义就是详细描述研究变量的操作程序和测量指标。在实证性研究中，操作性定义尤为重要，它是研究是否有价值的重要前提。 https://baike.baidu.com/item/操作性定义
比如现在要定义“价格敏感客户”，可以考虑这类用户的关键行为：
筛选商品时使用“价格按从低到高排序”功能的频率；
是否有“比价”行为，可能访问商品详情页的时候跳出转而访问其他网站，不久后有再次访问同一商品；
对优惠的偏好，e.g.凑单参加活动，只在(或者大多数时候)大促的时候才下单，或者过往订单中，优惠金额占该用户总交易金额的比例较大；
“操作性定义”的能力需要分析师熟悉业务和用户，且能很好的将业务语言“翻译”成技术语言，这样才能较好地将模糊的业务指标映射为数据指标。
对指标“自上而下”的拆解，常见的思路有两种：
计算公式拆解；
业务环节拆解；
3.1.1 计算公式拆解
常见的形式有连乘和加权组合两种。
连乘公式中多涉及转化率。
e.g. GMV = 访客数*下单转化率*支付成功率*出仓转化率*客单价
e.g. 活动实际参与人数 = 目标用户数*活跃率*领取率*可用率*使用率
拿一次站内优惠券发放活动来说明，先是圈定了一定数量的目标人群，然后push消息或者短信通知(或者活动信息只对该群体用户可见)，最初筛选的这一批用户就是“目标用户”，但是用户即使收到通知也不一定会访问产品，中间还有一层“活跃转化率”，用户真来了也不一定对这个活动感兴趣啊，如果感兴趣用户会领取优惠，就会涉及“领取率”，有些优惠券都是有门槛的(比如满100减10)，但是不是所有用户都会达到优惠券门槛的，有的用户会去凑单，但有的不会，所以还有达到使用条件的“可用率”，达到可用条件了就一定使用么？不一定，比如用户到达收银台支付的时候有了优惠券，但是此时还有其他“竞品优惠”(而且通常优惠不叠加)，比如收银台出现使用XXX信用卡打折等，甚至有些价格敏感的用户发现即使在该平台使用了优惠券，还是不如另一家平台便宜，然后直接弃单。
注意：针对活动的转化分析时要注意区分哪些是“用户主动”和“平台自动”，因为有的活动是平台直接往用户账号上发放优惠券，就没有“领取”的动作以及对应的“领取率”。
加权组合则涉及细分类目，比如各渠道贡献的访问流量、不同类型用户带来的交易占比等。
e.g. 客单价 = 
，这里c表示商品i的数量，p表示商品i的价格，那么要提升客单价可以参考这个公式，可以调整商品价格、提升单品销售量、扩充商品品类等。
调整价格方面，可以针对不同人群、不同地区差异化定价，或者提供不同的产品“版本”(每个版本差异化服务)，比如印象笔记的个人付费版就有“标准账户”和“高级账户”，
截图来自印象笔记官网
如果要促进用户多多地买，可以参考下图
3.1.2 产品流程
产品流程可以简单理解为典型用户使用产品的典型路径。
需要注意3方面：
产品的主要业务类型是啥？面向的用户是C端还是B端，卖的产品和服务是啥，e.g. 京东上的生活用品和电器，唯品会的服装、美妆，国美主要卖家电，豆瓣、知乎等是信息平台；
产品的用户角色有哪几类，e.g.出行平台上的角色可以分为司机、乘客，电商平台可以分为卖家、买家等，信息平台上可以分为生产者、传播者、消费者等；
不同用户角色使用产品的流程是怎么样的？e.g.出行平台、外卖平台上的供需两方的操作流程显然是不一样的；
梳理流程图时要注意一些关键要素，可以参考《商业模式画布》(如下图)，或者也可以用关键字“业务逻辑图”在百度上搜索图片，有很多案例的，因涉及版权，这里就不贴示例的流程图了。
注：《精益数据分析》中也提供了常见业务模式的流程图
商业模式画布
此外，还可以结合以往的分析经验、请教产品和运营的同时、处理数据波动归因的发现、他人的分析文章等方法找到其他影响因素。
对于影响因素可以按可控性、稳定性两个维度分类。
稳定是指已经得到验证的假设。简单划分某一因素x对Y的影响效果，可以考虑方向性，比如正向关联或者负向关联，正向关联可以理解为这个因素x的取值越大，Y就越大，方向是定性的分析，更精细的定量分析要考虑x和Y的明确“函数关系”——x改变多少量会带来Y多大的改变(准确来说应该是Δx和ΔY的关系)。
可控是指可以通过产品或运营的方法来引导用户的认知和行为，进而改善关键指标，这些因素背后对应着可以操作(改变/驱动)的行为。
不同类型的影响因素的应对策略(仅供参考)：
稳定&可控因素的作为产品和运营的长期策略，
不稳定&可控的可以作为短期策略，可能需要细化颗粒度以及迭代测试来发现和验证因素和指标的关系的稳定性。
稳定&不可控很可能是用户的因素或者市场环境，通常具有时间周期性的，e.g.节假日用户的活跃下降、春节期间某地区的出行订单大量减少，不同出生年代的人群在不同app上的活跃占比不一样，占比也会随着时间缓慢变化。
不稳定&不可控的因素，通常是偶发外部因素，e.g.竞品的市场活动、突发舆论事件等，通常做到定性解释，这部分的因素通常都比较复杂。
3.2 自下而上的方法
这是笔者总结的方法，类似于搭积木一样，将基本的指标组装成指标体系。
常见的分析指标都是由“维度”和“计量”组合的。可以把“维度”理解为分类变量或者标签，而“计量”就是统计数值(也可以把“维度”看作是对“计量”的修饰词)，比如：
DAU，日、活跃、用户、数量，其中【日、活跃、用户】就对应【时间、事件、用户】3个维度；
PV，页面、浏览、数量，【页面、浏览】对应【产品、事件】2个维度；
UV，独立访问用户数，【事件】维度下的计数；
当然，“复合指标”也是可以拆解的，比如：
页面转化率，页面B访问UV/页面A访问UV
“复购”和“留存”本质都是在一段时间内发生第二次关键行为的比率；
注意：复购可以针对“用户”，也可以是“平台”、“品牌”、“品类”甚至某SKU，比如“二次续费会员”，这个会员就可以看做一个SKU
对常用的指标进行梳理后，整理出来的基本维度(dimension)有：
时间 When
地点 Where
用户 Who
事件 What
产品 Product
5个维度英文字母缩写成“4WP”，可以将这些维度看做“标签”。维度之间可以组合成新维度，维度和计量组合成常见的分析指标。
基本的计量(measure)：
时长、金额、频次(或计数)、距离、重量、长度(面积、体积)、温度等；
映射到业务上，比如交易金额、在线时长、登陆次数、出行距离、包裹重量、货物体积、天气温度；
基本计量通过组合运算或者在时间维度上衍生出“复合计量”：
统计指标：sum、count、avg、max、min、median、var、std等；
复合指标：客单价，件单价、平均每次访问时长(页面数等)、页面A到页面B的转化率，行为A到行为B的转化率等；
综上，自下而上的方法就是“4WP-H”(H代表维度，How Much/Many)，这个方法的好处是：
它可以像思维导图一样，帮助你发散思维，从“维度”和“计量”两方面去找到可以计算的指标(好比一张“指标地图”)。
这些维度和计量是跨业务场景的，通用性很强；
这5个维度是产品和运营中常关注的5个维度，常见的业务场景都可以覆盖到。
4WP
以下分别说明各维度的含义。
时间 When
起止时间，e.g. 访问时间，活跃时段；
持续时长，e.g. 页面停留、使用时长、浏览/观看/收听时长等；
业务映射，e.g.工作日/周末，早上/中午/晚上，平常日/节假日，通勤时间/休息时间/三餐时间；
不同颗粒度，e.g. 年、季、月、周、日、时、分等；
特殊标记，e.g. 第一次，第二次，最后一次等；
地点 Where
从哪里来，强调入口信息；
e.g. 新客引流渠道(POE)，用户登录入口(app\wap\web等)；
待在哪里(定位)，强调用户所在的位置；
e.g. 现实地理位置，e.g.登陆地(IP解析、GPS定位等)，收货地(收货地址等)，打车出发地等；
e.g. 生活场所(业务场景映射)，e.g.在家、办公室、商超餐饮、车站地铁、外出旅行；
e.g. 设备信息(在线入口的现实载体)，e.g.手机型号、操作系统、网络类型；
e.g. 网络虚拟空间，在某群组(网站、app等)、游戏的某个区或某个地点；
去往哪里，强调用户行为指向的地点；
e.g. 出行应用(包括日常通勤、出差、旅行等场景)、求职类的网站某种程度上也有这类特性；
用户 Who
产品“外”的用户标签，即不依赖于产品的用户属性。
社会角色：家庭角色(妻子、妈妈等)、工作角色(职业、工作性质)；
传播角色：内行、联系员、推销员、消费者(参考《引爆点》)；
收入水平，财产/负债情况等；
国籍、种族、年龄、性别、学历、婚育情况等；
产品“内”的用户标签，即依据业务对用户划分的角色。
用户的生命周期或产品参与深度，e.g. AARRR；
用户在产品中扮演的角色，e.g.卖家/买家，借款方/贷款方，司机/乘客，内容生产者/传播者/消费者等；
产品赋予用户的角色，e.g. 加V，会员等级，游戏中扮演的角色
事件 What
如上图所示，事件包括两类：
用户->产品，用户主动对产品的操作行为；
e.g. 注册、浏览、访问、点击、评论、投诉、收藏、支付、转发等；
产品->用户，包括产品中的信息反馈、信息通知、产品策略干预、运营活动等活动，用户通常是“被动”状态。
e.g. ABTest测试用户对几种不同的广告展示方案的点击率的差异；
e.g. 节假日大促的时候上线了不同的运营活动，有的是为了拉新，有的是为了促交易；
产品 Product
产品可以看做是“人货场”模型中的“货”，不过在该维度下除了“货”外，还包括产品的页面设计及支撑服务：
“货”，即用户的消费对象(产品)，e.g. 电商购物、多媒体信息(电子书、音频、音乐、电影/演出等)；
产品的页面设计(可以看做是“货”架)，e.g. 某页面、栏目、专题等；
产品的支撑服务，即用户为了得到“货”需要开通或使用的产品功能，e.g. 绑定手机号，绑定银行卡，身份验证等；
对于时间、地点、用户、事件、产品这5个维度上的划分得到的标签大多可以用于“用户画像”或者用户标签中，维度下的细分要结合实际业务场景，上面的细分维度只作抛砖引玉。
最后，补充说明一下个人关于报表开发的一点思考。
报表开发的3个层级：
第1个阶段是需求处理，类似前文报表开发中提到的那样，大多数时候业务方已经有明确的报表形式或者字段，报表开发者通常按需求“照单抓药”即可，不过这样可能存在问题，比如多个分析师都对接一个业务，各自开发的报表之间数据有重叠，那么就可能出现数据计算、存储资源的浪费，甚至可能出现口径不一致(比如指标名称相同但计算方式有差异)的情况，进而导致业务方的困惑；
第2个阶段是数据整合，要解决多人开发报表存在的“多乱杂”，可以考虑的方案是维护少量几张中间宽表，分析师统一口径，数据统一管理，这些中间表覆盖了业务分析的高频场景(不论是数据分析还是报表开发)，直接调用这些中间表的效率会高很多(常用的维度和计量都在里面，不用二次计算)。此外，有的中间表可以当做用户的标签表(这样可以直接将数据推送到运营平台调用)，免去了不少重复工作。
第3个阶段是“自由”定制，把报表需求分为“主动”和“被动”两类，前文报表开发更多处于“被动”模式(或者“代加工”模式)，在“被动”模式中，报表开发的大部分工作是由数据分析师负责。
在“主动”模式下，则是由业务方访问报表系统，该系统提供了友好的交互页面，通过拖拉拽(类似于操控Excel数据透视表那样)来搭建自己的报表(不用写代码)，报表可以共享，可以定时推送。分析师则负责维护指标的口径和生命周期，同时还负责培训业务方如何使用报表平台。底层的数据则由ETL的同事负责，按不同的分析主题搭建底层的数据宽表。简而言之，报表前端由业务方操作，中间层由分析师来规划主题并给到指标口径，底层则由ETL同事负责开发。
附：本文思维导图
报表开发的需求处理可以看这篇文章 报表开发
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
