捷運「吃到飽月票」能轉移搭乘行為嗎?數據證明價格不是唯一誘因

捷運「吃到飽月票」能轉移搭乘行為嗎?數據證明價格不是唯一誘因
Photo Credit: fabg

我們想讓你知道的是

其實票價不是通勤族思考的唯一觀點,公共運輸是否能較為方便、是否能較為省時,配合適當的票價,整個複合決策結果,才是影響公共運輸旅次是否轉移的決策因子。

日前雙北市兩位首長共同宣佈,「為了鼓勵民眾多搭乘大眾運輸工具」,因此推動每月1,280元、不記名可以無限次搭乘公共運輸(搭配30分鐘公共自行車優惠)的「1,280元吃到飽月票」,主打「每天42元任遊雙北市」為訴求,希望可以吸引民眾轉移搭乘行為。

究竟,這一項政策推出,預期實際效果如何?受影響的對象又是誰?我們就搭配幾項統計數據來進行說明。

價格是關鍵因素嗎?

這項月票政策的成立目的,就是「為了提供公共運輸使用率」,在雙北市的環境中,目前使用率的情形如何?依據交通部於2016年進行調查、2017年6月發布的「民眾日常使用運具狀況調查」資料顯示,通勤(學)公共運輸市占率,台北市為45.6%、新北市為32.2%;如果詳細剖析通勤學、雙北市在捷運與公車的佔比,則分別為捷運台北26.1%、新北16.9%,公車台北13.5%、新北11.1%。通勤學各種運具的分配情形,請見表一顯示。

  • 表一、雙北通勤學主運具市佔率
縣市別 公共載具 非機動載具 私人機動載具
捷運 市區公車 國道客運 計程車 自行車 機車 小客車
台北市 26.1% 13.5% 0.4% 4.6% 3.3% 32% 13.1%
新北市 16.9% 11.1% 0.7% - 2.2% 47.5% 14.4%

資料來源:交通部統計處「民眾日常使用運具狀況調查」2016年統計結果

我們可以看到,其實公共運輸月票政策的目的,應該是以私有機動運具的「機車」為主要轉移目標對象。不過,如果我們對照同一年交通部進行的「機車使用狀況調查結果表」,在這個調查中有一個問題是:「在未來三年內、考慮用公共運具代替機車」的選項中,使用者呈現的結果是「台北有27%、新北有18%會用公共運具替代原本使用機車的習慣」。

那麽,民眾不替代公共運輸的原因是什麽?依據統計資料,顯示如表二:

  • 表二:機車通勤(學)者未來三年內不會考慮使用公共運具來代替機車之原因
縣市別 通勤(學)搭乘公共運輸工具不方便 較費時 通勤(學)成本較高 離上班(學)地點近,不需要 機動性較低
台北市 26.4% 26.3% 13.3% 11% 16.2%
新北市 34.3% 19.3% 8.2% 17.3% 13.9%

資料來源:交通部「機車使用狀況調查」2016年統計結果

有趣的是,調查旅客行為中,機車使用者不會轉移到公共運輸的主要理由中,統計數字證明,「通勤、通學現行成本較高」並非主要原因(台北排第四、新北排第五),代表其實票價不是通勤族思考的唯一觀點,公共運輸是否能較為方便、是否能較為省時,配合適當的票價,整個複合決策結果,才是影響公共運輸旅次是否轉移的決策因子。

雙北市政府付出多少成本?

P4296503
Photo Credit: fabg

不過,如果長時間在關注台灣公共運輸發展的讀者就會知道,雙北市雖然是台灣公共運輸最密集的區域,以2017年的公車和客運的供需情形為統計,雙北提供公車供給量佔全國車公里的三成、公車需求量則佔全國人公里的四成。但是,到底雙北每年要編列多少的預算,才能達成這樣的公共運輸成果?

各位應該知道,雙北的公共運輸有三項「政策優惠」,分別是「捷運電子票證刷卡八折」、「公車每段次優惠3元(運價18元、旅客實付15元)」、「捷運公車雙向轉乘優惠」等三項,可是各位知道,雙北市政府在今年編列多少預算?

翻開台北市政府、台北捷運公司、以及新北市政府2018年的預算書,我們可以看到今年度截至目前為止,雙北市政府編列了以下的年度補貼款:

  1. 台北市公車票差補貼款(含其他優惠票價補貼):25.8億元
  2. 新北市公車票差補貼款(含其他優惠票價補貼):17.6億元
  3. 台北捷運與雙北公車雙向補貼:11.7億元

另外,2017年7月起台北市開始試辦的幹線公車政策,隨著幹線公車路網逐步擴張,2018年又編列了6.8億元款項、補貼幹線公車的公車轉公車政策。

因此,雙北市在還沒實施月票政策之前,雙北市在2018年已經編列了接近62億元台幣的補貼款,壓制票價、補貼旅客搭乘的成本;而為了月票政策,預計雙北還要多編列9.4億元補貼業者提供服務的差額,雖然月票將會減少原本轉乘補貼的額度,但全年度的補貼款仍可能介於60至70億元之間。這樣的預算規模,相對於交通部每年推動的「公路公共運輸計畫」大約在35-40億元之間、補助全國雙北市以外的市區客運與公路客運的軟、硬體更新與虧損補貼,可見雙北都會區能有今日的公共運輸運能,著實也是投入大量的補貼款所達成的效果。

什麽樣的客群是吃到飽月票獲利者?

依據台灣鐵道暨國土規劃學會的推估結果,就距離來看,以1,280元的對應捷運加上公車的通勤距離,單程通勤距離在15公里以上的旅次是直接受益對象;單程通勤距離在10-15公里之間的旅次,除非起訖點之間、每趟次要進行公車—捷運—公車的二次轉乘,否則1,280元大約就是在臨界點。至於10公里以下的公共運輸旅次,應不在本次月票設定的受益對象。

在全球先進國家中,依據世界銀行的研究,通勤月票的設定標準大約可設定在「可支配所得5%」的範疇,也就是所有所得收入扣除非消費性支出(例:利息、社會保險保費、稅金、罰款、捐款及禮金等)後,每月每人可支配所得25,600元以上的族群、如果能使用月票通勤與完成大部分的雙北市區內移動的族群,就會成為月票的獲利者。

被遺忘與被影響的族群

當捷運與公車的票價有了上限之後,直接受到衝擊的當然就是沒有上限、但是在同一個區域內一樣提供通勤服務的公共運輸業者,因為對於旅客來說非常明顯,一個有上限、可以搭到飽;另一個沒有上限,搭越多次越貴,所以可見在平行範圍中,台鐵的鶯歌-八堵區間、還有本來就已經被新北各種快速公車打得遍體鱗傷的國道與公路客運業者,以及同樣加入台北都會區通勤範疇的機場捷運,都是成為這次雙北合作中被預期面對衝擊的營運業者。
.
另外,本來就已經因為捷運系統普及而受到嚴重壓力的計程車,由於新一代月票通勤票證的機制並不完善,也會受到另外一波衝擊,尤其可見的未來可以想見不乏會有公司行號要求員工在雙北移動時以公共運輸系統為優先,以控制公司差旅成本,間接的當然就是計程車成為下一個受害者。


猜你喜歡


加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

加速敏捷開發腳步!AWS Amplify 協助企業打造高效能應用服務

我們想讓你知道的是

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

打造第一個你在 AWS 上的應用程式

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

透過 AWS 增加你的雲端技能 在組織發揮你的影響力

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

填寫表單諮詢專人 快速在 AWS 找到適合你的快速上雲服務與工具!

了解更多:AWS 開發者系列


猜你喜歡