旅客 WiFi：大眾運輸營運商如何利用 WiFi 數據洞察旅程狀況

乘客 WiFi：大眾運輸營運商如何利用 WiFi 數據深入洞察旅客旅程 Purple 智慧簡報 — 閱讀時間約 10 分鐘 --- 前言與背景介紹 — 1 分鐘 歡迎收看 Purple 智慧簡報。我是您的主持人。今天我們要探討一個多數大眾運輸營運商身處其中，卻尚未完全意識到其價值的寶貴資源：乘客 WiFi 數據。 如果您負責鐵路營運、公車路網或渡輪服務的 IT 或營運部門，您的旗下幾乎肯定已經部署了 WiFi 基礎架構。乘客對此已有預期。但關鍵在於 - 當相同的基礎架構搭配適當的分析層時，它就會成為您所能掌控、最強大的營運智慧工具之一。 我們所探討的是在尖峰需求來臨前先一步掌握狀況、繪製乘客在您的路網中實際移動的軌跡，並根據真實行為而非單憑售票數據來做出服務規劃決策。 在接下來的十分鐘內，我將帶您了解技術架構、實際應用案例、不容忽視的合規性考量，以及將現有狀態逐步轉化為讓 WiFi 真正發揮商業智慧資產效益的實用步驟。 讓我們開始吧。 --- 技術深度解析 — 5 分鐘 首先從基本原理開始。什麼是乘客 WiFi 分析？它又是如何運作的？ 其核心在於，每當乘客連接到您的 WiFi 網路時 - 無論是在火車上、車站內或渡輪上 - 他們的裝置都會產生一系列數據訊號。無線基地台會記錄連線事件。它會記錄時間戳記、工作階段持續時間、訊號強度、消耗的數據量，以及關鍵的裝置識別碼。在多數運行 IEEE 802.1X1ax - 也就是 WiFi 6 - 的現代部署中，您還能擷取無線基地台之間的漫遊切換，這能為您提供極為有用的資訊：移動軌跡。 現在，有趣的地方來了。您不需要知道該乘客的具體身分，就能從這些數據中獲得巨大的營運價值。匿名、整合後的 WiFi 訊號能告訴您在特定時間、特定區域內有多少台裝置。這就是人流量。它們還能告訴您裝置在該區域停留了多長時間。這就是停留時間。當您追蹤裝置在不同無線基地台之間的移動時 - 從車站大廳、月台再到火車車廂 - 您就能獲得旅程模式數據。起點、路線和終點，全部都能從 WiFi 切換中推導出來。 支持此項應用的架構包含四個層級。首先是存取點（Access Point）層 - 部署在車站、月台和列車車廂間的實體硬體。對鐵路營運商而言，這通常代表結合了車站內執行 802.11ax 的固定式基礎設施，以及使用行動網路回傳（通常為 LTE 或 5G）來維持車站間連線的車載系統。第二是數據收集層 - 一個集中式控制器或雲端管理平台，用於彙整來自每個存取點的原始工作階段日誌。第三是分析引擎 - 在此將原始日誌轉換為具意義的指標，例如停留時間分佈、連線尖峰時段、區域間的轉移率。像 Purple 的 WiFi Analytics 分析層即位於此處，運用機器學習模型來識別模式與異常。第四則是營運儀表板 - 供您的網路規劃人員、車站主管及商務團隊實際評估並使用這些洞察的前端介面。 讓我舉一個實際運作的具體範例。一家英國主要的鐵路營運商在十二個城際車站的網路中部署了 WiFi 分析。在第一季內，他們就清楚掌握了連線尖峰 - 不僅能精確到一天的特定小時，還能細分至特定月台與班次。他們發現最繁忙終點站的 7 號月台在 07:52 列車出發前四十分鐘會出現連線暴增，但當該班次延誤時，停留時間就會急遽下降。這種透過 WiFi 數據量化出的服務表現與旅客行為之間的關聯性，為營運團隊提供了前所未有的收穫：一個不依賴旅後問卷、能即時反映旅客體驗的替代指標。 現在，我們專門來談談火車站 WiFi，因為車站面臨著與車載部署不同的挑戰。車站是一個多區域的環境，包含主大廳、零售區、候車室、月台和停車場。每個區域都有不同的停留時間輪廓與不同的商業影響。在登車前於零售區停留十二分鐘的旅客，其行為輪廓與在出發前兩分鐘抵達並直接前往月台的旅客截然不同。WiFi 分析讓您能夠細分這些行為並採取相應行動 - 無論是調整零售店面的人力配置、重新規劃標示位置，還是透過 Captive Portal 觸發精準的推播通知。在合規性方面，我想在這裡多花點時間說明，因為這是我經常看到營運商犯下代價高昂錯誤的地方：所有這些數據收集都必須在符合 GDPR 的框架內運作。根據 UK GDPR 和 2018 年數據保護法（Data Protection Act 2018），任何個人數據的處理 - 在特定語境下，即使是隨機的裝置 MAC 位址也可能構成個人數據 - 都需要有合法依據。對於大多數交通營運商而言，該合法依據是正當利益，並透過在登入 WiFi 時顯示的透明隱私聲明來支持。Captive Portal 不僅僅是品牌展示的機會，更是您的同意與披露機制。請務必正確處理。Purple 的平台包含可設定的同意流程，專為滿足 ICO 指南而設計，能為您的內部團隊減輕顯著的合規負擔。 還有一個值得注意的技術要點：MAC 位址隨機化。自 iOS 14 和 Android 10 以來，大多數現代裝置都會針對每個網路隨機化其 MAC 位址，這限制了您跨工作階段追蹤回訪裝置的能力。這並不會消除 WiFi 分析功能 - 彙整的人流量和停留時間仍然完全有效 - 但它確實會影響對重複訪客的識別。解決方法是進行驗證的 WiFi：當乘客透過 Captive Portal 使用電子郵件地址或社群帳戶登入時，您就建立了一個持久且經同意的識別碼，該識別碼在 MAC 隨機化後依然存在。這才是數據真正變得豐富的地方。 - 實作建議與常見陷阱 - 2 分鐘 好的，讓我們來談談如何實際部署。無論您是從頭開始，還是將分析功能改造至現有的 WiFi 基礎設施中，我建議您優先考慮以下三件事。 首先，在執行任何其他操作之前，先稽核您現有的無線存取點覆蓋範圍。WiFi 分析的品質完全取決於其所建構的覆蓋範圍。如果月台或車站大廳存在訊號死角，您的數據就會出現缺口，這將損害人流量和停留時間指標的準確性。在進行任何分析部署之前，應該先進行適當的射頻（RF）調查 - 最好使用像 Ekahau 這樣的工具。 其次，及早將您的數據綱要（Data Schema）標準化。在多站點部署中，我最常遇到的問題之一是不同存取點硬體商匯出的工作階段數據格式不一。如果您在主要車站使用 Cisco Meraki，而在滾動軌道車輛上使用其他硬體商的設備，您需要一個整合層，在這些日誌進入分析引擎之前進行正規化。Purple 的平台透過與硬體商無關的 API 層來處理此問題，但如果您正在建置客製化的系統，專案通常會在此處停滯不前。 第三，在正式上線之前定義您的 KPI。這聽起來很顯而易見，但我曾見過營運商部署了完整的分析架構，然後花了六個月的時間爭論該衡量什麼。請預先達成共識：您是要優化每位乘客的吞吐量？商業區域的停留時間？還是將連線成功率作為服務品質的指標？這些指標中的每一個都會驅動不同的儀表板配置和不同的警報閾值。 要避免的陷阱：不要過度關注原始連線數。在發生營運中斷事件時，月台上的高連線數看起來像是高互動率 - 實際上卻是乘客正焦急地確認服務更新。情境至關重要。建立您的分析系統以區分正常的停留模式與因中斷引起的異常飆升。並且不要忽略您的網路安全防護。面向乘客的 WiFi 是一個高風險的受攻擊面。確保您的部署在裝置相容性允許的情況下強制執行 WPA3，實施用戶端隔離以防止乘客裝置之間的橫向移動，並使用 DNS 過濾來阻擋惡意網域。Purple 的平台已將 DNS 安全控制納入標準配置 - 如果您想深入瞭解安全架構，Purple 部落格中有對此進行詳細的技術解析。 - - - 快速問答 - 1 分鐘 以下是我在此主題上經常被問到的幾個問題。 「我們是否可以在沒有票務整合的情況下，使用 WiFi 數據來計算乘客數量？」可以，但有一些限制。WiFi 裝置數量與乘客量密切相關，但其比例會因路線和人口統計特徵而異。在將其用於容量規劃之前，請先與人工計數或驗票閘門數據進行校準。 「車載 WiFi 分析在隧道中運作嗎？」即使行動網路回傳中斷，分析引擎仍會繼續處理來自車載存取點的數據。數據會在本機進行快取，並在恢復連線時進行同步。您在隧道中不會有即時的儀表板，但您也不會遺失工作階段數據。 「小型渡輪營運商的最小可行部署是什麼？」在登船閘口設置一個雲端管理的存取點，在乘客休息室設置一到兩個存取點，以及一個 SaaS 分析平台。在部署後的一週內，您就可以開始產生停留時間和人流量數據，而硬體成本不到五千英鎊。 - - - 摘要與後續步驟 - 1 分鐘 總結來說：乘客 WiFi 不僅僅是一項連線便利設施。它是一項營運智慧資產，如果部署得當，它能為運輸營運商提供對乘客行為、尖峰需求模式以及服務效能指標的即時掌握，這是其他數據源在該成本點上無法比擬的。 該技術已相當成熟。IEEE 802.11ax 硬體已廣泛普及。合規架構也已完善建立。包括 Purple 在內的分析平台都是專為此使用案例而打造的。入門的門檻比大多數營運商想像的還要低。 如果您正在為您的網路評估此方案，實際的下一步是進行覆蓋範圍審計，隨後在一至兩個高流量車站進行概念驗證部署。定義三到五個關鍵績效指標（KPI），執行九十天，並讓數據在內部為此方案提供有力證明。 Purple 的交通運輸團隊與鐵路、巴士及渡輪營運商合作，專門規劃這類部署。您可以造訪 purple.ai/industries/transport 了解更多資訊，或直接與我們聯絡以進行技術簡報。 感謝您的收聽。我們下次再見。 - 腳本結束