cookieOptions = {...}; ‧ 產品經理,你會如何設計一款智慧停車場 APP? - 3S Market「全球智慧科技應用」市場資訊網

3S MARKET

3S MARKET
2016年4月20日 星期三


最近看了XX停車的一些資訊,同時也看了一個以色列公司做智慧找停車場新思路的一些介紹,分析了一下,與各位產品經理分享:

产品经理,你会如何设计一款智能停车场APP?

智慧停車原來以為不難做,但仔細想想,有幾點確實是挺有挑戰的。
  • 即時性要求高:車要是到了目的地,發現你的資訊不準確,幾次過來估計就不用了。
  • 停車場並沒有強烈意願主動提供資訊:現在大城市的停車場,應該不需要大力宣傳,車多&停車場少才是真正的痛點。
  • 商業模式是什麼?這個也許我想錯了,但有多少人願意花錢買停車場資訊?
不提商業模式了(但如果有大拿願意幫著分析分析,絕對歡迎),基於這樣的前提下,如果你是一個產品經理,你會怎麼辦呢?
說說我根據網上的資訊,總結的一點思路吧:智慧停車場資訊提供目前主要有兩種思路來做
  • 即時資訊為主,智慧預測為輔
  • 智能預測+眾籌為主,即時資訊為輔


下面一個一個介紹一下我的思路:
即時資訊為主,智慧預測為輔
XX停車應該是這種思路下的一個設計方式,以下幾個方式可以提供即時資訊:
  • 與停車場合作,使用平臺統一提供的停車場管理系統,這樣管理系統在説明停車場的同時,也能提供平臺需要的資訊。
  • 在停車場內安裝一些傳感設備,這樣,不用侵入停車場管理系統,也能得到當前停車場的資訊。
  • 和停車場管理人員(或參與管理人員)合作,人為獲取資訊,比如和停車場保全人員合作

  • (這裡提一句話,原來一個產品大拿告訴我的:“做產品,別光想著用技術解決所有問題,有可能技術之外的方式更簡單”)。
當然,光有即時資訊也不行,因為開車的人離的可能遠,查到有車位和開到有車位,不是一回事。這種情況下,就需要智慧預測的輔助了。
同時,智慧預測應該有兩方面的內容:
  • 停車位資訊是即時的,但車離的比較遠,預測車到後停車場的情況。雖然有的APP提供線上預定的功能,這樣用戶可以提前預定車位,這樣車到後,車位是有了的,但這種情況需要與停車場系統集成,不是每個都能支持。
  • 停車位資訊是非即時的,這時候預測的範圍就更廣了,需要預測當前停車場內車輛情況,同時還要加上車開到後可能的情況。
接觸了XX停車後,感覺他們在能支援即時停車位資訊的情景下做的不錯,但在預測這事兒上,感覺沒有發揮技術提高生產力的優勢,比如我一個朋友家周圍的情況:

产品经理,你会如何设计一款智能停车场APP?

产品经理,你会如何设计一款智能停车场APP?

其實這周圍停車場有不少,而且,停車位在不同時候的情況緊張程度,相對固定,但APP上,沒有體現這麼多;同時,當前停車位情況和價格,也明顯也不對。對於一個需要停車位APP的人來說,如果在這地方沒有幫到他,或資訊錯誤,那使用者就可能放棄它。

其實從技術的角度來說,這事應該也可以實現,比如,對一個停車場來說,能夠影響它的停車位緊張程度的,應該有如下資訊:(只是舉例)
  • 城市的基本情況,車輛飽和程度......
  • 目前周圍的traffic情況怎麼樣?一般比較堵車的地方,停車場都是滿的
  • 今天某個時段的Traffic情況怎麼樣?一段上午比較堵車時,停車場是滿的......
  • 周圍有商場嗎?商場大概的開門時間和人流量?
  • 周圍有居民區嗎?大概的人口數量。
  • 周圍有景點嗎?一般景點周圍在節假日,都會緊張。
  • 天氣情況如何?比如下大雨的天氣,有的停車場就可能會車少。
......

有點像是個“地點畫像”吧,通過這些資訊的綜合評價和持續學習,對於一般情況下的預測,效果應該還可以的。(這裡面需要涉及大數據、地圖資料及機器學習的綜合應用內容,略過了)
可以看到,即時+預測的模式,有一定的優勢,就是資訊準確;但劣勢也明顯,就是成本高,同時需要相當多的時間、資料和歷史資訊來優化提高引擎的預測能力。

預測+眾籌為主,即時為輔
以色列一家公司宣稱自己的演算法,不需要任何歷史資料的支援
像上面一樣,我也來“猜一猜”這樣的產品應該如何設計吧
預測上面提到了,這部分我覺得就算是不需要歷史資料的支援,但是“地理畫像”這部分也應該跑不掉。

重點說說眾籌,要是設計一款產品,想讓使用者真的自願來提供資訊,個人覺得有這樣幾種方法
  • 有獎勵。
  • 產品對自己有用。
  • 不經意間就資訊眾籌了。
個人覺得第三種可能可行性更高些(第一種費用高,第二種對一部分人來說,沒有即時資訊的支撐,不好做)
對第三種,下面的思路可供參考:
  • 用戶打開APP,想找一個停車場,輸入目的地後,顯示周圍的停車場。
  • 系統推薦一個停車場,這時候,系統沒有即時資訊,所以根據“地理畫像”,選擇一個停車場推薦(這時候,根據情況可以選擇我們希望“眾籌”的停車場)。
  • 如果用戶順利停車進去,說明停車場我們的預測是正確的,可以讓用戶幫助提供一些當前停車場的簡單資訊(比如是不是推薦其它人停入......
  • 如果沒有停車進去,說明這個停車場已滿(系統可以把這個資訊,用於下一次使用者訪問)。提示用戶,可以選擇下一個停車場,同時,使用系統推薦的導航路徑時,路徑的規劃中,不再是最短路徑,而是儘量選擇途徑停車場比較多的路徑,這樣,提示使用者可以在開車的過程中,進行選擇。
  • 如果用戶停進停車場了,可以幫用戶進行計時計費(如果沒開通的情況下),這樣,停車場的費用情況資訊,也可以收集上來。
按以上的設計的話,以下幾個場景,不同的情況下,會有不同的幫助:
  • 場景一:想要去的停車場,沒有任何資訊。上面的情況,部分的解決了這些問題,而且,如果“地理畫像”做的好的話,準確度應該能在50%以上。
  • 場景二:想要去的停車場,沒有即時資訊,但有“眾籌”資訊。上面的情況,如果加上一個比較準確的輸入,準確度應該會在780%以上了。
  • 場景三:想要去的停車場,有即時資訊。這種情況下,準確度會很高,同時,周圍的停車場資訊,也可以通過使用者的資訊得到,一舉兩得。
這種設計的優勢很明顯,前期不需要歷史資料和大的硬體成本投入,易於推廣;但劣勢也很明顯,就是需要你有能力來控制導航,控制POI搜索等等,需要較強的技術背景。


這樣,一個使用者的服務過程中,使用者得到了方便,我們也得到了想要的一些資訊。

當然,以上的設計,只是憑藉個人的經驗,猜測的,如果不對,請大家指正。

再說說如何快速地獲取更多的停車場資訊呢?路推的方式獲取?大家估計都知道這個成本很高了。這時候APP如果提供一個免費找車的功能,讓用戶把自己的愛車停的位置照下來,同時系統把GPS存下來,一能幫助用戶方便的找到車,避免在陌生的地方忘了車在哪裡;二能説明系統方便的找到“各種各樣”的停車場,一舉兩得。

                                                                                                                                                                                                                            

0 comments: