切換訪客 WiFi 供應商：多據點場域的移轉檢查清單

在多據點場地更換訪客 WiFi 服務供應商，需要匯出訪客資料、依據 RFC 2865 與 RFC 2866 設定雲端 RADIUS，並在分階段推展前進行為期 14 天的試驗。來自 Cisco Meraki 或 HPE Aruba 等廠商的現有硬體皆可直接整合，無需更換設備，而在 30 天重疊期間維持雙軌並行報表，則可確保服務不中斷。

更換訪客 WiFi 服務供應商到底涉及哪些工作？

更換訪客 WiFi 服務供應商會轉移三項內容：您的訪客資料、您的網路設定以及您的報表。您的無線基地台（AP）會維持在原位。透過如 Purple 的 Guest WiFi 這類雲端覆蓋層，新的供應商可以直接建置在您已擁有的硬體上。這些硬體包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 與 Fortinet。相關原理已在 為什麼您的下一次 WiFi 升級不需要新硬體 中進行了說明。

在訪客 WiFi 移轉過程中，有三個詞彙承擔了大部分的工作：

• 強制入口： 訪客在連線上網前看到的登入頁面。
• 圍牆花園（Walled garden）： 裝置在登入前可存取的網域名稱清單，以確保入口頁面及任何社群登入頁面能夠載入。
• RADIUS： 依據 RFC 2865 定義的通訊協定，無線基地台利用它向伺服器查詢是否准許裝置連線。其記帳擴充功能（RFC 2866）則會向伺服器回報工作階段的開始、結束及持續時間。

最重要的兩種失敗狀況是「斷網日」與「名單遺失」。「斷網日」是指因遺漏設定而導致訪客無法上網的據點。「名單遺失」則是指因同意證明仍留在舊供應商端，而導致您無法再發送電子郵件的行銷資料庫。以下的工作順序正是為了防止這兩種情況發生。

在更換訪客 WiFi 服務供應商之前，您需要準備什麼？

您的合約日期與資料條款

請從舊合約開始，而非網路架構。找出三個日期：通知期限、服務終止日以及任何資料返還期限。根據 GDPR 第 28 條第 3 款第 (g) 目的規定，處理者必須在服務結束時，依據您作為控制者的選擇，刪除或返還個人資料。在發出終止通知之前，請以書面方式致函舊供應商並選擇「返還」。

請規劃新服務上線與舊服務終止之間至少有 30 天的重疊期。您需要這段重疊期來執行後續說明的雙軌並行報表。如果通知期為 90 天，請倒推計算：前兩週內匯出、第 45 天前完成試驗、第 75 天前完成最後一波推展。

所有據點的詳細清冊

您無法為看不到的環境安排切換順序。請建立一份試算表，每個據點佔一列，並包含以下資料欄：

• 無線基地台廠商與控制器或管理後台（例如：Cisco Meraki 儀表板、HPE Aruba Central、Ruckus SmartZone）。
• 訪客 SSID 名稱以及訪客流量所在的任何 VLAN（虛擬區域網路，獨立的網路區段）。
• 該站點的防火牆與寬頻線路所有權人。
• 一位指定的本地聯絡人，可確認入口網站能於手機上正常載入。
• 營運高峰期與暫停異動期間（blackout dates）。

來自舊供應商的乾淨匯出資料

請以書面形式要求匯出資料並明確指定格式。模糊的要求只會換來模糊的檔案。下表列出了應要求的項目。

欄位	需求原因	建議要求的格式
電子郵件地址	行銷與重複資料刪除的主要索引鍵	UTF-8 CSV，每列一筆記錄
行動電話號碼	簡訊行銷與比對	ITU-T E.164 國際格式
各管道的同意標記	依 PECR 規定，電子郵件與簡訊同意必須分開	每個管道一個 true/false 欄位
同意時間戳記	證明給予同意的時間（GDPR 第 7 條第 1 項）	含 UTC 時區偏差的 ISO 8601
同意文字或版本	證明當時向訪客說明的內容	對應至封存入口網站文案的版本 ID
擷取站點	將同意關聯至收集該資訊的場地	與您的資產清冊相符的站點 ID
撤回與取消訂閱	避免向已退出的人員傳送電子郵件	包含日期的獨立排除清單檔案（suppression file）
造訪記錄	報表對賬的基準	各站點近 13 個月的每月總計

收到檔案時請核對資料筆數。如果舊控制台顯示 200,000 筆個人檔案，而檔案中僅有 160,000 筆，在簽核確認前請務必詢問原因。

遷移後依然有效的同意證明

GDPR 第 7 條第 1 項規定，若處理作業仰賴同意，控管者必須能夠舉證。英國資訊委員會辦公室（ICO）的同意指南指出了該記錄應包含的內容：同意者身分、同意時間、同意方式、當時向其說明的內容，以及其是否已撤回同意。僅有一欄「marketing = yes」的電子郵件試算表完全不符合這些檢驗標準。

透過以下三個步驟可完整轉移同意記錄：

1. 封存舊入口網站文案。 將每個版本的登入頁面與隱私權聲明截圖並標註日期，且將每一份對應至同意版本欄位。
2. 檢查同意是以誰的名義取得。 GDPR 敘述理由 42 指出，資料主體至少應知悉控管者的身分。給予您場地品牌的同意可繼續沿用；給予舊供應商自身行銷的同意則無法沿用。
3. 優先匯入排除清單。 任何已取消訂閱的使用者，從第一天起就必須在全新系統中維持取消訂閱狀態。

缺少時間戳記或文案版本的記錄無法用於行銷。請將其作為未獲行銷同意的聯絡人匯入，而非直接刪除，以便完整保留造訪記錄。

如何逐一站點進行訪客 WiFi 遷移？

步驟 1：在改動無線基地台（AP）前先匯入清單

請先匯入至 Purple Engage。Purple Engage 會匯入已同意的訪客記錄及其同意歷史記錄，因此每份設定檔都會保留其時間戳記、管道和文字版本。在進行任何移轉切換之前先完成此步驟，可確保在載入抑制清單（suppression list）前不會發送任何行銷內容。這也代表再次來訪的訪客能與已存有其記錄的資料庫進行比對。

Purple Engage 可與 CRM 和行銷平台整合。如果您的電子郵件平台是取消訂閱記錄的單一真實來源系統（system of record），請在進行第一次宣傳活動之前完成連線，而非事後才連接。

步驟 2：建立強制入口、圍牆花園（walled garden）與 RADIUS 設定

Purple Access 可在您現有的無線基地台（AP）上處理強制入口與雲端 RADIUS。請為每個品牌建立一個入口範本，然後按站點進行複製，以確保站點 ID 從一開始就正確無誤。請撰寫具有自主選擇加入（opt-in）機制的新同意文字（每個管道各一則），並在正式上線前記錄其版本。

在無線基地台方面，請參考 Purple 針對您特定廠商所提供的支援文章，而不要直接複製舊供應商的設定值。不同供應商之間的伺服器位址、共用金鑰（shared secrets）和圍牆花園網域均有所不同。沿用舊設定通常是導致移轉切換失敗最常見的原因。

步驟 3：切換單一試點站點

選擇一個具代表性而非最容易處理的試點站點。該站點應運作您最常用的硬體設備、具備正常的訪客流量，且位於 IT 團隊便於支援的範圍內。請在營業離峰時段進行切換，並保留儲存舊的 SSID 設定，以便能在數分鐘內完成復原。

請至少在四種裝置上進行測試：最新款 iPhone、最新款 Android 手機、Windows 筆記型電腦以及 macOS 筆記型電腦。請測試您提供的每種登入方式。接著在進行第 1 梯次移轉前，讓試點站點運作 14 天，因為有些問題只有在實際負載下才會顯現。

步驟 4：分梯次切換

將站點分組，以便每個梯次都能重複使用已經過驗證的設定。此決策矩陣可用來設定優先順序。

站點特徵	梯次	原因
代表性站點、常見硬體、鄰近 IT 團隊	試點	在單一站點找出設定錯誤，而非 30 個站點
與試點站點使用相同控制器或儀表板	第 1 梯次	經過驗證的範本，風險最低
不同的硬體廠商	獨立試點，接續下一梯次	圍牆花園與 RADIUS 語法因廠商而異
季節性或低營業額站點	第 1 或第 2 梯次	若有未發現的錯誤，受影響的訪客較少
旗艦店或營收最高的站點	最後梯次	獲得最成熟且經充分驗證的設定
計劃期間內有活動或處於高峰期的站點	避開高峰期前後 7 天的緩衝期	避免在最繁忙的時刻違反變更凍結（change freeze）規定

每個梯次的站點數量應控制在團隊單一班次即可驗證完畢的範圍內。在該梯次結束之前，應由當地聯絡人確認每個站點的入口頁面皆能正常載入。

實際應用情境：擁有 30 間飯店的集團

以下數據為實際推演範例，並非特定客戶的實際部署情況。某擁有 30 家飯店的集團在其中 22 家據點採用 Cisco Meraki，並在 8 家據點採用 HPE Aruba 來提供訪客 WiFi。其合約規定須提前 90 天通知。您可以前往我們的 飯店 頁面，深入了解該產業的相關資訊。

**執行內容：**該集團根據第 28 條規定選擇「返還」，並在第一天發出終止通知。匯出資料在第二週送達，共計 210,000 筆記錄。其中有 31,000 筆沒有同意時間戳記，因此作為非行銷對象匯入至 Purple Engage。試行計畫在一家擁有 120 間客房的 Meraki 飯店進行了 14 天。其餘的 Meraki 飯店透過資訊看板範本，分兩波進行遷移（分別為 10 家與 11 家）。Aruba 據點則進行了專屬的試行計畫，隨後以一波 7 家的方式完成遷移。

**成果：**到了第七週，所有 30 家飯店皆已導入新入口網站。任何據點的最長中斷時間僅為 12 分鐘，且發生在夜間變更期間。試行據點的每日登入次數與舊廠商數據相較，差異在 3% 以內。舊合約終止時，尚有 40 天的重疊緩衝期。

如何證明新報表與舊報表一致？

在試行階段讓兩套系統並行運作

您無法比較兩套從未測量過相同訪客的系統報表。在試行的兩週內，請維持舊廠商的資訊看板運作並啟用匯出功能。針對相同的日期與據點，從兩套系統中擷取以下相同的五項指標：

• 每日登入次數。
• 不重複訪客數。
• 新訪客與回訪客比較。
• 平均工作階段長度。
• 行銷同意（opt-in）率。

Purple 的 WiFi Analytics 會針對個別據點及整個集團提供這些報告。工作階段長度取決於 RADIUS 帳務計費，因此在採信該數字之前，請確認計費記錄已正常送達。

依定義進行核對，而非比對總數

總數在第一天通常難以完全一致，這本身並非系統問題。大部分的落差源自於定義的不同。一家廠商可能會將每一次裝置連線皆計為一次造訪；另一家廠商則僅計算經過驗證的工作階段。有的可能會將 30 分鐘內的工作階段合併，有的則不會。

記錄每家廠商的定義，然後在相同基礎上進行比較。裝置隱私功能也會影響回訪客的計數。Apple 在 iOS 14 中推出了專用位址，而 Android 從 Android 10 開始預設隨機分配位址。僅透過 MAC 位址識別回訪客的廠商，所回報的回訪客數量會少於透過登入身分進行比對的廠商。

在開始之前請先商定容許誤差，例如每日登入次數誤差在 5% 以內。如果沒有事先約定數字，任何落差都會引發爭議。

在通知期結束前完成簽核

製作一份單頁的簽核文件：包含比較的指標、各廠商的定義、落差幅度與原因說明。請讓 IT、行銷和採購部門共同簽署。接著從舊廠商處匯出最後的歷史報表，以確保在切換系統後仍可保留歷年同期比較的數據。

實際案例情境：擁有 120 家門市的連鎖零售店

以下數據為實際推算的範例，並非特定部署專案。某家擁有 120 間門市的時裝連鎖店，透過集中式控制器管理 Ruckus 台無線基地台。集團行銷團隊需要維持歷年顧客造訪趨勢資料的延續性，不受系統轉換影響。我們的 零售業 頁面針對該產業進行了更詳細的說明。

執行過程。 試點門市發現社群登入在 Android 裝置上失敗。圍牆花園（Walled Garden）包含入口網站的網域，但缺少識別提供者的登入網域。IT 部門在第一階段推廣前修正了此問題。在平行比對報表時，原廠商顯示的每日造訪次數比 Purple 多出 18%。原廠商計算了每次關聯（association），而 Purple 僅計算已驗證的工作階段。將原廠商的資料僅以已驗證工作階段重新匯出後，差距縮小至 2%。

成果。 所有 120 間門市在四週內分四梯次完成轉換。沒有任何門市在營業時間內遺失訪客 WiFi 服務。在原合約結束前三週，雙方以 2% 的差距完成核對驗收，符合協議的 5% 容許值。

進行強制入口移轉時，最常出問題的無線基地台設定有哪些？

大多數失敗都可以追溯到少數幾項設定。此表格列出各項設定、發生錯誤時的症狀以及解決方案。

設定	錯誤時的症狀	解決方案
圍牆花園遺漏新入口網站網域	手機已連線，但入口網站無法載入	新增 Purple 廠商指南中的所有網域，然後移除舊廠商的網域
圍牆花園遺漏社群登入網域	電子郵件登入正常，但社群登入失敗	新增廠商指南中列出的識別提供者網域
RADIUS 共用密鑰不符	已接受登入，但裝置始終無法上網	在控制器與新伺服器上重新輸入密鑰
RADIUS 會計記帳功能已停用	顯示登入紀錄，但工作階段長度顯示為零	啟用會計記帳功能（RFC 2866）並設定定期更新
防火牆封鎖 RADIUS 連接埠	僅在單一站點發生登入逾時	允許出站 UDP 1812 與 1813，即 RFC 2865 與 RFC 2866 指定的連接埠
站點識別碼對應錯誤	工作階段顯示在錯誤的場地	將控制器的站點識別碼與 Purple 站點 ID 配對
舊的重新導向設定殘留在某個無線基地台群組	站點有一半顯示舊入口網站	稽核每個 SSID 與無線基地台群組，而不僅是預設群組
複製了舊廠商的工作階段逾時設定	訪客在造訪途中被要求重新登入	將逾時設定為您的造訪停留時間；請參閱 如何在訪客 WiFi 上實施時間與頻寬限制

存在於舊廠商內部的政策

部分廠商是在自己的雲端套用內容過濾或頻寬限制，而非在您的硬體上執行。當您轉換系統時，這些政策會無預警消失。請列出舊廠商強制執行的每項政策，並在切換前逐一重新建立。深夜營業場所最常面臨此問題，正如 夜店與深夜營業場所 WiFi 供應商：內容過濾、尖峰負載容量與員工存取權限 所述。

時鐘與憑證問題

RADIUS 計費與入口網站憑證皆依賴正確的時間。時鐘偏差的控制器所產生的工作階段記錄會落在錯誤的日期。請在試行前將每個控制器指向可靠的 NTP（網路時間協定）來源。

更換需要多少成本，以及您能獲得什麼回報？

需編列預算的成本項目

在現有硬體上進行更換有四個成本項目，全都不屬於硬體：

• 重疊授權。 預計至少需同時支付兩家供應商 30 天的費用。
• 各站點的 IT 工時。 試行之後，以範本為基礎的儀表板能大幅縮減此項工時。使用獨立控制器的站點則需要較長時間。
• 資料清理。 必須有人對應同意版本、消除重複記錄並載入排除名單。
• 現場驗證。 每個站點指派一名指定人員在當天檢查入口網站是否能正常載入。

Purple 透過三種方案提供授權：Connect、Capture 和 Engage。採購部門應針對重疊期為所需的方案進行定價，而非以轉換起算的一整年計算。

您獲得的回報

您可保留已擁有的無線基地台，因此無硬體資本支出。您可保留能合法發送電子郵件的行銷名單，因為同意證明會隨每筆記錄一同移轉。您將在每個站點獲得單一報表模型，因此全資產規模的比較不再取決於哪家供應商經營哪個場地。

您也加入了已在大規模環境中獲得驗證的平台。Purple 運行於 90 多個國家/地區的 80,000 多個場地，每年處理 5 億名使用者與登入次數。Purple 提供 99.999% 的正常運行時間，擁有 ISO 27001 認證，並符合 GDPR 規範。

常見問題

要將訪客 WiFi 供應商更換為 Purple，我們需要新的無線基地台嗎？

不需要，Purple 可在您現有的無線基地台運作。Purple 與硬體無關，可與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 搭配使用。這項更換會變更控制器或儀表板上的強制入口、圍牆花園 (walled garden) 和 RADIUS 設定。您的無線基地台、佈線和交換器皆保留原狀，因此更換供應商是一項配置專案，而非硬體汰換。

更換後，我們是否能繼續向現有的訪客名單發送電子郵件？

可以，前提是同意證明隨名單一同移轉。GDPR 第 7 條第 1 款要求您必須能證明取得同意，因此每筆記錄都需要時間戳記、管道、擷取站點以及訪客所看見的用詞文字。Purple Engage 匯入已獲同意的記錄時會附帶該歷程記錄。沒有證明的記錄應匯入為不可行銷。若同意是給予舊供應商本身名義而非您的品牌，則無法移轉。

多站點訪客 WiFi 移轉需要多久時間？

對於大多數擁有 20 到 150 個據點的產業規模，請預留六到八週的規劃時間。這涵蓋了兩週的匯出期、14 天的試行期，以及依您團隊在一個班次內所能驗證的數量來規劃的分批切換（cutover waves）。共用雲端儀表板的據點遷移速度更快，因為一個經過驗證的範本即可套用於多個據點。請從您舊合約的終止通知日開始規劃，並至少保留 30 天的重疊期以進行平行報表對比。

我們的據點在切換期間會離線嗎？

不會，只要您遵循先試行後分批的順序即可。每個據點都會在離峰營業時間進行變更，並保留舊有設定，以便在數分鐘內復原。大多數的中斷時間僅相當於控制器推送新設定所需的時間。導致較長時間中斷的故障（例如遺漏圍牆花園網域或 RADIUS 連接埠受阻），都會在試行據點被找出並解決，而非擴散至整個產業據點。

在不同服務供應商之間遷移訪客資料是否符合 GDPR 規定？

是的，當您擔任控制者，且兩家服務供應商依合約均擔任處理者時即符合規定。GDPR 第 28(3)(g) 條規定，舊處理者必須在服務結束時依您的選擇歸還或刪除個人資料。在發出終止通知前，請以書面形式選擇「歸還」。請優先遷移禁止名單（suppression list），以確保所有已選擇退出的人員維持退出狀態。Purple 符合 GDPR 規範並通過 ISO 27001 認證。

舊服務供應商仍持有的資料會如何處理？

如果您的合約遵循 GDPR 第 28 條，舊服務供應商必須在服務結束後將其刪除。在您驗證匯出的資料並完成報表簽核後，請索取書面的刪除確認函。在此之前，請先完成歷史報表的最終匯出，因為同期比對需仰賴這些歷史資料。請將刪除確認函與您的處理活動紀錄一併妥善保存，以備監管機構或訪客查詢。

我們該如何證明 Purple 的報表數據與舊服務供應商一致？

在試行據點讓雙方系統平行運作 14 天，並比對五項指標：每日登入數、不重複訪客數、新訪客與回訪客比例、連線工作階段長度以及同意加入率（opt-in rate）。大多數落差源自對「造訪」的定義不同，而非資料錯誤。請記錄每家供應商的定義、預先議定容許誤差（例如 5%），並在舊合約終止前完成簽核。

Purple 能否與我們現有的 CRM 和電子郵件平台串接？

可以，Purple 可與 CRM 及行銷平台整合。匯入的訪客個人檔案、新登入記錄與同意狀態變更，皆可串聯至您行銷團隊既有的系統。請在遷移後的首次行銷活動前啟用整合功能，以確保任一方的取消訂閱要求從首次寄送起即被落實。如此一來，即可在 WiFi 登入與電子郵件之間維持單一同意紀錄，符合 ICO 同意指引中的合規要求。