版本对比 - 滴滴网约车算法政策协议

滴滴网约车算法政策协议

平台：滴滴

🔗 查看政策原文

📄 上一个版本

2025年08月26日

📄 当前版本

2026年05月01日

🤖 AI智能分析

分析时间: 2026年05月01日

好的，收到指令。作为一名严谨的政策分析专家，我将以极高的时间敏感性，对该文件的两个版本进行详尽的比较分析。 --- ## 滴滴出行算法备案文件版本演变分析报告 **版本对比**: 旧版本 (2025年08月26日 22:12) vs. 新版本 (2026年05月01日 01:11) ### 1. 总体评估本次更新属于 **“实质性条款变更”**。 **核心依据**: 新版本在原有七项算法备案内容**完全不变**的基础上，**新增**了一个关键的“Q&A”章节。该章节不仅对原有算法的运行机制进行了补充说明，更重要的是，首次以官方文件形式明确回应了公众高度关注的“大数据杀熟”、优惠券发放规则、价格差异等敏感问题。这标志着平台在算法透明度方面迈出了实质性的一步，但其内容也引入了一些需要用户仔细甄别的表述。 ### 2. 详细变更点分析以下列出了所有重要的、实质性的变更： 1. **变更类型**: **新增** (大幅扩充，构成文件主体) * **变更内容**: 在“七、滴滴用车服务分单算法”之后，新增了“Q&A”章节。该章节包含 **分单Q&A** 和 **定价相关QA** 两个子部分，共计8个问题与回答。 * **分单Q&A** (3个问题，Q1-Q3): * Q1: 平台派单的原则是什么 * Q2: 影响派单的因素有哪些 * Q3: 直接距离≠接驾距离是什么意思 * **定价相关QA** (5个问题，Q1-Q5): * Q1: 滴滴是否存在“大数据杀熟"的情况，不同用户定价不同？ * Q2: 平台的优惠券发放原则是什么，为什么别人有优惠券，我却没有？ * Q3: 打车前看到的预估价为什么和我支付的不一样？ * Q4: 同样的路线，为什么这次打车比以前要贵？ * **潜在影响**: * **积极影响 (透明度提升)**: 通过官方文件形式，对用户常见的、与价格和派单相关的质疑给出了系统性解释。例如，明确否定了“大数据杀熟”，并框架性地解释了定价机制。 * **需警惕的表述**: 部分回答可能引发新的疑问。例如，在否认“杀熟”的同时，承认了“新用户、沉默用户的优惠”和“平台随机发放的补贴活动”，但并未详细说明“沉默用户”与“普通用户”的界定标准，以及“随机”算法的具体逻辑。这可能导致用户对“随机”的公平性存疑。 * **用户认知影响**: 该新增章节可能会被部分用户视为“免责声明”，意在向监管和公众表明合规立场，而非完全为解决用户个体体验问题而设计。例如，对于价格差异的解释主要归因于时间、路况等客观因素，但未完全覆盖用户对“同一时间、同一路线、不同用户显示不同价格”这一核心体验痛点的解释。 2. **变更类型**: **修改** (微调定义) * **变更内容**: 在“定价相关QA”的Q1回答中，对平台优惠活动的分类进行了更清晰的界定和列举。旧版本仅提到“用户自主选择购买的优惠”和“常规营销活动”。新版本将其重新划分为四类并形成表格： 1. 供需调节补贴（如呼返补贴） 2. 用户自主购买的权益（如套餐、会员） 3. 常规营销活动（如新用户礼包、沉默用户唤醒） 4. 随机红包活动 * **潜在影响**: 这种分类法使得补贴类型更加结构化。但将“沉默用户唤醒”归类为“常规营销活动”而非“个体维度特征”，可能是一种策略性的表述，即承认对用户行为（如使用频率）进行了分类，但否认针对其个人消费偏好进行“杀熟”。这实质上承认了对用户历史行为（沉默）的监测和利用。 3. **变更类型**: **无需修改的“无变化”确认** * **变更内容**: 对旧版本中原有的七项算法（供需折扣、路径规划、上车点推荐、预估到达时间、一口价、车型推荐、分单算法）的正文内容，新版本未做任何增删改。 * **潜在影响**: 这看似是一个“无变化”的确认，但实际上，其与新增的Q&A章节共同构成了一个更完整的政策声明。旧版本主要描述了算法“是什么”和“为什么”，而新版本则尝试回答“为什么用户会有困惑”以及“平台声称自己没问题”。这表明平台认为其核心算法的设计逻辑无需调整，问题在于用户对算法运行结果的理解需要“官方解读”。 ### 3. 结论本次更新是一次 **“实质性内容补充”** 而非“算法本身的变更”。滴滴通过新增详尽的“Q&A”章节，显著提升了文件在解答公众核心关切方面的功能，尤其针对算法公平性（杀熟）、价格差异和派单机制等敏感话题给出了官方立场和解释。 **对用户的总体影响是双重的**: 一方面，用户获得了前所未有的、关于平台运作机制的官方解释框架，透明度确实有所提升；另一方面，这些解释本身带有鲜明的立场性和策略性，旨在为现有算法逻辑提供合规性辩护。用户需要保持批判性思维，仔细甄别其中“解释”与“承诺”的区别，例如对“随机”机制的描述是否足够具体，对“沉默用户”优惠的定义是否排除了潜在的偏见。这份文件更多是平台对外沟通的合规性工具，而非一份纯粹的用户权益保障说明书。 --- *分析由 DeepSeek 提供*

删除的内容

新增的内容

修改的内容

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