設計 B2B Captive Portal：收集註冊姓名與公司數據

歡迎來到 Purple 智慧簡報。我是 Purple 的資深技術內容策略師，今天我們要探討一個幾乎在我協助部署的每個 B2B 場域中都會遇到的主題：如何設計一個能正確收集註冊姓名與公司資料的 captive portal。 這不是一個消費級 WiFi 的問題。當您在會議中心、設有會議設施的飯店、共同工作空間或商務機場貴賓室運行 WiFi 時，您的訪客不只是普通的賓客。他們是專業人士。他們擁有職稱、公司隸屬關係以及採購決策權。您在 WiFi 註冊點收集的資料，是您可以收集到最具有商業價值的首方資料。但大多數場域要不是收集得太少、收集方式錯誤，就是以會產生 GDPR 責任風險的方式收集。我們今天就要來解決這三個問題。 讓我來設定一下場景。captive portal 是一個網頁，用於在授予網路存取權限之前，攔截訪客的連線嘗試。裝置連線到您的 WiFi SSID 並嘗試進行 HTTP 請求，而您的網路控制器會將該請求重導向至您的入口網站。訪客會看到您的品牌登入頁面，完成註冊表單，然後獲得存取權限。這就是基本的流程。改變的是您隨後如何處理這些資料，以及您所處的法規監管環境。 與消費級部署相比，B2B 環境顯著改變了設計需求。在消費級場景中，您通常只需要詢問姓名和電子郵件地址，以便建立行銷清單。但在 B2B 環境中，您會想要註冊姓名與公司資料，因為這種組合可以解鎖帳戶層級的情報。當您知道在三天內有 47 位來自同一家金融服務公司的員工連線到您的會議中心 WiFi 時，這就不僅僅是人流量統計數據。這是一個銷售訊號，是活動投資報酬率（ROI）數據，也是能證明您場域商業合作關係價值的情報。 現在我們來談談技術架構。一個 B2B captive portal 部署有四個核心組件。第一是存取點（Access Point）層：Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 或 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 和歐盟的通用資料保護規則，向 WiFi 訪客收集姓名和公司數據需要有合法的處理依據。對於 B2B Captive Portal，您有兩個切合實際的選擇：第 6(1)(a) 條規定的同意，或第 6(1)(f) 條規定的正當利益。 從合規的角度來看，同意是較為明確乾淨的選擇。訪客主動勾選核取方塊，您記錄時間戳記和他們閱讀的隱私聲明版本，這樣您就擁有了可供佐證的稽核軌跡。同意的挑戰在於它必須是自由給予的。這意味著 WiFi 存取不能以同意行銷為前提。您需要將網路存取的同意與行銷傳播的同意分開。設定兩個核取方塊：一個是用於服務條款的必填項目，另一個是用於行銷的選填項目。絕對不要將它們綁定在一起。 正當利益是一個更微妙的依據。它適用於為了網路安全和管理目的而處理基本工作階段數據。但若要透過訪客註冊來建立行銷資料庫，正當利益就比較難以立足，特別是在個人身分可被識別為專業人士的 B2B 數據中。我的建議是：採用同意機制並妥善設計表單，您就能擁有乾淨、合規的架構。 在我們進入實際部署之前，還有一個技術要點需要說明：MAC 位址隨機化。自 iOS 14 和 Android 10 起，行動裝置預設會針對每個網路進行 MAC 位址隨機化。這意味著訪客今天連線時，您的存取點所偵測到的 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 認證。同意記錄、資料保留規則以及資料當事人存取要求回應工具皆已內建其中。 您的下一步是根據我今天概述的欄位設定與合規檢查清單，審計您目前的 Portal 設定。如果您經營的是 B2B 場所，卻沒有以結構化、合規的方式收集註冊名稱與公司資料，您就錯失了商務情報。 如需更多技術指南與實作資源，請造訪 purple.ai。感謝您收聽 Purple 智慧簡報。