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