打車不再加價?大數據說可以有

起晚了,著急去上班;下班了,著急回家吃飯;我們都習慣拿起手機準備叫個車,卻總是被打車應用扔來一枚炸彈,把我們炸回現實,沒有一點點防備:

這種一言不合就扔炸彈的行為,難道警察叔叔不管管嗎?考慮到警民一家親,我決定先一本正經地思考一下。

問題分析

高峰期為什麼會漲價?廢話,當然是因為高峰期乘客多,車輛供不應求啊。這是最最基礎的經濟規律。這個經濟活動中,有三個博弈主體:乘客、司機、平台方。而高峰期加價現象本質是:

  • 需求和供給匹配失衡

  • 平台方不夠給力,只能通過加價來調控

我們先對高峰期加價定個性:這不是帕累托最優的調控策略,因為:

  1. 加價嚇走了很多乘客(需求沒被滿足);

  2. 加價沒有快速吸引來更多的司機

  3. 平台方最終沒有在高峰期賺到更多的錢,反而冒了一些用戶可能會流失的風險。

理想的調控目標是:

  1. 不加價或者少量加價讓乘客打到車;

  2. 司機都能拉到想拉的乘客,不空駛,賺更多的錢;

  3. 乘客和司機都對平台方滿意,並且平台方賺更多的錢

為了達到這個理想的目標,加價只是一種供求失衡的事後彌補的手段,我們應該充分利用乘客和司機積累的巨大數據,挖掘其中各自蘊藏的秘密,從而幫打車平台提前應對每一個上下班的洪峰來襲。

要解決高峰期打車應用的需求供給不匹配問題,我們需要從全局考慮兩個問題:

  • 如何把運力資源從過剩的地方引導到稀缺的區域來;

  • 如何把市場需求從過旺的地方引導到冷門的區域來。

第一個主體方案,現在打車應用的做法是粗暴對乘客加價來吸引運力,這並不是理想方法,理想方法是幫司機找到他最想拉的乘客,獲得金錢獎勵效用之外的效用,這是一個典型的推薦系統,將司機對訂單的訴求和乘客訂單的特點精準匹配起來。

第二個方案是一個輔助方案,就是引導那些深處訂單洪峰區域的用戶通過可接受的少量其他交通方式(步行,公交,地鐵)去到別的區域發送訂單。比如引導中關村西區的乘客步行到黃庄發送訂單,這可以稍微分散一下集中的訂單,緩解交通擁堵。

基於這些思路,我們構想一下解決高峰期打車問題的主要模塊:

  1. 供求關係預測系統

  2. 動態調度系統

  3. 司機偏好挖掘

  4. 乘客偏好挖掘

其關係如下:

乘客偏好挖掘

平台方需要對用戶進行挖掘,掌握乘客的這些方面:

  1. 是否是願意用時間換取合適的司機的人

  2. 是否是願意用金錢換取合適司機的人

  3. 是否是通勤用戶

  4. 常去目的地

  5. 願意接受的加價倍數

  6. 用戶價值

司機偏好挖掘

  1. 司機在當前時刻是否有常走的特定路線(如回家)

  2. 司機是否更在乎賺錢

  3. 司機商圈喜好

  4. 司機家庭地址(需組合時間特徵)

  5. 司機常去目的地(更為熟悉的路線)

  6. 司機偏好的獎勵類型(湊單/早晚高峰補貼/其他)

供求關係預測系統

該系統的作用是提前預測某個區域在某個時間段可能出現的訂單數量。訂單數量受多個因素的影響:

1.時間

比如:上下班高峰期、節假日、周五下午、企業可報銷打車的臨界點、電影院散場時間等等

2.地點

比如帝都著名的三環國貿段、北醫三院的花園路、下班時期的後廠村路等,地點的區域類型。

3.天氣

突發陣雨、下雪等你能想到的各種惡劣天氣

4.路況

修路、臨時交通管制等

5.同期平均通勤人數

熱門區域通常有大量的通勤人數,可以很好預測正常訂單量

綜合這些因素及其組合,可以預估某個區域的訂單趨勢,同時實時地結合該區域已有的司機數量,計算出預估的供求比。如果供求比緊張,可以提起給常用用戶發送報警push,提醒他們錯峰下班;另一邊,還提前通知司機端目前閑置的運力,趕往供求比比較緊張的區域。

關於如何選擇被通知的司機,大數據也可以發揮重要作用。本質上是要把合適的區域匹配給合適的司機,並提前推送告知。而推薦系統的核心價值是挖掘潛在司機,不斷提高應答率。為此,系統需要用到司機端和目標區域(供求失衡區域)的特徵數據。

需考慮的司機端的即時場景特徵有:

  • 司機與目標區域之間距離

  • 司機去目標區域的時間成本

  • 司機的商圈喜好

  • 司機當前已接單的目的地方向

  • 司機當日的成交單數(滿足司機湊單需求)

需考慮的供求失衡區域的即時場景特徵有:

  • 目標區域的地理位置

  • 目標區域的訂單特徵(路程長短、目的地分布等)

  • 目標區域的擁堵情況

提前調度過程如下:

整個過程包含5個模塊:召回潛在司機、預估司機應答率&排序、廣播量預測、廣播司機、統計與反饋。

前兩個模塊用於計算應答率最高的司機名單;廣播量預測模塊需結合目標區域的訂單量(預測值)和司機應答率(可結合歷史經驗)計算需廣播的司機數量;統計與反饋模塊用於實時收集司機應答率並反饋給系統用以補充候選司機名單,同時司機的應答行為也可以用於調整整個推薦系統的召回與排序模型。

另外,除系統主動廣播司機外,還可以有一隻「看不見的手」提前將運力資源過剩區域的司機在分派單策略中實現逐步引導到資源緊張的區域,具體策略下期細討論。

調度系統

車輛調度系統本質上是一個推薦系統和廣告系統的合體,把訂單推送給最合適的司機,以提高轉化率,讓乘客,司機,平台三方的博弈趨向均衡態。

說他是個推薦系統,是因為它本質是在做匹配,為了提高訂單轉化率。這個推薦任務是把當前訂單推送給最適合、最可能的司機。把這個想成是推薦系統,可以解決那些不願意加價而願意等待的用戶的需求。推薦系統這邊,需要大量用到挖掘到的乘客偏好和司機偏好,然後用技術手段將兩者匹配,而不是統統加價。

一旦用戶願意主動加價,那我們又說他是個廣告系統,是因為用戶加價後本質上是在為自己買一個司機廣告,本質上也是在計算轉化率,並考慮到乘客願意提出的競價來進行綜合排序,把預估轉化率*加價作為最終輸出的排序因素。

推薦和廣告需要用到乘客端和司機端的各種偏好數據,以及當前場景下的供求關係預測結果。

需考慮的司機端即時場景特徵有:

  • 司機與目的地之間距離

  • 司機去目的地的時間成本

  • 司機當日的成交單數(滿足司機湊單需求)

  • 司機當前已接單的目的地(商圈、區域、方向)

同時還需要考慮乘客端的即時場景特徵:

  • 乘客願意等待時間

  • 乘客是否願意拼車

  • 乘客所去目的地(商圈、區域、方向)

  • 乘客願意接受的加價(一般是系統默認加價,乘客可自己增減)

整個匹配過程如下:

調度過程分為召回訂單和訂單排序推送兩個階段。從司機端來說,召回訂單分為三個層次:

  1. 第一個層次是召回個性化的訂單,不加價的情形下滿足長尾和個性化需求。

  2. 第二個層次是召回具有附加值的訂單,包括有現金加價的,高價值用戶的訂單,通勤用戶訂單

  3. 第三個層次是可能有傷害,但風險略低的訂單,也是為了滿足核心需求之外的訂單,包括為司機贏取獎勵或者升級湊單;臨時訂單(低頻用戶的訂單,非通勤用戶訂單);願意等待的用戶根據等待時間長短優先召回。

逐級為司機召回訂單,並預估訂單轉化率,給司機推送他最想接的訂單。這是結合推薦系統和廣告系統的綜合調度系統。

不論是調度系統是一個廣告系統還是推薦系統,調度系統的框架就是計算匹配的可能性以及乘客應該付出的代價。基於這個框架,不斷去發掘乘客取消訂單的原因,不斷發掘司機不接訂單的原因,把這些原因作為特徵加入到調度框架中,以提升訂單轉換率。

如何發掘司機不接訂單的原因,可以通過數據挖掘一批司機進行訪談,比如系統預測可調度性高的司機,但並沒有應答,或者比如明明在空駛,推送訂單卻不被司機接受,這些原因需要深入分析司機背後的心理來決定調度系統的改進。關於如何設計有效的用戶訪談,可以參看《精益數據分析》第15章。

最後的小結

高峰期打車的供求關係不均衡的問題,一直被詬病。我們提議可以把打車看成一個推薦系統和一個廣告系統,通過預估轉化率,結合乘客的競價來分配給相應的司機了。這個框架下,最重要的是調度系統,乘客分析、司機分析。

但是,如果實在是你不想進行這麼複雜的設計和計算,那麼也不要氣餒,無人駕駛可能馬上就到來了。一旦實現無人駕駛,就可以完全用計算機去調度每一輛車了,而不是通過利用司機的人性來達到推廣目的。


推薦閱讀:

TAG:大數據 | 滴滴出行 | 優步Uber |