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

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