跳至主要内容

设计 B2B Captive Portal:收集注册姓名与公司数据

本指南为 IT 经理和场所运营者提供了一个与供应商无关的技术框架,用于设计 B2B captive portals。它详细介绍了如何构建注册字段以捕获注册姓名和公司数据,在确保高完成率的同时,保持 GDPR 合规并构建账户级智能。

📖 5 分钟阅读📝 1,109 🔧 2 应用实例3 练习题📚 8 关键定义

收听本指南

查看播客转录
欢迎阅读 Purple 智能简报。我是 Purple 的高级技术内容策略师。今天,我们将探讨一个在我参与的几乎所有 B2B 场馆部署中都会遇到的课题:如何设计一个能正确收集注册姓名和公司数据的 Captive Portal。 这不仅仅是消费级 WiFi 的问题。当您在会议中心、设有会议设施的酒店、联合办公空间或商务机场贵宾室运营 WiFi 时,您的访客不仅仅是宾客。他们是专业人士,拥有职称、公司背景和采购决策权。您在 WiFi 注册环节收集的数据是您所能获取的商业价值最高的第一方数据之一。但大多数场馆要么收集得太少,要么收集方式错误,要么收集方式带来了 GDPR 合规风险。今天我们就要解决这三个问题。 让我来还原一下场景。Captive Portal 是在授予网络访问权限之前,拦截访客连接请求的网页。设备连接到您的 WiFi SSID,尝试发送 HTTP 请求,接着您的网络控制器会将该请求重定向到您的门户网站。访客会看到您的品牌登录页面,填写注册表单,然后获得访问权限。这就是基本流程。发生改变的是您随后对数据的处理方式,以及您所处的监管合规环境。 与消费级部署相比,B2B 环境极大地改变了设计需求。在消费级场景中,您通常只需要询问姓名和电子邮件地址,用于构建营销列表。而在 B2B 场景中,您需要注册姓名和公司数据,因为这种组合可以解锁客户级别的智能分析。当您得知在三天内,有 47 名来自同一家金融服务公司的员工连接了您会议中心的 WiFi 时,这不仅仅是一个客流量统计数据,而是一个销售信号,是活动投资回报率(ROI)数据。正是这种智能分析,为您场馆的商业合作提供了价值支撑。 接下来我们谈谈技术架构。一个 B2B Captive Portal 部署有四个核心组件。首先是接入点层:Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet。接入点拦截初始连接并重定向到门户网站。其次是门户控制器,用于提供注册页面、验证表单提交,并与您的 RADIUS 服务器通信以授权设备的 MAC 地址。第三是身份存储库,用于存储注册姓名、公司数据和同意记录,并实时同步到您的 CRM 系统。第四是分析层,用于聚合会话数据、停留时间和重复访问模式,使其具备可操作性。 Purple 在所有这些硬件平台上作为云端覆盖网络运行。您无需拆除并更换现有的基础设施。您只需在已有的任何接入点上部署 Purple 即可。在 2024 年,覆盖了 80,000 个活跃场所以及 4.4 亿次登录,对于评估您自己的部署来说,这是一个非常庞大且有参考价值的数据集。 现在谈谈表单设计的问题。您应该包含哪些字段?直觉是索要所有信息:姓名、公司、职位、部门、电话号码、LinkedIn 个人资料。请克制这种直觉。每增加一个字段,都会降低您的表单完成率。将字段从两个增加到五个,表单完成率会下降大约 20%。在场所环境中,这意味着五分之一的商务访客会完全放弃尝试连接。 最小可行的 B2B 字段集是:全名、公司名称和商业电子邮箱。全名用于识别个人。公司名称用于进行客户账户聚合。商业电子邮箱提供了一个经过验证的联系点,更关键的是,即使访客输入的公司名称不一致,域名后缀也能让您辨识出公司身份。有人可能会注册为 Deloitte、Deloitte UK 或 Deloitte LLP,但他们的邮箱域名始终是 deloitte.com。请围绕邮箱域名而不是自由文本的公司名称字段来构建您的数据规范化逻辑。 职位是一个有价值的可选字段。它可以按职级和职能对您的访客数据进行细分。但请将其设为可选。跳过职位字段的访客仍然是拥有姓名和公司的已注册访客。而完全放弃表单的访客则不会给您留下任何信息。 现在让我们来谈谈 GDPR,因为在设计 B2B Captive Portal 时,必须具备稳固的合规架构。根据 UK GDPR 和欧盟通用数据保护条例,从 WiFi 访客那里收集姓名和公司数据需要合法的处理依据。对于 B2B Captive Portal,您有两个切合实际的选择:根据第 6(1)(a) 条的同意,或根据第 6(1)(f) 条的正当利益。 从合规角度来看,同意是更清爽的选择。访客主动勾选一个框,您记录时间戳以及他们看到的隐私声明版本,这样您就拥有了可辩护的审计追踪。同意面临的挑战是它必须是自愿给出的。这意味着 WiFi 接入不能以同意营销为前提条件。您需要将网络接入的同意与营销沟通的同意分开。两个复选框:一个用于服务条款(强制),一个用于营销(可选)。切勿将它们捆绑在一起。 正当利益是一个更微妙的依据。它可以适用于出于网络安全和管理目的处理基本会话数据。但对于通过访客注册来构建营销数据库,正当利益则更难辩护,特别是对于个人属于可识别专业人士的 B2B 数据。我的建议是:使用同意,合理设计表单,您将获得清爽的合规态势。 在进入实施之前,还有一个技术点需要说明。即 MAC 地址随机化。自 iOS 14 和 Android 10 以来,移动设备在默认情况下会针对每个网络随机化其 MAC 地址。这意味着,即使是同一台设备和同一个人,访问者今天连接时您的接入点看到的 MAC 地址也可能与上个月看到的 MAC 地址不同。对于 B2B 注册名称和公司数据的收集,这不是什么大问题,因为您的身份锚点是注册的电子邮件地址,而不是 MAC 地址。电子邮件地址是稳定的。围绕电子邮件构建您的身份解析逻辑,MAC 随机化就会变成次要问题。 现在,让我带您了解两个实际的实施场景,以说明这在实践中是如何运作的。 第一个是位于金融区的会议中心。他们每年举办 200 场活动,每场活动平均有 300 名与会者。在部署设计合理的 B2B 登录页面(Captive Portal)之前,他们的 WiFi 注册数据非常混乱:公司名称不一致、使用个人电子邮件地址、没有职位数据,也没有同意记录。他们无法回答一些基本问题,比如哪些公司给我们派出的代表最多,或者我们与会者的平均资历如何。 在部署了包含全名、公司名称、商业电子邮件和可选职位字段,并在后端结合了电子邮件域名规范化的结构化 B2B 门户之后,他们在六个月内建立了一个干净的账户级数据库。他们现在可以向参展商展示,其 34% 的与会者来自富时 100 指数(FTSE 100)公司。这一数据点直接支持了其赞助费率 40% 的增长。WiFi 注册表单变成了一项创收资产。 第二个场景是一家拥有 45 家物业的酒店集团,每家物业都配有会议设施。他们面临的挑战是一致性:每个物业的门户配置略有不同,字段设置不同,且数据存储在不同的系统中。在曼彻斯特物业参加过会议,然后又入住伦敦物业的宾客,会被视为两个独立的、毫无关联的访客。 通过在所有 45 家物业中标准化部署单一的 B2B 门户模板,并采用集中式数据存储和基于电子邮件的身份解析,他们建立了一个统一的访客数据库。在 12 个月内,他们识别出 8,200 名曾使用过多个物业的商务访客。该群体成为了针对性目标账户营销计划的基础。通过该识别群体带来的新增会议预订,在第一季度内就收回了部署标准化门户的成本。 现在,让我为您列出要避免的实施陷阱。这些是我最常看到的错误。 陷阱一:没有进行规范化的自由文本公司名称。如果您接受公司名称的自由文本输入,并且没有在后端对其进行规范化,您的数据库将包含同一家公司的数百种变体。请将电子邮件域名作为您的主要公司标识符。 陷阱二:将 WiFi 访问授权与营销授权捆绑。这违反了 GDPR。信息专员办公室明确规定:营销授权必须与服务本身的授权分开。如果访客必须同意接收营销电子邮件才能获得 WiFi 访问权限,则该授权不是自由做出的,因此无效。 陷阱三:在 B2B SSID 上没有设置会话超时或带宽策略。设置单台设备的带宽上限和会话超时。对于会议环境,四小时是一个合理的默认值。 陷阱四:将授权记录与会话日志存储在同一个系统中。授权记录的保留期限需要比会话日志更长。会话日志可以在 30 天后清除。授权记录应在合作关系存续期间加两年内予以保留。使用像 Purple 这样能够自动对不同数据类型应用不同保留规则的平台。 现在解答我最常被问到的快速问答。 对于 B2B 场所,我们应该使用 LinkedIn 登录而不是注册表单吗?LinkedIn OAuth 可以让您获取姓名、公司、职位和行业领域,而无需访客输入任何内容。数据质量高于自由文本输入。权衡之处在于转化率较低:并非每个商务访客都有 LinkedIn 账号。我的建议是将 LinkedIn 作为一种选项与标准表单并列提供,而不是作为唯一的方法。 我们如何处理使用个人电子邮件地址而不是企业电子邮件的访客?您可以通过对照已知消费级域名列表进行验证并拒绝它们,从而要求必须使用企业电子邮件域名。或者,您可以接受任何电子邮件地址,并将个人域名标记出来以进行手动审查。对于高价值的 B2B 场所,我建议采用第一种方法,并附上清晰的错误提示信息,说明为什么需要企业电子邮件。 我们能将 Captive Portal 数据直接与 Salesforce 或 HubSpot 集成吗?可以。Purple 的平台提供与主流 CRM 平台的原生集成。注册的姓名和公司数据将直接流向您的 CRM 成为新联系人,或更新现有记录,同时将 WiFi 访问记录为一项活动。 总结一下今天简报的关键要点。 围绕三个必填字段设计您的 B2B Captive Portal:全名、公司名称和企业电子邮件。将职位作为可选字段。保持表单简短。每增加一个必填字段都会降低您的完成率。 使用电子邮件域名作为您的规范公司标识符。在后端规范化自由文本公司名称。基于电子邮件域名构建您的账户级智能分析,而不是基于访客在公司名称字段中输入的内容。 将您的同意复选框分开。一个用于服务条款和网络访问的强制性复选框。一个用于营销沟通的可选复选框。切勿将它们捆绑。记录每个带有时间戳和隐私声明版本的同意事件。 通过将您的身份识别锚定到电子邮件地址而不是 MAC 地址,来应对 MAC 随机化。电子邮件在不同会话和设备之间是稳定的。 最后,选择一个能为您处理合规架构的平台。Purple 已通过 ISO 27001 认证,符合 GDPR 和 CCPA,并获得 Cyber Essentials 认证。同意日志记录、数据保留规则和数据主体访问请求响应工具均已内置。 您的下一步是根据我今天概述的字段集和合规性清单审计您当前的门户配置。如果您正在运营 B2B 场所,而没有以结构化、合规的方式收集注册名称和公司数据,那么您就是在流失商业情报。 如需更多技术指南和实施资源,请访问 purple.ai。感谢收听 Purple 情报简报。

header_image.png

執行摘要

設計 B2B Captive Portal 需要採用與面向消費者的零售部署不同的架構方法。對於會議中心、酒店和商務樞紐的 IT 經理及場地運營總監而言,首要目標不僅僅是構建一個通用的電子郵件列表,而是捕獲結構化的註冊姓名和公司數據,以構建帳戶級別的情報。

本技術指南概述了在捕獲具有商業價值的首方數據的同時、最大化表單完成率所需的精確字段架構。它涵蓋了從接入點到 CRM 的技術數據流、B2B 數據處理所需的特定 GDPR 合規機制,以及如何使用電子郵件域名來規範公司身份。通過在 Cisco Meraki 或 HPE Aruba 等硬件平台上實施這些與廠商無關的建議,場地可以將其訪客 WiFi 從成本中心轉變為可衡量的商業投資回報率(ROI)驅動器。

技術深度解析

Captive Portal 會攔截訪客的初始 HTTP 請求,並在授予網絡訪問權限之前,將其設備重定向到託管的登錄頁面。在 B2B 環境中,在此身份驗證流期間捕獲的數據非常有價值。然而,該架構必須在數據收集需求、用戶摩擦和合規義務之間取得平衡。

B2B 字段架構

B2B Captive Portal 設計中最常見的失敗模式是表單冗餘。研究一致表明,將必填字段從兩個增加到五個會導致表單完成率下降 20%。對於會議中心繁忙的商務專業人士而言,冗長的註冊表單會直接導致放棄連接。

最佳的 B2B 註冊表單包含且僅包含三個必填字段:

  1. 姓名:識別個人訪客。
  2. 公司名稱:提供明確的商務隸屬關係。
  3. 企業電子郵件:作為經過驗證的聯繫方式和主要的身份錨點。

職位應作為可選字段。它為參展商或贊助商提供了有價值的細分數據,但將其設為必填會引入不必要的摩擦。

captive_portal_b2b_form_mockup.png

身份解析與數據規範化

B2B 數據收集中的關鍵技術機制是使用電子郵件域名進行身份解析,而不是依賴自由文本格式的公司名稱字段。訪客輸入的公司名稱往往不一致(例如,"Deloitte"、"Deloitte UK"、"Deloitte Consulting")。

您的后端逻辑必须使用电子邮件域名后缀(例如 @deloitte.com)对这些输入进行规范化。这可以确保来自同一组织的 50 名访客在您的 CRM 中被聚合到单个账户档案中,无论他们如何输入公司名称。这种方法还减轻了 MAC 地址随机化(在 iOS 14 和 Android 10 中引入)的影响,因为经过验证的电子邮件地址在不同设备和会话之间保持稳定。

技术架构与数据流

合规的 B2B Captive Portal 数据流涉及四个不同的层级。Purple 作为跨这些层级的云覆盖层运行,与现有基础设施进行集成,而无需采用“推倒重来”的方法。

  1. 接入点层 (Access Point Layer):来自 Cisco Meraki、HPE Aruba 或 Juniper Mist 等厂商的硬件拦截连接并处理重定向。
  2. Portal 控制器 (Portal Controller):提供品牌化的注册页面并验证提交的数据。
  3. 身份存储 (Identity Store):安全地存储注册姓名、公司数据和明确的同意日志。
  4. 分析与 CRM 集成 (Analytics and CRM Integration):对数据进行规范化,并通过 API 将其同步到营销平台或 CRM 系统。

b2b_data_architecture_diagram.png

实施指南

部署 B2B Captive Portal 需要仔细配置网络硬件和 Portal 软件。

第 1 步:网络配置

将您的访客 SSID 配置为使用带有 Captive Portal 重定向的开放网络。确保在客户端设备支持的情况下启用 WPA3,以便在开放网络上提供空中加密。将访客 VLAN 与企业网络完全隔离,将流量直接路由到防火墙。

第 2 步:Portal 设计

使用最小字段集构建注册页面:全名、公司名称和业务电子邮件。如果在您的场所政策中严格要求使用商务地址,请对电子邮件字段实施域名验证,以拒绝已知的个人电子邮箱域名(例如 @gmail.com@yahoo.com)。

第 3 步:同意架构

为网络访问和营销传播设置独立的复选框。服务条款复选框是访问所必需的;营销复选框必须是可选的,且默认不勾选。

第 4 步:CRM 集成

配置从 Portal 控制器到 CRM 的 API Webhook。将 Portal 字段映射到相应的联系人和账户对象,使用电子邮件域名来处理账户匹配和去重。

最佳实践

在设计 B2B Captive Portal 时,请遵循以下行业标准建议:

  • 强制使用业务电子邮件:对于高价值的 B2B 场所,验证电子邮件输入以拒绝个人电子邮箱域名。这可以确保收集的数据在专业上具有相关性。
  • 实施会话限制:实施每台设备的带宽上限和会话超时(例如 4 小时)。这可以防止单一设备垄断网络,并在此类访客停留时间较长时强制其重新进行身份验证。
  • 谨慎提供社交登录:LinkedIn 登录可提供出色的 B2B 数据(姓名、公司、职位),无需手动输入。将其作为一种选项提供,但请务必提供标准表单作为备用方案,因为并非所有访客都会在企业设备上授权社交连接。

故障排除与风险缓解

部署 Captive Portal 的主要风险是违反监管合规性,特别是在 UK GDPR 框架下。

管理 GDPR 合规性

收集注册姓名和公司数据构成了处理个人数据。您必须为此处理建立合法依据。虽然正当利益可以涵盖网络安全所需的基本会话数据,但建立营销数据库需要根据第 6(1)(a) 条获得明确同意。

请勿捆绑同意。如果访客必须同意接收营销电子邮件才能访问 WiFi,则该同意并非自愿给出,是无效的。您的 Portal 必须记录同意的确切时间戳以及所显示隐私声明的版本。

数据保留

请勿将会话日志和同意记录存储在具有相同保留政策的同一系统中。用于故障排除的会话日志应在 30 天后清除。同意记录必须保留在合作关系存续期内再加上两年,以处理数据主体访问请求 (DSAR)。使用能够自动执行这些不同保留规则的平台。

ROI 与业务影响

精心设计的 B2B Captive Portal 可以将匿名的客流量转化为结构化的账户情报。对于会议中心而言,了解到 34% 的与会者来自富时 100 指数 (FTSE 100) 公司可以直接支持更高的赞助和广告费率。对于酒店集团而言,识别出访问多个物业的商务旅客,可以实现高度针对性的基于账户的营销活动,从而推动直接预订。投资回报率的衡量不仅在于营销名单的规模,还在于注册公司数据所产生的可操作销售信号。

播客简报

收听我们的高级技术顾问讲解 B2B Captive Portal 的技术架构和合规要求。

关键定义

Captive Portal

一个拦截访问者连接尝试并在授予网络访问权限之前强制进行交互(例如注册或身份验证)的网页。

在访客 WiFi 网络上获取第一方数据和执行服务条款的主要机制。

Identity Resolution

将分散的数据点匹配到单一、统一配置文件的过程。

在 B2B WiFi 中,这意味着使用企业邮箱域名将访问者链接到特定的企业账户,而不是依赖临时的 MAC 地址。

MAC Address Randomisation

现代移动操作系统中的一种隐私功能,可生成临时的、特定于网络的硬件地址,以防止跨网络追踪。

迫使 IT 团队依靠经过验证的数据(如邮箱地址)而不是硬件标识符来进行访问者分析。

Data Normalisation

对数据进行结构化和标准化的过程,以消除冗余和不一致性。

对于 B2B 门户至关重要,因为访问者可能会输入 "IBM"、"IBM UK" 或 "I.B.M." - 规范化会将这些归类在 ibm.com 域名下。

Article 6(1)(a) Consent

GDPR 合法依据,要求自由给予、具体、知情且毫不含糊地表明数据主体的意愿。

将 WiFi 访问者添加到营销数据库所需的法律依据。

Article 6(1)(f) Legitimate Interests

GDPR 合法依据,如果数据处理对于组织的合法利益是必要的,且不侵犯用户的权利,则允许进行数据处理。

可用于证明为网络安全处理基本会话数据的合理性,但通常不足以用于 B2B 营销数据收集。

RADIUS Server

远程用户拨号认证系统;一种网络协议,提供集中的身份验证、授权和计费管理。

注册完成后与门户控制器通信以授权设备 MAC 地址的后端系统。

VLAN Isolation

配置网络交换机以将特定流量隔离到其专属的虚拟局域网中。

一项强制性的安全实践,旨在确保访客 WiFi 流量无法访问内部企业网络资源。

应用实例

一家每年举办 200 场活动的金融区会议中心需要获取可操作的参会者数据,以证明提高赞助费率的合理性。目前,他们的 WiFi 门户要求填写 8 个字段,导致流失率高达 45%,且公司数据不一致。

该场所将 8 字段表单替换为结构化的 B2B 门户,仅要求填写全名、公司名称和企业邮箱,并提供可选的职位字段。他们利用邮箱域名实施了后端规范化,从而将访问者整合到规范的公司账户中。

考官评语: 这种方法直接解决了表单臃肿的问题,提高了完成率。通过使用邮箱域名进行规范化,该场所构建了一个干净的账户级数据库,使他们能够向赞助商证明有特定比例的参会者来自目标企业账户。

一家拥有 45 家酒店的集团希望识别频繁使用其多个地点会议设施的企业客户,但其当前的门户数据存在于每家酒店的孤岛中,并依赖 MAC 地址,而 iOS 和 Android 设备对 MAC 地址的随机化越来越普遍。

该集团在所有 45 家酒店中标准化了单一的 B2B 门户模板。他们将其身份解析逻辑从 MAC 地址转向,并完全锚定在注册时验证的企业邮箱地址上,将所有数据存储在集中式 CRM 中。

考官评语: 这是应对 MAC 地址随机化的正确架构响应。企业邮箱在不同设备和场所之间是稳定的。这个统一的数据库使该集团能够识别出 8,200 名跨场所的商务访问者,为利润丰厚的基于账户的营销计划奠定了基础。

练习题

Q1. 您的营销团队希望在会议中心 WiFi 登录门户中添加“行业领域”和“公司规模”下拉菜单,以改进潜在客户评分。IT 部门应该如何回应?

提示:考虑表单长度对连接放弃率的影响。

查看标准答案

IT 部门应建议不要添加这些字段。增加表单长度会导致完成率显著下降,从而减少潜在客户总量。相反,IT 部门应建议仅收集商务邮箱,并使用与 CRM 集成的第三方数据富化工具,根据邮箱域名自动追加“行业领域”和“公司规模”信息。

Q2. 场馆运营商建议将营销同意复选框设为必填,以便更快地建立其数据库。技术和合规层面的回应是什么?

提示:审查 GDPR 第 6(1)(a) 条关于有效同意的要求。

查看标准答案

这种做法违反了 GDPR。同意必须是“自由给出的”。如果将接入 WiFi 作为接受营销信息的条件,则该同意属于捆绑同意,在法律上是无效的。门户网站必须将强制性的服务条款接受与可选的营销勾选分离开来。

Q3. 分析仪表板显示,在为期两天的企业活动中,有 500 个唯一的 MAC 地址已连接,但 CRM 仅显示 280 个已注册的电子邮件地址。最可能的技术原因是什么?

提示:考虑现代移动操作系统的隐私特性。

查看标准答案

这种差异很可能是由 iOS 和 Android 设备上的 MAC 地址随机化引起的。单个用户的设备在重新连接或第二天返回时可能会生成新的 MAC 地址,从而夸大了硬件数量。CRM 中登记的 280 个已注册电子邮件地址是实际参会人数的准确衡量指标。