設計 B2B Captive Portals：收集註冊姓名與公司資料

歡迎來到 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 在所有這些硬體平台上皆以雲端覆蓋（cloud overlay）方式運作。您不需要拆除並更換現有的基礎設施。您只需在現有的任何基地台上部署 Purple 即可。在 2024 年，我們服務了 80,000 個實體場域和 4.4 億次登入，這是一個非常龐大的數據集，可作為您評估自身部署時的基準。 現在，我們來談談表單設計的問題。您應該包含哪些欄位？直覺上會想索取所有資訊：姓名、公司、職稱、部門、電話號碼、LinkedIn 個人檔案。請克制這種衝動。每增加一個欄位都會降低您的填寫完成率。從兩個欄位增加到五個欄位，表單完成率大約會下降 20%。在場域的情境中，這意味著每五位商務訪客中就有一位會完全放棄連線嘗試。 最小可行性的 B2B 欄位組合是：全名、公司名稱和商務電子郵件地址。全名用於識別個人。公司名稱便於進行帳戶彙整。商務電子郵件提供了一個經過驗證的聯絡點，關鍵在於，即使訪客輸入的公司名稱不一致，網域後置字元也能讓您識別出公司身份。有些人可能會註冊為 Deloitte、Deloitte UK 或 Deloitte LLP，但他們的電子郵件網域一律會是 deloitte.com。請圍繞電子郵件網域建立您的數據正規化邏輯，而不是自由文字的公司名稱欄位。 職稱是一個有價值的選填欄位。它可以依據資歷和職能對您的訪客數據進行細分。但請將其設為選填。跳過職稱欄位的訪客仍然是擁有姓名和公司的已註冊訪客。而完全放棄表單的訪客則不會給您留下任何資訊。 現在我們來談談 GDPR，因為在設計 B2B Captive Portal 時，不能沒有完善的合規架構。根據 UK GDPR 和歐盟一般資料保護規範（GDPR），從 WiFi 訪客收集姓名和公司數據需要有合法的處理依據。對於 B2B Captive Portal，您有兩個切實可行的選擇：依據第 6(1)(a) 條的同意，或依據第 6(1)(f) 條的合法利益。 從合規的角度來看，同意是較為明確的選擇。訪客主動勾選方塊，您記錄時間戳記和他們閱讀的隱私權聲明版本，這樣您就擁有一個可辯護的稽核軌跡。同意面臨的挑戰在於它必須是自由給予的。這意味著 WiFi 連線不能以同意行銷為前提條件。您需要將網路存取的同意與行銷傳播的同意分開。設定兩個核取方塊：一個是服務條款的必填項目，另一個是行銷的選填項目。絕對不要將它們綁在一起。 合法利益是一個更細緻的依據。它可以適用於為網路安全和管理目的而處理的基本工作階段數據。但若是為了從訪客註冊中建立行銷資料庫，合法利益就較難以辯護，特別是對於個人身分可識別的專業人士之 B2B 數據。我的建議是：使用同意，並正確設計表單，這樣您就能擁有乾淨的合規態勢。 在進入部署之前，還有一個技術要點需要說明：MAC 位址隨機化。自 iOS 14 和 Android 10 起，行動裝置預設會針對每個網路隨機化其 MAC 位址。這意味著，當訪客今天連線時，您的存取點（access point）所看到的 MAC 位址，可能與上個月看到的不同，即使是同一台裝置和同一個人也是如此。對於 B2B 註冊名稱和公司資料收集而言，這並不是什麼大問題，因為您的識別定位點是註冊的電子郵件地址，而不是 MAC 位址。電子郵件地址是穩定的。將您的識別解析邏輯圍繞在電子郵件上建構，MAC 隨機化就成了次要問題。 現在，讓我帶您了解兩個實際的部署案例，說明這在實務中是如何運作的。 第一個案例是位於金融區的會議中心。他們每年舉辦 200 場活動，每場活動平均有 300 名與會者。在部署設計完善的 B2B Captive Portal 之前，他們的 WiFi 註冊資料非常混亂：公司名稱不一致、使用個人電子郵件地址、沒有職稱資料，也沒有同意記錄。他們無法回答基本問題，例如「哪些公司送來的代表最多？」或「我們與會者的平均資歷為何？」。 在部署了包含全名、公司名稱、商務電子郵件和選填職稱欄位的結構化 B2B 入口網站，並在後台結合電子郵件網域正規化之後，他們在六個月內建立了一個乾淨的帳戶級別資料庫。他們現在可以向參展商展示，其與會者中有 34% 來自富時 100 指數（FTSE 100）企業。該數據直接支持了其贊助費率提高 40%。WiFi 註冊表單成了一項能創造營收的資產。 第二個案例是一家擁有 45 家物業的飯店集團，每家物業都設有會議和研討會設施。他們的挑戰在於一致性：每個物業的入口網站設定、欄位組合都略有不同，且資料儲存在不同的系統中。在曼徹斯特物業參加會議，然後入住倫敦物業的賓客，會被視為兩個獨立且毫不相關的訪客。 透過在所有 45 家物業標準化部署單一 B2B 入口網站範本，並採用集中式資料儲存和基於電子郵件的識別解析，他們建立了一個統一的訪客資料庫。在 12 個月內，他們識別出 8,200 名曾使用過多個物業的商務訪客。該群體成為了精準目標帳戶行銷（ABM）計劃的基礎。部署標準化入口網站的成本，在第一季內就透過該識別群體帶來的會議預訂增量全數回收。 現在，讓我為您指出要避免的部署陷阱。這些是我最常看到的錯誤。 陷阱一：未經標準化的自由文字公司名稱。如果您接受公司名稱的自由文字輸入且未在後台進行標準化，您的資料庫將包含同一個公司的數百種變體。請使用電子郵件網域作為您的主要公司識別碼。 陷阱二：將 WiFi 存取同意與行銷同意綁定。這違反了 GDPR。資訊專員辦公室（ICO）明確指出：行銷同意必須與服務本身的同意分開。如果訪客必須同意接收行銷電子郵件才能存取 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 智慧簡報。