HubSpot 與 Guest WiFi：名單擴充與分眾

執行摘要

對於企業場域（從大型連鎖零售店到高容量的體育場館）而言，訪客 WiFi 網路是技術堆疊中，最常被低估且未充分利用的數據採集層之一。每個通過驗證的連線工作階段，都代表一個已驗證的身份信號：姓名、電子郵件地址以及明確的行銷同意書。然而，多數企業組織仍任由這些數據孤立在他們的 WiFi 管理平台中，與 CRM 完全脫節。Purple 與 HubSpot 的整合填補了這一缺口，透過在 Captive Portal 與 HubSpot 之間建立一個即時、事件驅動的數據管道。

本指南涵蓋完整的部署架構：如何將 Guest WiFi 入口網站欄位對應到 HubSpot 的標準和自訂屬性、如何設定重複數據刪除邏輯、如何建立由 WiFi 連線工作階段事件觸發的生命週期階段工作流程，以及如何將聯絡人細分為具備執行力的名單。本指南專為需要在實際生產環境中實作此整合（而非僅在理論上進行評估）的 HubSpot 管理員、行銷營運經理和 IT 架構師所編寫。

技術深度解析

架構與數據流

此整合基於 webhook 驅動的架構運作。當使用者透過 Purple Captive Portal 進行驗證時，該平台會扮演身份識別提供者的角色，驗證連線工作階段並產生包含使用者人口統計資料和連線工作階段數據的結構化 JSON 酬載 (payload)。此酬載會透過安全的 HTTPS REST API 呼叫傳輸至 HubSpot Contacts API 端點。

數據流遵循四個獨立階段：入口網站層的驗證、Purple 平台產生酬載、傳輸 API 至 HubSpot，以及在 CRM 中建立或更新紀錄。對於多場域部署（常見於 Retail 零售和 Hospitality 款待業環境）而言，場域識別碼會在產生酬載時嵌入，確保每筆聯絡人紀錄都帶有區域細分所需的地理位置背景資訊。

Purple 內部的 WiFi Analytics 層會產生行為指標（連線次數、停留時間、造訪頻率），這些指標將與人口統計數據一同傳遞。這些指標是僅收集基本電子郵件與獲得真正豐富 CRM 聯絡人資料之間的關鍵差異。

屬性對應機制

準確的屬性對應是可靠整合的基礎。HubSpot 的原生聯絡人屬性可處理標準的人口統計欄位，但 WiFi 特定的行為數據則需要在啟用整合前建立自訂屬性。

下表定義了建議的屬性對應設定：

這四個自訂屬性 — wifi_last_visit、wifi_venue、wifi_session_count 和 wifi_dwell_time — 必須在啟用整合之前於 HubSpot 中建立。若未預先建立這些屬性，將導致承載資料 (payload) 被 HubSpot API 直接捨棄。

去重與身分識別

HubSpot 使用電子郵件地址作為聯絡人記錄的主要唯一識別碼。當收到 Purple 的承載資料時，HubSpot 會對現有記錄進行查閱。如果存在電子郵件地址相符的聯絡人，HubSpot 會以新的工作階段數據更新該記錄 — 增加 wifi_session_count 並更新 wifi_last_visit。如果未找到相符項，則會建立新的聯絡人記錄。

此行為是確定且可靠的，前提是多次造訪時使用的電子郵件地址必須一致。主要風險在於來源端的髒資料。如果 Captive Portal 允許格式錯誤或虛假的電子郵件地址，則會在 HubSpot 中建立孤立記錄，這些記錄無法在後續造訪時進行比對，也無法寄送電子郵件。緩解措施是在傳送門表單上強制執行嚴格的 RFC 5322 電子郵件格式驗證，並透過伺服器端驗證將電子郵件欄位設為必填。這是 Purple 傳送門設定中可設定的選項，應被視為不可妥協的基本要求。 對於在 醫療保健 或公共部門環境中營運，且 GDPR 合規性需接受審計的組織而言，同樣值得注意的是，去重機制意味著單一聯絡人記錄將整合所有的造訪歷史記錄。這簡化了 GDPR 第 17 條下的主體存取請求 (SAR) 回應與數據刪除請求。

實作指南

步驟 1：預先設定 HubSpot 自訂屬性

導覽至 HubSpot 設定 > 屬性 > 聯絡人屬性。建立上方對照表中列出的四個自訂屬性。請確保資料類型設定正確 — wifi_last_visit 必須為日期選取器 (Date picker)，wifi_session_count 和 wifi_dwell_time 必須為數字 (Number) 類型。不正確的資料類型將導致 API 拒絕傳輸承載值。

步驟 2：審計並對齊 Captive Portal 欄位

審查目前的 Purple Captive Portal 設定。確保電子郵件 (Email) 欄位設定為必填，且已啟用格式驗證。對於多場域部署，請確認場域識別碼已設定為根據存取點位置動態傳遞。在 交通運輸 環境（例如機場或火車站）中的場域，單一場域內可能有多個區域，每個區域都需要一個獨立的場域識別碼。

步驟 3：在 Purple 中設定屬性對照

在 Purple 平台的 HubSpot 整合設定中，將每個 Portal 欄位對照到對應的 HubSpot 內部屬性名稱。請使用確切的內部屬性名稱（例如 wifi_session_count，而非 WiFi Session Count），以確保 API 傳輸承載結構正確。

步驟 4：建立生命週期階段自動化

請勿將所有新增的 WiFi 連線預設為「開發客戶 (Lead)」生命週期階段。請使用 HubSpot 工作流程實作事件驅動的分層模型。

建議的生命週期進程如下：在首次登入 WiFi 時，將生命週期階段設定為訂閱者 (Subscriber) — 這是 HubSpot 中適用於已提供詳細資訊但尚未展現行為意圖之聯絡人的正確階段。當在滾動的 30 天內 wifi_session_count 達到 2 次或以上時，觸發工作流程將聯絡人轉換為行銷合格潛在客戶 (MQL)。當 wifi_dwell_time 在多次工作階段中累計超過 45 分鐘時，轉換為銷售合格潛在客戶 (SQL)。當套用會員計劃標籤時，轉換為客戶 (Customer)。

在 HubSpot 中，將每次轉換建立為獨立的工作流程，並將觸發條件設定為「聯絡人屬性值變更」。這可確保在達到閾值時立即啟動轉換，而無需等待排程的批次處理。

步驟 5：對照處理的法律依據

此步驟對於符合 GDPR 規範至關重要。Captive Portal 上的行銷同意勾選框必須對應到 HubSpot 的 hs_legal_basis 屬性。當使用者選擇同意時，該值應設為 Freely given consent from the contact（聯絡人自由給予的同意）。若沒有此對應，HubSpot 內建的合規控制將會阻止向這些聯絡人傳送外發電子郵件，進而使此整合在行銷自動化上失去商業價值。

步驟 6：建立區隔清單

在屬性資料正常流動後，請針對主要的區隔使用案例建立 HubSpot 作用中清單（Active Lists）。例如：所有 wifi_venue = 特定地點的聯絡人（用於地理定位行銷活動）、所有 wifi_session_count >= 5 的聯絡人（用於忠誠度計畫宣傳），以及所有 wifi_last_visit 在過去 30 天內的聯絡人（用於基於近期活動的重新互動）。

最佳實踐

在源頭強制執行電子郵件驗證。 HubSpot 中源自 WiFi 整合的所有資料品質問題，都可以追溯到未經嚴格驗證的電子郵件地址。請將 Portal 表單視為維護 CRM 資料品質的第一道防線。

從第一天起就按場域進行區隔。 對於跨多個地點的任何部署（無論是零售物業、醫療體系還是體育場館），wifi_venue 屬性都是最重要的區隔維度。請從一開始就正確設定它。在建立數千個未包含該屬性的聯絡人之後，才重新回頭進行場域區隔是一項重大的補救工程。

尊重同意架構。 GDPR 的目的限制原則意味著，為了網路存取目的而透過 WiFi Portal 收集的資料，在未經明確同意的情況下，不能自動轉用於直接行銷。hs_legal_basis 對應並非一項技術細節，而是授權行銷使用案例的法律機制。

監控 API 吞吐量。 對於體育場或會議中心等高密度環境，尖峰時段的並行驗證量可能會對 HubSpot API 造成壓力。Purple 會將負載排隊並重試失敗的要求，但建議在重大活動期間於 HubSpot 開發者儀表板中監控 API 呼叫量，並確保 HubSpot 帳戶級別支援所需的吞吐量。

使用增量更新，而非完全覆寫。 當返回的訪客連線時，負載應僅更新已變更的屬性（wifi_last_visit、wifi_session_count），而不是覆寫所有欄位。這可以防止在聯絡人已直接在 HubSpot 中更新其姓名的情況下，發生意外的資料遺失。

疑難排解與風險緩釋

問題：聯絡人已建立，但無法接收行銷電子郵件。 根本原因：hs_legal_basis 屬性未對應，或對應的值字串不正確。 解決方法：驗證傳遞的確切字串值。HubSpot 需要「Freely given consent from the contact」— 任何變更都會導致合規性檢查無聲失敗。

問題：HubSpot 中出現重複的聯絡人記錄。 根本原因：同一使用者提交了多個電子郵件地址（例如：個人與公司信箱），或者 Portal 上的電子郵件欄位非必填。 解決方法：在 Portal 上啟用強制電子郵件驗證。考慮在 HubSpot 中實施合併工作流程，以整合使用不同電子郵件地址但顯示相同名稱的記錄。

問題：儘管整合已啟用，但自訂屬性並未填入。 根本原因：在整合啟用前，未在 HubSpot 中建立自訂屬性，或者 Purple 對應設定中的內部屬性名稱與 HubSpot 屬性內部名稱不完全相符。 解決方法：交叉比對 HubSpot 設定 > 屬性中的內部屬性名稱與 Purple 中的對應設定。內部名稱區分大小寫，且使用底線而非空格。

問題：儘管已達到工作階段次數臨界值，但生命週期階段並未推進。 根本原因：HubSpot 工作流程觸發條件被設定為「聯絡人已註冊」，而非「聯絡人屬性值變更」。 解決方法：使用正確的觸發類型重建工作流程。「聯絡人屬性值變更」會在每次屬性更新時觸發，這才是基於臨界值推進的正確機制。

風險：因資料保留而導致違反 GDPR。 緩解措施：實施 HubSpot 工作流程，將 24 個月內無 WiFi 活動（即 wifi_last_visit 超過 24 個月前）的聯絡人標記為不活躍。觸發重新同意電子郵件。若在 30 天內未收到回覆，則阻止該聯絡人接收所有行銷通訊。這符合 GDPR 的儲存限制原則。

ROI 與商業影響

Purple 與 HubSpot 整合的商業案例非常直接：它將被動的網路基礎架構成本轉化為主動帶來營收的資料管道。衡量佈署成功的關鍵績效指標（KPI）為：

在飯店業的部署中，一間擁有 300 間客房的飯店每月產生 2,000 個不重複的 WiFi 連線，假設從連線到完成表單的轉換率為 20–25%，預計每月可為 HubSpot 增加約 400–500 個全新且資訊豐富的聯絡人。以保守的 10% MQL 轉換率計算，這代表每月可從先前無法產生任何 CRM 價值的數據源中，獲得 40–50 個新的行銷合格潛在客戶。

對於在 50 個據點營運的連鎖零售商而言，其累計的數據量會顯著增加，而客群細分的價值（特別是針對特定分店位置鎖定聯絡人的能力）更能實現超在地化的促銷活動，使其在開信率和轉換率上，皆能持續超越一般的群發電子郵件。