本文作者结合自己顺风车车主的经历，来谈谈关于滴滴顺风车的车主体验和一些策略思考，一起来看看~
关于滴滴顺风车的一点题外话
滴滴顺风车安全问题，前一阵闹得很大，也很快有相关整改措施出来。有人说根上是在活跃度和交易量的指标压力下，各顺风车平台都为其赋予了社交属性（真人照片、自由评论&标签、聊爽了还可以免单），甚至宣扬美丽邂逅（男女交友、投资人找项目、boss找员工）。
有人替滴滴鸣不平：没有在线约车平台，不良黑车司机犯罪也一直有啊。
这话让我想起了多年前，马云针对人们抨击淘宝上售假泛滥时，同样的反击口吻。好的是，淘宝拿出了更有力的措施（大数据预警与追踪、人工稽查团队、更严格的商家管理办法等），虽未杜绝但有了较大改观。
人们对此选择了宽容，毕竟售假丢的只是钱（有时候其实是买卖方你情我愿），而网约车安全隐患丢的是命。作为行业老大的滴滴，确实在安全问题上存在疏忽和不作为。
如果没有之前持续发生的恶性事件，投资人、媒体、大众能容许拿了不菲投资的共享出行平台，为了优先保证安全而牺牲业绩指标吗？
或许不能。滴滴作为该领域的头部公司，以名誉受损、危机公关、（顺风车）停业整顿的方式给行业上了一课。只能说“能力越大，责任越大”。
这方面的文章、观点很多，不想蹭热点，也不在本文讨论之列。
作为一名自驾爱好者，以及有着重度体验嗜好的产品人，偶尔也会在条件允许的情况下拉拉顺风车，体验下“拉活”的感觉，顺便“补贴下家用”。大概出于产品人的职业敏感，尽管到目前仅有35次（拼单算作一次）顺风车车主经历，但对于滴滴顺风车的一些策略、机制，以及产品使用上（app中顺风车模块，或独立顺风车app）的不便，有好多槽想吐。
产品上的“反馈与建议”属于极低频需求，入口藏得深（打开滴滴app主界面——点击左上头像弹出下拉浮层进入“个人中心”——点“客服”进入客服中心——往上拖动页面点击“反馈与建议”进入录入界面），录入不方便，针对“反馈的反馈”也不及时（笔者于2018年5月26日、27日反馈的问题，至今仍显示“未处理”）。
大概外部没有多少人会认真写反馈，内部也没有多少人会认真看反馈。所以借这个平台跟产品同行们一起交流，也希望跟滴滴相关人士有直接的探讨学习。
一、关于顺风车车主的需求分析
排除纯交友目的、纯喜欢开车，专业顺风车拉活外，主流顺风车车主部分静态用户画像如下：
- 男性居多；
- 年龄25-45岁为主；
- 爱驾驶，车技娴熟且自信，方向感好；
- 出行目的：上下班或城市间通勤，外出商务交往居多；
- 增加乐趣，避免空驶，顺带挣点外快。
以上几点出自于个人经验判断，有待验证修正。在数据支撑下，可以对车主做一些有意思的分析和研究，从而完善服务，提升业绩。例如：车主活跃度及增减趋势（接单周期&频次）、路线特征、接单金额分析（按城市的排名、人均、车均等）、拼单偏好、接驾准时率、使用系统自动接单比例等。
对顺风车的使用场景进行分析，具有以下特点：
- 双方对出行的即时性要求不高，是典型的预约型用车市场；
- 由于是车主接单而非系统派单的方式，成单效率低，往往需要沟通协商。车主占有主动权，处于优势地位；
- 车主不以此为职业，文化层次/素质相对较高，整体在载客专业性上要比快车/专车司机逊色一些。因车主的兼职身份，平台对其管控力较快车/专车司机弱，存在一定安全隐患；
- 平台负责规则&资费制定、运营&监管、交易撮合等，通过顺风车方式弥补其他产品（快车、专车）运力不足或服务不了的情况；
- 平台根据乘客设定的行程起终点距离预先计算费用，车主无法对资费进行操控（快车/专车的不良车主通过绕路、故意低速行驶延长在途时间、提前点击乘客上车/延迟点击乘客送达等方式来增加资费）。
二、关于导航
导航是共享出行很重要的一环，还能记录行车轨迹，偏离既定路线后及时对乘客进行提醒，同时方便不良事件发生后取证。
经实际使用后，有以下优化建议：
（1）拼单时，针对多名乘客的“起点和终点”智能安排全程行车路线，或提供手动组合功能
为方便说明，作如下约定：
实际接送路线策略可能有六种排列组合：
- A1—B1—A2—B2
- A1—B1—B2—A2
- B1—A1—B2—A2
- B1—A1—A2—B2
- A1—A2—B1—B2
- 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）局限性
笔者的构想存在两个关键点：必经点；绕路里程。
存在以下局限性：
- 示例中两个必经点都是人为选择，如何在海量数据下实现机器自动选取？
- 起点和终点的绕路里程，需要必经点与对应司乘地点的2组3个导航里程（共6个数据）计算。运算量较大，系统是否支撑？是否值得这么做？是否有其他变通的简易计算方法？
因本人非GIS专业出身，以上构想是否合理并能（方便）实现，还有待专家们共同探讨。笔者以为，以下四种情况视为比较顺路，应具有较高的百分比。
无论何种算法，都可以据此取点计算验证：
- 司乘起点距离W1、终点距离W2分别在3公里以内（或者W1、W2之和，与司机原有路线既定里程相比，占比较低）；
- 乘客的起点和终点，在司机原有路线途中，且绕路偏离在一定公里数之内；
- 乘客起点在司机原有路线途中（或偏离不远），司乘终点距离W2为3公里以内（或W2与司机原有路线既定里程相比，占比较低）；
- 司乘起点距离W1为3公里以内（或W1与司机原有路线既定里程相比，占比较低），乘客终点在司机原有路线途中（或偏离不远）。
针对上面第1种情况的示例图如下：
示例图说明：
- 司机原有行程：北京大学东门——》朝阳公园东门（导航部分截图来自PC版搜狗地图）；
- 乘客起点在“北京大学东门”3公里以内（实际为行驶公里数，这里用圆半径简化）；
- 乘客终点在“朝阳公园东门”3公里以内（实际为行驶公里数，这里用圆半径简化）。
五、关于司乘两端行程订单的时间发布规则，及匹配机制研究
如何让车主与乘客的行程订单，充分表达出各自出行需求（出发和到达的时间要求、是否拼单、是否高速等），同时易于双方的查看、判断，快速选择，即“供需匹配”问题，往小了说影响单个司乘的订单产品使用&服务体验，往大了说影响整个平台的成单量&满意度。
从笔者的实际使用及角色模拟思考，目前在行程订单的时间相关参数上，还可以做一些优化和探索。
1. 司乘两端行程订单发布，现有时间规则解读
（1）乘客
1）跨城订单——两个时间点：最早出发时间、最晚出发时间。
跨城出行，乘客没有那么急迫，（顺路）司机也少，因此出发时间宽泛一些，以便匹配更多的司机。
2）市内/郊区县订单——出发时间、是否愿等15分钟（勾选项）
市内/郊区县出行，乘客出发时间明确、里程短。其下单方式与叫出租车、叫快车的习惯保持一致。通过“愿等15分钟”的勾选项，筛选出那些不是特别急迫的乘客订单，从而有更多的车主行程订单与之匹配。
（2）车主
只有一个时间点，即：车主出发时间。因为车在车主手上，他是能够且必须明确出发时间的。
下图为乘客的同城、跨城订单，在车主端的不同展示。
2. 司乘两端-最优行程订单探讨
（1）对乘客来说，什么样的车主订单是“好订单”
- 更顺路：顺路百分比高，意味着车主接单意愿更强，主动邀约成功率更高。
- 更早出发：预估到达乘客起点时间（“车主出发时间” 导航到乘客起点耗时），在“乘客（最早）出发时间”之前越接近越好。意味着乘客不用等，车主等待少（车主更愿意接单）。
- 司乘起点更近：乘客出发时间与当前时间间隔较长时，只要司机能尽早赶到，司乘起点距离参考意义不大。只有出发时间与当前时间间隔较短时（立即出行），司乘起点距离才更有意义，对乘客与车主互相邀约有促进作用。
以上三点，可作为乘客端-车主行程订单“默认排序”（只有这一种排序）算法的重要参考因子。
（2）对车主来说，什么样的乘客订单是“好订单”
- 更顺路：顺路百分比高，意味着绕路里程越少，额外耗时短、耗油少。
- 更高金额：通常是距离远、乘客人数多，或者能拼单。
- 不用等or等待少：“乘客（最早）出发时间”，在预估车主到达乘客起点时间（“车主出发时间” 导航到乘客起点耗时）之前，越接近越好。意味着车主不用等，乘客等待少。
以上三点，可作为车主端-乘客行程订单“智能排序”算法的重要参考因子。
3. 司乘两端发布行程订单时的时间项改进探讨
（1）乘客
市内/郊区县
与现有规则保持一致。
跨城
- 最早出发时间（必填项）；
- 最晚到达时间（必填项）。
输入时系统需判断，两时间点间隔时长，大于起点&终点导航预估时长。
目前规则设定“最晚出发时间”，也是基于现实考虑：虽然乘客坐顺风车不是很急迫，而且时间不可控，但乘客心里总得预估有个时间点我必须出发了（最晚出发时间）。
而顺风车的特点是：司机到达时间不可控，实际在途时间不可控，如果拼单另一乘客时间也不可控，等等。各种因素叠加，这个“最晚出发时间”是否有效，是否达到乘客最终抵达终点的时间预期，值得考量。
这里引入“最晚到达时间”这个参数，则更加科学地表明乘客诉求：多晚走不重要，只要能保证多晚前能到，而且越早出发越好。而通过计算车主抵达起点时间，通过导航预估送达乘客终点的时间，就能够与“最晚到达时间”去比对，并作为行程订单排序的重要因子。
（2）车主
- 出发时间（必填项）；
- 最晚到达时间（选填项）。
不填即默认车主时间充裕，多晚到都行，输入时系统需判断，两时间点间隔时长，大于车主起点&终点导航预估时长。
平台规则设计者，更多考虑的是乘客的时间诉求（最早出发时间、最晚出发时间），车主发布的“出发时间”也是以匹配乘客需求为出发点的。如果真的从车主角度考虑，多一些关怀，就会发现：顺风车车主不是对时间没有要求，只是有一定宽容度罢了。
因此他一定会有两个时间诉求：
- 可最早出发时间；
- 可接受最晚到达个人目的地时间。
我们不能寄希望于每位车主都能预估好在途时间，尤其是在目前“顺路百分比”偶尔失常（朴素理解顺路意味着路上耽误时间少），拼单时至少两组乘客上车等待时间非完全可控等情况下。
车主“最晚到达时间”参数的引入，对那些有一定时间要求的顺风车车主非常有用，能够通过设定条件帮助其筛选。滴滴也无需担心会减少展示的订单数，只需优先展示满足时间设定的订单，预估超过车主设定的“最晚到达时间”，标注类似“预估晚到*小时*分钟”即可。
4. 司乘两端订单列表优化示例
（1）乘客端
针对每一个车主订单，增加了车主到达起点和送达终点时间（标黄处），从而帮助乘客判断是否主动发起邀约。
下图说明：顺路程度一致情况下，车主虽然晚出发但因为隔得近，到达起点早，所以排在前面（为示例截图中出发时间、相隔公里数均有调整）。
（2）车主端
假设车主设定行程为：
针对每一个乘客订单，增加了车主到达乘客起点，以及车主送完乘客后到达个人终点时间（标黄处），从而帮助车主判断，方便下单。
目前的做法是：点开订单详情后，展示地图预览，并在地图上提示到达乘客起点需要多长时间（图略），不够直观和方便。
下图示例排序规则解读为：对车主来说，顺路程度一致的情况下，即使司乘距离远（后到达乘客起点），即使金额少，将符合“最晚到达时间”的订单排在前面。
为使读者对“最晚到达时间”有直观理解，特对此案例的两位乘客终点及车主终点地理位置截图如下。
通过截图可以很清晰地看出：
- 目前滴滴关于顺路百分比的算法，需要重新审视和优化（前文已有论述）；
- 当顺路百分比一致或相近时，可以通过优先排序估算的“车主抵达个人终点”时间来帮助筛选，并将超出设定最晚到达时间的订单往后排。
六、“车主端”乘客行程订单列表展示逻辑研究
目前在乘客端，按系统默认规则展示车主订单排序（图略），不提供其他订单筛选逻辑设置。细想也是合理的：乘客只能决定自己的行程，通常对方位、距离不够敏感，而且不能主动接单。
车主端的乘客行程列表，如上图所示提供了5种排序规则：智能排序（默认）、出发时间最早、距起点最近、价格最高、拼座优先。
笔者的观点如下：
（1）“出发时间最早”与“距起点最近”
- “出发时间最早”并不能保证车主送完乘客后，到达个人终点更早。还取决于顺路程度，是否拼单等等。但车主往往有习惯性理解，早出发好。
- “距起点最近”也不能保证顺路百分比高，或者最终完成送达乘客的时间短。这只是一种车主挑选乘客的习惯：貌似可以早出发（还取决于乘客出发时间），另外对周边地理位置更熟悉（有了智能导航后，不熟悉的地方也基本不是问题）。
这两个维度，车主可能会经常用或者说很依赖，尤其是当“智能排序”不够智能，不能很好地帮助车主筛选订单的时候，是一个很好的补充。
（2）“价格最高”与“拼座优先”
- 价格高的订单，往往绕路里程较多。从现有订单展示规则来看，就是起点、终点间隔里程远。有多少顺风车车主，是只看价格不看里程的（顺路百分比）？如果还需要不断往下刷屏再筛选订单，则说明这条排序规则意义不大。希望滴滴内部可以跟踪下数据，通过这个规则进入并成功下单的比例有多少。
- 选择“拼座优先”，则需要根据2组不同的起点、终点位置，以及出行时间做出判断是否适合拼单，其实难度不小。系统提供的“自动拼单”，以及成单（愿拼座）以后的“再拼一单”功能，是选择拼座订单的易用操作方法。
本质上，两者都是为了多赚钱。“价格最高”是通过挑选乘客多、路程远的订单多赚钱， “拼座”则是通过在一趟行程中多拉订单多赚钱。这两种方式看似增加了筛选方法，实则增加了选择难度，笔者建议砍掉。
其实在“智能排序”规则中，顺路百分比高且金额高的订单（优先列出“顺路的价格高的非拼座订单”、后列出“顺路的拼座订单”），已经排在前列了。
（3）建议增加筛选维度“整体用时最少”
即：车主完成乘客送达后，能够最早抵达自己的目的地。当车主行程比较赶时，会根据自己设定的“最晚到达时间”来查看是否来得及拉一单顺风车。
这时，最重要的考量标准是时间。而不是金额，也不完全是顺路百分比（有时候顺路百分比高，但可能因为拥堵路段而造成里程少用时长的情况）。
综上，建议提供如下4种排序规则即可：智能排序（默认）、出发时间最早、距起点最近、整体用时最少。
本文由 @ 谭翀 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自网络
