前文报表开发准确应该说是“报表开发的流程”,即报表开发的需求处理流程,本文关注点在于设计报表时需要关注的指标体系。
本文主要讨论报表指标设计的主要思路:
1 报表的用途
抛开报表的最终呈现形式,报表并不是要让数据看起来很酷炫,或者看起来只是“表”。不妨把报表看成PPT报告的另一种形式(文字比较少,数据会相对更多),这样就能理解报表的核心是“讲故事”,而不是“秀数据”。
假设你现在运营一家网络店铺,那么你可能关心的信息有:
今天进店多少人,有多少人下单,客单价多少,销售额多少;
为了知道数据上反映的业务好坏,你还需要找到“参照点”来对比,比如:
接下来,你可能会想一些办法来提升店铺交易,比如:
a. 购买广告服务,为店铺带来更多的新客;
b. 发掘爆品,促进用户的活跃,以带动店里的其他商品销售;
c. 搞各类活动来提升交易,比如搭配促销、N件8折、满额抽奖、随机福袋等;
d. 按照价值高低对用户细分,然后针对性地运营,比如新客首单优惠,设立店铺会员,不同等级的会员优惠力度不同等;
上面4个想法都需要额外增加成本,你需要数据来判断多花的钱是否值得:
a. 店铺的人群结构如何,哪些广告渠道和店铺的目标人群吻合度高,不同广告渠道的质量参差不齐,试过一些渠道后,你可能还需要从中挑选几个长期合作,那么你需要评估渠道的质量;
b. 哪几个商品销量最好、单品的利润高?新客喜欢买什么?老客喜欢买什么?
c. 这些活动真的对交易带来提升了么?比如投入产出比如何,人均净利润如何,不同商品在不同活动上的响应效果如何?
d. 每类人群的交易表现是否有提升?新客转化率提升了?客单价提升了?老客复购频率增加了?流失减少了?
报表在一定程度上可以回答上面的问题,以“业务问题导向”的报表需要关注一下几点:
这几点也是在报表需求沟通时需要注意的。
明确了报表要解决的业务问题,那么问题对应的指标也就有了限定范围。
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 从整体到细分
细分的目的主要是对比和诊断。
细分的常见两种方式:
细分的颗粒度并不是越细越好,通常满足业务诊断所需的最小颗粒度即可。
经过细分,原来表示整体的一个数值,可以在横向上按转化流程或者乘法因子进行展开,或者纵向上按不同的细类展开,这样就成了一张表(如下图)。
另一个关于报表展示的问题是可视化,这里推荐一些书籍:
3 指标的拆解
指标的拆解分为两种方法:
3.1 自上而下的方法
自上而下的方法涉及到两个重要的课题:
对模糊的业务概念进行量化定义就是“操作性定义”的过程。
操作性定义,又称操作定义,是根据可观察、可测量、可操作的特征来界定变量含义的方法。即从具体的行为、特征、指标上对变量的操作进行描述,将抽象的概念转换成可观测、可检验的项目。从本质上说,下操作性定义就是详细描述研究变量的操作程序和测量指标。在实证性研究中,操作性定义尤为重要,它是研究是否有价值的重要前提。 https://baike.baidu.com/item/操作性定义
比如现在要定义“价格敏感客户”,可以考虑这类用户的关键行为:
“操作性定义”的能力需要分析师熟悉业务和用户,且能很好的将业务语言“翻译”成技术语言,这样才能较好地将模糊的业务指标映射为数据指标。
对指标“自上而下”的拆解,常见的思路有两种:
3.1.1 计算公式拆解
常见的形式有连乘和加权组合两种。
连乘公式中多涉及转化率。
e.g. GMV = 访客数*下单转化率*支付成功率*出仓转化率*客单价
e.g. 活动实际参与人数 = 目标用户数*活跃率*领取率*可用率*使用率
拿一次站内优惠券发放活动来说明,先是圈定了一定数量的目标人群,然后push消息或者短信通知(或者活动信息只对该群体用户可见),最初筛选的这一批用户就是“目标用户”,但是用户即使收到通知也不一定会访问产品,中间还有一层“活跃转化率”,用户真来了也不一定对这个活动感兴趣啊,如果感兴趣用户会领取优惠,就会涉及“领取率”,有些优惠券都是有门槛的(比如满100减10),但是不是所有用户都会达到优惠券门槛的,有的用户会去凑单,但有的不会,所以还有达到使用条件的“可用率”,达到可用条件了就一定使用么?不一定,比如用户到达收银台支付的时候有了优惠券,但是此时还有其他“竞品优惠”(而且通常优惠不叠加),比如收银台出现使用XXX信用卡打折等,甚至有些价格敏感的用户发现即使在该平台使用了优惠券,还是不如另一家平台便宜,然后直接弃单。
注意:针对活动的转化分析时要注意区分哪些是“用户主动”和“平台自动”,因为有的活动是平台直接往用户账号上发放优惠券,就没有“领取”的动作以及对应的“领取率”。
加权组合则涉及细分类目,比如各渠道贡献的访问流量、不同类型用户带来的交易占比等。
e.g. 客单价 =
,这里c表示商品i的数量,p表示商品i的价格,那么要提升客单价可以参考这个公式,可以调整商品价格、提升单品销售量、扩充商品品类等。
调整价格方面,可以针对不同人群、不同地区差异化定价,或者提供不同的产品“版本”(每个版本差异化服务),比如印象笔记的个人付费版就有“标准账户”和“高级账户”,
截图来自印象笔记官网
如果要促进用户多多地买,可以参考下图
3.1.2 产品流程
产品流程可以简单理解为典型用户使用产品的典型路径。
需要注意3方面:
梳理流程图时要注意一些关键要素,可以参考《商业模式画布》(如下图),或者也可以用关键字“业务逻辑图”在百度上搜索图片,有很多案例的,因涉及版权,这里就不贴示例的流程图了。
注:《精益数据分析》中也提供了常见业务模式的流程图
商业模式画布
此外,还可以结合以往的分析经验、请教产品和运营的同时、处理数据波动归因的发现、他人的分析文章等方法找到其他影响因素。
对于影响因素可以按可控性、稳定性两个维度分类。
不同类型的影响因素的应对策略(仅供参考):
3.2 自下而上的方法
这是笔者总结的方法,类似于搭积木一样,将基本的指标组装成指标体系。
常见的分析指标都是由“维度”和“计量”组合的。可以把“维度”理解为分类变量或者标签,而“计量”就是统计数值(也可以把“维度”看作是对“计量”的修饰词),比如:
当然,“复合指标”也是可以拆解的,比如:
对常用的指标进行梳理后,整理出来的基本维度(dimension)有:
5个维度英文字母缩写成“4WP”,可以将这些维度看做“标签”。维度之间可以组合成新维度,维度和计量组合成常见的分析指标。
基本的计量(measure):
基本计量通过组合运算或者在时间维度上衍生出“复合计量”:
综上,自下而上的方法就是“4WP-H”(H代表维度,How Much/Many),这个方法的好处是:
4WP
以下分别说明各维度的含义。
时间 When
地点 Where
用户 Who
产品“外”的用户标签,即不依赖于产品的用户属性。
产品“内”的用户标签,即依据业务对用户划分的角色。
事件 What
如上图所示,事件包括两类:
产品 Product
产品可以看做是“人货场”模型中的“货”,不过在该维度下除了“货”外,还包括产品的页面设计及支撑服务:
对于时间、地点、用户、事件、产品这5个维度上的划分得到的标签大多可以用于“用户画像”或者用户标签中,维度下的细分要结合实际业务场景,上面的细分维度只作抛砖引玉。
最后,补充说明一下个人关于报表开发的一点思考。
报表开发的3个层级:
第1个阶段是需求处理,类似前文报表开发中提到的那样,大多数时候业务方已经有明确的报表形式或者字段,报表开发者通常按需求“照单抓药”即可,不过这样可能存在问题,比如多个分析师都对接一个业务,各自开发的报表之间数据有重叠,那么就可能出现数据计算、存储资源的浪费,甚至可能出现口径不一致(比如指标名称相同但计算方式有差异)的情况,进而导致业务方的困惑;
第2个阶段是数据整合,要解决多人开发报表存在的“多乱杂”,可以考虑的方案是维护少量几张中间宽表,分析师统一口径,数据统一管理,这些中间表覆盖了业务分析的高频场景(不论是数据分析还是报表开发),直接调用这些中间表的效率会高很多(常用的维度和计量都在里面,不用二次计算)。此外,有的中间表可以当做用户的标签表(这样可以直接将数据推送到运营平台调用),免去了不少重复工作。
第3个阶段是“自由”定制,把报表需求分为“主动”和“被动”两类,前文报表开发更多处于“被动”模式(或者“代加工”模式),在“被动”模式中,报表开发的大部分工作是由数据分析师负责。
在“主动”模式下,则是由业务方访问报表系统,该系统提供了友好的交互页面,通过拖拉拽(类似于操控Excel数据透视表那样)来搭建自己的报表(不用写代码),报表可以共享,可以定时推送。分析师则负责维护指标的口径和生命周期,同时还负责培训业务方如何使用报表平台。底层的数据则由ETL的同事负责,按不同的分析主题搭建底层的数据宽表。简而言之,报表前端由业务方操作,中间层由分析师来规划主题并给到指标口径,底层则由ETL同事负责开发。
附:本文思维导图
报表开发的需求处理可以看这篇文章 报表开发