如何利用簡訊行銷代理商提高回訪率
本技術指南說明 IT 與場地營運團隊如何將簡訊行銷代理商與 Purple 的 Guest WiFi 平台整合，以收集經過驗證的第一方數據，並自動化執行推動回訪的行銷活動。內容涵蓋零售、餐飲旅宿及活動等企業環境的部署架構、合規性要求以及可衡量的業務成果。
收聽此指南
查看播客逐字稿
執行摘要
場域營運商面臨著一個持續的挑戰：將一次性訪客轉化為忠實的回頭客。雖然電子郵件行銷仍是標準管道，但簡訊卻擁有 98% 的開啟率 - 且通常在收到後三分鐘內開啟（來源：GSMA Intelligence，2024）。為了利用這一點，場域需要大規模獲取準確的電話號碼和明確的同意。Purple 在網路邊緣解決了這個問題。當訪客連接到您的 Guest WiFi 時，Purple 會擷取其經過驗證的手機號碼和符合 GDPR 規範的同意，然後透過 API 將此第一方數據路由到您選擇的 SMS 行銷機構。2024 年，在 80,000 多個現場場域和 4.4 億次登入中，我們看到這種架構持續推動回訪。本指南涵蓋了本季準備採取行動的 IT 和行銷團隊所需的技術整合、部署步驟、合規性要求和 ROI 評估。
技術深入探討
數據擷取層的工作原理
Purple 在您現有的企業硬體上作為雲端重疊運作。我們與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 進行原生整合。當訪客連接到 Guest WiFi SSID 時，網路會將其重定向到 Purple 的 Captive Portal。在這裡，Purple 會對使用者進行身份驗證，並擷取其手機號碼，以及對行銷傳播明確且自願的選擇同意（Opt-ins）。
此過程與硬體無關。無論您的場域是在零售店運行 Cisco Meraki，還是在總部運行 HPE Aruba，Purple 都會向底層的 SMS 行銷機構呈現統一的數據模型。您無需重新建構網路即可受益。
基於身份的網路與 MAC 隨機化問題
現代作業系統 - iOS 14 及以上版本、Android 10 及以上版本 - 會隨機化裝置 MAC 位址以保護使用者隱私。這給任何試圖在硬體層評估回訪率的場域帶來了重大問題：同一個人的每次造訪都可能顯示為一個新的不重複裝置。在實際應用中，被動裝置追蹤已失效。
Purple 的基於身份的網路解決了這個問題，它將追蹤錨點從裝置轉移到已驗證的使用者。一旦訪客透過 Captive Portal 登入並提供經過驗證的電話號碼，其工作階段就會與該身份綁定。當他們返回並再次驗證時，Purple 會比對該記錄。其結果是真實人物和真實造訪歷史的確定性數據集 - 這正是 SMS 行銷機構觸發精準、及時行銷活動所需的數據。
憑藉我們網路收集到的 290 億個數據點，此身分識別層是 Purple 為您的行銷技術堆疊提供的最寶貴資產。
API 整合架構
數據透過兩種主要機制從 Purple Engage 流向您的 SMS 行銷代理商：
| 方法 | 最適合 | 延遲 | 複雜度 |
|---|---|---|---|
| Webhooks | 即時觸發（歡迎訊息、活動廣播） | 趨近於零 | 低 - 在 Purple 入口網站中設定端點 URL |
| 排程 API 匯出 | 重新互動行銷活動、批次處理 | 幾分鐘到幾小時 | 中等 - 需要中介軟體或代理商端接收 |
這兩種方法都使用權杖型（token-based）驗證。Purple 在匯出階段進行去重處理，因此同一位使用者在一天內登入三次，不會在您 SMS 代理商的 CRM 中產生三筆紀錄。
實作指南
部署 SMS 整合需要網路工程、行銷和法務團隊之間的協調。以下四個步驟涵蓋了整個部署流程。
步驟 1：設定 Captive Portal 以收集 SMS
在 Purple 入口網站中，導覽至歡迎頁面建置工具。啟用行動電話號碼欄位並將其設為必填。至關重要的是，啟用 SMS OTP（一次性密碼）驗證。這會向訪客輸入的號碼發送一個四位數代碼，在授予 WiFi 存取權限之前確認該號碼有效。無效的號碼會使您的資料庫膨脹並浪費 SMS API 額度。OTP 驗證從源頭消除了這個問題。
如需設計能維持品牌一致性同時最大化數據收集效果的歡迎頁面，請參閱 如何透過您的訪客 WiFi 留下極佳的第一印象 。
步驟 2：確立您的合規基準
更新您的條款與細則，明確指出與您分享數據的 SMS 行銷代理商。同意核取方塊預設必須為未勾選狀態，以符合 GDPR 第 7 條的要求。Purple 會記錄每次同意訂閱事件的確切時間戳記、IP 地址和同意文字版本。此稽核軌跡即為您在 GDPR 和 CCPA 規範下進行合法處理的證據。
對於跨多個地區營運的場所，Purple 已通過 ISO 27001、GDPR、CCPA 和 Cyber Essentials 認證。合規框架是內建的，而非外掛的。
步驟 3：設定 API 整合
在 Purple Engage 的「設定」>「整合」下產生 API 金鑰。設定您的 SMS 行銷平台以透過 webhook 接收數據，或排程每日匯出。正確對應以下欄位：
user.phone對應至目的地電話號碼欄位user.marketing_opt_in布林值對應至代理商的同意標記session.venue_id用於在多據點部署中按位置進行區隔session.first_seen和session.last_seen用於計算造訪頻率與近期造訪時間
確保在每個階段都遵守 marketing_opt_in 布林值。請勿傳送此值為 false 的紀錄。
步驟 4：與您的 SMS 行銷代理商定義觸發規則
在正式上線之前，與您的 SMS 行銷代理商共同定義自動化邏輯。常見可促進再次造訪的觸發條件包括：
- 歡迎訊息： 於首次登入後 15 分鐘傳送，為當次的造訪提供折扣優惠。
- 重新互動活動： 於最後一次記錄造訪的 30 天後傳送，以促使其再次光臨。
- 贏回顧客活動： 於最後一次造訪的 90 天後傳送，並提供價值更高的誘因。
- 活動廣播： 在體育場活動或會議期間，傳送給所有當前已連線的使用者。
- 忠誠度里程碑： 當使用者達到第五次造訪時傳送，由 Purple 的造訪次數數據觸發。
最佳實踐
優先考慮數據品質，而非數量
請勿為了加速登入流程而繞過 SMS OTP 驗證。在傳送率、開啟率和轉換率等各項指標中，包含 10,000 個已驗證號碼的資料庫，其成效皆優於 50,000 個未驗證的項目。Purple 每年處理超過 4.4 億次登入（Purple 內部數據，2024 年）。我們的數據顯示，OTP 驗證可將 SMS 彈回率降至接近零。
依垂直產業與行為進行區隔
針對特定的垂直產業量身打造您的訊息內容。零售業顧客期望的溝通方式與飯店住客不同。使用 WiFi Analytics 根據停留時間、造訪頻率和新近度來區隔目標對象。停留三小時的訪客，其參與度明顯高於路過並僅連線五分鐘的人。請將這些行為區隔作為不同的目標對象清單傳遞給您的 SMS 行銷代理商。
對於零售部署，請參閱我們的 零售業指南 以取得特定垂直產業的區隔策略。對於旅宿業，請參閱 旅宿業指南 。
尊重傳播媒介
SMS 是一種私密的管道。過度使用會導致用戶退訂，這將永久從您的資料庫中移除該使用者。建議將促銷訊息限制在每位使用者每月最多兩則。每則訊息都必須提供實質、即時的價值 - 如折扣、活動通知或獨家存取權限。一般的品牌訊息在 SMS 上的成效並不理想。
維持雙向同意同步
當使用者對 SMS 回覆 STOP 時，代理商必須立即處理此退訂，並將其同步回 Purple Engage。請在正式上線前設定好此雙向同步。若未能將退訂狀態反映在 Purple 中，意味著未來的數據匯出可能會包含已撤回同意的使用者 - 這將違反 GDPR。
疑難排解與風險緩釋
MAC 隨機化導致重複記錄
如果您在分析中觀察到不正常的獨特訪客計數，可能的原因是 MAC 隨機化為同一位使用者建立了多個裝置記錄。若要解決此問題，請確保所有再次造訪的評估皆依賴於來自 Purple Engage 的已驗證使用者身分，而非來自硬體控制器的裝置計數。Purple 的 Identity-Based Network 層才是正確的單一事實來源。
高人流量活動期間的 API 速率限制
在高密度活動期間 - 體育場比賽、會議開幕、零售促銷日 - 同時登入的流量可能會壓垮您的 SMS 行銷代理商接收 API。請在您的中間件中實施指數型退避與重試邏輯。對於預期在 10 分鐘內有超過 1,000 次登入的活動，請將即時 Webhooks 切換為排程在尖峰時段後 5 分鐘執行的批次匯出。
同意撤回未同步
如果退訂率上升，但您的資料庫大小沒有減少，那麼您的 SMS 代理商與 Purple Engage 之間的雙向同步很可能已經中斷。請檢查代理商平台中的 Webhook 端點設定，並驗證 unsubscribe 事件是否已對應到正確的 Purple API 端點。在每次重大活動前，請務必手動測試此功能。
智慧入口網站 (Captive Portal) 訂閱率偏低
如果提供電話號碼的訪客少於 30%，請重新檢視 Splash Page 設計。價值交換必須是明確的：清楚說明訪客提供號碼能獲得什麼回報。對文案和同意勾選框的位置進行 A/B 測試。如需指導，請參閱 如何讓您的顧客 WiFi 留下美好的第一印象 。
ROI 與業務影響
透過追蹤三個指標來衡量您 SMS 行銷整合的 ROI：
| 指標 | 如何衡量 | 目標基準 |
|---|---|---|
| 回訪率提升 | 比較 90 天內收到 SMS 的收件者與未收件者的回訪率 | 提升 10-15% (Purple 場域數據) |
| SMS 兌換率 | 已兌換的折扣碼 / 已發送的 SMS 簡訊數 | 精準分眾活動為 15-25% |
| 每位回訪顧客成本 | 總 SMS 支出 / 歸因的增量回訪次數 | 因行業而異；目標低於付費獲客成本 |
一家採用此架構的連鎖餐廳在 90 天內回訪率提高了 12%，這直接歸功於由 Purple 現場定位數據觸發的重度參與 SMS 行銷活動。這些行銷活動針對 60 天內沒有回訪記錄的顧客，提供 20% 的折扣優惠。每位回訪顧客的成本比同期付費社群媒體獲客成本低了 34%。
對於大眾運輸營運商，請參閱 大眾運輸行業指南 以取得針對旅客的回訪指標。對於醫療保健環境， 醫療保健指南 涵蓋了在法規限制下的訪客參與。Purple Engage 方案涵蓋了本指南中所描述的數據收集、分群和 API 整合功能。Purple Connect 會在登入時擷取已驗證的身分數據。這兩個方案相輔相成，提供了您的簡訊行銷代理商所需之完整數據管道，以大規模推動可衡量的回訪率。
關鍵定義
第一方數據 (First-party data)
直接從您的受眾收集的資訊，例如在連線 WiFi 時透過 Purple Captive Portal 收集並經過驗證的電話號碼和電子郵件地址。
隨著第三方 Cookie 被淘汰，第一方數據成為簡訊行銷代理商的主要輸入來源。其價值完全取決於每筆記錄的準確性與同意狀態。
Captive Portal
公共存取網路的使用者在獲得網路存取權限之前必須瀏覽並互動的網頁。Purple 的 Captive Portal 是數據收集和同意收集的主要介面。
每個簡訊行銷整合都從這裡開始。Captive Portal 的設計和文案直接決定了選擇加入率 (opt-in rates) 和數據品質。
MAC 隨機化
iOS 14+ 與 Android 10+ 中的一項隱私功能，定期變更裝置的硬體 MAC 位址，以防止跨網路被動追蹤。
強制場所依賴使用者驗證（Identity-Based Networks），而非被動裝置追蹤，以準確衡量回訪率。
Webhook
由特定事件（在此情境中為使用者登入）觸發的 HTTP 回呼，可將資料從 Purple 近乎即時地推送到外部系統（例如 SMS 行銷機構）。
用於有時間敏感性的觸發器（例如歡迎訊息）。需要接收端 API 能夠處理預期的流量，特別是在高人流量活動期間。
Identity-Based Network
一種網路架構，其存取策略與資料追蹤係綁定至已驗證的使用者，而非硬體裝置。這也是 Purple 的核心架構。
解決 MAC 隨機化問題，並為 SMS 行銷機構提供準確、個人層級的造訪資料，而非吵雜的裝置層級資料。
SMS OTP (One-Time Password)
一種安全機制，在 Captive Portal 登入過程中，透過 SMS 發送唯一的數字代碼以驗證使用者的電話號碼。
這對於確保 SMS 行銷機構使用的資料庫僅包含有效且可聯絡的號碼至關重要，能消除退信率並避免浪費活動預算。
Dwell time
在單次造訪期間，使用者的裝置保持連接到或靠近該場所 WiFi 網路的持續時間。
關鍵的細分變數。與短暫路過的人相比，Dwell time 長的使用者參與度更高，通常對 SMS 活動的反應也更好。
API rate limiting
API 提供者套用的一種控制機制，用以限制用戶端在定義的時間範圍內可以發送的請求數量。
高人流量活動期間的關鍵風險。如果 Purple 發送 webhook 的速度快於 SMS 機構 API 的接收能力，酬載將會被丟棄，使用者也會錯過活動推播。
Bidirectional consent sync
一種資料整合模式，其中拒絕接收事件（例如對 SMS 回覆 STOP）會從 SMS 機構傳播回來源 CRM - 在此案例中為 Purple Engage。
為符合 GDPR 合規性所需。若沒有此功能，已撤回同意的使用者可能會繼續收到導出至 SMS 機構的資料。
範例
一家擁有 500 個據點的連鎖零售商需要針對 60 天內未到店的顧客實施簡訊重新互動活動。他們使用 Cisco Meraki 硬體和第三方簡訊行銷代理商。IT 團隊該如何建構此解決方案？
- 透過 Purple 雲端覆蓋將 Purple 與 Cisco Meraki 控制器整合 - 除了將訪客 SSID 登入頁面指向 Purple Captive Portal URL 之外，無需對 Meraki 設定進行任何變更。2. 設定 Purple Captive Portal 以強制進行簡訊 OTP 驗證，並透過未預先勾選的同意核取方塊收集符合 GDPR 規範的行銷同意。3. 設定每日從 Purple Engage 定期匯出資料至簡訊代理商的 API，篩選條件為
last_seen > 60 days且marketing_consent = true的使用者。4. 簡訊代理商觸發含有 20% 折扣碼的個人化重新互動訊息。5. 當顧客返回並在網路上進行驗證時，Purple 會記錄此次訪問。行銷團隊透過將兌換時間戳記與代理商報告中的簡訊發送時間戳記進行比對，將回訪歸功於該簡訊活動。
體育場營運商希望在球迷於比賽期間連線至 Guest WiFi 正好 10 分鐘後，發送一則包含餐飲點餐應用程式連結的歡迎簡訊。這該如何設定？
- 球迷連線至 Guest WiFi 並透過 Purple 入口網站進行驗證，提供其行動電話號碼與行銷同意。2. Purple Engage 註冊登入事件並立即向簡訊代理商的 API 端點發送 Webhook，傳送包含電話號碼、場地 ID 和登入時間戳記的使用者承載資料。3. 簡訊代理商的自動化引擎接收該 Webhook 並開始 10 分鐘的延遲步驟。4. 10 分鐘後，代理商發送預先設定好的歡迎訊息，其中包含點餐應用程式的深層連結。5. 送達與點閱率數據在發送後數分鐘內即可在代理商的報告儀表板中查看。
練習題
Q1. 一家餐旅業客戶反映，其 SMS 行銷活動的退信率高達 40%。他們目前透過 Captive Portal 上的標準文字輸入欄位收集電話號碼，且沒有任何驗證步驟。建議的架構變更是什麼？除了降低退信率之外，它還能帶來什麼次要好處？
提示：思考在資料進入 CRM 之前，您如何在進入點對其進行驗證。同時也請思考驗證步驟能證明使用者的什麼特徵。
查看標準答案
在 Purple Captive Portal 上實施 SMS OTP 驗證。這會強制使用者必須接收並輸入驗證碼才能存取 WiFi，從而保證只有有效、使用中的電話號碼會傳送給 SMS 行銷機構 - 進而消除 40% 的退信率。次要好處是，OTP 驗證還能確認使用者確實持有與該號碼關聯的實體裝置，從而強化身分記錄並提高回訪歸因的準確性。
Q2. 場所營運商希望準確追蹤回訪次數，但注意到其 Cisco Meraki 儀表板報告的唯一裝置數量，比 Purple Engage 中已驗證的使用者數量高出三倍。SMS 行銷機構應該使用哪個指標？為什麼？
提示：思考現代行動作業系統的隱私功能，及其對裝置層級追蹤的影響。
查看標準答案
該簡訊行銷代理商必須專門使用來自 Purple Engage 的已驗證使用者計數。該差異是由 MAC 隨機化所引起的，此技術會使 iOS 和 Android 裝置輪替其硬體位址，進而使 Meraki 儀表板中的不重複裝置計數虛高。Purple 的基於身分的網路層 (Identity-Based Network) 將每次造訪與已驗證的電話號碼連結，繞過硬體混淆並提供準確的個人級數據集。使用 Meraki 裝置計數會導致重複記錄以及不準確的重返造訪歸因。
Q3. 在一次大型會議期間，有 6,000 名與會者在 20 分鐘的時間視窗內登入 WiFi。將數據推送到簡訊行銷代理商的 webhook 在大約 25% 的負載上失敗，且這些與會者沒有收到歡迎訊息。可能的原因是什麼？以及有哪兩種緩解策略？
提示：請考慮接收系統的容量以及數據傳輸的時間點。
查看標準答案
簡訊行銷代理商的 API 由於 webhook 流量突然暴增（在此案例中約為每分鐘 300 次請求）而實施了速率限制，這超出了大多數標準 API 的速率限制。緩解策略一：在 Purple 與代理商的 API 之間實施一個具有指數退避演算法的佇列層，以便自動重試失敗的請求，而不會使端點過載。緩解策略二：對於高密度活動，將即時 webhook 切換為排程在預期尖峰登入視窗後五分鐘的批次匯出，將瞬間請求量降低至可管理的水平。