← 返回首页

版本对比

查看政策在不同版本之间的内容变化

滴滴网约车算法政策协议
平台：滴滴
🔗 查看政策原文

📄 上一个版本

2026年05月01日

📄 当前版本

2026年06月12日

🤖 AI智能分析

分析时间: 2026年06月12日
好的，遵照您的指示，以下是对滴滴出行该政策文件两个版本（2026年05月01日版与2026年06月12日版）的按时间顺序比较分析报告。 ### 总体评估 本次从 **2026年05月01日** 到 **2026年06月12日** 的更新属于 **微小勘误与格式调整**。经过逐字逐句的对比，两个版本的算法描述、FAQ问答、定价声明等所有实质性内容完全一致，没有任何功能、规则、数据或法律条款的变更。唯一的修改是更新了品牌名称的称呼，将“滴滴出行APP”统一简化或修正为“滴滴APP”。这属于一次名从主人的文本修正或格式统一行为。 ### 详细变更点分析 经全文比对，新版本相较于旧版本，仅存在一处极其微小的非实质性修改。具体如下： 1. **变更类型：** **修改** * **变更内容：** 修改了品牌应用程序的名称引用。在所有算法应用场景的描述中，将原来的 **“滴滴出行APP”** 更改为 **“滴滴APP”**。 * **潜在影响：** **无任何实质性影响**。这只是为了与平台当前的市场宣传和品牌简称保持一致，进行了术语的简化和统一。这既不影响算法的运行机制，也不影响用户的权利义务。 *（注：除上述唯一一处修改外，包括问答部分在内的所有其他文本均保持不变。）* ### 结论 本次政策文件更新是一次非实质性的、纯文本书写的修订。核心变化在于将品牌应用程序的称呼从“滴滴出行APP”统一修改为“滴滴APP”，反映了品牌简称的规范化。该更新未对算法原理、数据规则、用户权益或任何商业实践产生影响，属于典型的日常维护性更新。 --- *分析由 DeepSeek 提供*
删除的内容
新增的内容
修改的内容
上一个版本 (2026年05月01日 ) 当前版本 (2026年06月12日)
1 一、滴滴网约车供需折扣算法 1 一、滴滴网约车供需折扣算法
2 2
3 网信算备120116299582406230023号 3 网信算备120116299582406230023号
4 4
5 算法基本原理：供需折扣指的是，系统结合订单所在时间、空间的供需情况来进行订单折扣发放。对于供给大于需求的区域，平台会对该区域内的呼叫订单发放乘客折扣，乘客支付更优惠，也能帮助司机接到更多的订单。供需情况的不同，折扣力度会有所不同，一般在7-9折之间。 5 算法基本原理：供需折扣指的是，系统结合订单所在时间、空间的供需情况来进行订单折扣发放。对于供给大于需求的区域，平台会对该区域内的呼叫订单发放乘客折扣，乘客支付更优惠，也能帮助司机接到更多的订单。供需情况的不同，折扣力度会有所不同，一般在7-9折之间。
6 6
7 算法运行机制：供需折扣是根据实时的供需情况，提供每单折扣。供需情况考虑的因素有且仅有如下几类：订单里程、订单时段、起终点及周边供需信息、历史统计信息。供需折扣对所有乘客平等适用。其主要运行机制可以用下表定性解释： 7 算法运行机制：供需折扣是根据实时的供需情况，提供每单折扣。供需情况考虑的因素有且仅有如下几类：订单里程、订单时段、起终点及周边供需信息、历史统计信息。供需折扣对所有乘客平等适用。其主要运行机制可以用下表定性解释：
8 8
9 9
10 10
11 算法应用场景：供需折扣的应用场景是在网约车产品（包括滴滴出行APP和微信、支付宝等渠道的小程序）中，用户在发单前，输入起终点后，系统计算预估价时，系统结合订单所在时间、空间的供需情况来进行订单折扣发放。对于供给大于需求的区域，平台会对该区域内的呼叫订单发放乘客折扣，乘客支付更优惠，也能帮助司机接到更多的订单。供需情况的不同，折扣力度会有所不同，一般在7-9折之间。 11 算法应用场景：供需折扣的应用场景是在网约车产品（包括滴滴APP和微信、支付宝等渠道的小程序）中，用户在发单前，输入起终点后，系统计算预估价时，系统结合订单所在时间、空间的供需情况来进行订单折扣发放。对于供给大于需求的区域，平台会对该区域内的呼叫订单发放乘客折扣，乘客支付更优惠，也能帮助司机接到更多的订单。供需情况的不同，折扣力度会有所不同，一般在7-9折之间。
12 12
13 算法目的意图：在平峰期供给严重大于需求的情况下，通过实时供需折扣来拉动更多乘客呼叫，也帮助司机接到更多订单，维持收入相对稳定。 13 算法目的意图：在平峰期供给严重大于需求的情况下，通过实时供需折扣来拉动更多乘客呼叫，也帮助司机接到更多订单，维持收入相对稳定。
14 14
15 二、滴滴路径规划算法 15 二、滴滴路径规划算法
16 16
17 网信算备120116299582406230031号 17 网信算备120116299582406230031号
18 18
19 算法基本原理： 19 算法基本原理：
20 20
21 滴滴-路径规划分为以下几个步骤： 21 滴滴-路径规划分为以下几个步骤：
22 22
23 1）路线生成； 23 1）路线生成；
24 24
25 2）路线排序； 25 2）路线排序；
26 26
27 3）挑选备选路线。 27 3）挑选备选路线。
28 路线生成 28 路线生成
29 29
30 路线生成是基于路网基础信息，构建成一个有向图，再使用相关搜索算法在地理空间搜索候选路线。基于道路属性（如长度、道路等级等）或历史通行能力构建图的权值，然后使用相关算法搜索生成若干路线。 30 路线生成是基于路网基础信息，构建成一个有向图，再使用相关搜索算法在地理空间搜索候选路线。基于道路属性（如长度、道路等级等）或历史通行能力构建图的权值，然后使用相关算法搜索生成若干路线。
31 31
32 32
33 33
34 原始路网拓扑 34 原始路网拓扑
35 35
36 36
37 37
38 最快路线生成 38 最快路线生成
39 路线排序 39 路线排序
40 40
41 路线排序是在获取到所有已生成的候选路线后，按照安全，历史常走的热度，行驶时间、距离等因素综合排序，给出综合性能最好的路线。 41 路线排序是在获取到所有已生成的候选路线后，按照安全，历史常走的热度，行驶时间、距离等因素综合排序，给出综合性能最好的路线。
42 42
43 其中，安全、时间、距离，红绿灯等因素是纯地理空间特征的描述，和用户行为无关；而历史常走的热度信息会根据用户在历史上该起终点路线实走过的次数统计得到。在采集过程中仅记录用户实走的次数，不记录其他任何信息。如用户显示关闭“个人常走”功能，后台不会再记录该信息。 43 其中，安全、时间、距离，红绿灯等因素是纯地理空间特征的描述，和用户行为无关；而历史常走的热度信息会根据用户在历史上该起终点路线实走过的次数统计得到。在采集过程中仅记录用户实走的次数，不记录其他任何信息。如用户显示关闭“个人常走”功能，后台不会再记录该信息。
44 44
45 路线排序的逻辑如下： 45 路线排序的逻辑如下：
46 46
47 1）首先按热度对路线进行排序，第一条路线就是热度最高的路线； 47 1）首先按热度对路线进行排序，第一条路线就是热度最高的路线；
48 48
49 2）如果有更快的路线比热度最高的路线快3-5分钟以上，并且新路线里程不会比“拟合价格（接时间和里程的一个固定的融合参数相加）”增加4元，第一条路线会被更快路线替换； 49 2）如果有更快的路线比热度最高的路线快3-5分钟以上，并且新路线里程不会比“拟合价格（接时间和里程的一个固定的融合参数相加）”增加4元，第一条路线会被更快路线替换；
50 50
51 3）如果没有更快路线替换热度最高的路线，但是有路线的里程比热度最高的路线近1公里且占总里程10%以上，并且时间不变慢5分钟以上，则把符合上述要求的路线替换热度更高的路线。 51 3）如果没有更快路线替换热度最高的路线，但是有路线的里程比热度最高的路线近1公里且占总里程10%以上，并且时间不变慢5分钟以上，则把符合上述要求的路线替换热度更高的路线。
52 挑选备选路线 52 挑选备选路线
53 53
54 在第一条路线确定之后，为了让用户有更多的选择，以满足用户在不同场景下的需求，系统会在用户发单时提供1-2条备选路线。 54 在第一条路线确定之后，为了让用户有更多的选择，以满足用户在不同场景下的需求，系统会在用户发单时提供1-2条备选路线。
55 55
56 备选路线的挑选优先顺序如下：挑选时间更快，但里程不优于当前推荐路线 56 备选路线的挑选优先顺序如下：挑选时间更快，但里程不优于当前推荐路线
57 挑选里程更短，但时间不优于当前推荐路线 > 挑选路线差异度和当前推荐路线比较大。 57 挑选里程更短，但时间不优于当前推荐路线 > 挑选路线差异度和当前推荐路线比较大。
58 58
59 示意图： 59 示意图：
60 60
61 61
62 62
63 算法运行机制： 63 算法运行机制：
64 64
65 1.触发逻辑 65 1.触发逻辑
66 66
67 用户在发单页输入起点终点后，会自动进入发单页规划页面，接口会将起点终点传给路线引擎，路线引擎根据上述的生成、排序规则推荐出一条或若干条候选路线，并在路线上展示对应的里程、时间和路线属性。 67 用户在发单页输入起点终点后，会自动进入发单页规划页面，接口会将起点终点传给路线引擎，路线引擎根据上述的生成、排序规则推荐出一条或若干条候选路线，并在路线上展示对应的里程、时间和路线属性。
68 更新逻辑 68 更新逻辑
69 69
70 行程开始后，默认会继承用户在发单页面点选的路线，并同步给司机端导航。在整个行程中，如果路况发生变化或行程路线偏航则会触发重新计算路线。如重新计算后出现更优路线，则在司机端触发弹窗提示更换路线，司机与乘客沟通确认后切换到新路线上。 70 行程开始后，默认会继承用户在发单页面点选的路线，并同步给司机端导航。在整个行程中，如果路况发生变化或行程路线偏航则会触发重新计算路线。如重新计算后出现更优路线，则在司机端触发弹窗提示更换路线，司机与乘客沟通确认后切换到新路线上。
71 关闭逻辑 71 关闭逻辑
72 72
73 订单结束会自动关闭。 73 订单结束会自动关闭。
74 74
75 算法应用场景：路径规划算法主要在网约车产品（包括滴滴出行APP和微信、支付宝等渠道的小程序）的以下应用场景中： 75 算法应用场景：路径规划算法主要在网约车产品（包括滴滴APP和微信、支付宝等渠道的小程序）的以下应用场景中：
76 预估价格，用于计算里程费； 76 预估价格，用于计算里程费；
77 分单系统，用于计算司机到乘客的距离； 77 分单系统，用于计算司机到乘客的距离；
78 导航，分为接驾段导航和送驾段导航两阶段。 78 导航，分为接驾段导航和送驾段导航两阶段。
79 79
80 算法目的意图：在地图中生成并推荐一条到三条较优的候选路线提供给用户选择，帮助用户实现美好出行。 80 算法目的意图：在地图中生成并推荐一条到三条较优的候选路线提供给用户选择，帮助用户实现美好出行。
81 81
82 三、滴滴上车点推荐算法 82 三、滴滴上车点推荐算法
83 83
84 网信算备120116299582406230049号 84 网信算备120116299582406230049号
85 85
86 算法基本原理： 86 算法基本原理：
87 87
88 滴滴上车点推荐功能分为以下四个步骤： 88 滴滴上车点推荐功能分为以下四个步骤：
89 上车点生成 89 上车点生成
90 上车点召回打分 90 上车点召回打分
91 上车点规则重排 91 上车点规则重排
92 上车点命名 92 上车点命名
93 93
94 下面简单介绍四个流程： 94 下面简单介绍四个流程：
95 上车点生产 95 上车点生产
96 基于路网数据（道路拓扑、道路长度、宽度、轮廓等）和用户历史上车位置信息， 生成路网拓扑上的上车点（可上车位置）集合。 96 基于路网数据（道路拓扑、道路长度、宽度、轮廓等）和用户历史上车位置信息， 生成路网拓扑上的上车点（可上车位置）集合。
97 上车点召回打分 97 上车点召回打分
98 基于上车点生成模块中得到的基础点位以及用户自身位置（包括用户主动输入），上车点召回模块召回优质候选上车点，再经过排序引擎对候选点位进行排序打分。 98 基于上车点生成模块中得到的基础点位以及用户自身位置（包括用户主动输入），上车点召回模块召回优质候选上车点，再经过排序引擎对候选点位进行排序打分。
99 上车点规则重排 99 上车点规则重排
100 对于已生成的候选上车点，根据点位与用户的距离、热度、通行性、可停靠属性等信息，基于业务规则对点位进行重排，产生最终推荐的上车点（1-3条）。 100 对于已生成的候选上车点，根据点位与用户的距离、热度、通行性、可停靠属性等信息，基于业务规则对点位进行重排，产生最终推荐的上车点（1-3条）。
101 上车点命名 101 上车点命名
102 对于最终推荐的上车点（1-3条），推荐上车点一定范围内POI信息和路网信息，为每个上车点配置一个容易理解的名字。 102 对于最终推荐的上车点（1-3条），推荐上车点一定范围内POI信息和路网信息，为每个上车点配置一个容易理解的名字。
103 103
104 104
105 105
106 算法运行机制： 106 算法运行机制：
107 触发逻辑 107 触发逻辑
108 108
109 用户启动滴滴应用程序后，平台基于用户当前的位置以及周边环境，结合用户历史上车地点、停靠性等特征，为用户推荐最优的一至三个上车位置点。 109 用户启动滴滴应用程序后，平台基于用户当前的位置以及周边环境，结合用户历史上车地点、停靠性等特征，为用户推荐最优的一至三个上车位置点。
110 更改逻辑 110 更改逻辑
111 111
112 如果用户对推荐的点位不满意，可以手动拖动地图，上车点推荐系统会根据用户拖动的地图位置重新推荐一至三个上车点。用户也可以在滴滴出行应用程序的首页起点输入框中搜索特定的POI名称作为起点。此外，用户在设置订单起终点后的发单页面中也可以再次更改上车点。 112 如果用户对推荐的点位不满意，可以手动拖动地图，上车点推荐系统会根据用户拖动的地图位置重新推荐一至三个上车点。用户也可以在滴滴应用程序的首页起点输入框中搜索特定的POI名称作为起点。此外，用户在设置订单起终点后的发单页面中也可以再次更改上车点。
113 113
114 算法应用场景： 114 算法应用场景：
115 115
116 滴滴上车点推荐算法主要用于滴滴平台网约车服务（包括滴滴出行APP、小程序及其他类型应用程序）中，在发单前为用户推荐一至三个上车位置点，由用户挑选合适的上车点。 116 滴滴上车点推荐算法主要用于滴滴平台网约车服务（包括滴滴APP、小程序及其他类型应用程序）中，在发单前为用户推荐一至三个上车位置点，由用户挑选合适的上车点。
117 117
118 算法目的意图： 118 算法目的意图：
119 119
120 用户发单前，在用户位置附近推荐一至三个上车位置点，由用户挑选合适的上车点，帮助用户便捷出行。 120 用户发单前，在用户位置附近推荐一至三个上车位置点，由用户挑选合适的上车点，帮助用户便捷出行。
121 121
122 四、滴滴预估到达时间算法 122 四、滴滴预估到达时间算法
123 123
124 算法基本原理： 124 算法基本原理：
125 125
126 预估到达时间（ETA）算法到达时间预估是在限定的道路拓扑条件下，基于既定的起点、终点、交通状况、可能行驶路线、道路情况等输入特征，对于行驶时间进行预估。该算法以深度学习技术为基础、以预估准确和避免用户恶劣体验为算法的优化目标，持续进行迭代和优化。 126 预估到达时间（ETA）算法到达时间预估是在限定的道路拓扑条件下，基于既定的起点、终点、交通状况、可能行驶路线、道路情况等输入特征，对于行驶时间进行预估。该算法以深度学习技术为基础、以预估准确和避免用户恶劣体验为算法的优化目标，持续进行迭代和优化。
127 平台使用的时间预估(ETA)模型通过数据训练，每日会迭代更新。该模型针对不同的城市和业务场景（如接驾、送驾、预估价等）单独建模，以达到算法效果最优。 127 平台使用的时间预估(ETA)模型通过数据训练，每日会迭代更新。该模型针对不同的城市和业务场景（如接驾、送驾、预估价等）单独建模，以达到算法效果最优。
128 128
129 129
130 130
131 算法运行机制： 131 算法运行机制：
132 触发逻辑 132 触发逻辑
133 133
134 用户在网约车发单页面输入行程起点、终点后，平台将起点至终点的规划路径提供给计算模块，计算模块根据订单出发时间和实时道路拥堵情况计算本次行程的预估到达时间。 134 用户在网约车发单页面输入行程起点、终点后，平台将起点至终点的规划路径提供给计算模块，计算模块根据订单出发时间和实时道路拥堵情况计算本次行程的预估到达时间。
135 更新逻辑 135 更新逻辑
136 行程开始后，平台会根据本次行程中驾驶员使用的应用程序实时位置，以固定的时间间隔请求计算模块用于更新预估到达时间。在请求的时间间隔内，乘客用户使用的应用程序通过内部倒计时模块，根据时间自然流逝进行倒计时，用于保障服务性能。 136 行程开始后，平台会根据本次行程中驾驶员使用的应用程序实时位置，以固定的时间间隔请求计算模块用于更新预估到达时间。在请求的时间间隔内，乘客用户使用的应用程序通过内部倒计时模块，根据时间自然流逝进行倒计时，用于保障服务性能。
137 关闭逻辑 137 关闭逻辑
138 行程结束后，预估到达时间算法自动关闭。 138 行程结束后，预估到达时间算法自动关闭。
139 139
140 算法应用场景： 140 算法应用场景：
141 141
142 预估到达时间算法主要应用在以下场景： 142 预估到达时间算法主要应用在以下场景：
143 预估价格：根据预估时间和路线计算预估价； 143 预估价格：根据预估时间和路线计算预估价；
144 分单系统：根据司机和乘客之间路线预估司机接到乘客的时间； 144 分单系统：根据司机和乘客之间路线预估司机接到乘客的时间；
145 导航：根据乘客的路线预估司机到达乘客上车点位置的时间；在行程中，根据自车点位置和下车点位置预估乘客到达时间。 145 导航：根据乘客的路线预估司机到达乘客上车点位置的时间；在行程中，根据自车点位置和下车点位置预估乘客到达时间。
146 146
147 算法目的意图： 147 算法目的意图：
148 148
149 在客观地理世界中基于既定的路线、订单出发时间和当时道路的拥堵情况，预估从订单起点到达终点的行驶时间。 149 在客观地理世界中基于既定的路线、订单出发时间和当时道路的拥堵情况，预估从订单起点到达终点的行驶时间。
150 150
151 五、滴滴网约车一口价算法 151 五、滴滴网约车一口价算法
152 152
153 网信算备120116299582406230065号 153 网信算备120116299582406230065号
154 154
155 算法基本原理： 155 算法基本原理：
156 一口价是指当乘客输入起终点后，系统给定本次出行在该起终点、路线确定的前提下，所见价格即为结账价格（区别于预估价模式）的出价模式，当前主要用于非快车的品类。 156 一口价是指当乘客输入起终点后，系统给定本次出行在该起终点、路线确定的前提下，所见价格即为结账价格（区别于预估价模式）的出价模式，当前主要用于非快车的品类。
157 一口价的价格会据订单的里程、订单起终点的供需状况等因素综合确定（不包含其他额外的费用，如：高速费等）。当实际行驶路线与平台推荐路线不一致，或者行程起终点变更后，可能导致此次行程的一口价重新计算。 157 一口价的价格会据订单的里程、订单起终点的供需状况等因素综合确定（不包含其他额外的费用，如：高速费等）。当实际行驶路线与平台推荐路线不一致，或者行程起终点变更后，可能导致此次行程的一口价重新计算。
158 158
159 算法运行机制： 159 算法运行机制：
160 160
161 根据不同区域的实时供需情况叠加订单起终点的距离和时间，计算出订单的一口价。 161 根据不同区域的实时供需情况叠加订单起终点的距离和时间，计算出订单的一口价。
162 一口价的价格会据订单的里程、订单起终点的供需状况等因素综合确定（不包含其他额外的费用，如：高速费等）。当实际行驶路线与平台推荐路线不一致，或者行程起终点变更后，可能导致此次行程的一口价重新计算。其主要运行机制可以用下表定性解释： 162 一口价的价格会据订单的里程、订单起终点的供需状况等因素综合确定（不包含其他额外的费用，如：高速费等）。当实际行驶路线与平台推荐路线不一致，或者行程起终点变更后，可能导致此次行程的一口价重新计算。其主要运行机制可以用下表定性解释：
163 163
164 164
165 165
166 注：价格上浮机制仅限滴滴专车和滴滴特快品类，且只在部分供不应求的区域或时段内触发。 166 注：价格上浮机制仅限滴滴专车和滴滴特快品类，且只在部分供不应求的区域或时段内触发。
167 167
168 算法应用场景： 168 算法应用场景：
169 169
170 当城市和/或网约车品类具备一口价定价能力时，根据不同区域的实时供需情况叠加订单起终点的距离和时间，计算订单的一口价。 170 当城市和/或网约车品类具备一口价定价能力时，根据不同区域的实时供需情况叠加订单起终点的距离和时间，计算订单的一口价。
171 171
172 算法目的意图： 172 算法目的意图：
173 提升用户的价格确定性感知：所见即所得的价格展示更有利于用户对于订单价格产生稳定预期；在遇到相对可控范围的堵车等情况时，用户不用担心价格波动。 173 提升用户的价格确定性感知：所见即所得的价格展示更有利于用户对于订单价格产生稳定预期；在遇到相对可控范围的堵车等情况时，用户不用担心价格波动。
174 满足乘客的出行需求：根据线路起终点的供需差异，当供给小于需求时可以提高乘客的乘车确定性，当供给大于需求时可以降低乘客的支付价格。 174 满足乘客的出行需求：根据线路起终点的供需差异，当供给小于需求时可以提高乘客的乘车确定性，当供给大于需求时可以降低乘客的支付价格。
175 175
176 六、滴滴车型推荐算法 176 六、滴滴车型推荐算法
177 177
178 网信算备120116299582402240015号 178 网信算备120116299582402240015号
179 179
180 算法基本原理： 180 算法基本原理：
181 181
182 目前，车型推荐功能在发单前页面和等待应答页面生效： 182 目前，车型推荐功能在发单前页面和等待应答页面生效：
183 发单前页面，平台会向用户推荐和预勾选车型，流程如下： 183 发单前页面，平台会向用户推荐和预勾选车型，流程如下：
184 1）根据用户的车型偏好和当前的供需情况，推荐用户可能使用的车型：上一次订单中呼叫的车型、应答率高的车型、用户接受率高、完单可能性高的车型、优惠补贴更高的车型，将所述车型加入展示候选车型列表中； 184 1）根据用户的车型偏好和当前的供需情况，推荐用户可能使用的车型：上一次订单中呼叫的车型、应答率高的车型、用户接受率高、完单可能性高的车型、优惠补贴更高的车型，将所述车型加入展示候选车型列表中；
185 2）为用户预勾选上述推荐车型。如用户需要调整预勾选的车型，可以在点击发单前，取消预勾选的某些车型，或者增加勾选某些车型； 185 2）为用户预勾选上述推荐车型。如用户需要调整预勾选的车型，可以在点击发单前，取消预勾选的某些车型，或者增加勾选某些车型；
186 3）根据用户使用的应用程序打车界面可展示的空间大小以及表单形态，可能会有不同的车型推荐展示和预勾选逻辑： 186 3）根据用户使用的应用程序打车界面可展示的空间大小以及表单形态，可能会有不同的车型推荐展示和预勾选逻辑：
187 方案一：依次从流程1、2生成的展示候选车型列表中，选择推荐展示和预勾选的车型，这类车型会优先在打车页面推荐区展示，其余车型在更多车型区展示。如果展示和预勾选的车型较多，推荐区无法完全放满时，会将余下的车型在更多车型区进行展示和勾选。 187 方案一：依次从流程1、2生成的展示候选车型列表中，选择推荐展示和预勾选的车型，这类车型会优先在打车页面推荐区展示，其余车型在更多车型区展示。如果展示和预勾选的车型较多，推荐区无法完全放满时，会将余下的车型在更多车型区进行展示和勾选。
188 方案二：所有车型按照实付价格从低到高升序排列展示，包括推荐并预勾选的车型和未勾选车型，由于勾选的车型在价格上可能并不连续，按实付价格从低到高升序排列展示后，可能会出现一些车型价格比勾选车型价格低但没有被勾选的情况，对于这种情况，会对最高价勾选车型价格之下的车型进行补充勾选。 188 方案二：所有车型按照实付价格从低到高升序排列展示，包括推荐并预勾选的车型和未勾选车型，由于勾选的车型在价格上可能并不连续，按实付价格从低到高升序排列展示后，可能会出现一些车型价格比勾选车型价格低但没有被勾选的情况，对于这种情况，会对最高价勾选车型价格之下的车型进行补充勾选。
189 等待应答页面推荐时，当用户发单后，如果其呼叫的车型长时间无司机应答，平台会向用户推荐更快应答的车型，用户可自行选择是否接受，流程如下： 189 等待应答页面推荐时，当用户发单后，如果其呼叫的车型长时间无司机应答，平台会向用户推荐更快应答的车型，用户可自行选择是否接受，流程如下：
190 1）触发：用户发单后，其选择的车型长时间无司机应答，或平台预估未来一段时间此类车型的应答概率较低； 190 1）触发：用户发单后，其选择的车型长时间无司机应答，或平台预估未来一段时间此类车型的应答概率较低；
191 2）过滤：对当前可推荐车型，按照用户预估接受率、预估上车时间及应答率进行门槛过滤； 191 2）过滤：对当前可推荐车型，按照用户预估接受率、预估上车时间及应答率进行门槛过滤；
192 3）推荐：针对预估应答更快、更优惠、用户接受率更高的车型进行强化提示，用户可自行选择是否接受平台推荐的车型，未被推荐的车型可以通过用户上滑车型列表进行查看。 192 3）推荐：针对预估应答更快、更优惠、用户接受率更高的车型进行强化提示，用户可自行选择是否接受平台推荐的车型，未被推荐的车型可以通过用户上滑车型列表进行查看。
193 193
194 对平台车型推荐勾选功能影响比较大的因素包括： 194 对平台车型推荐勾选功能影响比较大的因素包括：
195 1）不同车型的预估应答率：主要依赖于车型的供需情况； 195 1）不同车型的预估应答率：主要依赖于车型的供需情况；
196 2）不同车型的预估接受率：主要来自用户的历史车型偏好； 196 2）不同车型的预估接受率：主要来自用户的历史车型偏好；
197 3）不同车型的预估上车时间：主要依赖于车型的供需情况以及用户订单起点周边运力的位置分布； 197 3）不同车型的预估上车时间：主要依赖于车型的供需情况以及用户订单起点周边运力的位置分布；
198 4）不同车型的预估完单率：结合用户的车型偏好以及待推荐车型的预估应答率，对完单率进行综合预估； 198 4）不同车型的预估完单率：结合用户的车型偏好以及待推荐车型的预估应答率，对完单率进行综合预估；
199 5）用户上一次使用打车服务时选择的所有发单车型。 199 5）用户上一次使用打车服务时选择的所有发单车型。
200 200
201 201
202 202
203 算法运行机制： 203 算法运行机制：
204 触发逻辑 204 触发逻辑
205 用户每次进入发单前页面或者等待应答页面时，平台会根据上述计算逻辑产生推荐结果。由于供需因素的变化较快，同一位用户在一段时间内多次触发车型推荐勾选算法可能会产生不同的推荐结果。 205 用户每次进入发单前页面或者等待应答页面时，平台会根据上述计算逻辑产生推荐结果。由于供需因素的变化较快，同一位用户在一段时间内多次触发车型推荐勾选算法可能会产生不同的推荐结果。
206 更新逻辑 206 更新逻辑
207 算法模型每天自动更新用于优化车型推荐勾选算法效果。 207 算法模型每天自动更新用于优化车型推荐勾选算法效果。
208 关闭逻辑 208 关闭逻辑
209 用户可以通过滴滴出行应用程序产品界面便捷关闭车型推荐和勾选功能。关闭后系统将会按照不针对用户个人特征的默认固定顺序对用户展示车型品类。 209 用户可以通过滴滴应用程序产品界面便捷关闭车型推荐和勾选功能。关闭后系统将会按照不针对用户个人特征的默认固定顺序对用户展示车型品类。
210 210
211 算法应用场景： 211 算法应用场景：
212 212
213 车型推荐的应用场景是在网约车产品(包括滴滴出行APP和微信、支付宝等渠道的小程序)中，乘客打开APP或者小程序，输入目的地，在发单前页面和等待应答页面生效，会有以下主要场景： 213 车型推荐的应用场景是在网约车产品(包括滴滴APP和微信、支付宝等渠道的小程序)中，乘客打开APP或者小程序，输入目的地，在发单前页面和等待应答页面生效，会有以下主要场景：
214 214
215 1）用户发单前在页面进行车型智能推荐和勾选； 215 1）用户发单前在页面进行车型智能推荐和勾选；
216 216
217 2）用户等待应答中在追加车型场景中车型智能推荐和勾选。 217 2）用户等待应答中在追加车型场景中车型智能推荐和勾选。
218 218
219 算法目的意图： 219 算法目的意图：
220 220
221 为了满足用户差异化诉求（例如，车型、距离、时间、座位数、价格等），滴滴平台提供了多种车型品类供用户进行选择。由于可以通过应用程序产品界面向用户进行展示的空间有限，平台会根据用户的车型偏好进行车型排序展示推荐和预勾选，用户可自行选择是否呼叫对应的车型。 221 为了满足用户差异化诉求（例如，车型、距离、时间、座位数、价格等），滴滴平台提供了多种车型品类供用户进行选择。由于可以通过应用程序产品界面向用户进行展示的空间有限，平台会根据用户的车型偏好进行车型排序展示推荐和预勾选，用户可自行选择是否呼叫对应的车型。
222 222
223 七、滴滴用车服务分单算法 223 七、滴滴用车服务分单算法
224 224
225 网信算备120116299582406230015号 225 网信算备120116299582406230015号
226 226
227 算法基本原理： 227 算法基本原理：
228 228
229 乘客发出订单后，订单将进入等待找车的状态，并按照如下流程进行派单计算： 229 乘客发出订单后，订单将进入等待找车的状态，并按照如下流程进行派单计算：
230 配对。首先将待找车订单和所有可派单司机进行配对，形成若干个”订单-司机“对。 230 配对。首先将待找车订单和所有可派单司机进行配对，形成若干个”订单-司机“对。
231 过滤。按照一定的规则，过滤掉不符合要求的“订单-司机”对，过滤规则主要包括政策要求和司乘意愿两大类。政策要求规则举例：尾号限行司机不能与途径限行区域的订单配对。司乘意愿举例：设置了顺路目的地的司机不能与目的地是反向的订单配对。 231 过滤。按照一定的规则，过滤掉不符合要求的“订单-司机”对，过滤规则主要包括政策要求和司乘意愿两大类。政策要求规则举例：尾号限行司机不能与途径限行区域的订单配对。司乘意愿举例：设置了顺路目的地的司机不能与目的地是反向的订单配对。
232 算分。主要根据订单和司机距离及司机口碑值等因素，计算“订单-司机” 对的分数，距离是影响分数的最大因素，距离越近，分数越高。 232 算分。主要根据订单和司机距离及司机口碑值等因素，计算“订单-司机” 对的分数，距离是影响分数的最大因素，距离越近，分数越高。
233 匹配。将订单和司机进行一一匹配，得到最终匹配结果。 233 匹配。将订单和司机进行一一匹配，得到最终匹配结果。
234 234
235 特殊的，若某个区域乘客呼叫多而司机少，产生了乘客排队，为保证排队公平性，则按照乘客排队顺序依次进行派单。乘客排队场景下，可能存在排名靠后的乘客先走的情况，如司机设置了顺路，只有排名靠后的乘客与司机顺路。 235 特殊的，若某个区域乘客呼叫多而司机少，产生了乘客排队，为保证排队公平性，则按照乘客排队顺序依次进行派单。乘客排队场景下，可能存在排名靠后的乘客先走的情况，如司机设置了顺路，只有排名靠后的乘客与司机顺路。
236 236
237 算法运行机制： 237 算法运行机制：
238 就近派单原则 238 就近派单原则
239 239
240 就滴滴的派单策略而言，最大的原则是“就近派单”原则，从派单结果看，绝大部分的订单都是派给距离最近的司机，若距离相同，则会派给口碑值分数更高的司机，以激励司机为乘客提供更好的出行服务。 240 就滴滴的派单策略而言，最大的原则是“就近派单”原则，从派单结果看，绝大部分的订单都是派给距离最近的司机，若距离相同，则会派给口碑值分数更高的司机，以激励司机为乘客提供更好的出行服务。
241 兼顾司乘体验原则 241 兼顾司乘体验原则
242 242
243 在就近分配的基础上，平台会兼顾司乘体验。如优先给司机匹配接驾时间更短的订单、尽可能提升司机接单效率；为设置顺路目的地的司机，匹配顺路程度更高的订单；当乘客发出乘车需求时，平台会基于乘客的车型选择，优先选择应答更快、接驾时间短的车辆，最终满足乘客尽快上车的需求等。 243 在就近分配的基础上，平台会兼顾司乘体验。如优先给司机匹配接驾时间更短的订单、尽可能提升司机接单效率；为设置顺路目的地的司机，匹配顺路程度更高的订单；当乘客发出乘车需求时，平台会基于乘客的车型选择，优先选择应答更快、接驾时间短的车辆，最终满足乘客尽快上车的需求等。
244 244
245 算法应用场景： 245 算法应用场景：
246 246
247 乘客通过滴滴出行 App 或微信、支付宝等渠道的小程序呼叫一个或多个品类的车型，平台通过分单算法实现订单匹配，将合适接单的司机信息返回给乘客 App，并将乘客的订单信息发给司机的App。 247 乘客通过滴滴 App 或微信、支付宝等渠道的小程序呼叫一个或多个品类的车型，平台通过分单算法实现订单匹配，将合适接单的司机信息返回给乘客 App，并将乘客的订单信息发给司机的App。
248 248
249 算法目的意图： 249 算法目的意图：
250 250
251 平台派单的目标是，在考虑时间、距离等客观限制条件以及司机和乘客公平性感知的情况下，尽可能满足更多乘客和司机的体验需求，实现乘客打车成功率和司机接单收入的最优。 251 平台派单的目标是，在考虑时间、距离等客观限制条件以及司机和乘客公平性感知的情况下，尽可能满足更多乘客和司机的体验需求，实现乘客打车成功率和司机接单收入的最优。
252 Q&A 252 Q&A
253 Q1:平台派单的原则是什么 253 Q1:平台派单的原则是什么
254 254
255 影响平台派单的因素有很多，如接驾距离、司机口碑值、顺路设置、乘客对车型的选择、取消率、司机安全行为等等，但整体遵循以下两大原则进行派单：  255 影响平台派单的因素有很多，如接驾距离、司机口碑值、顺路设置、乘客对车型的选择、取消率、司机安全行为等等，但整体遵循以下两大原则进行派单： 
256 256
257 1、就近分配原则。根据司机接驾距离就近分配是滴滴派单的最大原则，世界上主流的网约车公司也主要遵循此原则。在此基础上，滴滴也会为了业务的正常运行、遵守相关交通法规等设置一些规则来过滤不合理的”订单和司机”的匹配关系，如：规则（1）：快车司机不可接专车订单；规则（2）：为只听预约单司机过滤实时订单；规则（3）：为设置顺路目的地的司机分配顺路的乘客；规则（4）：保证司机接单后不会通过限行限号区域；规则（5）：同一笔订单只会分配给一位司机一次等等。  257 1、就近分配原则。根据司机接驾距离就近分配是滴滴派单的最大原则，世界上主流的网约车公司也主要遵循此原则。在此基础上，滴滴也会为了业务的正常运行、遵守相关交通法规等设置一些规则来过滤不合理的”订单和司机”的匹配关系，如：规则（1）：快车司机不可接专车订单；规则（2）：为只听预约单司机过滤实时订单；规则（3）：为设置顺路目的地的司机分配顺路的乘客；规则（4）：保证司机接单后不会通过限行限号区域；规则（5）：同一笔订单只会分配给一位司机一次等等。 
258 258
259 2、兼顾司乘体验原则。在就近分单的基础上，平台会兼顾司机接单体验，如优先给司机匹配接驾时间更短的订单、尽可能提升司机接单效率；未设置顺路目的地的司机，匹配顺路程度更高的订单等等。在此基础上，也会兼顾乘客的出行体验，基于乘客的车型选择，参考取消率、司机安全行为（如无安全投诉）等综合因素来派单。 259 2、兼顾司乘体验原则。在就近分单的基础上，平台会兼顾司机接单体验，如优先给司机匹配接驾时间更短的订单、尽可能提升司机接单效率；未设置顺路目的地的司机，匹配顺路程度更高的订单等等。在此基础上，也会兼顾乘客的出行体验，基于乘客的车型选择，参考取消率、司机安全行为（如无安全投诉）等综合因素来派单。
260 260
261   261  
262 262
263 Q2：影响派单的因素有哪些 263 Q2：影响派单的因素有哪些
264 264
265 系统派单一看距离，二看口碑值，在此基础上，滴滴会兼顾乘客的出行体验，基于乘客的车型选择，参考取消率、司机安全行为（如无安全投诉）等综合因素来派单。除了上述情况，司机是否设置顺路单、是否设置愿接场站单等情况也会影响派单。 265 系统派单一看距离，二看口碑值，在此基础上，滴滴会兼顾乘客的出行体验，基于乘客的车型选择，参考取消率、司机安全行为（如无安全投诉）等综合因素来派单。除了上述情况，司机是否设置顺路单、是否设置愿接场站单等情况也会影响派单。
266 266
267   267  
268 268
269 Q3：直接距离≠接驾距离是什么意思 269 Q3：直接距离≠接驾距离是什么意思
270 270
271 接驾距离不等于直线距离。如果采用直线距离，可能会让乘客等更久，师傅们空驶更远。接驾距离指的是乘客发单点和司机所在位置之间的「路面距离」，路面距离是由导航系统计算，结合路网、路况信息综合规划出的路线的长度。所以即使乘客就在马路对面，如果司机师傅需要去远处掉头才能接到乘客，路面距离可能也会很远。 271 接驾距离不等于直线距离。如果采用直线距离，可能会让乘客等更久，师傅们空驶更远。接驾距离指的是乘客发单点和司机所在位置之间的「路面距离」，路面距离是由导航系统计算，结合路网、路况信息综合规划出的路线的长度。所以即使乘客就在马路对面，如果司机师傅需要去远处掉头才能接到乘客，路面距离可能也会很远。
272 272
273 273
274 274
275 定价相关QA 275 定价相关QA
276 276
277   277  
278 278
279 Q1：滴滴是否存在“大数据杀熟"的情况，不同用户定价不同？ 279 Q1：滴滴是否存在“大数据杀熟"的情况，不同用户定价不同？
280 280
281 A：滴滴平台绝不存在“大数据杀熟"。平台坚持公平透明的定价机制，从方案设计上确保定价、优惠相关算法满足公平性、透明性的要求。平台现行定价机制主要包括基础定价与一口价两种模式，其中基础定价层面仅依赖订单起点所属区域、订单发生时段、订单里程、订单时长来计算基础车费，平台根据时空供需特征及季节性差异因素采取分时分区矩阵式设置基础计价参数。一口价是在基础定价之上，综合考虑实时供需，分品类计算乘客一口价（不含其他额外费用，如高速费等）。基础定价和一口价策略中，均未考虑或使用任何人维度特征，确保定价补贴的结果在相同起点、相同终点、相同时间条件下，不同人结果相同，所有人平等适用。一口价策略配套价格缓存能力，确保不同乘客在同一时间、相同起终点、呼叫同一车型时，订单价格完全一致，进一步杜绝基于用户个人特征的差异化定价。此外，平台坚决保护用户个人隐私，禁止向任何第三方泄漏用户个人信息。 281 A：滴滴平台绝不存在“大数据杀熟"。平台坚持公平透明的定价机制，从方案设计上确保定价、优惠相关算法满足公平性、透明性的要求。平台现行定价机制主要包括基础定价与一口价两种模式，其中基础定价层面仅依赖订单起点所属区域、订单发生时段、订单里程、订单时长来计算基础车费，平台根据时空供需特征及季节性差异因素采取分时分区矩阵式设置基础计价参数。一口价是在基础定价之上，综合考虑实时供需，分品类计算乘客一口价（不含其他额外费用，如高速费等）。基础定价和一口价策略中，均未考虑或使用任何人维度特征，确保定价补贴的结果在相同起点、相同终点、相同时间条件下，不同人结果相同，所有人平等适用。一口价策略配套价格缓存能力，确保不同乘客在同一时间、相同起终点、呼叫同一车型时，订单价格完全一致，进一步杜绝基于用户个人特征的差异化定价。此外，平台坚决保护用户个人隐私，禁止向任何第三方泄漏用户个人信息。
282 282
283 平台的价格优惠活动分为以下四类：1）呼返等面向供需调节的补贴，不使用个体维度的特征，已完成算法备案并在App上公示；2）用户自主选择购买的优惠，例如套餐、乘客任务、会员等；3）符合商业惯例的，符合公平透明原则、规则清晰可透传的合理营销活动，例如新用户、沉默用户的优惠；4）平台随机发放的补贴活动，例如在一些特定或者不定期的营销节点，为了激发更多用户需求而进行的随机补贴活动。随机发放活动会以常态化的营销模式进行，但会在规则详情页中明确跟用户说明活动规则。 283 平台的价格优惠活动分为以下四类：1）呼返等面向供需调节的补贴，不使用个体维度的特征，已完成算法备案并在App上公示；2）用户自主选择购买的优惠，例如套餐、乘客任务、会员等；3）符合商业惯例的，符合公平透明原则、规则清晰可透传的合理营销活动，例如新用户、沉默用户的优惠；4）平台随机发放的补贴活动，例如在一些特定或者不定期的营销节点，为了激发更多用户需求而进行的随机补贴活动。随机发放活动会以常态化的营销模式进行，但会在规则详情页中明确跟用户说明活动规则。
284 284
285 平台承诺：平台定价算法不考虑任何用户个体维度特征，不会利用用户浏览记录、支付意愿、消费习惯等个人信息对同一服务在同等交易条件下设置不同价格。 285 平台承诺：平台定价算法不考虑任何用户个体维度特征，不会利用用户浏览记录、支付意愿、消费习惯等个人信息对同一服务在同等交易条件下设置不同价格。
286 286
287   287  
288 288
289 Q2：平台的优惠券发放原则是什么，为什么别人有优惠券，我却没有？ 289 Q2：平台的优惠券发放原则是什么，为什么别人有优惠券，我却没有？
290 290
291 A： 当前平台优惠券分为四类，针对不同类型的优惠券均有不同的适用人群及目的，主要分为4种（详见下表）。如果用户想主动获取优惠，可以关注App内的「优惠中心」、参与会员套餐，或留意不定期的营销节点活动。平台同时在持续优化优惠券发放机制的公示说明，让每一类优惠的获取渠道和规则都更加清晰可查。 291 A： 当前平台优惠券分为四类，针对不同类型的优惠券均有不同的适用人群及目的，主要分为4种（详见下表）。如果用户想主动获取优惠，可以关注App内的「优惠中心」、参与会员套餐，或留意不定期的营销节点活动。平台同时在持续优化优惠券发放机制的公示说明，让每一类优惠的获取渠道和规则都更加清晰可查。
292 292
293 | | | | 293 | | | |
294 | --- | --- | --- | 294 | --- | --- | --- |
295 | 优惠类型 | 适用人群 | 说明 | 295 | 优惠类型 | 适用人群 | 说明 |
296 | 供需调节补贴（如呼返补贴） | 所有用户 | 不使用个体维度特征，系统结合订单所在时间、空间的供需情况进行发放，供需情况不同，补贴金额或折扣力度会有所不同。 | 296 | 供需调节补贴（如呼返补贴） | 所有用户 | 不使用个体维度特征，系统结合订单所在时间、空间的供需情况进行发放，供需情况不同，补贴金额或折扣力度会有所不同。 |
297 | 用户自主购买的权益 （如套餐、会员） | 主动购买的用户 | 自愿选择，价格和权益均公开。 | 297 | 用户自主购买的权益 （如套餐、会员） | 主动购买的用户 | 自愿选择，价格和权益均公开。 |
298 | 常规营销活动 （如新用户礼包、沉默用户唤醒） | 特定行为人群 | 符合商业惯例，符合公平透明原则、规则清晰可透传的合理营销活动，规则在活动详情页明确说明。 | 298 | 常规营销活动 （如新用户礼包、沉默用户唤醒） | 特定行为人群 | 符合商业惯例，符合公平透明原则、规则清晰可透传的合理营销活动，规则在活动详情页明确说明。 |
299 | 随机红包活动 | 随机抽取 | 激发更多用户需求，节点性发放，规则在活动详情页明确说明。 | 299 | 随机红包活动 | 随机抽取 | 激发更多用户需求，节点性发放，规则在活动详情页明确说明。 |
300 300
301 Q3：打车前看到的预估价为什么和我支付的不一样？ 301 Q3：打车前看到的预估价为什么和我支付的不一样？
302 302
303 A： 打车前看到是「预估价」，「预估价」指乘客确定出发地和目的地后，平台根据推荐路线或乘客主动选择的路线对应的实时交通状况、预估行驶里程、时长等因素，按照该笔订单的计价模式预估基础车费并扣除用户优惠券或其他补贴费用(如有)。当行驶途中用户主动变更路线、增改途径点、变更下车点，或由于路况变化导致里程时长发生变化、切换路线后途径高速产生高速费等情况发生时，平台根据行程实际行驶的「实际时间」和「实际距离」计算支付车费，均有可能出现预估价格与最终实际结算价格之间可能存在差异。 303 A： 打车前看到是「预估价」，「预估价」指乘客确定出发地和目的地后，平台根据推荐路线或乘客主动选择的路线对应的实时交通状况、预估行驶里程、时长等因素，按照该笔订单的计价模式预估基础车费并扣除用户优惠券或其他补贴费用(如有)。当行驶途中用户主动变更路线、增改途径点、变更下车点，或由于路况变化导致里程时长发生变化、切换路线后途径高速产生高速费等情况发生时，平台根据行程实际行驶的「实际时间」和「实际距离」计算支付车费，均有可能出现预估价格与最终实际结算价格之间可能存在差异。
304 304
305   305  
306 306
307 Q4：同样的路线，为什么这次打车比以前要贵？ 307 Q4：同样的路线，为什么这次打车比以前要贵？
308 308
309 A：不同车型、不同时段（高峰期和平峰期）的路况不同。即使在路线一致的情况下，用车时间段不同、车型不一致、路况不同，都可能和之前打车有价格差异，详情可查看车费金额下方“查看计价规则”。另外，如果您购买了滴滴套餐或通过其他活动获取了滴滴优惠券，会减免部分车费，也可能会导致两次不同用车最终支付车费不一致。 309 A：不同车型、不同时段（高峰期和平峰期）的路况不同。即使在路线一致的情况下，用车时间段不同、车型不一致、路况不同，都可能和之前打车有价格差异，详情可查看车费金额下方“查看计价规则”。另外，如果您购买了滴滴套餐或通过其他活动获取了滴滴优惠券，会减免部分车费，也可能会导致两次不同用车最终支付车费不一致。