乘客 WiFi：運輸業者如何運用 WiFi 數據理解旅程

乘客 WiFi：運輸業者如何運用 WiFi 數據理解旅程 Purple 智慧簡報 — 約 10 分鐘 --- 簡介與背景 — 1 分鐘 歡迎收聽 Purple 智慧簡報。我是主持人，今天我們要深入探討一個大多數運輸業者都擁有、卻未充分發揮其價值的事物：乘客 WiFi 數據。 若您負責火車營運商、公車網或渡輪服務的 IT 或營運工作，您幾乎肯定已部署了 WiFi 基礎設施。乘客期望使用它。但關鍵在於——相同的基礎設施，當結合適切的分析層時，便會成為您所能取得的最強大的營運智慧工具之一。 我們談的是在尖峰需求來臨前就掌握它、描繪乘客在您網路中實際移動的方式，並根據真實行為而非僅僅是售票數據來制定服務規劃決策。 接下來的十分鐘，我想帶您了解技術架構、真實世界的應用案例、您絕不能忽視的合規考量，以及從現狀邁向讓您的 WiFi 真正成為商業智慧資產所需的實際步驟。 讓我們開始吧。 --- 技術深入探討 — 5 分鐘 那麼，讓我們從基礎開始。什麼是乘客 WiFi 分析，它實際上如何運作？ 核心來說，每當乘客連接到您的 WiFi 網路——無論是在火車上、車站內或渡輪上——他們的裝置都會產生一系列數據訊號。存取點會記錄一個連線事件。它會記錄時間戳記、連線持續時間、訊號強度、消耗的數據量，以及至關重要的裝置識別碼。在大多數執行 IEEE 802.11ax——也就是 WiFi 6 的現代部署中，您還會擷取到存取點之間的漫遊交遞，這能告訴您一件極有用的事情：移動。 現在，有趣的地方來了。您無需知道乘客是誰，就能從這些數據中獲得巨大的營運價值。匿名、彙總的 WiFi 訊號能告訴您在給定時間點某個特定區域內有多少裝置存在。那就是人流。它們能告訴您裝置在該區域停留了多久。那就是停留時間。而當您追蹤一個裝置在存取點之間移動時——從車站大廳、到月台、到列車車廂——您就獲得了旅程模式數據。起點、路線和目的地，全部從 WiFi 交遞中推斷出來。 支撐這一切的架構有四層。第一，存取點層——您部署在車站、月台和車廂上的實體硬體。對火車營運商來說，這通常意味著在車站設有運作 802.11ax 的固定基礎設施，以及車上使用蜂巢式回程網路（通常是 LTE 或 5G）以在站間維持連線的系統。第二，數據收集層——一個集中式控制器或雲端管理平台，彙集來自每個存取點的原始連線記錄。第三，分析引擎——在這裡，原始記錄被轉化為有意義的指標。停留時間分佈、尖峰連線時段、區域間移動率。像 Purple 的 WiFi Analytics 層這類平台就坐落在這裡，應用機器學習模型來辨識模式和異常。第四，營運儀表板——這是前端，您的網路規劃人員、車站管理者和商業團隊實際消費洞察的地方。 讓我給您一個具體例子，說明這在實務上看起來如何。一家英國主要鐵路營運商在一個包含十二個城際車站的網路上部署了 WiFi 分析。在第一季內，他們就能清楚看到連線高峰——不僅是按一天中的時段，而是按各月台和各車次。他們能看到最繁忙終點站的第七月台在 07:52 發車前四十分鐘出現連線尖峰，但當該班次誤點時，停留時間便急劇下降。服務表現與乘客行為之間的這種關聯——透過 WiFi 數據量化——為營運團隊提供了一件前所未有的東西：一個不依賴於旅後調查的即時乘客體驗代理指標。 現在，讓我們特別談談火車站 WiFi，因為車站對車上部署提出了不同的挑戰。車站是一個多區域環境。您有主大廳、零售區、候車室、月台和停車場。每個區域都有不同的停留時間概況和不同的商業意涵。一位乘客在乘車前於零售區停留十二分鐘，與另一位在發車前兩分鐘才到並直接前往月台的乘客，其概況截然不同。WiFi 分析讓您能區隔這些行為並據以採取行動——無論是調整零售人力、重新擺設標牌，或是透過 Captive Portal 觸發目標推播通知。 在合規方面，我想花點時間談談，因為這正是我看到業者犯下昂貴錯誤的地方：所有這些數據收集都必須在符合 GDPR 的框架內運作。根據英國 GDPR 和《2018 年資料保護法》，任何對個人資料的處理——而裝置的 MAC 位址，即使是隨機化的，在特定情境下也可能構成個人資料——都需要合法基礎。對多數運輸業者來說，那個合法基礎是「合法利益」，並輔以在 WiFi 登入時提供的透明隱私權聲明。Captive Portal 不僅是品牌展示的機會；它更是您的同意與揭露機制。要正確處理。Purple 的平台包含可配置的同意流程，這些流程是專為符合 ICO 指引而設計的，這能為您的內部團隊省去重大的合規負擔。 還有一點技術問題值得提出：MAC 位址隨機化。自 iOS 14 和 Android 10 起，大多數現代裝置會針對每個網路隨機化其 MAC 位址，這限制了您跨連線追蹤回訪裝置的能力。這並不會扼殺 WiFi 分析——彙總的人流和停留時間依然完全有效——但它確實會影響重複訪客的識別。變通的解決方案是認證式 WiFi：當乘客透過 Captive Portal 以電子郵件地址或社群個人檔案登入時，您便建立了一個持續且經同意的識別碼，它能在 MAC 位址隨機化的情況下存活。這就是數據變得真正豐富之處。 --- 實作建議與陷阱 — 2 分鐘 好的，讓我們談談如何實際部署。無論您是從零開始，還是將分析功能附加到現有的 WiFi 基礎設施上，我建議您優先處理三件事。 第一，在做任何其他事情之前，先審計現有的存取點覆蓋範圍。WiFi 分析的優劣取決於它所依據的覆蓋範圍。如果您的月台或車站大廳存在死角，您的數據就會有缺口，從而削弱人流和停留時間指標的準確性。在進行任何分析部署之前，應先進行適當的 RF 調查——理想上使用像 Ekahau 這類工具。 第二，及早標準化您的數據格式。我在多站點部署中最常見的問題之一是，不同存取點廠商導出的連線數據格式各異。若您的主要車站使用 Cisco Meraki，而車廂上使用不同廠商，則需要一個整合層，在這些記錄送達分析引擎前進行標準化。Purple 的平台透過一個不受廠商限制的 API 層來處理這點，但如果您正在打造客製化解決方案，這正是專案通常會停滯的地方。 第三，在上線前定義好您的關鍵績效指標。這聽起來顯而易見，但我見過業者部署了完整的分析套件後，卻花了六個月爭論該測量什麼。提前達成共識：您是要優化每位乘客的吞吐量？商業區域的停留時間？還是將連線成功率作為服務品質的代理指標？每項指標都會驅動不同的儀表板配置和不同的警示門檻。 要避免的陷阱：不要過度依賴原始連線數量。在服務中斷事件期間，月台上的高連線數看似是參與度——實際上那是乘客在瘋狂地查詢服務更新。情境很重要。建立您的分析系統，使其能夠區分正常的停留模式與因服務中斷導致的高峰。還有，不要忽視您的網路安全態勢。面向乘客的 WiFi 是一個高風險的攻擊面。確保您的部署在裝置相容性允許的情況下強制採用 WPA3，實施客戶端隔離以防止乘客裝置間的橫向移動，並使用 DNS 過濾來阻擋惡意網域。Purple 的平台包含作為標準功能的 DNS 安全控制——若您想更深入探討安全架構，Purple 部落格上有很好的技術分析。 --- 快問快答 — 1 分鐘 關於此主題，我常被問到的幾個問題。 「我們能使用 WiFi 數據來計算乘客人數，而不需要進行票務整合嗎？」可以，但有附帶條件。WiFi 裝置數量與乘客量有很強的相關性，但其比例會因路線和人口統計而異。在依賴它進行容量規劃前，應與人工計數或票閘數據進行校準。 「車上 WiFi 分析在隧道裡能運作嗎？」即使蜂巢式回程網路中斷，分析引擎仍會繼續處理來自車上存取點的數據。數據會被暫存在本地，並在連線恢復時進行同步。您在隧道內不會有即時儀表板，但也不會遺失連線數據。 「對一家小型渡輪業者來說，最低可行的部署是什麼？」在登船口設置一個雲端管理的存取點，在乘客休息室設置一或兩個存取點，以及一個 SaaS 分析平台。您可以在五千英鎊的硬體成本內，於部署一週後開始產出停留時間和人流數據。 --- 總結與後續步驟 — 1 分鐘 總結來說：乘客 WiFi 不僅僅是一項連線便利設施。它是一項營運智慧資產，一旦正確部署，能為運輸業者提供即時的乘客行為、尖峰需求模式及服務表現代理指標的可視性，這是在該成本點上沒有任何其他數據來源能比擬的。 這項技術已經成熟。IEEE 802.11ax 硬體廣泛可用。合規框架已充分建立。分析平台——包括 Purple 的——正是為此應用案例而打造。進入門檻比大多數業者想像的要低。 若您正在為您的網路評估此方案，切實的下一步是進行覆蓋範圍審計，接著在一或兩個高流量車站進行概念驗證部署。定義三到五項關鍵績效指標，執行九十天，讓數據在內部為方案說話。 Purple 的運輸團隊與鐵路、公車及渡輪業者合作，規劃這類部署的範圍。您可以在 purple.ai/industries/transport 找到更多資訊，或直接聯繫我們以取得技術簡報。 感謝收聽。下次見。 --- 腳本結束