本文作者結合自己順風車車主的經曆，來談談關于滴滴順風車的車主體驗和一些策略思考，一起來看看~

關于滴滴順風車的一點題外話

滴滴順風車安全問題，前一陣鬧得很大，也很快有相關整改措施出來。有人說根上是在活躍度和交易量的指标壓力下，各順風車平台都為其賦予了社交屬性（真人照片、自由評論&标簽、聊爽了還可以免單），甚至宣揚美麗邂逅（男女交友、投資人找項目、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）車主端

假設車主設定行程為：

針對每一個乘客訂單，增加了車主到達乘客起點，以及車主送完乘客後到達個人終點時間（标黃處），從而幫助車主判斷，方便下單。

目前的做法是：點開訂單詳情後，展示地圖預覽，并在地圖上提示到達乘客起點需要多長時間（圖略），不夠直觀和方便。

下圖示例排序規則解讀為：對車主來說，順路程度一緻的情況下，即使司乘距離遠（後到達乘客起點），即使金額少，将符合“最晚到達時間”的訂單排在前面。

為使讀者對“最晚到達時間”有直觀理解，特對此案例的兩位乘客終點及車主終點地理位置截圖如下。

通過截圖可以很清晰地看出：

• 目前滴滴關于順路百分比的算法，需要重新審視和優化（前文已有論述）；
• 當順路百分比一緻或相近時，可以通過優先排序估算的“車主抵達個人終點”時間來幫助篩選，并将超出設定最晚到達時間的訂單往後排。

六、“車主端”乘客行程訂單列表展示邏輯研究

目前在乘客端，按系統默認規則展示車主訂單排序（圖略），不提供其他訂單篩選邏輯設置。細想也是合理的：乘客隻能決定自己的行程，通常對方位、距離不夠敏感，而且不能主動接單。

車主端的乘客行程列表，如上圖所示提供了5種排序規則：智能排序（默認）、出發時間最早、距起點最近、價格最高、拼座優先。

筆者的觀點如下：

（1）“出發時間最早”與“距起點最近”

• “出發時間最早”并不能保證車主送完乘客後，到達個人終點更早。還取決于順路程度，是否拼單等等。但車主往往有習慣性理解，早出發好。
• “距起點最近”也不能保證順路百分比高，或者最終完成送達乘客的時間短。這隻是一種車主挑選乘客的習慣：貌似可以早出發（還取決于乘客出發時間），另外對周邊地理位置更熟悉（有了智能導航後，不熟悉的地方也基本不是問題）。

這兩個維度，車主可能會經常用或者說很依賴，尤其是當“智能排序”不夠智能，不能很好地幫助車主篩選訂單的時候，是一個很好的補充。

（2）“價格最高”與“拼座優先”

• 價格高的訂單，往往繞路裡程較多。從現有訂單展示規則來看，就是起點、終點間隔裡程遠。有多少順風車車主，是隻看價格不看裡程的（順路百分比）？如果還需要不斷往下刷屏再篩選訂單，則說明這條排序規則意義不大。希望滴滴内部可以跟蹤下數據，通過這個規則進入并成功下單的比例有多少。
• 選擇“拼座優先”，則需要根據2組不同的起點、終點位置，以及出行時間做出判斷是否适合拼單，其實難度不小。系統提供的“自動拼單”，以及成單（願拼座）以後的“再拼一單”功能，是選擇拼座訂單的易用操作方法。

本質上，兩者都是為了多賺錢。“價格最高”是通過挑選乘客多、路程遠的訂單多賺錢， “拼座”則是通過在一趟行程中多拉訂單多賺錢。這兩種方式看似增加了篩選方法，實則增加了選擇難度，筆者建議砍掉。

其實在“智能排序”規則中，順路百分比高且金額高的訂單（優先列出“順路的價格高的非拼座訂單”、後列出“順路的拼座訂單”），已經排在前列了。

（3）建議增加篩選維度“整體用時最少”

即：車主完成乘客送達後，能夠最早抵達自己的目的地。當車主行程比較趕時，會根據自己設定的“最晚到達時間”來查看是否來得及拉一單順風車。

這時，最重要的考量标準是時間。而不是金額，也不完全是順路百分比（有時候順路百分比高，但可能因為擁堵路段而造成裡程少用時長的情況）。

綜上，建議提供如下4種排序規則即可：智能排序（默認）、出發時間最早、距起點最近、整體用時最少。

本文由 @ 譚翀 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自網絡

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部