网约车司机工作情况中级分析 | 两维度分类(矩阵法)
本文是“思路比代码重要”系列的第4篇
前言
单维度分类推文的方法总结部分
单维度分类推文的结论汇总部分
单维度分类推文中,我们切分了在线时长和车费收入这两个指标,并将他们分别考量。最后得出该份数据中司机们工作强度和日收入层级的情况。
有没有分析方法是能够将两者联合起来考虑的呢?得出的结论可以增加“之间”二字。比如:在线时长与日收入之间的关系;完成订单数与日收入的关系...
这里肯定有不少读者会说:“简单啊做个相关系数热力图不就行了?”
热力图红圈中几个较高的数字:
- 0.93:说明订单实际总共公里数越高,车费收入就越高,这很正常,毕竟跑得越多挣得越多,合情合理
- 0.81:完成订单数越多,车费收入也越多,和也合乎多劳多得的常理
- 0.71:完成订单数越多,总公里数就越大,合理
那红圈里绿色方框这三个数字该怎么解释???
- 0.42、0.4、0.43:在线时长越长,完成订单数、订单实际总公里数和车费收入这三者竟然没有随之变多??
绿色这几个数字说明在线时间长也不代表司机能够获得收益和接到订单。这与网约车平台的初衷其实并不相符(鼓励司机入驻,在线时长多些,能多接点单,这样顾客的黏性也高些,最后平台和司机都能够赚更多的钱)
这个时候,司机们肯定喜欢直接把原因归因到公司上,毕竟推卸责任什么的最爽了。但我们作为数据分析人员来说,我们还得深入分析到底是平台出现了问题导致这样的现象还是司机自己本身出现了问题,不要过早的盲目归因。(毕竟上一篇单维度分析时我们已经发现有司机存在虚假运力的情况)
| 本文数据代码可以在后台回复「两维分类」获取
深入分析
01
分组对比
既然本文是两维度分类,那我们便先选取两个指标,从他们“之间”的关系发现潜在的问题。这里我们选择了相关系数0.42所在的在线时长和完成订单数这两个指标。
按常理(伏笔),完成订单数、订单实际总公里数、车费收入三者之间的关系如下:
所以这里我们分别将在线时长和完成订单数这两个指标进行分组,而后一起考量,探寻两者之间的关系。
pandas describe 数据集后,我们制定了两者的划分层级和对应标签
将两个类别变量综合起来考量时,建议优先考虑 pandas 的列联表分析(cross table)或数据透视表(pivot table)
02
“异常”司机处理
(每一列的比例和为 1。中间的百分比是指该在线时长内接到的订单数分类下的司机数量所占该在线时长分类下所有司机数的比例,比如56%:在线时长在0-4这个范围内,接到1-5单的司机比例占在线时长0-4的所有司机数的 56%)
粗略看来,平台的政策还比较公平,司机在线越久,接单越多。但值得注意的是,极端数值也出现在这个列联表中。
我们希望平台能鼓励司机入驻,在线时长多些,能多接点单,这样顾客的黏性也高些,最后平台和司机都能够赚更多的钱。但总有不符合我们初衷的情况发生?
- 在线时长 17+ 那一列的 1-5,6-10,11-15 这三个的概率值相加:4+14+16=34%,表明尽管在线时长已经超过 17 小时了,也还是有超过三分之一的师傅们的接单数量很少(可以简单猜想一下,是不是这一类司机他们接的都是长途单)
- 0-4 那一列的 16-20,21-25,26+ 这三个概率值相加,发现也还有 22%,在线时长这么少,却还有超过20%的司机会接到那么多单。(还是先不要着急,会不会有可能这一类司机他们接的都是高峰期特定路段跑短途)
至于为什么会想到长途单和高峰期特定路段跑短途这两个特例类。这个就是具体场景具体业务了,不同行业具体分析就行,这里举例只是为了分析。
- 高峰期特定路段跑短途:比如一线城市的地铁站终点到城郊这段路,车流量少,不塞车就很容易在短时间内接到多个订单,所以这些司机就守着这些地方来回跑。
- 长途单:这个不用多解释了,比如从市区去机场,一个来回就好几个小时了
所以我们需要把这两类找出来,它们是正常的业务形态,剩下的才算是疑似有问题的司机。这里我们先将司机类型划分为4类(自由组合:在线时长两类×订单数分类两类=4类)
- 在线时长多,订单数也多:平台初衷
- 在线时长少,订单数也少:平台初衷,毕竟鼓励多劳多得
- 在线时长多,但订单数少:这是一个问题,司机自身的接单效率低(不懂城市路线和蹲点,总是高峰期堵车的时候接客之类的)?还是平台派单机制不合理?
- 在线时长少,但订单数多:这是一个机会,可能这些司机比较聪明高效,对平台的后续优化也有借鉴价值。
根据上图的两条绿线,这里的在线时长我们以8小时作为分界,订单数分类以15单作为分类。
得出在线时长与订单数组合的四种情况的人数占比后,我们需要剔除红框中的“异常司机”
- 在线时长多,但订单数少:剔除专门跑长途的司机,他们是正常的业务形态。换言之,就是剔除在多订少类型下的里程数多的司机。
- 在线时长少,订单数也少:剔除在少订少下里程数少的司机,他们可能连基本的兼职都不是,而是出工不出力。(兼职的里程数至少还会有那么一点)
那么问题又来了,里程数多还是少,有没有明确的标准?(再次强调:数据加标准才等于结论)
查阅资料显示(笔者在深圳),2019年深圳网约车日均订单约为9.3单,日均行驶里程约为84.0公里,也就是说,一单平均9公里。这样一来,我们将订单数×9,大于它的算里程数多,小于的算少。
03
深入细分
这里我们对在多订少和在少订少这两类再多做“订单实际总公里数”这个维度的切分,并求解每一类型的司机人数占比。
先看大问题,再看小问题(先抓大后抓小),这里都只是一天的数据,对此,我们已经可以提出我们初步的猜想
- 就一天来看,有近14%的司机可能会流失。司机流失了,那我们花了那么多运营费用引进来的用户有可能在长时间的等待司机接单的时候也流失掉了。总之就是,如果这个可能的结果发生了,那一定不是我们希望看到的。
小结
这里总结一下我们上阶段的分析
- 数据观察:4%的司机付出没有回报,10%的司机出工不出力
- 含义解读1:付出没有回报和出工不出力的,都很有可能流失
- 假设1:有司机不会做,跑的路线不对,接不到单
- 假设2:有司机不出力(前几天已经挣了几笔),只是凑个在线时间
- 含义解读2:出工不出力的那些不是真正核心司机(尝试、兼职)运力待补充
- 假设1:这些司机已经挣够钱了,在休息
- 假设2:这些司机就是边缘司机,需要激励or补充新运力,可以探究一下那些效率高的在线时长少但订单多的司机是怎么做的。
我们绘制热力图之后,通过观察相关系数,并结合业务背景,发现了潜在问题,之后用两维度分类的方法将能够反映问题的指标结合起来综合考量,最后得出我们自己的猜想与假设。接下来就是获取更多的数据来验证我们的假设
后续的内容会越来越深入有趣和实用,敬请期待~
相关文章
- java集合介绍_java代码分析框架
- 四大国内外开源的java工作流程引擎,流程快速开发平台对比分析选型[通俗易懂]
- 加油站AI智能视频分析系统
- SpringSecurity默认页面生成分析
- 关于 Safari back 按钮在 iOS 16 不能按照期望工作的问题分析
- 【Android RTMP】RTMP 数据格式 ( FLV 视频格式分析 | 文件头 Header 分析 | 标签 Tag 分析 | 视频标签 Tag 数据分析 )
- 【Java 并发编程】线程池机制 ( 线程池状态分析 | 线程池状态转换 | RUNNING | SHUTDOWN | STOP | TIDYING | TERMINATED )
- 【数字信号处理】相关函数应用 ( 正弦信号 的 自相关函数 分析 二 | 在白噪声中检测正弦信号 )
- Linux基础:分析内核调度器源码之初始化
- Oracle 自动分析:实现数据精确分析(oracle自动分析)
- 深入浅出Redis: 分析其工作原理(redis的工作原理)
- 深入理解Oracle数据库分组和分析(oracle如何分组)
- 探索Linux堆栈信息:分析系统调用信息(linux堆栈信息)
- 精准掌控Redis集群存储算法可靠性分析(redis集群 存储算法)
- Oracle中两个表的视图结构分析(oracle两个表的视图)
- jQuery选择器的工作原理和优化分析
- 基于JavaScript数据类型之Boolean类型分析介绍
- JavaScript分析、压缩工具JavaScriptAnalyser