文章目录

前言
一、外卖订单的生命周期？
二、订单的配送过程
1.骑手侧
2.商家侧
3. 环境侧
4. 平台侧
三、时间预估
四、其他因素
四、总结
五、参考文献

前言

一、外卖订单的生命周期？

我们首先来看下，一个订单从你下单那一刻起，到送达你的手中，这个订单的状态有哪些。

我们通过APP，选中自己喜欢吃的菜品后，进行下单的时候，会存在一个时间“大约xxxx送到”，

这个时间，在外卖系统中叫预计送达时间（estimated time of arrival），简称ETA，这个时间的长短直接影响了外卖平台、用户以及骑手的利益，估计的过长会影响用户下单的概率，毕竟到了饭点，我们也不想亏待自己的肚子啊，但骑手是乐意看到的，平台收益会缩减；如果估计的过短，用户下单的概率会变大，但对于骑手而言要求更高，超时的概率更大，这个时间是整个外卖系统的核心时间，本文主要讨论的就是这个时间。

下单后，手机显示商家已接单，距离吃到想吃的饭又近了一步，之后到了骑手已到店，然后取餐，配送中，这时候，我们满怀期待的等着骑手的到来，可现实有时候喜欢给你开个玩笑，时间到了你的午餐还没到，只能饿着肚子看着时间，心里想着怎么给骑手打差评、给商家打电话了，盼望许久，午餐终于到了，接过午餐的那一刻，这个订单也就完成了。

大致上，订单的状态变化可以分为上述的六个步骤，如下：
从上述流程中，我们可以看到，上述每个环节的卡顿，都有可能导致最后的订单超时，而实际骑手配送过程中，不确定的因素会更多，所以偶尔的超时，也希望大家可以谅解下骑手，毕竟超时的事情也不是他们希望发生的。

那么，对于用户而言，我们只关注下单以及订单送到手中，那么对于外卖系统而言，订单状态变化中，每个环节都要考虑哪些因素，下面我们来简要概述下。注：实际外卖系统考虑因素会更多、更全，这里只列举大概的因素。

二、订单的配送过程

在整个的配送过程中要考虑的因素，我们可以从骑手、商家、环境以及平台四个方面进行考虑，其中每个方面的因素在不同的环节对整个配送时间的影响是不同，下面，我们分别来看下各个方面因素的情况。

1.骑手侧
对骑手而言，每个订单越早取到餐品越好，然后越快送达越好，而影响骑手送达的因素，主要有以下几个：
骑手身上背负的订单量：从骑手的角度考虑来看，是在给定的考核时间内将分配给他的订单配送完毕，这里需要注意的是,一般来说在一个时间段内，骑手会被分配多个订单，每个订单都有相应的考核时间，也就是说要在同样的时间内做多个订单的配送，所以骑手被分配的订单越多，订单超时的概率越大（顺路单、同目的地订单除外）。

骑手考核时间和ETA不等价，是平台对骑手配送一个订单所给定的时间，一般和ETA预估模型分离开来，单独给出，这个时间可能大于ETA，也可能小于ETA，超过这个时间则对骑手进行扣罚。

骑手对环境的熟悉程度：骑手负责将订单送到客户手上，那么对于客户的位置、周边路况的熟悉程度会影响骑手的配送时间，平台计算订单的配送距离，一般选择地图距离（地图数据缺失，可以采用直线距离代替）当作订单的配送距离，骑手对环境越熟悉，则走“冤枉路”的概率越小，耗时会越少。

地图距离，指的是从起点到终点，路径规划给出的实际路径长度，也分为骑行地图距离、步行地图距离和驾驶地图距离，而直线距离则是起点和终点之间的球面距离，计算的是（地）球面上两点之间的距离，一般两者差异较大，尤其是多山、多河地带。

骑手个人的因素：骑手一般骑电动车配送，那么电动车的平均车速会直接影响配送的耗时；另外电动车的负载能力、骑手的等级在一定程度上和骑手能够配送的订单量有关，进而影响到骑手的配送。另外骑手的配送习惯，例如先送低楼层，在高楼层，先写字楼在送小区等，也会对订单的配送时间产生较大的影响。

对外卖平台而言，骑手的历史数据都是可以获取的，那么对骑手进行所谓的大数据画像也就顺其自然了，从而产生一系列的特征标签，当作后续外卖平台各种模型的输入，从这个角度来看，骑手对于外卖平台而言，大致等于一个行走的“数据包”了吧。

2.商家侧
商家是订单流程的中间节点，从商家的角度出发，希望自己接受到越多的订单越好，但越多的订单意味着越多制作耗时，而“商家出餐慢”则是超时外卖订单中常见问题，毕竟商家不是只做一个人的餐品，而且不同餐品之间的耗时也差异较大，例如拉面和麻辣香锅，所以准确预估商家侧的“出餐时长”，能够更加合理的调度骑手，避免出现骑手到店取餐时等餐过长，或早就出餐而骑手未到的情况。

出餐时长，指的是一个订单下单后，商家完成该订单制作的预估时长，一般需要考虑订单的菜品、数量、商家历史出餐时间、商家当前订单量、后续预测到达单量等等

3. 环境侧
环境因素，是一个比较泛的考虑，比如时段、路况、天气、小区、写字楼等等，这些因素是可以通过历史数据进行估算的，例如小区、写字楼一般需要骑手步行送餐，平均步行时间的估计、骑手上楼时间估计、下楼时间估计等，有一些因素需要借助第三方数据，例如天气、路况信息，雨天比晴天耗时更多、下班高峰期比日常时段耗时多。

骑手上楼时间、下楼时间的估计，可以根据骑手位置的移动和相应耗时，进行估计，这里会涉及到室内定位问题。一个可以参考的方案是根据wifi指纹、GPS等设定围栏，然后统计平均耗时

4. 平台侧
骑手身上已有订单量、餐品种类、等级、业务逻辑、难配送区域、
平台根据上述的各种因素，结合业务逻辑，会生成一些平台侧特征，例如区域单量密度，用于衡量每个地理单元上单量的情况，从而调度骑手满足物流的供需平衡。为了更好的调度骑手，而不是每次出现订单积压时才发现状况，可以对地理单元进行未来单量的预估，对这个因子的预估，需要慎重，如果预测的不准确或相差太大，有可能会带来骑手运力的浪费，据我所知，滴滴在车辆调度的时候，有这个值的参考。

地理单元，业务指代名称为AOI，指的是H3或GeoHash编码生成地理单元，也有可能是平台自定义的实际区块，例如每个小区、每个写字楼或者一栋楼，都可以当作一个地理单元

另一方面，平台在进行订单调度时候，并不是订单到来的时候立刻进行派单，立即派单和滞后一段时间集中派单，在整体来看后者更容易达到最优解，因为可利用的信息更多。

立即派单，指的是订单到来的时候，从当前运力池直接获取当前最优的骑手。集中派单，也叫hold单，指的是，类似于时间片的概念，将一段时间内的所有订单，在特定时间点，集中进行派送，可以进行订单的打包合并，顺路单、超重单的拆分等，对运力的使用更加合理，这也是饿了么系统所采用的派单方式

相信大家也都见过一种饿了么下单方式，三五个人一起选餐，然后下一个订单的情况，这种情况下会产生一个超重单，不论体积还是重量，都远大于正常订单，配送这种订单是对骑手极大的考验。对于超重单系统可以进行拆分，也可能不拆分只指派到一个人骑手，这取决于平台的业务逻辑；在平台中，还存在一个概念叫“难配送区域”或“难配送实体”，这些可能是学校禁止外卖进入的区域，也可能是老小区缺少电梯上下楼耗时的地方或者超远的配送区域，对于这些区域的配送，耗时会明显的增加，一般来说，平台也会收取更多的配送费。

实体，在物流配送中也叫POI，地图上指代的是一个经纬度描述的坐标点，实际中可以指代一栋楼、一个小区、一个学校或一家公司等
难配送区域或实体，一般是根据历史耗时、站长或骑手反馈、业务指标定义等方式产生的，对这些区域的配送对运力资源的需求远大于正常区域。

三、时间预估

上面从四个方面，分别概述了一些对订单配送过程中，需要考虑因子，那么获取了上述的因子或者特征后，如何基于这些数据获取订单的配送预估时间，则是外卖平台真正核心的技术点。

预计配送时间估计，可以看作是一个回归问题，从基础的LR、GBDT到FM、DeepFM，以及深度AFM、WDR的演进，是对上述甚至更多特征的逐步精细化的使用，从原始文本的one-hot编码，到文本embedding向量化，从原始订单画像、骑手画像数据，到结合业务指标逻辑，通过更大、更深、更强的模型，产生更准、更好的结果，这也是当前深度学习的“万金油”做法了。

四、其他因素

上面提到了众多的ETA估计可以考虑的因子，但业务实际应用中还需要考虑更多、更全。例如，对一个订单而言，是骑手、商家、用户三个的点的路径规划，当骑手身上存在多个订单的时候，如何从找到最优的规划路径是系统提升性能的瓶颈所在；还有就是，当骑手身上存在订单的时候，继续给骑手派单，是否会导致已有的订单的超时？骑手后续可能的存在的顺路单是否更优于当前的订单？对这些更细致点的优化可能会带来平台、商家、骑手三方利益的进一步提升。当然还有其他的点，例如骑手定位、单量预估、路口耗时估计等，在此不一一叙述了。

四、总结

本篇主要对饿了么订单配送过程中ETA估计可能涉及的因素进行了展开，从骑手、商家、环境、平台四个角度分别叙述了主要的考虑点。本篇是自己在即时物流配送行业工作的总结记录之言，可能存在遗漏，欢迎交流。

五、参考文献

https://tech.meituan.com/2018/12/13/machine-learning-in-distribution-practice.html
https://tech.meituan.com/2019/02/21/meituan-delivery-eta-estimation-in-the-practice-of-deep-learning.html
https://www.leiphone.com/news/201808/EmRne91YDwwNCl4A.html
https://blog.csdn.net/Andy_shenzl/article/details/86480417
————————————————