网约车数据产品实战一：设计数据体系
一、如何着手
初接到任务的时候，没有0-1数据产品经验的我还是很无从下手的。但静下心来仔细思考数据产品的本质，无外乎两件事情：提取指标、辅助决策。
高效、精准地提取出业务指标是数据产品的根基，因为巧妇难为无米之炊。而辅助决策则需要依赖一些可视化工具，市面上有很多：Tableau、PowerBi、FineBi等等，我们最终选择微软提供的PowerBi为我们提供指标可视化能力，接下来的难点便在于提取数据指标了。
二、从目标开始
数据体系作为指标体系的前置条件，其架构的稳定性和延展性决定了输出的指标数据能否满足业务方的各类应用场景，能否适应业务的横向拓展。以下罗列几点数据体系的设计目标：
- 「时效性」需获取高时效性的今日数据，用于生成实时指标，应用于看板、仪表盘等；
- 「不可变」历史数据（指今日之前的）产生的指标一经生成，不可更改。（由于实际业务场景中可能存在系统脏数据、接口超时等，造成业务原始数据变动。如在不同时间生成同一项指标，可能出现指标数据不吻合，带来财务核算的错误风险）
- 「灵活性」高速发展的业务形态会带来各种各样的统计指标，为此数据体系必须拥有较强的灵活性，将指标提取和指标数据读取进行解耦，避免牵一发而动全身。
三、确定整体架构
整体架构如下图所示（重点关注指标提取层）：
指标分为两大板块：
1. 实时指标
定义：今日实时产生的指标数据，如今日发单量、今日完单量、今日出车司机数等等。指标要求最少5秒一次刷新。
用途：制作实时数据仪表盘、战术大盘等。
方法：SQL语句提取指标，各个指标数据组装为json格式，每隔2-3秒post到PowerBi的流式数据集api。
2. 汇总指标
定义：包含今日和历史的业务指标，如昨日注册司机数、昨日活跃司机数、今日出车司机数等等。「汇总指标」包含了「今日指标」。
用途：制作多维度指标图表，如折线图、饼状图、组合图、核心指标表等。
方法：
- 今日的业务指标通过python中的pymysql模块进行读库和组装指标数据。一些简易指标可以直接通过SQL语句获取（同步上文中的实时指标）
- 历史的业务指标为每日凌晨2点，通过python脚本抓取前一日指标数据，存储到「周期性汇总指标表」，每条指标一行数据（如颗粒度为半小时的完单数指标，最终落在指标表中为48条数据）。后续通过SQL语句即可通过指标表读取到指标数据。
汇总指标中的历史业务指标是整个数据体系中最关键的部分，所有业务数据最终都会形成指标落到「周期性汇总指标表」
四、总结与探讨
几点经验
1、合理利用异步思想：本次历史业务指标的设计思路即为异步思想，将“指标提取”和“指标数据读取”进行解耦并异步处理；
2、领域间保持一致性维度：各领域的业务数据（如财务、资产、运营、客服等），虽数据源不同，但大多数可以通过相同的维度进行打通关联。如时间、城市等。
网约车数据产品实战二：搭建交易指标体系
一、何为指标
数据指标是量化运营策略、财务状况、商业价值等等方方面面的工具。其可抽象分为两大板块：量度和维度。
- 量度：指指标的数值，如发单数为「300单」，出车人数为「40人」，TPH为「1.5单/小时」；
- 维度：指获取量度的角度，如「城市」、「订单类型」、「业务线」、「日期」、「时间」等。
指标可大致分为以下三类：
- 「基础指标」：指不可再次拆分的原始统计量度，如发单数、完单数、出车司机数等。
- 「复核指标」：指通过多个基础指标通过运算规则得到的新指标，如应答率、完单率等。
- 「派生指标」：指基础指标/复核指标之上添加维度进行限定后得到的指标，如“杭州市8月1日发单率”。
二、如何量化业务
网约车行业从最初的快的滴滴烧钱争霸，到后来的一枝独秀，再到现在的多足鼎立。不难看出这个行业已经从一家公司贯通整个链路，逐渐发展到拆分为各个垂直领域去各分蛋糕。本文将基于“流量聚合模式”描述如何通过指标来充分量化「运力平台」的交易领域业务能力。
运力平台指：挂在流量平台(如滴滴、高德、百度等)的网约车平台，为其提供运力、调度、风控等一系列能力。
交易
网约车交易板块承担的kpi，大多通过GMV这个大目标来拆解，而在聚合模式之下可以通过流量转化的角度来拆解，如下图：
（1）询价数
定义：即为乘客冒泡数，以滴滴为例，「同时呼叫」table页的每一个PV可视为一次询价（忽略接口超时的偶发场景）。
（#询价与发单之间实际还有一层漏斗，即“勾选数”，但作为运力平台大多无法拿到这一数据故而跳过#）
（2）发单数
定义：即乘客勾选了我方平台，并确认下单的数量，用户或为单选或为多选。
（3）举手数
定义：即运力平台调度到可派单司机后，将司机信息推送到流量方平台的数量。
（4）应答数
定义：即流量方平台在获得一个或多个运力平台举手后，进行决策(此处为黑盒逻辑，运力平台大多无法拿到)，决策订单指派给我方司机的订单数量。
（5）完单数
定义：订单在指派给我方司机后，订单完成接驾、送驾、发送账单等一系列业务流程的数量。通常我们将“行程完成”视为完单数+1.
以上为漏斗中核心指标的诠释，那它们分别能够量化交易领域的哪几项能力呢？
（1）发单率= 发单数/ 询价数：
此指标与计价策略直接挂钩，较低的定价会带来发单率的提升，同时外界的因素（天气等）会干扰到乘客的价格敏感度。
（2）举手率= 举手数/ 发单数：
此指标与运力密度和供需比正相关，司机越多乘客越少，则举手率越高。同时播单半径也会对此产生直接的影响。举手率在指导供需调度方面有极强的参考价值。
（3）应答率=应答数/举手数：
正如上文中所说，流量平台在进行内部决策时的复杂逻辑对于运力平台而言，大多数都是完全黑盒，此时很难去对这一指标进行分析，但大致可以分为三大方面。
- ETA：接驾距离越长意味着乘客体验越差，取消率越高。较低的ETA会获得流量平台更多的倾斜；
- 举手速度：这一维度是各大流量平台对外的一致说辞，虽说有些牵强但也不无道理；
- 司机历史行为：运力平台在接入流量平台时，需将各类司机数据、订单数据、客诉数据等等同步至流量平台，其对于各平台司机必会生成一套或简单或复杂的用户画像，历史行为不端的司机将不受到决策倾斜。
（4）完单率=完单数/应答数：
此指标关联到几个场景：接驾途中由于距离过远导致的乘客/司机取消，司机多平台接单时挑单而取消。究其本质实际上反映了一个关键要素「司乘体验」。
较高的完单率意味着较好的司乘体验，反之则说明体验较差。
（#此处为了便于理解漏斗而将这一指标并入交易板块，实际上在运用过程中，我们更多地将「体验」独立出来，其层级与「交易」相同。）
三、确定指标结构
通过上文中的描述，大致可以量化出聚合模式下网约车业务的交易链路，下表结合维度进行梳理：
在实际业务开展中，我们围绕着“效率”、“供需”这几项关键目标，还会拆分出更多的交易指标。
四、总结与探讨
1. 几点经验
- 为一个新生的业态（例如聚合模式下的网约车业务）搭建指标体系，可以抓住一个对象（例如一次呼叫订单）通过梳理主体业务闭环，拆分出每一个层级/节点的流失和转化；
- 搭建指标体系切记「统一统计口径」。例如“统一口径为下单时间”。那么当我需要获取7月1日各项指标时，统计的原始数据必须全部为7月1日下单的所有订单。
2. 探讨几个问题
聚合模式下运力平台需要对接各种各样的流量平台（滴滴、高德、百度等等），各家的业务模式或多或少会有区别（有些采取黑盒决策派单模式，有些采取先到先得模式）。如何优化交易指标体系使得抽象程度更高，以不变而应万变？