B端产品的数据指标设计思路-技术圈

点击上方“数据管道”，选择“置顶星标”公众号

干货福利，第一时间送达

关于指标，我们都知道其作用在于将定性的事物转换为可测量的数量，将解题的思路从语文变为数学。

其次，指标能够帮助我们将产出与收益量化，B端产品也是如此。推理的思路遵循B端产品的价值：降本增效，“本”指的成本，“效”指的效率及效果。

本文将基于此分享平台和业务2个角度的指标设计方式，年末也是考核的季节，，希望这篇文章能给大家带来一些帮助。

01 平台指标

平台指标的设计思路，源于目前所负责产品的设计方法，分别是：质量及安全、效率及成本。

理解为：保障质量以及安全的前提下，提升效率、效果，并降低成本。

1-1、质量及安全

质量及安全，二者相互依存、密不可分。前者侧重进攻，后者侧重防守。

质量，用于衡量产品能否使用。安全，则决定产品在使用时的稳定性。

从需求类型看，前者侧重功能性需求，后者则重非功能性需求。对应的流程类型分别是核心流程与异常流。

质量及安全也是衡量产品可用性的重要维度。

可用性指产品正常使用的概率或时间占有率，其衡量指标是系统可用时长以及不可用时导致的经济损失。

系统可用时长的计算公式是系统正常的使用时间和总时长之比。基于此公式，我们的目标是避免系统不可用或减少异常时长。

从可用时长向下拆解过程指标，分别是发现率、发现时长以及影响时长。

发现率，用于衡量监控的覆盖度；发现时长，用于衡量监控的敏捷性；影响时长，则用于衡量问题响应及解决的时效。

保障了质量与安全，才有资格谈论效率与成本。

1-2、效率及成本

质量与安全，保障我们拿到及格分，效率与成本才是加分项。

B端产品源于高频的需求被固化为功能或者产品，目的是提升需求实现效率，其次是降低人力成本。

如果提升的效率无用或降低的人力成本无法覆盖实现成本，这样的产品还是不要做了。

1-2-1、效率

B端产品的提效绝不仅是面向业务，还会面向平台的运营、研发以及测试。

只有支持团队的效率提升，才能投入到提升“质量及安全”以及“效果”的相关工作之中。

所以拆解的角色会同时包含支持方与业务方，并以此向下推理。

工作效率的衡量指标是完成每件工作的时间成本，分解的方式从支持方出发可以使用需求流程，从业务方出发可以使用操作流程。

当然还有咨询、审批、反馈等流程也同样适用此种拆解方式。

不妨遵循这个思路回答，我们所提升的效率包含了哪些环节？

1-2-2、成本

1）人力成本

世界和钱有关，所有的结果指标都应与金钱挂钩，才能便于我们计算投资回报率。

上一小节所说的时间成本，也应将其转换为人力成本，再与研发成本比对计算收益。

2）非人力成本

非人力成本即人力以外的其他成本，包含设备成本、服务成本等。

这两点都比较通俗易懂，简单举2个例子。如：优化了算法，运算资源的减少，费用也随之减少；减少了短信的字数，短信的成本减少了。

在这里需关注的是，降本提效不要拘泥于产品。解决问题的方法有很多，包括预算控制、成本考核、业务规划等都是非常好的办法。

02 业务指标

假设所负责产品真切地在解决有价值的问题，那么“质量与安全”是及格分，“效率与成本”能让我们加分拿到良，但业务指标做的好才能够拿到优。

产品之所以存在，是因为用户希望借助它做某件事，而企业会因为这件事获得某些收益，只不过在B端产品，用户变成企业内部的成员。

衡量收益的数字，更倾向于业务指标。

ROI的计算公式，相比传统的计算方法额外多了一个参数：“负向指标经济价值”。

道理也很简单，每发一篇公众号文章，有人关注也会有人取关，有正向也当然会有负向。

但这并不是说不需要继续运营了，而是要让分子大于0，并且尽可能的靠近、超出分母。

以上图的第二个例子进行解读，假设是某东Plus会员年卡，临近过期用户仍未进行续费，这时平台运营会将这部分用户推送至外呼专席，由外呼同学引导用户进行续费。

过程指标体现了结果指标的完成方式，要提升结果指标的经济价值，要么减少完成过程的损耗，要么提升完成结果的单价。

而负向指标，即这种运营行为可能导致的损失，主要分为绝对损失和概率损失。

绝对的损失是费用，如短信、电话外呼等。概率损失则与行为息息相关，如第一个例子中的取消关注。

负向指标同样需要换算为经济价值，如：1个公众号粉丝的费用，1个小程序UV的费用。

将指标拆解、定价完毕，工作就完成了一大半，指标的拆解方法和后续的产品设计方在此前的文章也有过许多的解读，在此也就不再赘述了。

03 指标的阶段性

做B端，其实挺难的。很多事情做好了是本份，做差了就会不及格。

为了避免只能体现苦劳，无论是什么样类型的B端产品都面临一个问题：怎么体现价值？更往前一步，不同阶段应该体现什么样价值？

前面2节阐述了不同角度的指标拆解方式，本节想和大家分享不同阶段关于指标的思考。

今年经历了1个B端产品0到1到100的过程，也简单将其抽象为了4个阶段，分别是“服务、规范、优化、扩展”。

1）服务

如前文所述，B端产品源于高频的需求被固化成为功能或者产品。

这也意味着有许多的逻辑此前是在不同的部门在不同的时间段以不同的方式实现的，而要体现产品能用，最底线目标是能够向前兼容。

这也是命题为服务的原因，要做牛做马的和业务、产品、研发甚至是测试了解旧有逻辑。

而产品的试运行阶段，迁移亦或者新上线看到的满满都是风险，很难看到收益。

你会发现自己以前的规划没有那么的美好，再顶层的设计也应变不了千变万化的业务，那个时候我更多想的是能用就足够了。

2）规范

服务的目的是为了规范。通过服务，我们了解了业务，完成了社交，打通了链路。

最终完成了规范的前提，保证产品最核心的这件事有了统一的出口，才能够控制变量，才能够进行比较。

这个阶段更多的是在填上一个阶段的坑，把以前轻视、非阶段性重点的目标捡起来优化。

优化完毕后，才能算得上所有人都在做相同的事情，才能基于功能以及运营的标准化，做到可溯、可管理、可复用、可优化。

规范，也意味着站稳了脚跟，才能去谈安全和效率。

3）优化

经历了服务及规范阶段，意味着苦劳的分拿到了。但这个阶段过后，如果我们仍以此作为自身的价值体现，那意味着你要被淘汰了。

优化阶段，是输出影响力的阶段。

统一实现规范，能够优化平台指标。统一运营规范，能够了解不同业务的运营情况，从而进行旧运营模式的优化以及新运营模式的开展。

所以指标聚焦在成本及效果。

4）扩展

扩展源于，碗里的奶酪总会吃完的，优化也是有上限的。再往前走，应该覆盖新的领域。

一方面是拥有了上一个项目的技术、产品、人脉储备，另一方面影响力的输出也让你再次推行新事物时阻力会更少。

覆盖的方向，目前是基于自身对产品上下游进行拓展。

至于说指标是什么？也许和前三步一样，也许会有新的想法。等我走完了这个阶段，再看看有什么变化吧。

写在最后

产品其实很像一个圈，圈的尽头又是旧的起点。现在回想这么多的重构，有多少是真的因为必要性呢？又有多少项目能真的产生价值？

写到这里其实还有些伤感，产品和产品经理相互依存的日子能有多长呢？这又是不是“再生一个”的原因？这么看来计划生育似乎和产品规划也没有啥区别了。

·················END·················

B端产品的数据指标设计思路

推荐阅读