我是搬运工--滴滴出行司乘撮合系统

本文探讨了出行APP中司乘撮合策略的演变,从以乘客为中心的派单,到以司机为中心的订单推荐,再到以平台为中心的订单撮合系统。策略随订单密度增加而进化,旨在提高成交率和用户体验。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

出行app

1、几个利益群体:乘客,司机

乘客希望最近的司机接单(等待时间最短)

司机希望挣到更多的订单(接驾最短,距离更长,更不堵车的订单)

 

2、定义每个用户群体的边界值:

乘客:能接受的最长等待时间最长是X分钟

司机:能接受的最远接驾距离是xkm

 

3、找到平衡的公式

第一步,分析双方利益关系

第二部,定义撮合规则

 

双方都是希望促成交易的,矛盾点在每个人都渴望最优质的匹配对象,而优质资源是稀缺的

阶段性目标:成交率最多(更偏乘客利益),每一刻的订单被最大程度消化

撮合方案:乘客做出让步:接单的不一定是最近的司机

          司机作出让步:接到的不一定是周围最大的订单

          单个司乘对的成交率

成交率最大的司乘组合方式:

  1. 穷举多个(司乘对)间所有的排列组合方式
  2. 求得某种组合方式,使得对于所有乘客司机,总成交率达到最大(或者说接近最大)

 

出行app的司乘撮合系统

在不同的阶段目标下,产品是如何进化的

产品目标:实现平台订单的高效分发。乘客打到车,司机挣到钱

衡量指标:广义的成交率为衡量指标

 

案例:版本1.0以乘客为中心

阶段现状:需求较低频和稀疏,w单/天

乘客:叫到车就好

司机:对平台上无依赖,有单便好

解决方案:

  1. 已乘客为中心,由近到远派单
  2. 存在最大播单距离,以保证司机体验

需求分发优先

 

阶段现状:随着订单量增长,开始暴露问题:

司机听到的订单是以订单生成为触发的,订单密度足够高时,多个订单无差别分给司机。

司乘体验都出现了严重的问题。

(P2推给D1时,D1正在听P1,最终是距离更远的D2抢到了P2,甚至P1P2同时推给D1,重叠在一起,一些订单可能被丢弃)

 

阶段现状:需求较密集,10w单/天

乘客:打到车

司机:希望更近更好的订单(市场上存在多个叫车平台)

 

版本2.0以司机为中心

现状和需求发生了变化,系统需要进化

解决方案:

解决方案:A)以司机为中心,当司机需要订单时,由进及远选取周围未成交订单播单

  1. 存在最大播单距离,以保证司乘体验

 ----供给占用优先

 

随着订单增长,开始暴露问题:司机周围订单变得越来越多,紧按距离排序,难以将好订单筛选出来,需要进一步优化排序策略

 

版本2.n 以司机为中心的订单推荐系统

阶段现状:需求继续密集,>10w单/天

解决方案:

  1. 排序系统进化:开始引入订单长度、目的地特征、已被抢概率、取消概率、司机特征等因素,升级为基于ctr预估模型的推荐系统
  2. 以司机为中心,当司机需要订单时,选取周围订单,按ctr预估模型进行排序
  3. 存在最大播单距离,以保证司乘体验

----供给占用优先

 

版本3.0 以平台为中心的订单撮合系统

阶段现状:需求继续密集,>100w单/天

解决方案:

  1. 同时考虑整个区域内的所有乘客司机,以哪种组合方式可以达到所有人的体验最优(成交率最高)
  2. 存在最大播单距离,以保证司乘体验

----群体利益最大化

随着平台规模的进化和供需变化,阶段性目标持续变化,业务导向的策略架构也持续变化

 

小结:

策略框架:是多个功能导向型框架的集合;

寻求各个群体间的共同利益点,作为不同小框架的结合点;

最终的目的是生态繁荣。

 

策略框架:是多个功能导向型框架的集合,

群求多个群体检共同的利益点,作为不同小框架的结合点,最终的目的是生态繁荣。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值