O2O行业数据平台实战：从监控到诊断的数据产品搭建

人人都是产品经理 • 3年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

10月的第一场会员直播，我们邀请到了前滴滴高级数据产品@高远老师，她将基于多年的数据产品经验，深度解析O2O行业场景及痛点，从监控——分析——诊断三个层次拆解数据产品的构建思路。本文为直播内容整理，内容有删改。

大家好，我叫高远，之前就职于出行行业的一家头部公司，担任高级数据产品。近5年专注于出行行业、内容行业、工业方向的数据产品领域，掌握上述领域的体系化搭建方法，创新性地打造出数据产品独有方法论，深度参与主流数据平台（滴滴网约车和字节内容方向）上述系统的规划和设计；并对应用型数据产品有着深刻认知，在企业内部研发数据驱动、数据增长相关课程，累计学员超过1w人。

O2O行业数据平台实战：从监控到诊断的数据产品搭建

本次分享主要包括两大部分： 第一部分 先给大家解析一下O2O行业业务管理的一些相关痛点； 第二部分 是关于数据产品整体落地的实践，从level 1的数据监控，到level2的数据分析，再到到level3的数据诊断。

一、O2O行业业务管理痛点解析

O2O行业数据平台实战：从监控到诊断的数据产品搭建

先进入到第一个部分——O2O行业业务管理痛点解析。

作为业务型的数据产品，我用十四个字概括其核心要务就是： 比业务更懂业务，让产品更加落地。

那大家就要考虑应该如何深入到业务中去，如何让产品更好地落地。其实做数据产品也罢，做产品经理也罢，各种产品类型都万变不离其宗，也就是要聚焦用户。所以我们要很清楚我们的用户到底是谁？我们服务于谁？

就上述问题我做了一个总结。大家可以看一下这个表格，我们服务于业务方，无非是面对两类人群，第一类是区域负责人和部门leader等管理人员，第二类是运营、策略、市场等业务人员。

首先来看一下管理人员最关注什么。管理人员需要第一时间产出相关数据，因为他需要通过这些数据去及时发现问题，并及时进行业务调整，所以数据监控对管理人员而言是非常重要的。另外，管理人员也想知道问题大概出在哪个环节。还有就是他们要做一些降本增效工作，所以需要知道如何去发挥人力最大的价值。

这些其实就是关于管理者的一些场景。那我们从需求层面来去抽象这些场景的话，可以概括为三点：

第一，需要多种时间粒度去监控业务的发展情况，更好地去发现业务问题。
第二，需要快速知道关键指标异动背后的原因，及时进行策略方向的调整。
第三，也是管理人员的终极目标，即如何通过一套科学的产品去提高人效和钱效。比如说以前可能需要五个人负责一个城市，现在可能通过数据的助力一个人就可以负责五个城市。

针对管理人员的这些需求，我们的解决方案里包含了L1阶段的数据监控，和L3阶段的数据诊断。这部分后续再给大家详细讲解。

接下来就是关于业务人员。业务人员经常会面临的场景可以总结为四类。

第一，每次进行业务分析都耗时耗力，尤其是对于一些分析理论掌握得不够扎实的业务人员而言，他们的方法通常比较粗犷，没有办法很好地进行精细化运营。
第二，在O2O行业最重要的是供需，而长期供需是通过定价手段去调控的，那如何去证明这一次的调价策略是正确的，对城市是有益的，这需要业务去衡量。
第三，对于业务而言，如何分析和量化单点的、外部的、特殊的事件对整体业务的影响也是经常需要面对的工作，单点事件包括一些极端天气、节假日等。
第四，对于常见的业务问题怎样可以一站式解决，提升人效和钱效。

同样地，根据这几个场景，对应可以提炼出业务人员的主要需求：

一是 B&C端需要一套可行可落地的方法进行精心化运营。二是通过数据产品更好地去评估定价。三是将单点事件对业务的影响量化出来。四是追求一个更高的水平，就是把数据产品做得更加智能化，能够一站式解决常见的业务问题，不再需要一个一个环节去定位。

在解决方案上，业务人员最关注的是数据分析，也就是L2的产品；其次是L3数据诊断方面的产品；最后也还会关注L1数据监控，但毕竟是业务人员，他们更关注的还是如何解决问题，所以数据监控只是作为辅助。

那刚刚我们说到的L1、L2、L3对应的数据监控、数据分析、数据诊断，这些究竟是怎样的概念？在整体的产品框架中起到怎样的作用？

大家可以看一下这个图。我们所有的产品都是在一些基础平台的模式上去建设的，具体可以分为对内和对外两大部分。

这次就重点给大家分析数据产品的对内建设，即红色虚线框内的内容。

首先是关于L1数据监控方面是如何去落地到产品的；其次是分析层面的L2阶段，比如核心分析、定价分析及事件分析如何落地这些产品、推动业务的；那 最高级别 ，也就是L3诊断层的话，主要是关于如何通过指标的诊断一站式解决问题。

接下来我将会把之前实际落地操作过的一些产品拆解到每个小点里给大家做详细讲述。此外，由于我之前做的是O2O的出行行业，所以会以出行行业为例给大家分享如何落地这三个方向的产品。

二、数据产品的落地实践：监控——分析——诊断

接下来进入到第二个环节，也是本次课程的核心部分——数据产品的落地实践：从监控到分析到诊断。

数据产品有三个层级。

第一层L1叫数据监控 ，它可能是最基础的一层，就是必须具备的。如果用一个词去解释的话就是需要去 “看数” ，从繁杂的数据中提炼出最核心的指标进行监控。

在这个基础之上晋升一个层级到 L2的数据分析 ，这个阶段要能够“ 用数” ，专项问题专门解决，用统一的方法去解决专项问题，到这一步开始有一些思路和一些方向引导，去定位具体的问题。

第三层相对而言就比较难了，它是建立在L1和L2上的 数据诊断 产品，总结来说可以称之为 “智数” ，也就是从发现问题到分析问题再到一站式解决问题，通过人机结合的方式帮助运营完成这个过程。

接下来我们就分别讲解这三个层级该怎么搭建。

1. 如何提取核心数据指标体系，高效把控业务表现

首先是数据监控这个环节。这个环节分四步走， 第一步 要去了解清楚盈利模式， 第二步 要根据盈利模式建构业务模型， 第三步 是在业务模型的基础之上抽象出一些指标分类，那由指标分类以及现在业务的一些痛点诉求最终就可以进入 第四步 ——监控产品的搭建。

在盈利模式这块，抛开O2O这个行业来说，所有市面上的行业都可以用这一套理论去解决它的盈利模式。

这个模式分为两个维度，维度一：是否省时间，维度二：是否直接提供价值。进而分为四个象限，其实每一种业务都可以映射到这个模式里。

比如 第一象限的省时间且直接提供价值就可以对应工具类业务， 像拍照工具、支付工具等，这些都是可以以免费模式去提供给用户的，当然可能会有一些增值服务去收取额外的一些费用，这部分其实就是这类业务的盈利模式。

然后 第二象限对应的就是内容类业务， 再细分的话可以分为两种，第一种是自研模式，比如以售卖课程为主的业务；还有一种是流量模式，像短视频领域。

那 第三个象限的话是一些社交类业务， 比如聊天软件等，这走的也是流量模式。

最后一个象限对应的是我们今天要重点讲解的交易类业务。 就比如O2O行业，走的是佣金模式，因为O2O是融合线上线下的一个模型，这个模型本质是为了撮合B、C两端的交易，我们就通过撮合这样的交易从中获取佣金，这就是O2O行业的盈利方式。

关于O2O行业使用的佣金模式，它的利润公式是这样的：利润=单笔应收金额*（1-分账比例）*单量

举个简单的例子，比如在出行行业，用户今天上班打了一次车，然后我们收了一百块钱，那这一百块钱就是对应公式里的“单笔应收金额”；“分账比例”则是给司机的那一部分，剩下的就是给我们平台中心；“单量”其实就是数量。

在实际过程中，除了分账比例外有时候还需要扣除一些额外费用，比如补贴率，因为有些地方可能缺需求，那我们可能就会通过一些活动去补贴乘客；以及可能还有一些管理费用，所以要把所有成本都减掉。

出行行业的利润是通过促成B&C端的交易来获取的，那么根据刚刚的利润公式，要达到利润最大化，无非就是提高单笔预售金额，降低分账比例，提升单量。

当然，对于B端和C端又有不同的处理方式。假设我们平台想通过提升单量来实现利润最大化，需要思考的是如何帮助业务去刺激更多需求，也就是让更多人去打车；而对于司机端，只有降低分账比例才能提高我方利润。这样就会导致平台和司机的利润矛盾，所以你 需要去寻求平衡点——一个让平台和司机都相对满意的最优值， 比如看看能不能让司机获得一些额外收入。

在刚刚的基础上再做一些拆解，把相关指标分类提取出来，从而得到一张业务流程图。

平台的目标是提高利润，那我们就通过流程拆解分析当前进度、差距以及挖掘增长洼地。

对于O2O平台而言，万变不离其宗，最重要的就是供需，关键就是去提升总量、调整结构。乘客端和司机端就像是翘翘板的两端，需要平台去平衡。 无论是是刺激乘客还是激励司机，都需要通过一定的策略去实现，比如采取补贴活动。但是活动的效果有时候可能并不好，说我们补贴的一些活动，进而评估活动效果和ROI。

在这个基础上继续拆解得到这张图，实际上就是将刚才的利润公式进一步细化，并且分别对应B端和C端。

像应收金额=C端的需求订单量*（B端的需求应答率*订单完成率），因为一份订单并不是直接就能达到完单的效果，还要看转化率。

按照这样把利润公式里的指标进行一层一层细拆下来的话，可以分为六类指标。

第一类是财务指标， 比如利润、补贴等； 第二类是C端相关指标， 在O2O行业的话就是乘客相关指标，比如需求订单量、C端补贴等； 第三类是B端相关指标， 包括需求应答率、订单完成率、司机在线时长、B端补贴等。这三类属于 纵向指标。

横向指标 分类也包括三大类， 第一类是订单相关指标， 比如订单的转化如何，是否存在漏洞，整体完成效果怎么样； 第二类是体验相关指标， 比如司机的差评率，或者司机是否有投诉乘客等，虽然体验这块占比会比较小，但对于平台的伤害却是比较大的，比如用户打车觉得坐车环境比较差、有气味儿之类的，可能下次就不会选这个司机了； 第三类是策略相关指标， 比如做活动花了多少钱等。

指标分类梳理清楚了之后就到了数据监控产品的落地环节。

有人就会说，做监控可以用excel 报表或者一些通用看板，为什么要定制化看板，这样不是更加耗时耗力吗？

根据我之前的经验，每一种方式都各有利弊。 首先是Excel报表的方式， 这种方式的优势就是数据获取灵活，自由度高，上手比较容易。但是缺点也多，比如自写sql难度会比较高，因为写sql的链路非常长；还有就是数据口径难以保证、可视化效果差等，所以这种方式其实不适用于长周期数据，比如在出行行业，当你拿到某条业务线全年的数据，这个Excel 报表可能得有几百兆，根本打不开。

其次是通用报表， 很多企业会购买市面上一些比较成熟的报表比如Tableau、FineBI，这些通用报表其实也非常强大，数据非常全面，使用也比较简单，都根据行业上一些标准方案去做的。同样地，这种方式也存在一定的缺点，比如对于业务而言功能相对单一，查询性能也比较有限，还无法添加个性化功能。就比如说我想快速看一下日均数据、周均数据，或者需要可视化表达比较好的方式去展现同环比等，这类个性化功能比较难以实现，所以无法灵活地进行业务扩展。

因此，定制化开发的数据监控产品就应运而生了。 那它的优点还是比较多的，首先是数据全面；其次是功能强大、贴近业务，因为一切都是定制化的，你可以根据现在的业务特点去增加一些数据功能；另外，这种方式还可以支持多种时间粒度，就比如日均、周均、月均这些数据，各种丰富维度都可以实现；最后可视化效果也比较好，最重要的是数据产出非常稳定。但唯一一个缺点就是需要进行定制开发。