更换访客 WiFi 服务商：多网点场所迁移核对清单

在多场所跨区域更换访客 WiFi 服务提供商需要导出访客数据、根据 RFC 2865 和 RFC 2866 配置云端 RADIUS，并在分批推广前开展为期 14 天的试点。来自 Cisco Meraki 或 HPE Aruba 等供应商的现有硬件无需更换设备即可集成，而在 30 天的重叠期内保持并行报表则可确保服务连续性。

更换访客 WiFi 提供商究竟涉及哪些工作？

更换访客 WiFi 提供商涉及迁移三项内容：您的访客数据、网络设置和报表。您的接入点无需变动。借助诸如 Purple 的 Guest WiFi 等云端覆盖方案，新提供商可以直接部署在您现有的硬件之上。这些硬件包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。具体逻辑已在 为什么下一次 WiFi 升级不需要新硬件 中详细阐述。

访客 WiFi 迁移中的大部分工作主要围绕三个术语展开：

• 强制门户： 访客在上网前看到的登录页面。
• 围墙花园： 设备在登录前可以访问的域名列表，用于加载门户和任何社交登录页面。
• 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 步：在对接入点进行任何改动之前，先导入清单

首先导入到 Purple Engage。Purple Engage 会接收已同意的访客记录及其同意历史记录，因此每个个人资料都会保留其时间戳、渠道和用词版本。在进行任何切换之前执行此操作，意味着在加载退订列表之前不会发出任何营销信息。这也意味着回访访客所面对的数据库中已包含其记录。

Purple Engage 可与 CRM 和营销平台集成。如果您的电子邮件平台是记录退订信息的权威系统，请在首次营销活动之前（而非之后）完成连接。

第 2 步：构建强制门户、围墙花园和 RADIUS 设置

Purple Access 可在您现有的接入点上处理强制门户和云端 RADIUS。按品牌构建一个门户模板，然后按站点进行克隆，确保站点 ID 从一开始就准确无误。编写包含明确选择加入机制的新同意用词（每个渠道一个），并在上线前记录其版本。

在接入点方面，请参阅针对具体供应商的 Purple 支持文章，而不是复制旧提供商的参数值。不同提供商之间的服务器地址、共享密钥和围墙花园域名均有所不同。直接沿用旧配置的设置是导致切换失败的最常见原因。

第 3 步：切换单个试点站点

选择一个具有代表性而非操作简单的试点站点。该站点应运行最常见的硬件设备、拥有正常的访客量，且处于 IT 团队的辐射范围内。请在营业最清闲的时段进行切换，并保存旧的 SSID 配置，以便在几分钟内完成回滚。

在至少四台设备上进行测试：最新款 iPhone、最新款 Android 手机、Windows 笔记本电脑和 macOS 笔记本电脑。测试您提供的每一种登录方式。随后在第 1 批次切换前让试点运行 14 天，因为某些故障只有在实际负荷下才会显现。

第 4 步：分批次切换

对站点进行分组，以便每个批次都能复用已验证的配置。此决策矩阵决定了实施顺序。

站点概况	批次	原因
代表性站点、常见硬件、靠近 IT 团队	试点	仅在一个站点排查配置故障，而非 30 个站点
与试点站点采用相同的控制器或仪表板	第 1 批次	经过验证的模板，风险最低
采用不同硬件供应商的站点	独立试点，然后进入下一批次	围墙花园和 RADIUS 语法因供应商而异
季节性或低营业额站点	第 1 或第 2 批次	若出现疏漏故障，受影响的访客更少
旗舰或高收入站点	最后一批	采用经过最充分验证的配置
计划期内有活动或高峰日期的站点	高峰日前后各 7 天缓冲期之外	避免在业务最繁忙时违反变更冻结规定

确保每个批次的站点数量均在团队一个班次内可验证的范围内。在结束该批次前，应由当地对接人员确认每个站点的门户均可正常加载。

实际案例：一家拥有 30 家酒店的集团

以下数据为实际测算案例，并非特定客户的实际部署。某拥有 30 家酒店的集团在 22 家酒店使用 Cisco Meraki 运行访客 WiFi，在其余 8 家使用 HPE Aruba。其合同包含 90 天的解约通知期。您可以在我们的 酒店 页面了解有关该行业的更多信息。

具体实施过程。 该集团根据第 28 条选择了“数据返还”，并在第一天发出了通知。导出的数据在第二周送达，共包含 210,000 条记录。其中 31,000 条记录没有同意时间戳，因而作为不可营销数据导入到 Purple Engage 中。试点项目在一家拥有 120 间客房的 Meraki 酒店运行了 14 天。其余 Meraki 酒店借助仪表盘模板分两批完成迁移，分别为 10 家和 11 家。Aruba 旗下资产进行了独立试点，随后一次性完成了剩余 7 家的迁移。

成果。 到第七周时，所有 30 家酒店均已接入新门户。所有门店内发生的最长业务中断仅为 12 分钟，且处于夜间变更时段内。试点酒店的每日登录量与旧供应商的数据差距在 3% 以内。旧合同终止时，还留有 40 天的重叠缓冲期。

如何证明新报表与旧报表相吻合？

在试点期间并行运行两个系统

如果两个系统从未测量过相同的访客群体，您就无法对其报表进行比较。在试点的两周内，请保持旧供应商的仪表盘处于活动状态并启用数据导出功能。在相同的日期和站点从两个系统中提取以下相同的五项指标：

• 每日登录量。
• 独立访客数。
• 新访客与回头客对比。
• 平均会话时长。
• 营销选择加入率。

Purple 的 WiFi 分析 支持按站点以及在整个物业资产范围内生成这些指标的报表。会话时长取决于 RADIUS 计费核算，因此在信任该数值之前，请先确认计费核算记录是否正常接收。

依据定义而非总数进行核对

在第一天，总数往往无法完全对齐，但这本身并不是系统缺陷。大多数差距源自不同的指标定义。一家供应商可能会将每次设备关联都计为一次访问，而另一家供应商可能只统计通过身份验证的会话。一家供应商可能会合并 30 分钟内的会话，而另一家可能不会。

记录下每家供应商的定义，然后在相同口径下进行比较。设备隐私功能也会影响回头客的统计。Apple 在 iOS 14 中引入了私有地址，而 Android 从 Android 10 开始默认将地址随机化。仅通过 MAC 地址识别回头客的供应商，所报告的回头客数量将少于通过登录身份进行匹配的供应商。

在开始前协商确定一个容差范围，例如每日登录量允许 5% 的误差。如果事先没有确定具体数值，任何微小的差距都会引发争议。

在通知期结束前完成验收确认

生成一份单页的验收确认书：列出对比的指标、各供应商的定义、差距以及原因说明。由 IT、营销和采购部门共同签署。然后从旧供应商处最后导出一次历史报表，以便在系统切换后仍能进行同比数据分析。

案例场景：拥有 120 家门店的零售连锁品牌

以下数据为实际操作示例，并非特定客户的真实部署案例。一家拥有 120 家门店的时尚连锁品牌在中央控制器下运行 Ruckus 接入点。集团营销部门需要确保系统切换后仍能保留历年顾客到店趋势分析数据。我们的 零售行业 页面对此领域有更详细的介绍。

实施过程。 试点门店发现社交账号登录在 Android 设备上失败。围墙花园（Walled Garden）中配置了门户域名，但缺少身份提供商的登录域名。IT 部门在第一阶段切换前解决了此问题。在并行报告期内，原提供商记录的每日访问量比 Purple 多出 18%。原提供商将每一次关联均计为访问，而 Purple 仅统计已验证的会话。重新按已验证会话筛选原提供商的导出数据后，双方差距缩小至 2%。

成果。 全部 120 家门店分四批在四周内完成迁移。没有门店在营业时间内发生访客 WiFi 中断。在原合同到期前三周，数据对账以 2% 的差距顺利通过验收，优于约定的 5% 容差标准。

在强制门户迁移过程中，哪些接入点设置最容易出现故障？

绝大多数故障都可以归结为少数几个设置。下表列出了常见问题、对应症状及修复方法。

设置	配置错误时的症状	修复方法
围墙花园缺少新门户域名	手机已连接，但门户始终无法加载	添加 Purple 厂商指南中列出的所有域名，然后移除旧提供商的域名
围墙花园缺少社交登录域名	邮箱登录正常，社交账号登录失败	添加厂商指南中列出的身份提供商域名
RADIUS 共享密钥不匹配	登录已被接受，但设备始终无法上网	在控制器和新服务器上重新输入密钥
RADIUS 计费已停用	显示有登录记录，但会话时长显示为零	启用计费 (RFC 2866) 及过渡更新（Interim Updates）
防火墙拦截 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 协同工作。切换操作会更改控制器或仪表板上的强制门户、围墙花园以及 RADIUS 设置。您的接入点、布线和交换机均保持不变，因此更换提供商是一个配置项目，而非硬件更新换代。

切换后我们是否可以继续向现有访客名单发送电子邮件？

可以，前提是同意证据随名单一同迁移。GDPR 第 7(1) 条要求您证明已获得同意，因此每条记录都需要时间戳、渠道、采集站点以及访客当时看到的具体措辞。Purple Engage 在导入已获同意的记录时会附带该历史记录。没有证据的记录应作为不可营销记录导入。如果同意是以旧提供商自身名义而非以您的品牌名义获得的，则该同意不可转移。

多站点访客 WiFi 迁移需要多长时间？

对于拥有 20 到 150 个场所的大多数资产组合，预计需要六到八周的时间。这包括两周的数据导出、14 天的试点，以及根据您的团队在一个班次内所能核验的工作量而划分的切换批次。共享云仪表板的场所迁移速度更快，因为一个经过验证的模板可以应用于多个场所。请从旧合同的通知日期开始制定计划，并保留至少 30 天的重叠期以进行并行报告。

我们的场所在切换期间会离线吗？

不会，只要您遵循“先试点再分批”的顺序就不会。每个场所都会在其业务最清闲的时间段进行更改，并保存旧配置以便在几分钟内回滚。大多数中断仅持续控制器推送新设置所需的时间。导致较长时间故障的问题（例如缺少围墙花园域名或被阻止的 RADIUS 端口）都会在试点场所发现并解决，而不是蔓延到整个网络资产中。

在不同提供商之间迁移访客数据是否符合 GDPR？

是的，前提是您作为数据控制者，而两家提供商均作为合同约定的数据处理者。GDPR 第 28(3)(g) 条规定，根据您的选择，旧处理者在服务结束时必须返还或删除个人数据。在发出通知之前，请书面选择“返还”。请首先迁移退订名单（suppression list），确保所有选择退出的用户继续保持退出状态。Purple 符合 GDPR 并通过了 ISO 27001 认证。

旧提供商仍持有的数据会怎样处理？

如果您的合同遵循 GDPR 第 28 条，旧提供商必须在服务终止后将其删除。在您核验导出数据并完成报告确认签字后，请索取书面删除确认函。请先对历史报告进行最终导出，因为同比数据对比依赖于这些历史记录。请将删除确认函与您的处理记录一起妥善保存，以备监管机构或访客提出要求时查验。

我们如何证明 Purple 的报告与旧提供商的数据一致？

在试点场所让两个系统并行运行 14 天，并对比五个指标：每日登录量、独立访客数、新访客与回访客对比、会话时长和选择加入率。大多数差异源于对“访问”的定义不同，而非数据错误。记录每个提供商的定义，提前达成公差共识（如 5%），并在旧合同到期前签字确认。

Purple 能否连接到我们现有的 CRM 和电子邮件平台？

可以，Purple 可与 CRM 和营销平台集成。导入的访客档案、新登录和同意变更均可同步流转至您营销团队已在使用的系统中。请在迁移后的首次营销活动前配置好该集成，以便从首次发送开始即可遵循来自任一方的退订要求。这将在 WiFi 登录和电子邮件之间保持统一的同意记录，而这正是 ICO 同意指南所要求的。