“滴滴顺风车”之车主体验与策略思考


时间: 2021-08-03 09:39:03 人气: 12 评论: 0

本文作者结合自己顺风车车主的经历,来谈谈关于滴滴顺风车的车主体验和一些策略思考,一起来看看~

关于滴滴顺风车的一点题外话

滴滴顺风车安全问题,前一阵闹得很大,也很快有相关整改措施出来。有人说根上是在活跃度和交易量的指标压力下,各顺风车平台都为其赋予了社交属性(真人照**、自由评论&标签、聊爽了还可以免单),甚至宣扬美丽邂逅(男女交友、投资人找项目、boss找员工)。

有人替滴滴鸣不平:没有在线约车平台,不良黑车司机犯罪也一直有啊。

这话让我想起了多年前,**针对人们抨击淘宝上售假泛滥时,同样的反击口吻。好的是,淘宝拿出了更有力的措施(大数据预警与追踪、人工稽查团队、更严格的商家管理办法等),虽未杜绝但有了较大改观。

人们对此选择了宽容,毕竟售假丢的只是钱(有时候其实是买卖方你情我愿),而网约车安全隐患丢的是命。作为行业老大的滴滴,确实在安全问题上存在疏忽和不作为。

如果没有之前持续发生的恶性事件,投资人、媒体、大众能容许拿了不菲投资的共享出行平台,为了优先保证安全而牺牲业绩指标吗?

或许不能。滴滴作为该领域的头部公司,以名誉受损、危机公关、(顺风车)停业整顿的方式给行业上了一课。只能说“能力越大,责任越大”。

这方面的文章、观点很多,不想蹭热点,也不在本文讨论之列。

作为一名自驾爱好者,以及有着重度体验嗜好的产品人,偶尔也**在条件允许的情况下拉拉顺风车,体验下“拉活”的感觉,顺便“补贴下家用”。大概出于产品人的职业敏感,尽管到目前仅有35次(拼单算作一次)顺风车车主经历,但对于滴滴顺风车的一些策略、机制,以及产品使用上(app中顺风车模块,或独立顺风车app)的不便,有好多槽想吐。

产品上的“反馈与建议”属于极低频需求,入口藏得深(打开滴滴app主界面——点击左上头像弹出下拉浮层进入“个人中心”——点“客服”进入客服中心——往上拖动页面点击“反馈与建议”进入录入界面),录入不方便,针对“反馈的反馈”也不及时(笔者于2018年5月26日、27日反馈的问题,至今仍显示“未处理”)。

大概外部没有多少人**认真写反馈,内部也没有多少人**认真看反馈。所以借这个平台跟产品同行们一起交流,也希望跟滴滴相关人士有直接的探讨学习。

一、关于顺风车车主的需求分析

排除纯交友目的、纯喜欢开车,专业顺风车拉活外,主流顺风车车主部分静态用户画像如下:

  • 男性居多;
  • 年龄25-45岁为主;
  • 爱驾驶,车技娴熟且自信,方向感好;
  • 出行目的:上下班或城市间通勤,外出商务交往居多;
  • 增加乐趣,避免空驶,顺带挣点外快。

以上几点出自于个人经验判断,有待验证修正。在数据支撑下,可以对车主做一些有意思的分析和研究,从而完善服务,提升业绩。例如:车主活跃度及增减趋势(接单周期&频次)、路线特征、接单金额分析(按城市的排名、人均、车均等)、拼单偏好、接驾准时率、使用系统自动接单比例等。

对顺风车的使用场景进行分析,具有以下特点:

  • 双方对出行的即时性要求不高,是典型的预约型用车市场;
  • 由于是车主接单而非系统派单的方式,成单效率低,往往需要沟通协商。车主占有主动权,处于优势地位;
  • 车主不以此为职业,文化层次/素质相对较高,整体在载客专业性上要比快车/专车司机逊色一些。因车主的兼职身份,平台对其管控力较快车/专车司机弱,存在一定安全隐患;
  • 平台负责规则&资费制定、运营&监管、交易撮合等,通过顺风车方式弥补其他产品(快车、专车)运力不足或服务不了的情况;
  • 平台根据乘客设定的行程起终点距离预先计算费用,车主无法对资费进行操控(快车/专车的不良车主通过绕路、故意低速行驶延长在途时间、提前点击乘客上车/延迟点击乘客送达等方式来增加资费)。

二、关于导航

导航是共享出行很重要的一环,还能记录行车轨迹,偏离既定路线后及时对乘客进行提醒,同时方便不良事件发生后取证。

经实际使用后,有以下优化建议:

(1)拼单时,针对多名乘客的“起点和终点”智能安排全程行车路线,或提供手动组合功能

为方便说明,作如下约定:

实际接送路线策略可能有六种排列组合:

  1. A1—B1—A2—B2
  2. A1—B1—B2—A2
  3. B1—A1—B2—A2
  4. B1—A1—A2—B2
  5. A1—A2—B1—B2
  6. B1—B2—A1—A2

目前系统通过站内信提供接送顺序推荐,也在拼单成功的订单主界面提供乘客一、乘客二的起点终点地图示例。但即使是我这样的“老司机”,偶尔也需要花一定的精力分析下最佳接送顺序,并在行车导航时点选不同乘客TAB页下,操作“导航-乘客起点”、“导航-乘客终点”共4次。

能否增加一个TAB页为总行程预览,系统给出接送顺序推荐。该页面入口点击导航后,系统按“车主起点—途经点1—途经点2—途经点3—某乘客终点”逻辑提交到导航软件中,避免多次繁琐操作,甚至可能导致的误操作(类似高德导航可在起点、终点间设定3个途经点)。

当然,如果存在拼三单的情况,系统能否在6个地点中合理选择接送顺序,以及此功能**给系统带来多大负荷,需要评估。笔者以为,拼两单的情况较为常见,是刚需。

(2)为车主从“起点到目的地”的导航路线策略,提供智能匹配或手动选择

使用高德导航时,通常**提供两到三种路线选择,如下图示例:时间最短、拥堵较少、距离最短。(高德导航中出现过的行车路线策略有:推荐、距离最短、高速较多、收费较少、时间最短、拥堵较少、备选方案X等)

当然,滴滴顺风车模块产品经理可能考虑到,车主在使用滴滴app导航时,“调出订单、选择某拼车乘客、点击导航、点击导航到起点or终点”这些操作,已经有较长路径了。如果在启动第三方导航软件后,还要进行路线选择,**加深操作繁琐程度。所以可能默认按该导航软件中设定的偏好,一键进入导航状态。

这个策略在起点、终点不远或者没有太多选择的情况下问题不大,而一旦距离较远,或涉及到拥堵路段需要绕行,导航的路线多半不够优化。从笔者的使用经验看(跨城),默认路线能到但往往不是最优。建议考虑增加路线策略选择(关于这点,笔者已在几个月前提交过反馈建议)。

(3)乘客地点or终点快速复制功能

乘客可能因为懒、可能是方位感不强、可能是操作不熟练,导致下单的上车位置不准确,尤其是在机场、火车站、大的商场时。这种情况下如果车主简单用滴滴顺风车的“导航到乘客起点”功能,多半**接不上乘客。

所以有经验的司机,通常都**电话确认位置,如果对上车地点不熟悉的话,则**在第三方导航软件中手动输入地点,精确查找上车地点。

建议在订单中乘客的起点、终点位置,增加长按复制功能,便于快速复制到导航软件的目的地中,进行再次编辑或选择。例如:乘客在滴滴中选择起点为“北京南站”,经沟通后上车点确定为“北京南站-地下停车场”,则车主直接复制文字“北京南站”,在高德导航中找到并点击“地下停车场”,这样操作起来非常方便快捷。

如下图所示:

三、关于司乘站内短信与电话

司乘聊天及电话功能非常必要,尤其为了安全和防骚扰,还特别贴心地设计了:电话通过滴滴中转保护双方手机号不被泄露,app内短信在对方回复前只能发3条,接单前只能站内信沟通无法拨通电话等机制。

平台引导的使用习惯是:双方用短信来沟通协商出发时间、确认出发地点,减少电话骚扰;接单后当司机(快要)到达乘客上车起点时(通常是在开车),电话通知比较方便、快捷。

这里笔者发现几点值得优化的地方:

(1)在聊天窗口沟通确认后,车主想要进行接单操作,却发现聊天界面处没有快速下单入口,只能先返回并回到最初的所有行程订单列表页,再去寻找此用户订单,点击“确认同行”。

此时往往可能发生如下状况:

  • 因虚拟头像一样而混淆,不得不再退回聊天界面进一步确认用户名,或是确认起点终点;
  • 此订单被新订单露出而挤到后面几屏,订单顺序也被打乱;
  • 因为操作麻烦而贻误商机,被其他车主抢单。后续要么车主放弃此单,要么乘客取消重新下单等待约定好的司机接单。

(2)快捷回复短语为操作带来了方便,但在实际使用中,因备选短语列表占用屏幕面积较大,而且操作设定是一碰就发出去了,容易造成误发消息(笔者有几次都是碰到“早点出发”、“晚点出发”这样的短语,之后赶紧“撤回”)。

建议评估下是否可缩小短语列表高度,另发送机制做一下调整:点选短语后自动读入“请输入内容… …”框,再点确认(或发送)后发出。

这里还可以对该快捷短语做再次编辑,我经常**一步到位,直接问诸如“您好,4点30可以出发吗?”(举例:乘客发布5点出发)这样直截了当的问题。当然,我只代表一部分用户。

下图为聊天窗口示例:

(3)关于“号码保护”的说明

车主接单后,司乘可互拨电话,无论是车主打给乘客,还是乘客打给车主,都**被滴滴以中间号的形式隐藏原手机号,从而保护用户隐私,防止可能的后期骚扰。

在实际使用中发现,乘客拨过来的电话,经过滴滴号码保护后显示的中转号,大多被标注为“出租车”之类。而乘客如果接到车主标注为“出租车”的来电,也**诧异和犹豫,有时候要拨打好几次才接听(亲身经历)。

滴滴在这一块要有更多的普及教育,除了提示外拨**保护手机号不被泄露,还要对来电可能**被标记为“出租车”之类做提醒。这样才能让司乘(车主大多明白,乘客担心的多)放心地拨打和接听电话,让沟通更顺畅。

四、关于顺路程度百分比的理解与计算

笔者对顺路的朴素理解为:接送人增加的里程(绕路里程),与原有既定路线的里程相比,比值越低则顺路程度越高。

如果用公式表示,则为:

顺路百分比 = 1 – 绕路里程/原有里程

下面笔者选用一个真实案例做一下校验,下图是系统智能排序推荐的“95%顺路”行程订单截图。图中我们看到,排第一位的这个行程,司乘起点距离为11.3KM,司乘终点距离为40.9KM。

按笔者对顺路的定义及公式,计算如下:

(1)起点绕路(数据来源PC版高德地图)

说明:无论是否接单乘客二,途中必经“京津塘高速金钟河收费站”。

滴滴行程订单中计算司乘起点距离为11.3公里,实际起点绕路里程计算如下:

X1 = 司乘起点距离13.9公里(因司乘起点均为手动输入小区名称,另有多条导航路线选择,这里与滴滴提示11.3公里有差异);

X2 = 乘客起点到金钟河距离9.2公里;

X3 = 司机起点到金钟河距离为9.7公里。

起点绕路里程为:X1 + X2 – X3 = 13.9 + 9.2 – 9.7 = 13.4公里。

(2)终点绕路(数据来源PC版高德地图)

说明:

  • 无论是否接单乘客二,途中必经“乘客一终点”;
  • 通过高德导航显示终点间相距里程与上面方法类似,截图略。

滴滴行程订单中计算司乘终点距离为40.9公里。实际终点绕路里程计算如下:

Y1 = 乘客一与乘客二终点距离(经高德导航查询54.9公里);

Y2 = 乘客二与司机终点距离(经高德导航查询40.4公里,与滴滴提示40.9公里稍有差异);

Y3 = 乘客一与司机终点距离(经高德导航查询26公里)。

终点绕路里程为:Y1 + Y2 – Y3 = 54.9 + 40.4 – 26 = 69.3公里。

(3)顺路程度计算

  • 笔者自有起点与终点导航里程为135公里左右;
  • 已接单乘客一增加的公里数假设15公里(按个人接单惯例不****过这个数);
  • 因为接单乘客二增加的公里数,即上面起点、终点分别绕路公里数之和82.7公里(13.4 + 69.3 = 82.7公里)。

综上:接乘客一后行驶总里程为150公里,为了接乘客二需要多绕行82.7公里。

因此,接送乘客二的顺路百分比,经计算为44.9%(1 – 82.7/150 = 44.9%),与系统给的提示95%顺路相差甚远。

从我个人使用感受来看,滴滴的顺路百分比不稳定,大部分时候还是比较准的。建议在车主端,为高质量车主账户增加关于“顺路百分比不准”的提交入口,方便获取一手数据,来改进算法。

(4)局限性

笔者的构想存在两个关键点:必经点;绕路里程。

存在以下局限性:

  1. 示例中两个必经点都是人为选择,如何在海量数据下实现机器自动选取?
  2. 起点和终点的绕路里程,需要必经点与对应司乘地点的2组3个导航里程(共6个数据)计算。运算量较大,系统是否支撑?是否值得这么做?是否有其他变通的简易计算方法?

因本人非GIS专业出身,以上构想是否合理并能(方便)实现,还有待专家们共同探讨。笔者以为,以下四种情况视为比较顺路,应具有较高的百分比。

无论何种算法,都可以据此取点计算验证:

  1. 司乘起点距离W1、终点距离W2分别在3公里以内(或者W1、W2之和,与司机原有路线既定里程相比,占比较低);
  2. 乘客的起点和终点,在司机原有路线途中,且绕路偏离在一定公里数之内;
  3. 乘客起点在司机原有路线途中(或偏离不远),司乘终点距离W2为3公里以内(或W2与司机原有路线既定里程相比,占比较低);
  4. 司乘起点距离W1为3公里以内(或W1与司机原有路线既定里程相比,占比较低),乘客终点在司机原有路线途中(或偏离不远)。

针对上面第1种情况的示例图如下:

示例图说明:

  • 司机原有行程:北京大学东门——》朝阳公园东门(导航部分截图来自PC版搜狗地图);
  • 乘客起点在“北京大学东门”3公里以内(实际为行驶公里数,这里用圆半径简化);
  • 乘客终点在“朝阳公园东门”3公里以内(实际为行驶公里数,这里用圆半径简化)。

五、关于司乘两端行程订单的时间发布规则,及匹配机制研究

如何让车主与乘客的行程订单,充分表达出各自出行需求(出发和到达的时间要求、是否拼单、是否高速等),同时易于双方的查看、判断,快速选择,即“供需匹配”问题,往小了说影响单个司乘的订单产品使用&服务体验,往大了说影响整个平台的成单量&满意度。

从笔者的实际使用及角色模拟思考,目前在行程订单的时间相关参数上,还可以做一些优化和探索。

1. 司乘两端行程订单发布,现有时间规则解读

(1)乘客

1)跨城订单——两个时间点:最早出发时间、最晚出发时间。

跨城出行,乘客没有那么急迫,(顺路)司机也少,因此出发时间宽泛一些,以便匹配更多的司机。

2)市内/郊区县订单——出发时间、是否愿等15分钟(勾选项)

市内/郊区县出行,乘客出发时间明确、里程短。其下单方式与叫出租车、叫快车的习惯保持一致。通过“愿等15分钟”的勾选项,筛选出那些不是特别急迫的乘客订单,从而有更多的车主行程订单与之匹配。

(2)车主

只有一个时间点,即:车主出发时间。因为车在车主手上,他是能够且必须明确出发时间的。

下图为乘客的同城、跨城订单,在车主端的不同展示。

2. 司乘两端-最优行程订单探讨

(1)对乘客来说,什么样的车主订单是“好订单”

  • 更顺路:顺路百分比高,意味着车主接单意愿更强,主动邀约成功率更高。
  • 更早出发:预估到达乘客起点时间(“车主出发时间” + 导航到乘客起点耗时),在“乘客(最早)出发时间”之前越接近越好。意味着乘客不用等,车主等待少(车主更愿意接单)。
  • 司乘起点更近:乘客出发时间与当前时间间隔较长时,只要司机能尽早赶到,司乘起点距离参考意义不大。只有出发时间与当前时间间隔较短时(立即出行),司乘起点距离才更有意义,对乘客与车主互相邀约有促进作用。

以上三点,可作为乘客端-车主行程订单“默认排序”(只有这一种排序)算法的重要参考因子。

(2)对车主来说,什么样的乘客订单是“好订单”

  • 更顺路:顺路百分比高,意味着绕路里程越少,额外耗时短、耗油少。
  • 更高金额:通常是距离远、乘客人数多,或者能拼单。
  • 不用等or等待少:“乘客(最早)出发时间”,在预估车主到达乘客起点时间(“车主出发时间” + 导航到乘客起点耗时)之前,越接近越好。意味着车主不用等,乘客等待少。

以上三点,可作为车主端-乘客行程订单“智能排序”算法的重要参考因子。

3. 司乘两端发布行程订单时的时间项改进探讨

(1)乘客

市内/郊区县

与现有规则保持一致。

跨城

  • 最早出发时间(必填项);
  • 最晚到达时间(必填项)。

输入时系统需判断,两时间点间隔时长,大于起点&终点导航预估时长。

目前规则设定“最晚出发时间”,也是基于现实考虑:虽然乘客坐顺风车不是很急迫,而且时间不可控,但乘客心里总得预估有个时间点我必须出发了(最晚出发时间)。

而顺风车的特点是:司机到达时间不可控,实际在途时间不可控,如果拼单另一乘客时间也不可控,等等。各种因素叠加,这个“最晚出发时间”是否有效,是否达到乘客最终抵达终点的时间预期,值得考量。

这里引入“最晚到达时间”这个参数,则更加科学地表明乘客诉求:多晚走不重要,只要能保证多晚前能到,而且越早出发越好。而通过计算车主抵达起点时间,通过导航预估送达乘客终点的时间,就能够与“最晚到达时间”去比对,并作为行程订单排序的重要因子。

(2)车主

  • 出发时间(必填项);
  • 最晚到达时间(选填项)。

不填即默认车主时间充裕,多晚到都行,输入时系统需判断,两时间点间隔时长,大于车主起点&终点导航预估时长。

平台规则设计者,更多考虑的是乘客的时间诉求(最早出发时间、最晚出发时间),车主发布的“出发时间”也是以匹配乘客需求为出发点的。如果真的从车主角度考虑,多一些关怀,就**发现:顺风车车主不是对时间没有要求,只是有一定宽容度罢了

因此他一定**有两个时间诉求:

  1. 可最早出发时间;
  2. 可接受最晚到达个人目的地时间。

我们不能寄希望于每位车主都能预估好在途时间,尤其是在目前“顺路百分比”偶尔失常(朴素理解顺路意味着路上耽误时间少),拼单时至少两组乘客上车等待时间非完全可控等情况下。

车主“最晚到达时间”参数的引入,对那些有一定时间要求的顺风车车主非常有用,能够通过设定条件帮助其筛选。滴滴也无需担心**减少展示的订单数,只需优先展示满足时间设定的订单,预估**过车主设定的“最晚到达时间”,标注类似“预估晚到*小时*分钟”即可。

4. 司乘两端订单列表优化示例

(1)乘客端

针对每一个车主订单,增加了车主到达起点和送达终点时间(标**处),从而帮助乘客判断是否主动发起邀约。

下图说明:顺路程度一致情况下,车主虽然晚出发但因为隔得近,到达起点早,所以排在前面(为示例截图中出发时间、相隔公里数均有调整)。

(2)车主端

假设车主设定行程为:

  • 出发时间:今天15:55
  • 最晚到达时间:今天19:00

针对每一个乘客订单,增加了车主到达乘客起点,以及车主送完乘客后到达个人终点时间(标**处),从而帮助车主判断,方便下单。

目前的做法是:点开订单详情后,展示地图预览,并在地图上提示到达乘客起点需要多长时间(图略),不够直观和方便。

下图示例排序规则解读为:对车主来说,顺路程度一致的情况下,即使司乘距离远(后到达乘客起点),即使金额少,将符合“最晚到达时间”的订单排在前面。

为使读者对“最晚到达时间”有直观理解,特对此案例的两位乘客终点及车主终点地理位置截图如下。

通过截图可以很清晰地看出:

  • 目前滴滴关于顺路百分比的算法,需要重新审视和优化(前文已有论述);
  • 当顺路百分比一致或相近时,可以通过优先排序估算的“车主抵达个人终点”时间来帮助筛选,并将**出设定最晚到达时间的订单往后排。

六、“车主端”乘客行程订单列表展示逻辑研究

目前在乘客端,按系统默认规则展示车主订单排序(图略),不提供其他订单筛选逻辑设置。细想也是合理的:乘客只能决定自己的行程,通常对方位、距离不够敏感,而且不能主动接单。

车主端的乘客行程列表,如上图所示提供了5种排序规则:智能排序(默认)、出发时间最早、距起点最近、价格最高、拼座优先

笔者的观点如下:

(1)“出发时间最早”与“距起点最近”

  • “出发时间最早”并不能保证车主送完乘客后,到达个人终点更早。还取决于顺路程度,是否拼单等等。但车主往往有习惯性理解,早出发好。
  • “距起点最近”也不能保证顺路百分比高,或者最终完成送达乘客的时间短。这只是一种车主挑选乘客的习惯:貌似可以早出发(还取决于乘客出发时间),另外对周边地理位置更熟悉(有了智能导航后,不熟悉的地方也基本不是问题)。

这两个维度,车主可能**经常用或者说很依赖,尤其是当“智能排序”不够智能,不能很好地帮助车主筛选订单的时候,是一个很好的补充。

(2)“价格最高”与“拼座优先”

  • 价格高的订单,往往绕路里程较多。从现有订单展示规则来看,就是起点、终点间隔里程远。有多少顺风车车主,是只看价格不看里程的(顺路百分比)?如果还需要不断往下**屏再筛选订单,则说明这条排序规则意义不大。希望滴滴内部可以跟踪下数据,通过这个规则进入并成功下单的比例有多少。
  • 选择“拼座优先”,则需要根据2组不同的起点、终点位置,以及出行时间做出判断是否适合拼单,其实难度不小。系统提供的“自动拼单”,以及成单(愿拼座)以后的“再拼一单”功能,是选择拼座订单的易用操作方法。

本质上,两者都是为了多赚钱。“价格最高”是通过挑选乘客多、路程远的订单多赚钱, “拼座”则是通过在一趟行程中多拉订单多赚钱。这两种方式看似增加了筛选方法,实则增加了选择难度,笔者建议砍掉。

其实在“智能排序”规则中,顺路百分比高且金额高的订单(优先列出“顺路的价格高的非拼座订单”、后列出“顺路的拼座订单”),已经排在前列了。

(3)建议增加筛选维度“整体用时最少”

即:车主完成乘客送达后,能够最早抵达自己的目的地。当车主行程比较赶时,**根据自己设定的“最晚到达时间”来查看是否来得及拉一单顺风车。

这时,最重要的考量标准是时间。而不是金额,也不完全是顺路百分比(有时候顺路百分比高,但可能因为拥堵路段而造成里程少用时长的情况)。

综上,建议提供如下4种排序规则即可:智能排序(默认)、出发时间最早、距起点最近、整体用时最少

 

本文由 @ 谭翀 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自网络

给作者打赏,鼓励TA抓紧创作!
6人打赏
---蛙鱼源码WAYUYM.COM---专业提供网站模板,网站源码下载,教程培训,程序插件,网站素材等建站资源,主要收集各类精品源码资源,包含CMS程序模板、网站源码、游戏源码、APP源码等 ,所有资源都没有水印适合搬运,我们致力于打造一个优秀的建站资源共享学习平台!

专业厂家,设备先进,技术力量雄厚,自动化生产技术先进,产品质量符合国家标准,价格合理,https://www.69shenlan.com/,具有质量保证,生产及时,交货快捷的特点。 我们的宗旨:做我们擅长的事,希望用我们的创意和创意为客户实现战略定位,塑造品牌,强化形象!
我们的要求:坚持“优质产品、优质服务、优惠价格、快速交货”的经营方针,努力开拓市场,真诚为客户服务! 我们的发展:以独特的专业和专业精神,https://www.69shenlan.com/1:1--

3年

评论