運用大數據和風控手段,解決共享單車供求匹配問題
最近,看了不少共享單車方面的文章,其中有不少是探討如何改善用戶體驗、提高共享單車供求匹配度和單車適用頻次的。無論是文章本身,還是大家的評論,都讓本人受益匪淺,以下是個人總結的一點資料,歡迎吐槽。
- 用戶痛點:想用車的時候隨時都有車可用;
- 企業痛點:提高每臺單車的日均適用頻次(企業需求)。
兩者矛盾體現為:用戶想用車,附近卻無車可用或有車卻用不了。而企業呢?一方面,用戶有用車需求,卻無法及時響應;另一方面,在其他區域,有大量的單車處于暫時閑置狀態。這個需求其實是供與求在時間上、空間上相匹配的問題。匹配度越高,問題解決的就越好,匹配成本越低,效益就越好。
為了便于理解,先引入一個需求場景的例子,如下:
以深圳為例,年輕的上班族居多,也是共享單車的主要用戶群體。早上大部分單車都停留在地鐵口,公司上班時間一般是8:30或9:00,而在8:00 ~ 8:30之間的第一波上班族,把單車都騎到公司樓下了。結果8:30 ~ 9:00很少有從寫字樓往地鐵口騎車的,這期間出地鐵的人,就無車可用,大量的單車停留在寫字樓下,一直到下班,利用率極低。
那該怎么解決此類需求呢?很明顯這屬于大數據范疇了,通過大數據來實現是最理想的。此外,尚需引入風控思想,二者結合可達到意向不到的效果。另外,還需調整并新增功能,以摩拜單車為例,調整和新增的功能主要有:臨時用車、預約用車、用車需求、接單。
- 臨時用車:指的是普通用戶,直接通過掃二維碼用車的情況,此功能無需調整。
- 預約用車:指的是普通用戶,通過摩拜APP提前預約用車的情況,預約生效時間為:距離預約時間5分鐘至30分鐘內的一個時間段。預約的不是某一輛具體的單車,而是指定區域內的騎車服務,補充說明見后文。
- 用車需求:當用戶預約用車時,發現附近可用車輛有限,為了一會能順利用車,可以發布一個用車需求,讓其他用戶通過接單,來滿足自己的用車需求。用車需求與預約用車相比,在用車權利上是相同的,但失效條件略微不同。另外,在特定條件下,預約用車會自動轉變成用車需求,詳細說明見后文。
- 接單:當有用車需求產生時,用戶就可以接單,將單車在有效時間內送至指定區域。用戶發布的用車需求或由預約用車轉變成的用車需求,都是屬于某一具體區域的。如你想接單,通過騎車去到某個地方,你只需輸入目的地,系統就會自動匹配并顯示,由當前位置至目的地的幾條主要騎行參考路線,以及接單方案,如圖1所示:
圖 1
當然,你也可以從當前位置直接騎車去到目的地,中途不換車。接單功能跟預約用車類似,接單也是不綁定具體的用車需求,而是指定區域內的任意用車需求。由圖1可知,接單流程大致為:選定接單區域(可多個)→啟動接單任務→將單車送至指定區域→結束接單任務(鎖車后,系統默認匹配離失效時間最近的用車需求、或用戶指定完成某一接單任務,個人傾向前者)
為了進一步闡釋臨時用車、預約用車、用車需求、接單之間的關系,請看圖2和下方注釋:
圖 2
- 如圖2所示,若甲直接掃碼用車則屬于臨時用車的范疇;
- 在圖2中,甲位于區域五,如出門前預約了區域四的單車,預約時間內騎的也是區域四中的單車,則屬于預約用車;若實際騎的是其它區域的單車或不在預約時間內用車均屬于臨時用車;
- 如甲在區域一中發布了用車需求,乙接單了,并在有效時間內,將車送至指定定點(區域一),則乙順利完成接單任務。否則,視為接單失敗。
通過眾包接單的形式就很好的利用了大數據的特性,當然也有些朋友指出,可通過后臺大數據分析,在適當的時候安排車輛進行調度。其實,在成本可控范圍內,安排專車調度也是不錯的選項。
下面結合大數據和風控來詳細介紹下,如何在保證預約用戶用車的同時,又不影響普通用戶臨時用車,還可提高單車的適用頻次。
首先,必須明確一點,用車需遵行的基本原則是:先到先用,這里指的是具體的人,誰最先掃碼,誰優先使用該單車。
為了更方便的說明問題,把右圖中的單車標記為不同顏色,以便于區分。以區域五為例,在區域五(直徑100m的正方形)中,藍顏色的單車,表示停放于該區域內的單車,數量為A;綠顏色的單車,表示區域五之外,到區域五中心半徑為250m范圍內,用戶接單后騎行中、且目的地是區域五的單車,數量為B;紅色表示距離區域五中心,半徑250m范圍內,騎行中的單車(這部分單車目的地是隨機的),數量為C。若區域五中預約用車數為M,令Q = (A+B+uC)/M,(其中u是比例系數),P = A/M。如取Q = 0.6,P = 0.4為鎖定預約用車閥值,則表示,當Q > 0.6且P>0.4時,臨時用戶與預約用戶,均遵循先到先用車的原則;當Q <= 0.6或P <= 0.4時,區域五中的單車將被鎖定,此時需優先滿足預約用戶的用車需求,先到先用車的原則就暫時只適用于預約用戶了。
例如:圖2中的甲預約了15分鐘內區域五中的單車,那么如果當滿足條件Q <= 0.6或P <= 0.4時,臨時用戶無法使用區域五中的單車,只有跟甲一樣的預約用車用戶才能使用單車,且預約用車用戶之間遵行先到先用車的原則,只要先到,就可以使用其中的任何一輛單車。當條件被破壞后,則先到先用車的原則同時適用于預約用車用戶和臨時用車的普通用戶。
上面已經包含了風控的思想,其中有很多風控點,如:區域的大小、預約用車時段、上圖中的圓半徑、以及P、Q、u等參數。如果想把風控做的更精細些,還需考慮其他因素,如:天氣、行業競爭、歷史影響(使用周期的問題,個人認為以周為單位比較合適)等。
預約用車與用車需求之間的關系:
- 當P <= 0.6時,新產生的預約用車會自動轉變成用車需求數據。如前文所述:預約用車與用車需求在用車方面,權限是一樣的,但失效條件,略微不同。當用戶在預約時間段內,使用了預約區域中的單車,預約用車即可失效;或在預約時間內,用戶未使用預約區域中的單車,則預約時間結束后,預約用車即失效。
- 針對某一區域的用車需求,當P > 0.6時,在指定時間內,有用戶完成接單任務的,用車需求即刻失效;若在指定時間內,無用戶完成接單任務的,指定時間一過,則用車需求失效。
- 當P <= 0.6時,若無用戶完成接單任務,用車需求將保留至次日凌晨2:00后自動失效。值得注意的是:用車需求的失效與否,與發布用車需求的人,是否在指定時間內,使用發布區域內的單車無關。
可根據長期的實際運行效果和收集的數據,不斷完善和調整風控規則與參數,使風控效果趨于完美。另外,若用戶量有明顯增長,也需考慮適當加大單車投入量,以保證用戶用車的基本需求。
需要特別說明的一點是:為了更好的引導用戶使用上述功能,達到通過眾包、大數據、風控等手段來實現共享單車在供求關系上的高度匹配,從而解決用戶用車難、有車不可用,單車適用頻次低等問題??梢赃m當、合理的引入獎勵(物質和精神上的都行)措施和社交元素,如:發布用車需求,可9折用車,接單可享受5折用車,鼓勵大家綠色出行,用戶量積累到一定量,可創建騎行日(如摩拜騎行日,可多個,如春、夏、秋、冬),并設置騎行日大獎(適當的設置一些獲獎門檻,以達到長期互動,維持用戶熱度的效果)、形成騎行社區和社交圈等。當然,如何把握好獎勵力度、實現激勵用戶的目標,并保證企業收益,也離不開大數據和風控的思想,此文就不在做深入的探討。
聲明:本文受益于《思考 | 站在產品的角度,如何提升摩拜的單車使用頻率》一文,感謝文章作者Mr Tang 和評論區的各位吐槽大神。
本文由 @阿良?原創發布于人人都是產品經理。未經許可,禁止轉載。
個人認為,暫且不論競品競爭和這套方法具體對單車騎行次數是否帶來較好的效果。
該模式還有幾個問題:
1、這個模式將用戶使用單車的步驟變得的麻煩,用戶使用單車,如果可以我想用戶連手機都不想打開,但這邊將業務模式搞的較為復雜,學習成本較高,用戶用車本身是一個小額消費場景,如果引入了接單的概念,那么接單用戶的補貼如何進行,如果補貼低,則用戶可能會不愿意浪費時間成本接單,如果補貼高,對于企業來說,該模式的商業價值在哪里?
2、就算用戶預約了,還得遵循先先用車原則,這就讓預約的效率變的很低,如果用戶預約了,并且照著地圖去尋找車輛的途中,發現車輛被其它預約用戶騎走了是多么糟糕的體驗。
3、該模式的預想狀態在前面例子中說到的,高峰期的調度中,實際上可能還是效果有限,你的例子中,8:00~8:30這段時間,車輛都被從地鐵站騎到公司樓下,那么在高峰期,用戶行為和需求相對集中和趨同的情況下,如何保證有那么多人去接單將車子從公司樓下騎回到地鐵站。
以上個人愚見。如果有說的不對,歡迎指出。
非常感謝您的請問,作為產品汪,答疑解惑是最基本的工作?,F依次回答您的問題如下(注:因時間隔得太久,有些可能記不太清了,
如有紕漏或需要,再做詳細探討):
1. 首先必須明確的一點是,用戶的使用成本沒有增加,所有的規則、算法都是通過后臺和數據庫去完成的,APP用戶體驗上不但沒有任
何影響,反而更簡單明了。業務邏輯和算法那一塊較復雜,就不做詳細說明。接單作為新增功能,不影響已有功能的使用和體驗。接單
補貼標準,可以根據市場運作情況在后臺設置,所以企業成本這一塊是不用擔心的。至于用戶那一塊,出發點并不是讓用戶靠這個賺錢
,而是對“順路”用戶的一種激勵。用車時,用戶一般會先看看有沒有紅包單車,接單跟這個道理一樣,原本需要5塊錢的車費,可能只
需付2塊,用戶到達目的地后,只需放到指定的區域內,距離大都在百米內(距離太遠的,平臺不反對也不推薦,用戶應該也很少會為了
省幾塊錢,還特意停到幾百米外的吧)。這樣做,在不增加運營成本的基礎上,不僅不會降低運營推廣效果,也不會影響正常的用車需
求,還可以及時解決一部分車輛調度及“目的地”的用車需求,同時也便于共享單車的管理(據了解,共享單車已經開始劃區停放了),
弘揚社會正能量等,這些都是其商業價值。關于補貼成本及用戶接單意愿,可根據實際運行效果及運營需求進行設置,因而不是問題。
2.預約功能么有你想的那么復雜,這個是按區域劃分好的,若劃分的合理,用戶體驗是完全不用擔心的,舉個簡單的例子,如某方形寫
字樓,前后左右(或以4個角為參考)劃分為4個區域,用戶事先預定好某一區域的車,找起來還是很方便的(APP上對該區域做好標注,
找車過程中,用戶是否已進入該區域,是一目了然的),與已有找車功能區別不大,而且目的地很明確,也很方便。至于你說預約好的
車被別人騎走的情況,不是大問題。把風控做好,很大程度上是可以規避的。通過大數據分析及風控規則,實現實時風控即可。當然,
風控不是萬能的,無法保證不出現你所說的情況,但是可以通過數據的積累、技術的成熟、算法的智能化,將該情況出現的概率逐漸降
低。此外,還可采取運營手段,對該情況的用戶(在風控成熟的條件下,比例極小)送去平臺的特別補償和問候,這樣,用戶體驗是沒
問題的,可能還會有意想不到的收獲。
3.針對此問題,其實上面已經給出了部分解釋。首先,設想下用戶需求與使用場景:早上 8:00 – 8:30 這段高峰期內,由地鐵口至各寫
字樓的用車需求大,盡管地鐵口早有大量共享單車等著,但相對需求量來說仍然十分有限。那該如何解決這一矛盾呢?安排調度,不僅
成本高,也不實際(難不成開個車,把挨個辦公樓底的車運到地鐵口?時間來的及么?一次又能運幾輛?以深圳為例,客流量如此巨大
這方法現實嗎?還有……)。但,如果以地鐵站為中心,擴大至百米半徑區域內的共享單車呢?是不是就可大大的緩解高峰期用戶行為
和需求相對集中與趨同的矛盾。然而,想讓用戶出地鐵口,走百米用車,確實很困難,該如何把車集中到地鐵口50米以內的區域呢?通
過接單功能,就可以把原本停在距離地鐵口 50 – 150 米內的共享單車,絕大部分停到距離地鐵口50米以內的范圍。補貼力度越大,效
果越明顯。
當然要實現上述要求,需要很大的數據沉淀以及技術和資金投入。
沒看懂。。。
有點想法,不錯不錯!
謝謝
同學你這想法適合去發論文
處女座,獻丑了,歡迎吐槽