滴滴推荐上车点功能分析

编辑导语：如今打车变得十分方便，不用在路边拦的士，直接在手机上就可以把车提前叫好；但是这也会有一个问题，有时定位不准让双方都找不到位置，浪费时间的同时也带来了不好的用户体验；本文作者分析了滴滴推荐上车点的功能分析，我们一起来看一下。

下面我将就滴滴推荐上车点的逻辑，以及乘客、司机、平台三个方面来分析“推荐上车点“这个功能，最后会再提出几个我使用下来认为可以提高的点。

一、滴滴推荐上车点逻辑

首先我们要明白这个逻辑里有三个比较重要的地理位置——第一是打车点、第二个是上车点、第三个是推荐上车点。

打车点就是用户打开滴滴平台并开始打车的定位点，上车点是用户实际最终的上车点，推荐上车点是滴滴平台建议用户输入的起始位置。

需要注意的是——打车点并不等于上车点，他们之间很可能是有一段距离的。

（黑色为打车点，红色为推荐上车点）

先来说说推荐上车点的标记，简单来说就是哪些地址应该被标记为推荐上车点呢？

1. 推荐上车点是根据地图数据来进行标记的

这些包括地图里比较重要的一些标志性的点，比如说小区的大门、公交站、大厦门口，或者是一些比较出名的店面等；因为这些点是可以确保一定在路边，车辆可以到达的，并且是广为人知，司机比较好找的；当然要排除一些内部的点，比如说小区内部的1号楼、办公区内部的一些点。

2. 大数据赋能的用户上车点的聚类

滴滴平台会收集某个地域用户输入的上车点的所有历史数据，通过分析这些用户的行为来得出用户之间的相似度，从而来聚类用户，并且聚类他们的上车点成为推荐上车点。

3. 推荐上车点的分发

在哪个范围里的人会被分发到哪个推荐上车点呢？

我觉得滴滴可能是通过每位用户的打车点和实际上车点的地理位置来进行划分的；比如某位用户输入的上车点正好是附近的一个推荐上车点，那以后再有用户在这个位置打车时该推荐上车点就会被分发给这位用户。

因为这是被别的用户验证过的可行的上车点，不会离用户的打车点过远，让用户走一大段路，也不会太难找，因为这是通过聚类无数用户所得到的最佳上车点。

二、乘客

根据俞军老师的用户价值公式，用户价值=（新体验-旧体验）—转换成本

新体验-旧体验——“推荐上车点”这个功能点满足了乘客在哪些场景的哪些需求，解决了哪些痛点？

• 乘客出去旅游的时候，在陌生的地方打车；乘客不知道自己现在所处的地方叫什么名字，因此不知道该在起始位置里输入什么地址。
• 乘客在商场内或者步行街逛街时打车；乘客不知道哪里上下车方便，哪里是禁车区，因此不知道该在起始位置里输入什么地址。
• 乘客赶着上班，并且站在一个标志性建筑物前，很多人在此等着打车；乘客为了省时间不想输入所在地址，想直接输入去哪里后直接打车。

但是在新体验在这些场景带来便利的同时，也在其他一些场景牺牲掉了用户体验；比如，由于出发点已经默认为推荐上车点，用户不需手动填写，也不会有提示跳出来提醒用户检查推荐上车点是否正确；因此，很可能出现上车点与自身位置大而不自知的情况（比如我…）。

此时用户要么一头雾水的去寻找推荐上车点，要么和司机电话沟通新的上车点的位置，要么就是取消订单重新打车。

再者，用户有时在自己非常熟悉的地区打车，他非常清楚自己所在的位置就是最好上车的地方；但是平台却总是用一个并没有那么方便的推荐上车点来做上车位置，这些情况所导致的不便利都有可能导致用户对滴滴平台心生埋怨。

替换成本——由于这只是滴滴平台里一个很小的功能点，我认为乘客的替换成本将无限接近与零；所以在推荐上车点这个功能里我将主要考虑新旧体验的差别，对司机侧同理。

三、司机

司机也是平台的一种用户，同样可以套用用户价值公式

新体验-旧体验——“推荐上车点”这个功能解决了司机的哪些痛点？

• 乘客输入的出发点太难找，比如说小区内部的第几栋楼；明明很近的距离却要绕半天找不到，空载时间长导致司机的效率不高不说，乘客还经常会因为等待而埋怨司机。
• 乘客自定义了上车点，该出发点在地图根本找不到，司机需要花很长时间在电话里跟乘客沟通地点。

在司机侧，推荐上车点的新体验在大多数场景下都是正向的，我能想到的唯一的负面体验就是当乘客误用了推荐上车点作出发位置的情况了；在这种情况下，司机到了推荐上车点后找不到用户，会浪费比较多的时间和用户沟通推荐位置。

四、平台

滴滴作为平台，本质上要做的是撮合司机和乘客之间的交易。

在这个过程中，它可能要关注如下几点：

• 确保“推荐上车点”是可行的，高覆盖度的，清晰的。
• 在设计“推荐上车点”时司乘体验是否平衡。因为司机和乘客是平台同等重要的两端，而他们的利益点既有重叠的部分又有冲突的部分。

对于第一点，在增加这个功能的时候，滴滴平台需要明确这个功能有足够的技术支撑。

首先，所有“推荐上车点”都是可行的，也就是说都是处在打车位置附近，并且都是路边，车辆可到达的地方的；其次，确保这些推荐上车点覆盖住了所有区域，让每个地域范围内都有一个推荐上车点；最后，确保所有推荐上车点都是有认知度的，方便找的。

接下来说说第二点，由上文的分析可以发现，司机对“推荐上车点”这个功能的需求度较强，属于就算没办法帮我提升效率也对我没有不好的影响的存在；但是乘客虽然对这个功能在很多场景下都有需求，但是也有很多时候就是想在打车点上车，不愿意多走几步路至推荐上车点。

因此，为了平衡司乘体验，不牺牲掉太多用户体验，滴滴平台没有强制用户使用推荐上车点，用户还是可以随时修改推荐上车点的；但至于会不会对使用推荐上车点的乘客采取优先派单，甚至价格优惠等激励措施就不得而知了。

五、现存的问题和解决方法

1. 乘客端

1）误以为自己的打车点就是推荐上车点，司机到了推荐上车点后没看见乘客电话沟通过后才发现自己与推荐上车点有一定的距离；经常听到滴滴的用户抱怨滴滴的定位不准确，总是把上车点定在一个离自己很远的地方，让自己走半天才能找到车；司机也常常抱怨到了上车点找不到乘客，打电话沟通过后才得知乘客在另一个地方。

2）乘客不知道该怎么从打车点到达推荐上车点。

针对这两个问题，除了在技术上进行对推荐上车点的进一步优化以外，我觉得在用户点击开始呼叫司机以后可以多一个确认页面，页面会让用户确认是否使用默认的推荐上车点作为上车点；并且显示用户打车点和推荐上车点的距离（比如“您据xxx有100米，预计步行1分钟可到达）；并且目前滴滴是没有从打车点到推荐上车点的路线导航的，我觉得这个导航也可以增加，来辅助用户更加方便的到达推荐上车点，同时也可以提高”推荐上车点“这个功能的使用率。

当然，多一个交互页面也会损失掉一些用户体验，权看如何权衡了。

2. 司机端

推荐上车点是非常好找，但是是在单行道的另一边，需要绕很久的路才能接到乘客。

我自己使用下来对这个问题的感受也非常明显，推荐上车点经常是一些比较好找但是不好停车或者是在单行道司机过来的方向的另一边。

上车以后司机经常和我抱怨说我再走几步到马路的另一边他就可以少绕一大圈，大家都可以省时间，当然他还可以省油钱；或者是有时候会跟在汽车后面跑，因为周围都是交警停不了车。

我个人认为滴滴可以把这些比较细小的因素考虑进“推荐上车点“的设计中，并且更加实时的捕获、更新路网数据；当然，这些改进的方法都是说说容易做起来难，对技术方面的要求会比较高。

 

本文由 @杰西卡 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。