由 Wi-Fi 偵測觸發的事件驅動型行銷自動化

歡迎來到 Purple 技術簡報系列。我是您的主持人，今天我們要探討一個處於網路基礎架構與營收創造交會點的主題：WiFi 存在自動化（presence automation）——具體來說，如何建構事件驅動型的行銷系統，將透過 WiFi 網路偵測到的訪客實體存在，轉化為個人化、即時行銷活動的觸發點。 如果您是行銷技術專家、網路架構師或場域營運總監，這場簡報正是為您準備的。我們將深入探討核心架構、區分優劣實作的延遲考量因素、每個團隊都低估的去重（deduplication）問題，以及您絕對不容忽視的隱私框架。讓我們開始吧。 --- 第一節：為什麼「存在」是您已經在收集且最具價值的行銷訊號 讓我先問一個問題。您的場域——無論是飯店、零售連鎖、體育場還是會議中心——都已經擁有 WiFi 基礎架構。每當裝置與無線基地台（access point）建立關聯時，您就已經在產生存在事件了。問題不在於您是否擁有這些數據，而是在於您是否利用它們做了一些有價值的事。 傳統的數位行銷依賴意圖訊號運作：有人搜尋產品、點擊廣告、打開電子郵件。這些雖然很有價值，但都發生在您的場域之外。WiFi 存在自動化則是基於一個本質上不同、且可以說更強大的訊號：實體接近（physical proximity）。訪客已經在那裡了，他們已經做出了拜訪的決定。您的任務是讓這次拜訪對他們和對您都更有價值。 架構上的挑戰在於：如何在仍然有效的時間窗口內，將原始的網路事件——裝置關聯（device association）、探測請求（probe request）、DHCP 租約（DHCP lease）——轉化為具備情境相關性的個人化行銷行動。在零售環境中，這個時間窗口可能是二到五分鐘；在飯店裡，您則有整個住宿期間。架構在設計之初，就必須圍繞這些限制條件進行規劃。 --- 第二節：四層架構 讓我為您介紹我們為企業級 WiFi 存在自動化所推薦的參考架構。它包含四個獨特的層級，正確處理它們之間的邊界至關重要。 第一層是網路層（Network Layer）。這是您的實體基礎架構：無線基地台、控制器以及處理身分驗證的 RADIUS 伺服器。這裡的核心設計決策是您要從網路中呈現哪些事件。您有三個選擇：第一，探測請求（probe requests）——來自裝置掃描已知網路的被動訊號；第二，關聯事件（association events）——裝置成功連線到您的 SSID 的瞬間；第三，已驗證會話事件（authenticated session events）——通常透過 Captive Portal 登入或 802.1X 驗證，使您擁有與裝置綁定的確認使用者身分。 我的強烈建議是將您的自動化建立在已驗證的工作階段事件上，而不是探測請求（probe requests）。原因如下：自 iOS 14 和 Android 10 起，Apple 和 Google 都已預設啟用 MAC 位址隨機化。掃描網路的裝置會呈現隨機的 MAC 位址，該位址會隨網路而變，在某些實作中甚至會隨工作階段而變。如果您將存在偵測（presence detection）系統建立在基於探測的 MAC 追蹤上，無異於將房子蓋在沙灘上。與 Captive Portal 登入綁定的關聯事件，能為您提供一個不受 MAC 隨機化影響、持續且與同意相關聯的識別碼。 第二層是 Presence Engine（存在引擎）。這是將原始網路事件轉換為有意義的存在訊號之處。Purple 的平台透過 Event Stream Engine（事件串流引擎）來處理此程序，該引擎執行四個關鍵功能：探測偵測與過濾（區分真實的停留與路過訊號）、關聯事件處理（擷取已驗證連線的瞬間）、停留時間計算（在觸發器啟動前確定裝置已存在多久），以及重複資料刪除（防止同一裝置在抑制期間內多次觸發同一個行銷活動）。 重複資料刪除組件特別值得注意。在繁忙的零售環境中，當訪客在商店的不同區域之間移動時，單一裝置可能會在一小時內與您的網路進行多次關聯、斷開關聯並重新關聯。如果沒有強大的重複資料刪除引擎，您將在 40 分鐘內發送三次相同的歡迎訊息。這不是個人化，這是騷擾。抑制期間需要能夠根據行銷活動類型、場域類型和使用者區隔進行設定。 第三層是自動化層（Automation Layer）。這是商務邏輯所在之處。在 Purple 的實作中，這是 LogicFlow —— 一個視覺化的工作流程引擎，讓行銷和營運團隊無需撰寫程式碼即可定義觸發條件、分支邏輯和動作順序。這裡的關鍵架構原則是自動化層應與網路層分離。修改行銷活動邏輯不應需要變更您的網路設定，反之亦然。這種關注點分離（separation of concerns）的設計，能讓行銷團隊反覆測試行銷活動，而無需每次變更都驚動 IT 部門。 第四層是遞送層（Delivery Layer）。這是觸發的動作實際觸達訪客的地方：可以是電子郵件、簡訊、推播通知、傳送至您 CRM 的 Webhook，或是您會員平台的更新。這裡的關鍵設計考量是，遞送層必須尊重在 Captive Portal 擷取的同意與偏好資料。如果訪客選擇接受簡訊而不接受電子郵件，您的自動化系統就必須遵守該選擇。這不僅是最佳實踐，在 GDPR 和 PECR 的規範下，這也是法律要求。 --- 第三節：延遲 —— 什麼是可以接受的，什麼是不能接受的 讓我給您一些具體數據，因為這正是許多實作出錯的地方。 在 WiFi 存在感應自動化系統中，端到端延遲是指裝置與您的網路建立關聯，到訪客收到觸發通訊之間的時間。在架構完善且採用現代基礎設施的系統中，大多數場域類型都應能在十秒內達成此目標。 然而，可接受的延遲因情境而異，且差異極大。在交通樞紐（例如機場或火車站）中，訪客在等待登機門或月台變更時，可能只會連線到 WiFi 三分鐘。您的觸發機制必須在連線後六十至九十秒內啟動，否則時機就錯過了。而在飯店，訪客會在館內停留十二至四十八小時，因此十秒甚至三十秒的延遲是完全可以接受的。 延遲時間預算主要分布在三個組成部分。網路到平台延遲：關聯事件從無線控制器傳輸到 Purple 平台所需的時間。在控制器設定良好的雲端連線部署中，此過程應在一秒內完成。平台處理延遲：Event Stream Engine 進行事件分類、檢查重複資料刪除、評估自動化條件並發送動作所需的時間。在 Purple 的架構中，這通常在兩秒內。傳送管道延遲：下游管道（電子郵件供應商、簡訊閘道器、推播通知服務）傳送訊息所需的時間。這是您最無法控制的部分，也是變數最大的地方。透過第一級（Tier 1）閘道器傳送簡訊通常在五秒內。而電子郵件的傳送時間則可能在兩秒到兩分鐘之間，具體取決於收件者的郵件伺服器。 實際影響：如果您需要低於十秒的端到端傳送，簡訊或推播通知是您唯一可靠的選擇。電子郵件並非即時管道，您不應以此為前提來規劃存在感應自動化的架構。 --- 第四節：深入探討重複資料刪除問題 我想花幾分鐘討論重複資料刪除，因為它是存在感應自動化部署中最常導致生產環境問題的組件。 核心問題在於：單次實體造訪可能會產生數十個網路事件。訪客走進您的飯店，在大廳連線到 WiFi，走向房間，裝置短暫失去訊號並重新連線，接著他們去餐廳，裝置漫遊到不同的存取點。從網路的角度來看，這可能代表四到五個關聯事件；但從訪客的角度來看，這只是一次造訪。 您的重複資料刪除引擎需要在兩個層級運作。裝置級重複資料刪除：將同一裝置在工作階段視窗（Session Window）內產生的多個關聯事件，合併為單一存在事件。對大多數場域類型而言，十五至三十分鐘的工作階段視窗是合適的——如果裝置在該視窗內中斷連線並重新建立關聯，將會被視為同一個工作階段的延續，而非新的造訪。活動層級的重複排除可防止在隱藏期內向同一位顧客重複發送相同的行銷活動。此視窗應可針對每個行銷活動進行設定。歡迎訊息的隱藏期應等於典型住宿的時間長度——飯店為七天，零售店為二十四小時。具有時效性的優惠活動隱藏期可能只需四個小時。常客積分提醒則可能需要隱藏三十天。 第三個需要考慮的重複排除是跨裝置重複排除。如果顧客先前曾在其筆記型電腦和手機上連線至您的網路，且兩部裝置同時存在，您應該只觸發一次行銷活動，而不是兩次。這需要具備設定檔連結功能——通常透過在 Captive Portal 收集的電子郵件地址或會員 ID 來實作——將多部裝置與單一顧客設定檔進行關聯。 --- 第五節：隱私框架——不可妥協的原則 讓我直接說明法規環境，因為我見過許多在技術上非常出色但在法律上存在問題的實作案例。 在 GDPR 和英國 GDPR 規範下，處理顧客的位置資料（這實際上就是 WiFi 存在偵測所構成的資訊）需要合法依據。最常適用的兩個依據是「同意」與「正當利益」。同意是較為明確的選擇：顧客在 Captive Portal 上明確同意接受基於定位的行銷。正當利益則需要有記錄在案的衡平性評估，以證明您發送通訊的利益不會侵害顧客的隱私權。對於大多數行銷應用情境，同意是更安全且更站得住腳的依據。 PECR（隱私與電子通訊條例）為電子行銷增加了額外的規範。發送由 WiFi 定位觸發的行銷簡訊或電子郵件，無論您的 GDPR 合法依據為何，都需要事先取得收件人的同意。此同意必須是具體、知情且自願給予的。Captive Portal 上預先勾選的核取方塊並不構成有效的 PECR 同意。 在技術層面，MAC 位址隨機化已有效終結了無須同意的被動式裝置追蹤時代。任何依賴在未經使用者同意的情況下追蹤隨機 MAC 位址的架構，在技術上既不可靠，在法律上也有疑慮。正確的方法是使用已驗證的會話識別碼（電子郵件地址或會員 ID）作為您的主要追蹤鍵值，而 MAC 位址僅用作會話層級的關聯控制碼。 PCI DSS 合規性要求您的顧客 WiFi 網路必須與任何處理付款卡資料的網路區段完全隔離。這意味著至少要進行 VLAN 隔離，並透過防火牆規則防止顧客網路與付款網路之間的任何流量往來。您的定位自動化平台應該部署在顧客網路區段或連線至該區段，絕不能連接至付款網路。 --- 第六部分：導入建議與常見陷阱 讓我分享在每位客戶正式上線 Presence 自動化部署前，我都會提供的五個建議。 第一：從您的資料模型開始，而非您的行銷活動。在設定任何一條自動化規則之前，請先定義您的顧客身分識別模型。主要識別碼是什麼？您如何處理每位顧客的多台裝置？您如何將 WiFi 身分連結至您的 CRM 或會員平台？一開始若走錯一步，將會產生極其昂貴的技術債。 第二：在正式上線前測試您的重複資料刪除機制。在發布前，讓系統以「觀察模式」運作至少兩週——僅記錄事件而不觸發任何行銷活動。這能為您提供有關關聯事件頻率、典型連線行為模式以及回訪率的真實數據。請利用這些數據來調整您的抑制視窗（Suppression Windows）。 第三：在規劃行銷活動流程前，先設計您的同意授權流程。Captive Portal 不僅僅是網路存取機制，更是您取得同意的關鍵節點。您預計進行的每項資料處理活動，都必須在此節點進行說明並取得同意。請與您的法務團隊合作，確保同意條款的文字足夠具體，以符合 PECR 的合規標準。 第四：在負載下測試您的延遲。一個在十個同時連線下表現良好的 Presence 自動化系統，在面臨一千個連線時效能可能會顯著下降。在大型活動或交易尖峰期正式上線前，請以預期尖峰同時連線裝置數量的兩到三倍，對您的事件處理管線進行壓力測試。 第五：將抑制管理納入您的營運工作流程中。行銷團隊會希望同時執行多個行銷活動。若沒有明確的抑制層級架構（當多個觸發條件同時發生時，哪個活動優先），最終會導致顧客在五分鐘內收到三條訊息。請在行銷活動上線前定義好此層級架構，而不是在收到第一宗投訴之後才處理。 --- 快速問答 問題：我可以在沒有 Captive Portal 的情況下使用 WiFi Presence 自動化嗎？ 回答：技術上可以透過探測偵測（probe-based detection）來實現，但在實務上，任何合規的行銷應用情境皆不可行。沒有 Captive Portal，您就沒有取得同意的機制，也沒有持續的顧客識別碼。您將在沒有法律依據的情況下追蹤隨機產生的 MAC 位址。請不要這麼做。 問題：要達到可靠的 Presence 偵測，最低的基地台（Access Point）密度是多少？ 回答：若要將停留時間誤差控制在五公尺內，您需要至少三個基地台的重疊訊號覆蓋。對於區域級的 Presence 偵測（例如僅得知顧客在店內，而非在哪個貨架），每個區域一個 AP 就足夠了。請根據您的應用情境來設計 AP 的密度。 問題：我該如何將 Purple 的事件串流與我現有的 CRM 整合？ 解答：Purple 支援基於 Webhook 的事件派送，並透過 Zapier 與直接 API 進行原生整合。針對 Salesforce 或 HubSpot 等企業級 CRM 平台，建議的方法是將 Webhook 傳送至中介軟體層，由其處理資料轉換與 CRM API 呼叫。這能保持整合的鬆散耦合，使其更易於維護。 --- 摘要與後續步驟 WiFi 軌跡定位自動化是您現有網路基礎架構中投資報酬率（ROI）最高的應用之一。此技術已相當成熟、法規架構明確，且實作模式也已十分完善。成功部署與產生問題的部署，其關鍵差異在於三點：能因應 MAC 隨機化並生存下來的強健身分識別模型、針對您特定場域與造訪模式進行校正的去重複化引擎，以及同時符合 GDPR 與 PECR 規範的同意授權架構。 如果您正在評估將 Purple 用於此情境，應重點關注的兩個元件是：用於軌跡訊號處理的 Event Stream Engine（事件串流引擎），以及用於自動化邏輯的 LogicFlow。這兩者均專為企業級規模運作而設計，具備您所需的配置能力，可從單一平台支援多種場域類型與行銷活動類型。 關於您的後續步驟：請對照 PECR 規範審查您目前的 Captive Portal 同意授權條款、稽核您現有的 WiFi 基礎架構以確保 AP 密度充足，並在開始調整任何自動化設定之前，定義好您的訪客身分識別模型。 感謝您收聽 Purple 技術簡報系列。完整文件、架構指南與整合參考資料，皆可於 purple.ai 取得。