USJ 等待時間平台
建立定期更新的資料管線，將即時設施資訊經過蒐集、清洗、儲存後提供前端查詢。
正式營運GWP4 自有產品案例
本案例為 GWP4 自行開發的產品或研究專案，並非外部客戶委託案。列出的內容用於呈現實際技術能力與做法。
- 即時資料
- 排程任務
- 資料清洗
- API
- 視覺化
背景與問題
遊樂園的等待時間資訊雖然存在，但要一個一個點進設施才看得到，在園區內網路不穩時載入又慢，無法一眼掌握全園狀況、也無法比較歷史趨勢。
原本的處理方式
使用者在官方 App 中逐一點開設施查看，無法橫向比較。
設計目標
- 在同一個畫面上呈現所有設施的等待狀況
- 頁面要輕、在弱網路環境下也能快速載入
- 保留時間序列資料，讓使用者能參考歷史模式
- 不需要安裝 App，開瀏覽器即可使用
解決方案
分為四層：蒐集層定期取得最新等待時間；處理層做清洗與標準化並存成時間序列；API 層提供查詢介面；前端呈現看板。重點在於管線要能長期穩定運作，而不是一次性抓取。
核心功能
- 全設施等待時間看板
- 定時蒐集與時間序列儲存
- 資料清洗與標準化
- 歷史趨勢查詢
- 輕量前端，弱網路環境可用
- RESTful API
系統架構
資料源 →（每 5 分鐘）Python 蒐集程式 → 資料清洗與標準化 → 時間序列儲存 → RESTful API → 前端看板。
技術選擇
- Python 定時蒐集
- 資料清洗與標準化流程
- 時間序列資料儲存
- RESTful API
- 輕量前端呈現
開發過程與限制
- 資料源格式可能變動，需要監控與快速修復機制
- 蒐集頻率需在即時性與來源負擔之間取捨
- 園區網路環境不穩，前端必須控制載入體積
可驗證指標
以下皆為可查證的技術事實，不含未經驗證的成效數字。
- 蒐集頻率
- 每 5 分鐘
- 系統分層
- 蒐集 / 處理 / API / 前端 共 4 層
- 資料型態
- 時間序列，保留歷史紀錄
- 上線狀態
- 正式營運中（usj.gwp4.com）
可以延伸到哪些產業
- 觀光與場館營運
- 零售門市即時狀態看板
- 設備稼動率與排隊狀況監控
- 任何需要分鐘級資料更新的營運看板