如何設計一個好的派單功能

平常我們使用的滴滴打車、Uber背後的派單功能看似簡單,但是其實後面有著無數複雜的機理。它一方面連接著司機和乘客,為出行服務提供基礎;另一方面維持和影響著城市裡不同時間不同區域的司機供應,保證供需平衡,說它為打車行業的命脈也不為過。Uber此前的2.0改版,靠著它精妙的派單功能和演算法,迅速拉開了與lyft的用戶體驗差距,得到飛速發展。滴滴在中國的快速發展也得益於它不斷發展的派單附加功能。

那麼今天我們來講個真(xu)實(gou)的故事。滴滴優步估值加起來突破了1000億美金,天使投資人許大平覺得這個行業很有賺頭,於是投資了00後CEO半藏的創業公司Biubiu打車,決定從這個萬億級的市場里分一杯羹。BiuBiu打車的唯一一個(還沒畢業的)產品經理源氏挑上了派單功能的大梁。

Ver 1.0 實現基礎派單功能

源氏心想,派單多簡單,我只要確定 派單範圍車輛及乘客位置 ,在乘客請求時,搜尋離他最近的司機就好了!於是刷刷刷地寫了第一版功能,乘客和司機分開客戶端,司機端心跳上報自己的位置,當乘客端叫車的時候,伺服器搜索根據乘客起點的坐標,找到半徑3km內的 狀態為可用 的司機,進行距離 排序 ,對最近的司機分發訂單。舉個例子:

搜尋附近最近司機

想更深點還能把城市分割成大大小小的方塊,司機上報的位置會得到落入方塊的編號中,這樣只要知道乘客的方塊編號,就可以只搜尋乘客方塊相鄰的方塊內的司機進行距離計算,能夠顯著減少工作量。

第二天,半藏看著源氏做出來的東西,勃然大怒!「愚蠢的歐豆豆啊,你這連個車型都沒有怎麼做運營!」。

Ver 1.1 加了車型功能

只是增加了車型功能,能在乘客端選擇車型,呼叫不同類型的車。司機端的賬號可以設置為有權力接一個或多個車型。

第二天,半藏把源氏做出來的東西上了線,司機炸鍋:「卧槽怎麼我不能拒絕訂單!」。(愚蠢的歐豆豆被敲了一下腦袋,繼續幹活)

Ver 1.2a 增加串列的司機確認流程

源氏心想,增加司機確認環節也可以有2種方法,串列的方法是:乘客發出訂單後,對 按距離排序 後的司機從頂到底逐個詢問是否接單,被詢問的司機客戶端顯示乘客的坐標和目的地等信息,15s時間確認。但這樣有可能司機在15s後狀態就不可用了,所以最好是詢問完一個司機後重新排序一次,取最優解。如果2分鐘內都沒有司機接受訂單,則告知乘客叫車失敗。舉個例子就是:

對Rank後的司機進行輪詢

Ver 1.2b 增加並行的司機確認流程

並行的方法則是:乘客發出訂單後,對周圍所有的司機同時進行告知,司機在60s內應答,應答後的司機再經由乘客(或系統幫忙)挑選,乘客挑選後再次確認司機可用性(因為司機可能會被乘客B挑走),如果司機可用性正常則完成派單,司機不可用重新回到乘客挑選環節。這個方法對演算法和技術的要求最低,不用對司機進行Ranking。舉個例子:

無腦告知所有司機後3次握手

寫完這個方案的源氏心裡一驚,這不是某電視打車廠商的派單方案嗎!我真是機智!半藏一看覺得好,就上這個了。

但是上線沒幾天,乘客擠爆了客服投訴熱線,司機也一直反應派單極其不科學,源氏又被拉出來頂鍋,思前想後提出了第二版。

Ver 2.0 利用路線規劃計算距離

原來用戶們反應,很多時候司機被定位在了馬路對面,每次掉頭都非常浪費時間。源氏決定司機乘客的距離計算不再使用直線距離,而是對乘客和範圍內的所有司機一一進行路徑規劃,用路徑規劃的距離進行排序,這個距離在下文統稱為 實際距離 。這個方法很好地解決了上述的問題,調整後下圖的 司機1 和 司機2 的排序的結果就和之前相反了,排序更為科學了。

路徑規劃確定距離

Ver 2.1 計算距離的時候綜合考慮整個行程

用戶行程在司機接到乘客的時候並沒有結束,司機還需要把乘客送至目的地才算完成一個行程。有時候實際距離最近的司機並不一定是生活中的最優解,因為有一些區域是不允許穿行的。舉個例子就是源氏就讀的「哪個門進就需要哪個出的」某211大學,司機分別從南門和北門進入的派單:

司機2雖然更近但是總行程更遠了

因為有這些封閉的區域,加上城市間可能發生的大大小小的道路管制,計算距離的時候進行2次路徑規劃,能夠得到更優解。

這個版本上線後,乘客司機們都很歡喜,投訴率也降到了1%一下,一切都是這麼祥和。然而一周後的周會上,運營Dva說上周刷單比例已經超過了90%,這個數字氣得半藏大喊「油卡挖卡嘚肯乃衣」,可憐的歐豆豆又被扔去背鍋。

Ver 3.0 排序演算法升級

源氏仔細研究了刷單司機的規律之後,做了3個改進比較好地控制了刷單率。

  • 和乘客距離低於一定範圍的司機不會接受到訂單
  • 曾經接載過該乘客的司機會大幅降低排序權重
  • 新手司機和新手乘客不會被匹配到一起

同時源氏認識到了:派單功能就是為乘客提供當前時間點乃至將來的一小段時間內最便捷的司機。除了為乘客服務,派單功能還應該為司機服務,為整個城市的出行服務,為調控司機資源服務。所以源氏又為派單功能增加了幾個考量點。

Ver 3.1 派單增加宏觀調控功能

  1. 平衡每個司機接到的好單和壞單,用浮動分來平衡司機接到的單(比如滴滴此前的滴米機制)
  2. 對司機排序的時候考慮司機距離上一單的待命時間,平衡司機接單的數量。
  3. 派單更多考慮將非溢價區域的司機引導到溢價區域,緩解溢價(如下圖)
  4. 增加第25單的等待時間,減少獎勵支出(劃掉)

司機3並非A的最優解但卻是整體更優解

現在的派單演算法已經能夠滿足乘客們的正常需要,還能滿足協調司機資源配置的需求,簡直棒呆了有沒有!但是競品出了很多新的功能,尤其是拼車功能,能在司機供應水平不變的情況下活生生地提高運載力,還能夠緩和政府關係、樹立環保的企業形象,怎麼可以沒有,源氏又被派去啃鍋了。

Ver 4.0 拼車功能上線

拼車的實際實現會非常的複雜,因為需要考慮非常多的因素。不過其中的核心概念,還是比較容易理解的。我們先假設,司機已經接載到乘客A上車,送達A去目的地的路徑為 Route藍。此時如果B也在發起拼車請求,就對接載B-到達目的地A-到達目的地B進行路徑規劃得到 Route黃。我們就可以計算 Route藍 和 Route黃 中A的行程距離增加是否超過閾值。如果在閾值內,再去判斷B若和A拼車,到達目的地的距離的增加是否超過閾值。如果雙方拼車的路程增加是合理的,那麼就拼車成功。

對雙方拼車前後距離變化判斷

當然實際過程中的拼車會更為複雜,因為還要考慮到A、B誰先下車、具體的交通狀況、A、B的行程長短等等。假設A的行程特別長,那麼他是不是可以在途中進行連環拼車(自己上車-拼到B-B下車-拼到C-C下車-自己下車)。

Ver 4.1 設置司機目的地/回家

當拼車功能順利上線之後,這個小功能也很順理成章抵觸來了。設置目的地的本質其實就是司機制定了一個隱藏的拼車目的地,之後接載的乘客都需用拼車的演算法來判斷是否接受。

有了這些功能之後,BiuBiu打車終於躋身國內一線打車軟體,並且在繼續高歌猛進,推出了5.0。

Ver 5.0 更大幅地提升司機配置效率

這個版本主要有3部分的功能:

  1. 推出3人拼車功能,更進一步壓榨先用的運載能力(同時也開啟了三拼+連環拼的用戶噩夢時代??)

  2. 為了緩解短時間內的需求高峰,送給乘客願等優惠券,只要乘客願意等候10分鐘再用車,就能減3-5元。

    能吸引一部分非緊急用車且對價格敏感的用戶推遲用車,減少一段時間內的需求壓力,提供時間窗口讓溢價區域外的司機補充進來

  3. 在司機即將結束上一單行程的時候,可以接受下一個乘客的訂單。

    對司機而言,提早接到下一個訂單能夠提供「單多到爆」的快感,提升司機粘性。同時解決了派單時希望派單結果是「將來一小段時間」內最優解的問題。舉個例子,司機2正在行程中,還有1分鐘結束,但他在結束行程後(黑點處)離乘客很近,只需1分鐘就能到達。而司機3雖然空閑,但是到達乘客需要4分鐘,那麼司機2才是將來1分鐘後,乘客A的最優解。

    即將結束行程的司機可能是未來的更優解

推出了這些功能後,Biubiu打車已經奠定了國內 Top2 打車軟體的地位,並且提出了更為創新的6.0版。

Ver 6.0 提供更豐富的派單建議

源氏先找到了做大數據分析的獵空,讓獵空找出了20條叫車用戶數最多的路線。再從中篩選出10條公共交通比較匱乏的路線,開始在上面運營大巴。當乘客符合這10條線路的時候,便推薦乘客使用大巴,價格僅為打車的1/3。大巴還能按照此前的行程數量調整不同時間點的發車頻次,資源配置效率極高。

儘管大巴的質優價廉還有座位吸引了一大批用戶,但是利潤相對較低,還對現有的快車業務造成了衝擊。研究發現每增加3人次大巴行程的時候,就會減少1人次的快車/拼車行程。於是源氏減少了20%的大巴發車輛,大巴瞬間就和公交一樣需要站位了,快車行程流失的量又回來了,源氏這波讓半藏打了個82分。

隨後Biubiu打車就讓市政府制定規則收編了,成了IBM智慧城市的一部分(誤)

Biubiu打車的故事到此結束了,上面提到的功能點大多都是已經在現有的打車軟體中實現的了。至於功能點的實現部分,也只是我最簡單的猜想,實際實現肯定比這個複雜的多。例如派單的司機Ranking演算法,要考慮的就絕不僅是路程這麼簡單,它更多地需要參考需求浮動、天氣、路況等,用機器學習來預測未來一段時間的供需。還有和派單緊密相關的價格預估功能,也有很多功能沒法一一介紹。文章內容的來源還需要感謝各個軟體的更新日誌、知乎上對於滴米的討論、滴滴演算法的工程師的日誌博客、Medium裡面關於Uber演算法的文章、網上對各家功能和演算法的分析研究、和司機平時聊天聽到的吐槽等等

6.0版是還沒有出現的功能,完全是我瞎猜的,如果滴滴優步以後這樣做了,一定要別忘了給我發紅包。

------------

更多內容,請關注微信公眾號FullPM


推薦閱讀:

滴滴還能走多久?
如何評價上海早晚高峰時段禁用打車軟體?
網約車新政實施 ┃ 打車難,豈止難於上青天
現在打車(包括的士和優步滴滴什麼的)這麼方便,還有沒有買車的必要?

TAG:产品 | 打车 | 功能 |