编辑导语：如今打车变得十分便利，不消在路边拦的士，直接在手机上就可以把车提前叫好；然则这也会有一个问题，有时定位不准让两边都找不到地位，浪费时光的同时也带来了不好的用户体验；本文作者分析了滴滴推荐上车点的功能分析，我们一路来看一下。
下面我姑息滴滴推荐上车点的逻辑，以及乘客、司机、平台三个方面来分析“推荐上车点“这个功能，最后会再提出几个我应用下来认为可以进步的点。
一、滴滴推荐上车点逻辑
起首我们要明白这个逻辑里有三个比较重要的地舆地位??第一是打车点、第二个是上车点、第三个是推荐上车点。
打车点就是用户打开滴滴平台并开端打车的定位点，上车点是用户实际最终的上车点，推荐上车点是滴滴平台建议用户输入的肇端地位。
须要留意的是??打车点并不等于上车点，他们之间很可能是有一段距离的。
（黑色为打车点，红色为推荐上车点）
先来说说推荐上车点的标记，简单来说就是哪些地址应当被标记为推荐上车点呢？
1. 推荐上车点是根据地图数据来进行标记的
这些包含地图里比较重要的一些标记性的点，比如说小区的大年夜门、公交站、大年夜厦门口，或者是一些比较出名的店面等；因为这些点是可以确保必定在路边，车辆可以达到的，并且是广为人知，司机比较好找的；当然要清除一些内部的点，比如说小区内部的1号楼、办公区内部的一些点。
2. 大年夜数据赋能的用户上车点的聚类
滴滴平台会收集某个地区用户输入的上车点的所有汗青数据，经由过程分析这些用户的行动来得出用户之间的类似度，从而来聚类用户，并且聚类他们的上车点成为推荐上车点。
3. 推荐上车点的分发
在哪个范围里的人会被分发到哪个推荐上车点呢？
我认为滴滴可能是经由过程每位用户的打车点和实际上车点的地舆地位来进行划分的；比如某位用户输入的上车点正好是邻近的一个推荐上车点，那今后再有效户在这个地位打车时该推荐上车点就会被分发给这位用户。
因为这是被其余用户验证过的可行的上车点，不会离用户的打车点过远，让用户走一大年夜段路，也不会太难找，因为这是经由过程聚类无数用户所获得的最佳上车点。
二、乘客
根据俞军师长教师的用户价值公式，用户价值=（新体验-旧体验）?转换成本
新体验-旧体验??“推荐上车点”这个功能点知足了乘客在哪些场景的哪些需求，解决了哪些痛点？
- 乘客出去旅游的时刻，在陌生的处所打车；乘客不知道本身如今所处的处所叫什么名字，是以不知道该在肇端地位里输入什么地址。
- 乘客在商场内或者步行街逛街时打车；乘客不知道哪里高低车便利，哪里是禁车区，是以不知道该在肇端地位里输入什么地址。
- 乘客赶着上班，并且站在一个标记性建筑物前，很多人在此等着打车；乘客为了省时光不想输入地点地址，想直接输入去哪里后直接打车。
然则在新体验在这些场景带来便利的同时，也在其他一些场景就义掉落了用户体验；比如，因为出发点已经默认为推荐上车点，用户不需手动填写，也不会有提示跳出来提示用户检查推荐上车点是否精确；是以，很可能出现上车点与自身地位大年夜而不自知的情况（比如我…）。
此时用户要么一头雾水的去寻找推荐上车点，要么和司机德律风沟通新的上车点的地位，要么就是撤消订单从新打车。
再者，用户有时在本身异常熟悉的地区打车，他异常清楚本身地点的地位就是最好上车的处所；然则平台却老是用一个并没有那么便利的推荐上车点来做上车地位，这些情况所导致的不便利都有可能导致用户对滴滴平台心生抱怨。
调换成本??因为这只是滴滴平台里一个很小的功能点，我认为乘客的调换成本将无穷接近与零；所以在推荐上车点这个功能里我将重要推敲新旧体验的差别，对司机侧同理。
三、司机
司机也是平台的一种用户，同样可以套用用户价值公式
新体验-旧体验??“推荐上车点”这个功能解决了司机的哪些痛点？
- 乘客输入的出发点太难找，比如说小区内部的第几栋楼；明明很近的距离却要绕半天找不到，空载时光长导致司机的效力不高不说，乘客还经常会因为等待而抱怨司机。
- 乘客自定义了上车点，该出发点在地图根本找不到，司机须要花很长时光在德律风里跟乘客沟通地点。
在司机侧，推荐上车点的新体验在大年夜多半场景下都是正向的，我能想到的独一的负面体验就是当乘客误用了推荐上车点作出发地位的情况了；在这种情况下，司机到了推荐上车点后找不到用户，会浪费比较多的时光和用户沟通推荐地位。
四、平台
滴滴作为平台，本质上要做的是撮合司机和乘客之间的交易。
在这个过程中，它可能要存眷如下几点：
- 确保“推荐上车点”是可行的，高覆盖度的，清楚的。
- 在设计“推荐上车点”时司乘体验是否均衡。因为司机和乘客是平台一致重要的两端，而他们的好处点既有重叠的部分又有冲突的部分。
对于第一点，在增长这个功能的时刻，滴滴平台须要明白这个功能有足够的技巧支撑。
起首，所有“推荐上车点”都是可行的，也就是说都是处在打车地位邻近，并且都是路边，车辆可达到的处所的；其次，确保这些推荐上车点覆盖住了所有区域，让每个地区范围内都有一个推荐上车点；最后，确保所有推荐上车点都是有认知度的，便利找的。
接下来说说第二点，由上文的分析可以发明，司机对“推荐上车点”这个功能的需求度较强，属于就算没办法帮我晋升效力也对我没有不好的影响的存在；然则乘客固然对这个功能在很多场景下都有需求，然则也有很多时刻就是想在打车点上车，不肯意多走几步路至推荐上车点。
是以，为了均衡司乘体验，不就义掉落太多用户体验，滴滴平台没有强迫用户应用推荐上车点，用户照样可以随时修改推荐上车点的；但至于会不会对应用推荐上车点的乘客采取优先派单，甚至价格优惠等鼓励办法就不得而知了。
五、现存的问题和解决办法 1. 乘客端
1）误认为本身的打车点就是推荐上车点，司机到了推荐上车点后没看见乘客德律风沟经由过程后才发明本身与推荐上车点有必定的距离；经常听到滴滴的用户抱怨滴滴的定位不精确，老是把上车点定在一个离本身很远的处所，让本身走半天才能找到车；司机也经常抱怨到了上车点找不到乘客，打德律风沟经由过程后才得知乘客在另一个处所。
2）乘客不知道该怎么从打车点达到推荐上车点。
针对这两个问题，除了在技巧长进行对推荐上车点的进一步优化以外，我认为在用户点击开端呼叫司机今后可以多一个确认页面，页面会让用户确认是否应用默认的推荐上车点作为上车点；并且显示用户打车点和推荐上车点的距离（比如“您据xxx有100米，估计步行1分钟可达到）；并且今朝滴滴是没有从打车点到推荐上车点的路线导航的，我认为这个导航也可以增长，来帮助用户加倍便利的达到推荐上车点，同时也可以进步”推荐上车点“这个功能的应用率。
当然，多一个交互页面也会损掉掉落一些用户体验，权看若何衡量了。
2. 司机端
推荐上车点是异常好找，然则是在单行道的另一边，须要绕良久的路才能接到乘客。
我本身应用下来对这个问题的感触感染也异常明显，推荐上车点经常是一些比较好找然则不好泊车或者是在单行道司机过来的偏向的另一边。
上车今后司机经常和我抱怨说我再走几步到马路的另一边他就可以少绕一大年夜圈，大年夜家都可以省时光，当然他还可以省油钱；或者是有时刻会跟在汽车后面跑，因为四周都是交警停不了车。
我小我认为滴滴可以把这些比较渺小的身分推敲进“推荐上车点“的设计中，并且加倍及时的捕获、更新路网数据；当然，这些改进的办法都是说说轻易做起来难，对技巧方面的请求会比较高。
本文由 @杰西卡 原创宣布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协定。
