许多工作环节都离不开数据指标、或者指标体系的支撑，那么在B端业务场景下，指标体系的建设应该遵循什么样的搭建策略？又有哪些细节方面需要额外注意？本篇文章里，作者结合自身经验，总结了他在B端业务场景做指标体系的建设过程，一起来看。

前言

我是西索，距离2011年6月22日，到现在是真正意义上做了十年数据分析，十年前没有种好树，十年后我想重新开始积累。工作之后的前两年是面向于C端的零售行业，余下的八年都沉浸在B端领域里面，研究数据增值、变现的场景。“The best time to plant a tree was 10 years ago. The second best time is now.”

21年7月份的时候写了一篇文章《感悟篇：我在B端做数据分析（一）》，对B端和C端在业务上的差异性进行了对比，将数据在B端业务下的应用场景做了概括性的总结。

时隔两年，续着第一篇接着往下写，说一说B端业务下的指标体系的建设过程。

在第一篇文章里面有提到过几个管理层关注的核心指标。

在指标建设过程中的合理性、复杂度、落地性都饱受争议，以至于很多分析面试的第一关便是如何建设基于某某场景的核心指标，如何去做指标的定义与监测，如何对核心指标进行跟踪…为什么我们一直在说指标建设，但是却又一直做不好？指标建设，绝对不是说做一套产品就可以了，产品只是指标应用的一个承载体而已。

前几天去省厅开会，有一句话特别有感触。

对做数据统计的岗位来说，如果没有系统化的指标来支撑，就会很痛苦，可能每天都会在找数据和凑数据的过程上，就显得比较低效。所以才会去推数字化转型建设，从源头就把信息内容变成数字化，减少人为干预的环节，实现全链路的数据可视化。

一、战略目标和管理必要性

做企业，最大的目标是为了盈利，非营利性的组织与团体，不在分析的范畴内。无论是平台型B类、SaaS服务型B类、实业型B类，从全生命周期的角度来说，都离不开「营收」、「品牌影响」、「行业知名度」。

1. 自上到下的考核机制，离不开指标建设

指标，是伴随考核而产生的，中央考核部委、部位考核省厅、省厅考核市局、市局考核县区、区县考核到单位，这就是一个完整的考核链路。

对公司而言，也是一样，董事会考核公司管理层、管理层考核事业部、事业部考核到子级业务线。促进数据指标建设的必然性，一定离不开企业在做数据化转型、数据管理、数据驱动中的主要痛点，尤其是在经济下行的市场环境下，营收目标的增长实现，就需要一套指标拆解的方式进行动态跟进。

参考《抖音集团数据指标体系分析与增长实践 》一文中的案例，任何一门生意都能用简单的数学模型来描述，实现运营公式的拆解。

2. 指标解决的几个实质性问题

指标的建设，不是空穴来风，做做样子，而是解决实打实的业务痛点，在企业运转过程中，几个最典型的问题在于：

3. 构建指标的几种业务思考

了解战略目标 – 熟悉业务特性 – 提炼场景指标 – 核心指标开发 – 跟踪监控预警。

二、B端指标建设的特性

在第一篇文章中从用户、业务、产品、行为、数据五个方面对B/C端进行了多维对比，在定义和设计指标的时候，需要充分认知到企业所在行业、市场上的差异性。

提到B端就离不开数字化采购，根据艾瑞发布的采购行业研究报告，可以把B端的数字化拆分为两个时代：ERP时代、SRM时代。

1. 简单的B端业务

为什么说B端很简单，大多数的理解起来，B端的用户体量比较少，所以数据就会少。

在中国，C端的用户体量大约在7～9亿左右额。

而B端的用户体量，根据工商统计大约有4、5000万家注册企业数，划分到细分垂直领域，每个行业下的体量更少了。

具体可以体现在以下4点：

2. 复杂的B端场景

但实际上，B端也不少，主要看业务体量，是属于订单性质，还是看大合同类的服务履约性质。

从供需的关系上来拆解，可以把采买过程拆分为四个环节：需求确认 – 供应商筛选 – 执行与追踪 – 交付验收。

决策链路复杂：

涉及的业务链路复：

大数定律在B端有用，但是没那么有用：

三、指标建设方式及内容设计

1. 指标建设方式

从上至下的指标体系建设需要跟随企业战略目标的变更而进行变更，从而需要进行大量的指标变更。

从下至上的指标体系应关注在每个业务域内的经营活动而形成指标。要注意的是，各个业务域内可能存在交叉环节，相对应的指标在内部以及部门合作之间需明确指标口径。

1）自上而下

基于BI本身的职责和公司/团队对BI的要求，设计BI建设体系并分别推进落地， 跨团队的项目模式进行；

2）自下而上

整体而言，公司的目标会贯彻到各个子业务线的中短期规划里面，从组织架构设计上来看，指标建设的过程也应该是从上到下的管理过程。

实现方式：从业务需求出发，提炼需求过程中涉及到的数据内容项，形成业务核心指标；

基于BI团队现有的职责和任务， 专注于用户侧需求的满足，涉及标准化建设的需求，建立推进机制，BI团队作为需求和问题的发起者和结果的验收者存在。

2. 主题域划分

实现方：

基于十大主题进行归类，可以构建原子粒度的DWD(数据明细层)和DWS(数据汇总层)，也可以用于方便集市内部表单管理。

3. 不同行业下的数据指标内容

B端企业有着非常强的行业特性，在不同的行业背景下，呈现出来的内容有着非常强的差异程度，根据日常关注的公众号、数据服务机构、白皮书，收集整理了以下一些行业的数据指标，不一定对，可供参考。

1）B端 – 电商

B2B/B2G，衔接厂商与经销商、政府与服务商、渠道代理与分销商之间的平台公司，从流量 – 曝光 – 获客 – 访问 – 选购 – 下单 – 支付 – 仓储物流 – 最后1公里配送的交易流程，对埋点强依赖，行业特性比较强。

核心指标：GMV、转化率、ROI、复购率。

2）B端 – SaaS

SaaS软件即服务，需求和服务的行业差异性特别大。包括信息软件服务、人力资源服务、财务会计服务、企业管理咨询服务、IT技术支持服务、法律咨询服务等。

核心指标：复购率。

3）B端 – PaaS

PaaS平台即服务，通常是指针对企业或组织等而设计和开发的互联网软件工具，旨在帮助企业提高工作效率、降低成本和提升业务管理水平等。

4）B端 – 零售

零售行业，通过快速建立品牌形象，以销售目标为导向，满足顾客的需求的同时确保获得最大的利润。

核心指标：GMV、连带率、客单价。

5）B端 – 汽车

利用互联网和移动互联网技术，为汽车行业提供线上和线下一体化的服务，包括汽车销售、维修、保养、租赁、二手车交易等领域，通过平台查询汽车信息、预约试驾、在线下单、申请金融服务等，为消费者提供更精准、更定制化的服务和产品。

主要包括：汽车生产厂商、经销商、维修保养机构、租车公司、物流运输企业等。

可按照细分场景做更细粒度的拆解。

6）B端 – 房地产

注重商业性和专业性，针对的是大型企业和机构的需求和目标，涉及的产品和服务范围更广，其特点是项目规模大、服务内容全面、专业性强、服务要求高。

7）B端 – 金融

金融行业，快速响应企业、家庭、个人的灵活用钱需求，解决资金短缺问题，同时也为机构带来稳定的收益来源，通过保险合同的签订，将某些风险的损失分散到众多保险客户之间。

主要包括：保险、保函、贷款、信用卡、消费分期、互联网金融、小额贷款等。

8）B端 – 医疗

通过互联网技术和平台，为医疗机构、医生、药企等B端用户提供一系列在线医疗服务的商业模式。

包括：在线问诊、远程医疗、病例管理、医疗影像处理、健康档案管理等。

9）B端 – 文娱类

平台为企业、机构和个人，提供短视频、课程、文案等内容创作、制作、发行的服务。

核心指标：LTV。

4. 数仓下的指标建设过程

1）数据指标的生成

原子指标：不可分割指标。实际业务中，原子指标很复杂，不同时间节点的原子指标不一样，行业规范不一样。原子指标含有高度行业属性。

派生指标：从原子指标发展，增加维度和定语去而形成的。可以在业务情况下，退化为原子指标。

ps：原子指标与派生指标的定义相对模糊，需要在特定业务场景下能清晰定义为原子或是派生。

指标口径：等同逻辑（条件、范围、维度、度量方法）。

例如SQL查询语句：

维度和事实：维度是可枚举性的值，且是有限值，可归集。事实是不可更改和调整的。复合指标：通过几个派生指标经过运算形成。

例如：将浙江省内2021年度交易次数>5次的供应商计数的运算。

2）数据指标的维护

谁在什么时候应该做规则更新？

• 生成：将条件、范围、维度、度量，事实明确而形成，例如SQL查询。
• 定义：通用规则，通过逻辑去诊断指标定义。包含指标名称与指标口径。外部用户叫法及内部系统名称，对于不同用户受众，需要不同叫法。
• 命名规范：需要注意针对对象进行命名，例如针对管理层GMV，对业务方销售额。中文和英文设置根据数据库表内的字段名生成。
• 应用：针对不同受众，所理解的指标别名不同。例如：GMV在有任务场景下被定义为月销售额输出。
• 迭代维护：当业务，系统等情况发生变化时，需要对指标定义进行重新定义、修改。

3）数据指标的销毁

生命周期的末端。

销毁：销毁指标同样是一种选择，但通常不常用。销毁复合指标的场景是：当复合指标不符合当期经营所需情况且不产生价值时。

四、指标应用——监控与预警

指标应用的几个方面，产品、业务、报表，以下为网图，真实环境下的数据不便于透出，如有需要探讨可联系。

1. 可视化大屏

2. BI数据产品

3. 用户标签与画像

4. 预警系统

五、写在最后

回过头看这些年的经历，感慨万千，在过去这十年的工作经验里面，一直都是在数据分析这个title上。很想把这些年积累的一些知识内容以文字的形式记录下来，对于一个纯理科生来说，这无疑是一种挑战。

后面应该会拆成很多个部分，缝缝补补，陆陆续续的完善。