业务和数据,可以理解为映射关系,数据是业务在数字世界里的另一个它。举个例子来说:你衣服鞋子的尺码、喜欢吃什么口味的菜、爱看什么内容的文章、什么时候起床和睡觉等等,所有这些个人的数据都在云端被记录着,它就是你在数字世界里的映射。网上之前流行的一句话很有意思:手机可能比你自己还要了解你。就是因为它里面存储了一个数据的你。

我相信大家都清楚,手机用的越频繁,越多个人的数据被记录,它就会越好用,然后你就会用的更频繁。业务和数据就是这样的闭环促进关系:业务越全面、越深入的被线上化,反过来数据对业务的赋能就会越大。

接下来我们会就其中的数据分析环节展开来讲,在这之前,先宏观的了解一下从数据到决策会经历怎样的一个过程。

我们时刻都在被数据所记录着:年龄、身高、体重、消费金额、运动步数等等,如果只是单纯的去看这些数字是没有意义的,要用心去思考数字背后鲜活的业(灵)务(魂)。说到这里,阿北笑着又重复补充到:业务是有灵魂的!当我们从这些数字中发现业务背后的信息,再将这些数据和信息转化成一组规则来辅助我们决策(知识)的时候,数据就会变得很有价值。这个过程就是:从数据到信息,再到决策(知识)。

跟大家举个生活中的例子:体温39度是单纯的数字,背后的信息是发烧了,做出的决策(知识)就是需要去医院看病。

图2 数据-信息-知识

对于上面总结的从数据到决策的过程,我们往往会说成根据数据分析的结果去做决策,虽然这样的说法没问题,但不够直接,实际上我们是基于业务理解去做决策的,而数据是帮助我们加深业务理解的工具。数据赋能业务一般会经历四个环节:数据表现、业务原因、业务策略和作用方式。最开始我们通过数据去评估业务状态,发现业务表现异常,再全面的分析数据并结合一线的调研反馈,反复的进行猜想和数据验证,弄清楚数据表现背后的业务原因,然后思考解决问题的策略,再落地执行,监控后续效果并不断的迭代,直到问题被解决,业务发展进入正轨。

再就刚才提到的生病发烧的例子详细解释一下数据赋能业务的过程:体温39度是数据表现,背后的身体原因是发烧了(业务原因),医生说需要打点滴退烧(业务策略),之后你就躺在病床上,护士过来给你输液(作用方式),这些流程走完之后,后续还会要求你持续的测量体温(监控落地效果),如果还一直不退烧的话,可能还需要继续去输液吃药(不断的迭代业务策略),直到最后体温恢复正常(问题被解决),身体进入健康状态(业务发展进入正轨)。

分析数据定位业务问题,基于业务理解,确定解决策略,到最终正向的影响业务,整个过程中,业务策略存在两个闭环:逻辑闭环和业务闭环。

这两个闭环是互相影响的,首先要做到的就是论证逻辑闭环,保证结论可以站得住脚。等真正落地执行的时候,业务上可能行不通,就需要基于新的业务理解去迭代论证逻辑,形成新的逻辑闭环,再去落地执行,直到在业务上可以跑通。

所以在数据分析过程中会常出现两类问题:

1. 逻辑闭环相关:

   不接地气,指的是策略的逻辑论证没问题,但离业务上跑通还很远;

2. 业务闭环相关:

   策略没有落地或者落地反馈周期太长,导致业务理解只停留在当时分析数据的节点,没有得到验证反馈;

那我们在工作中怎么判断业务策略是否接地气呢?主要分成两步:

1. 深入思考策略成立的业务假设是什么?

2. 调研判断业务假设是否成立?

举个例子:你设计了一套完整的针对B端商家的权益方案,希望牵引商家按平台的方向去做生意,假设权益方案在逻辑上没问题,但要真正落地有效的话,就会涉及到一些业务假设需要成立:

1. 平台可以很好的触达商家,商家也能够理解权益方案;

2. 权益方案细节,商家真的很在意;

3. ……

接着就需要去调研这些业务假设是否真的成立?如果成立的话,那么该策略落地有效的概率就会很大;如果商家理解不了复杂的权益方案,或者商家对权益根本不在意,那说明该业务策略是不接地气的,就需要及时做出调整。当然,策略是否有效的前置调研验证是很有必要的,但有时候调研结果并不能直接推导出策略有效或者无效,那就需要设计好的落地方案,快速验证迭代。

最后也类比过来,判断某个人是否懂业务:如果这个人通篇都在讲数学逻辑,没有业务判断,或者有些业务判断明显是不成立的,那大概率这个人就不太懂业务。要做出正确的决策首先逻辑上要成立,另外在业务上也要行得通。

如今不论是企业还是个人发展,整体都在往数据方向转型,数据变得越来越重要。企业需要数据资产保持行业竞争力、产品需要根据数据分析的结果来迭代、运营需要通过数据来评估活动效果等等,越往后,数据思维、分析能力会逐渐变成横向能力被大家所掌握,人人都会数据分析肯定是未来的趋势。所以我觉得大家在这个窗口期选择数据领域是非常明智的。

建立指标体系是数据分析的第一步。

在我们日常的数据工作中,指标的重要性毋庸置疑,指标来源于业务的场景化呈现,业务也通过指标来透视出问题,但也正因为如此重要,使用如此频繁,所以导致指标也出现各种混乱、难用、难找等等问题。所以我们必须有一套合理合规的指标治理方法,并将这套方法转化成工具,通过固定流程去约束原本不可控的行为。接下来我们就看看,指标治理的有那些方法论?以及这些方法是如何设计成系统,也就是我们说的——数据指标中心。

1、首先定义指标并归集到对应的主题域

指标的本质是量化了的目标,比如常见的例子:

①我们要把用户的盘子做大,那对应的量化指标就是已注册用户数;

②我们要统计今天的销售额,那对应的量化指标就是总支付金额;

③我们要衡量一次活动的效果,那对应的量化指标就是下单率。

从上面的例子我们可以看到,我们比较常用的几个类型的指标就是,存量型指标(已注册用户数)、事务型指标(支付金额)、转化型指标(下单率),其它还有比例型、统计型、排名型等,这些比较不常用,就不在此赘述了。

这些不同类型的指标,分散在我们产品中的不同功能模块中,所以为了更好地规范与管理,我们需要将这些指标也按照主题域的方式归集起来。主题域在“仓库模型中心”进行创建与定义,在这里只需要将对应的指标划归到对应的主题域就行了。

2、然后是拆分原子指标与派生指标

先来看看原子指标跟派生指标这两个概念具体是什么?

①原子指标:是事实表中,某一个字段的统计值(sum、count、max、min、avg),如下单用户数,下单金额等;

②派生指标:是基于原子指标,进行维度组合后产生的指标,如近1天商城下单用户数,本周商城黄金会员下单金额等。

原子指标无业务意义,它只是预定义的代码片段而已。业务中用到的指标基本都是派生指标。

3、接着定义原子指标与派生指标的生产逻辑

在本章的开头有提到这样一句话:“将指标的组成部分解耦拆分开来,并在逻辑表中进行规范性的定义”,这个解耦跟定义的过程,就是把一个派生指标拆解成原子指标、时间周期、限定维度、聚合粒度,然后再重新拼装,生成新的派生指标的过程:

4、最后通过指标管理平台对指标进行规范生产

(1)规范化指标命名

命名规范对于后期大量的指标管理来说非常重要,因为当指标多起来的时候,你要找一个指标经常需要用到检索功能,而检索的前提是你对指标有一些前置的认知。这就需要我们对指标的命名进行规范化。

指标命名规范有三个重点:

①简洁明了,易懂:最好是只要看到指标名,不需要看注释就可以知道它的意思,归属等;

②格式统一:每个指标的格式都是一样的,通过组合不同模块的命名拼凑起来;

③生成统一:原子指标与继承自它的派生指标的规范是一致的。

以商城相关的指标为例:

①所有业务下单跟支付指标,默认以主单为统计口径,不用带“主单”相关字眼,如商城下单次数;当统计口径为“子单”时则需要在命名中标出,如:商城子单下单次数;

②所有与人相关指标默认以“注册用户”为统计实体,不需要带“用户”相关字眼,如访问次数;当统计主体为“游客”时则需要在命名中标出,如:游客访问次数;

③无指定业务范围的指标默认为平台指标,不需要带“平台”相关字眼,如近30天支付人数。如果有限定业务范围,则需要加上业务名称,如:商城-近30天支付人数;

④无指定时间周期的指标默认为“近1天”(但需要保存小时粒度,便于后续下钻),不需要带“时间”相关字眼,如注册人数。如果有限定时间范围,则需要加上时间周期:如:近7天注册人数。

完整的命名的规范为:商城(业务板块)+用户(实体)+近7天(统计周期)+新增(业务动作)+子单(类型)+单日(间隔周期)+平均(统计运算规则)+支付金额(原子指标),如:商城-用户近7天新增子单单日平均支付金额(没有的部位可留空,如:商城-汇总支付金额)。

⑵规范化统计口径

当指标主体为实体(名词):游客、用户、商品等,则只需定义单位为“人/个” 即可。如:游客人数、用户人数、商品个数。

当指标为业务动作(动词):如点击、支付、下单等,单位除定义为“次数” 外,还需考虑跟这个动作关联的实体的单位,如“商品”时需要定义多一个单位“笔数”;为“用户”时则需要定义多一个“人数”等;所以一个下单动作的指标,会有多个不同的统计口径:下单次数,下单人数,下单笔数,下单金额……

在定义指标名时需要详细列出,避免出现“下单数”这样模糊的指标。

⑶规范化指标等级

我们都知道,随着公司的发展,产品在不断地进行迭代,功能的增删与业务的变化势必也影响着指标的发展,一些旧的指标被不断更新或废弃,而新的指标也不断增加。这时对指标的管理也成了一个问题,哪些指标由谁开发?后续谁来维护……

一个比较好的解决方案就是对指标进行等级划分,可以划分为两个等级:

①一级指标:即原子指标与小部分全平台的核心指标,从各业务部门收集需求后,统一由数据中台来产出,有一套完整规范的开发流程:需求-评审-排期-开发-测试-验收-上线。所有维护管理工作都由中台负责;

②二级指标:即派生指标,由各业务部门自定通过指标中心生成,没有严格的开发流程,各业务部门根据需要自行创建,但需要遵守命名规范。所有维护管理工作由部门内部负责。

指标中心建成后,还需要将在整个数据分析过程中各个角色的职责边界理清楚。公司在追求业务商业价值最大化的过程中,会涉及到多个部门间的合作。

具体的合作过程:首先是业务产研团队基于实际需求,上线产品,当业务数据被收集上来以后,会同步到数据仓库,数据开发工程师根据数据产品经理的需求对数据进行加工处理,数据分析师会全面有逻辑的去拆解和分析业务,并同数据产品经理一起合作把分析框架沉淀在数据产品上。数据分析师、数据产品经理和数据开发工程师一起搭建了整个业务的数据体系,然后对外输出:评估业务状态、数据支持运营活动、分析产品迭代效果等等。