如何利用簡訊行銷提高回訪率
本技術參考指南概述了企業級場域如何將 WiFi 分析與簡訊行銷引擎整合,以推動重複造訪。指南詳細介紹了擷取即時實體存在數據、根據實際行為觸發自動化簡訊活動,以及衡量對回訪率直接影響所需的架構。透過將網路基礎設施與行銷自動化相結合,IT 與營運團隊可以建立一個高收益的客戶留存管道。

執行摘要
實體場域在客戶留存能力上面臨著與數位空間抗衡的持續挑戰。當電子商務平台能夠精準追蹤、重新定位並與訪客重新互動時,實體場所往往在資訊真空的狀態下營運。企業級 WiFi 基礎架構若能與分析和通訊引擎整合,便能填補這一鴻溝。透過利用 Captive Portal 作為數據收集點,場域可以擷取經驗證的行動電話號碼,並將其與唯一的裝置識別碼相連結。
本指南詳細介紹如何利用由即時 WiFi 分析所觸發的 SMS 行銷,來系統化地增加回訪率。SMS 仍是極其有效的管道,擁有接近 98% 的開啟率,且大多數簡訊在送達後三分鐘內就會被閱讀。藉由將這些簡訊與實體行為(例如停留時間、到訪頻率或久未到訪)相結合,企業組織可以傳送高度情境化的通訊以促成行動。本文件提供了 IT 經理、網路架構師和營運總監部署可靠、合規且自動化 SMS 行銷系統所需的技術架構、實作步驟和最佳實踐。
技術深度剖析
要建立一個基於實體活動軌跡的自動化 SMS 行銷系統,您必須整合幾個不同的層級:實體無線網路、AAA(驗證、授權和計費)伺服器、WiFi 分析引擎,以及外部 SMS 閘道器。
數據擷取與驗證流程
當訪客進入場域並嘗試連接到訪客 WiFi 時,該程序會從存取點(AP)或無線區域網路控制器(WLC)開始。WLC 會將使用者的 HTTP 流量重導向至由 Purple 平台託管的 Captive Portal。
- 關聯與重導向:使用者的裝置與訪客 SSID 進行關聯。WLC 會攔截初始的瀏覽器請求,並將使用者重導向至 Captive Portal URL,同時將用戶端的 MAC 位址和 AP 的 MAC 位址(稱為 Called-Station-ID)附加到查詢字串中。
- 數據收集與同意:Captive Portal 會呈現一個註冊表單。若要啟用 SMS 行銷,該表單必須收集使用者的行動電話號碼,並提供一個符合當地法規(例如歐洲的 GDPR 或美國的 TCPA)的明確、主動勾選同意方塊。必須自動偵測或明確選擇國碼,以確保正確的路由發送。
- RADIUS 驗證:使用者送出表單後,Purple 平台會與網路的 RADIUS 伺服器進行通訊以授權網際網路存取。RADIUS 伺服器會記錄工作階段開始時間,並在資料庫中將通過驗證的 MAC 位址與使用者個人檔案進行關聯。
存在偵測與行為追蹤
若要根據回訪行為觸發簡訊,系統必須區分活動連線(已登入 WiFi 的使用者)與被動存在(已啟用 WiFi 但未登入的裝置)。
- 活動連線追蹤:這仰賴 RADIUS 計費封包(Start、Interim-Update 和 Stop)。當使用者連線時,RADIUS Start 封包會註冊其存在。Interim-Update 封包會依設定的間隔(通常為 15 分鐘)傳送,以確認持續的停留時間。RADIUS Stop 封包則註冊其離開。
- 被動存在追蹤:這利用行動裝置搜尋已知網路時傳送的探測請求(probe requests)。存取點(Access Points)會擷取這些探測請求,記錄裝置的 MAC 位址、時間戳記和接收訊號強度指示(RSSI)。如果該裝置先前已透過 Captive Portal 進行註冊,即使他們在該次造訪期間未登入 WiFi,系統也能識別出使用者在場域附近的物理存在。為了保護隱私,MAC 位址在擷取後會立即進行加密雜湊處理(使用 SHA-256)。
整合架構與 Webhooks
若要啟動簡訊,WiFi 分析引擎必須即時將資料傳輸至簡訊閘道器(例如 Twilio、Sinch 或 Link Mobility)。這可透過 webhooks 或 REST APIs 來達成。
+-------------------+ RADIUS +---------------------+
| 無線網路 | <----------------> | Purple Platform |
| (APs / WLC) | | (分析引擎) |
+-------------------+ +---------------------+
| |
| 重導向 | Webhook (JSON)
v v
+-------------------+ +---------------------+
| Captive Portal | | 簡訊閘道器 |
| (使用者同意訂閱) | | (Twilio / Sinch) |
+-------------------+ +---------------------+
|
| SMPP / HTTP
v
+---------------------+
| 使用者手機 |
+---------------------+
當符合行為規則時 - 例如,在 30 天內未在場域中偵測到已註冊的使用者 - Purple 分析引擎便會產生一個事件。此事件會觸發一個 webhook,向簡訊閘道器傳送包含 JSON 承載資料(payload)的 POST 請求。此承載資料包含收件人的電話號碼、訊息內文(填入名字和上次造訪位置等動態欄位)以及追蹤參數。
實作指南
部署自動化 SMS 行銷系統需要在您的網路基礎架構、Purple 平台以及您選擇的 SMS 閘道之間進行系統化設定。
步驟 1:設定符合規範的數據收集 Captive Portal
- 登入 Purple Portal 管理介面。
- 導覽至 Form Builder 並選擇您正在使用的 splash 頁面。
- 新增電話號碼欄位。設定欄位屬性:
- 將該欄位設為必填。
- 啟用國際格式驗證以強制使用者輸入其國家代碼。
- 專門為 SMS 行銷新增一個同意核取方塊。此核取方塊必須與一般條款和條件核取方塊分開。
- 標籤文字:「我同意透過 SMS 接收最新資訊和獨家優惠。每月最多 2 封簡訊。回覆 STOP 可退訂。」
- 確保該核取方塊預設為未勾選。
- 儲存並發佈 splash 頁面的變更。
步驟 2:建立 SMS 閘道整合
此步驟將設定 Purple 與您的 SMS 供應商之間的通訊連結。本範例以使用 Twilio 為例。
- 從您的 Twilio 主控台取得您的 Account SID、Auth Token 以及專用的 Messaging Service SID 或電話號碼。
- 在 Purple Portal 中,導覽至 Integrations > Connectors > Add New。
- 從支援的 SMS 供應商清單中選擇 Twilio。
- 在設定欄位中輸入您的 Twilio 憑證。
- 輸入您自己的行動電話號碼並按一下 Send Test SMS 來測試連線。驗證訊息是否送達,且傳送狀態是否記錄為成功。
步驟 3:定義行為客群與觸發條件
為了提高回訪率,您必須根據使用者的實際行為來鎖定目標。針對過去 30 天內未造訪過場域的「流失訪客」建立一個客群。
- 在 Purple Portal 中,導覽至 Analytics > Visitor Profiling > Segments。
- 按一下 Create Segment 並將其命名為
Lapsed_30_Days。 - 定義篩選條件:
Last Visit Date大於30 days ago。Total Visits大於或等於1(確保他們是曾造訪過的訪客)。SMS Opt-in等於True。
- 儲存該客群。
步驟 4:設定自動化活動與 Webhook 觸發條件
現在,將該客群連結到當使用者進入此狀態時觸發的自動化動作。
- 導覽至 Marketing > Campaigns > Create Campaign。
- 選擇 Triggered Campaign 並選擇觸發事件:Enter Segment(
Lapsed_30_Days)。 - 選擇 SMS 作為傳送管道。
- 使用動態預留位置撰寫訊息範本以個人化內容:
嗨 {{visitor.first_name}},我們在 {{venue.name}} 想念您!本週回來並出示此簡訊,下次消費即可享 85 折優惠。退訂請點擊:{{sms.opt_out_link}} - 設定靜音時間以防止在非社交時間傳送訊息。根據場所的當地時區,將靜音視窗設定為
20:00至09:00。在此視窗期間觸發的訊息必須排隊並於隔天早上傳送。 - 為此特定行銷活動設定每 30 天 1 條訊息的頻率限制,以防止過度溝通。
- 啟用行銷活動。
最佳實踐
為在維持高訂閱率和網絡性能的同時最大化回訪率,請遵守以下行業標準。
數據清理與號碼驗證
無效的電話號碼會浪費行銷預算並扭曲效能分析。請在收集點實施即時驗證。
- 使用 HLR 查詢:在傳送大量行銷活動之前,請設定您的 SMS 閘道以執行歸屬位置暫存器 (HLR) 查詢。這會查詢行動網絡以驗證號碼是否處於作用中且目前已路由,從而過濾掉市話和已停用的號碼。
- 強制執行 E.164 格式:確保收集的所有號碼均以國際 E.164 格式儲存(例如
+447700900077)。這可防止用戶在國際旅行或透過全球電信商進行路由時出現傳送失敗的情況。
時機與情境相關性
SMS 是一種具侵入性的管道。在錯誤的時間傳送訊息會導致高退訂率。
- 與歷史行為保持一致:如果分析顯示用戶通常在週五下午訪問您的場所,請將其重新互動 SMS 排定在週五早上 10:00 傳送。這能讓他們在規劃一天的行程時,最先想到您的優惠活動。
- 停留時間驗證:請勿在連線後立即觸發「謝謝」或意見回饋 SMS 訊息。設定最小停留時間閾值(例如 20 分鐘),以確保用戶確實曾在場所內停留,而不僅僅是路過並短暫與網絡關聯。
合規與隱私
監管機構對不合規的 SMS 行銷處罰非常嚴厲。
- 明確同意:切勿將 SMS 行銷同意與 WiFi 服務條款捆綁在一起。它必須是用戶獨立、肯定的確認操作。
- 簡單退訂:每條 SMS 必須包含清晰、免費的退訂方法。標準做法是支援回覆 "STOP" 或提供一個縮短的、免流量費的 URL 來立即處理退訂。當用戶選擇退訂時,他們在 Purple 資料庫中的個人檔案必須在幾秒鐘內更新為
SMS Opt-in = False,以防止後續傳送。
疑難排解與風險緩釋
問題 1:SMS 傳送失敗率高
- 根本原因:用戶輸入虛假電話號碼以繞過 Captive Portal 並獲取網路連線。
- 緩解措施:為 WiFi 存取實施 SMS 驗證(雙重驗證)。不要在提交表單時立即授予存取權限,而是透過 SMS 發送 4 位數 PIN 碼至輸入的號碼。使用者必須在 Captive Portal 中輸入此 PIN 碼才能存取網際網路。這可確保只有有效、持有的行動電話號碼才會新增至您的資料庫中。
問題 2:Webhook 延遲與佇列積壓
- 根本原因:在尖峰時段(例如:體育場的半場休息時間或週六下午的購物中心),數千名使用者可能會同時觸發事件,導致 SMS 閘道 API 負載過重。
- 緩解措施:在 Purple Webhook 輸出與 SMS 閘道之間配置非同步訊息佇列(例如 RabbitMQ 或 AWS SQS)。這可以緩衝請求,允許系統以受控速率處理訊息,而不會遺失承載資料或達到 API 速率限制。
問題 3:MAC 隨機化干擾回訪指標
- 根本原因:現代行動作業系統(iOS 14+、Android 10+)在掃描網路時預設會隨機化 MAC 位址,導致難以透過被動探測請求追蹤回訪情況。
- 緩解措施:針對高準確度的行銷活動,應依賴已驗證的資料而非被動探測資料。當使用者登入 Captive Portal 時,將其已驗證的身分(電話號碼)與其目前的 MAC 位址連結。如果他們再次回訪並登入,系統會比對電話號碼,從而繞過 MAC 隨機化的限制。
投資報酬率(ROI)與商業影響
為了證明投資 WiFi 整合式 SMS 行銷的合理性,您必須追蹤特定指標,以證明 SMS 發送與實體回訪之間的直接關聯。
關鍵績效指標(KPI)
- 回訪率(RVR):在定義的歸因窗口(通常為 7、14 或 30 天)內,收到 SMS 並隨後在場地 WiFi 上進行驗證的使用者百分比。 $$\text{RVR} = \left( \frac{\text{回訪並通過驗證的 SMS 接收者人數}}{\text{成功發送的 SMS 訊息總數}} \right) \times 100$$
- 歸因窗口比對:系統必須將 SMS 發送記錄與 RADIUS 記帳記錄進行關聯。如果使用者在週二收到 SMS,且其 MAC 位址在週四登錄了 RADIUS Start 封包,則這將被算作一次歸因的回訪。
- 每次回訪成本(CPRV):計算 SMS 發送的總成本除以歸因的回訪次數。 $$\text{CPRV} = \left( \frac{\text{SMS 總成本}}{\text{歸因的回訪次數}} \right)$$ 例如,如果發送 10,000 條 SMS 訊息花費 200 英鎊(每條訊息 0.02 英鎊)並帶來 400 次回訪,則 CPRV 為 0.50 英鎊。將此與平均顧客終身價值(LTV)或平均交易金額進行比較,以確定獲利能力。
數據驅動最佳化
透過在 Purple 儀表板中持續分析這些指標,營運團隊可以針對訊息文案、優惠價值和發送時間進行 A/B 測試。這種迭代過程可確保 SMS 管道始終是帶來客流量和營收的高效驅動力量。
關鍵定義
Captive Portal
在向新連線的 WiFi 網路使用者授予更廣泛的網際網路存取權限之前,向其顯示的網頁,通常用於收集使用者詳細資訊與行銷同意。
這是收集經驗證的手機號碼與明確行銷同意書的主要入口。
RADIUS (Remote Authentication Dial-In User Service)
一種網路協定,為連線和使用網路服務的使用者提供集中式的驗證、授權和計費 (AAA) 管理。
它會追蹤使用者登入與登出 WiFi 的時間,提供用於計算停留時間與造訪頻率的原始工作階段數據。
HLR (Home Location Register) Lookup
在傳送簡訊之前,用於確定行動電話號碼狀態與有效性的即時資料庫查詢。
它能防止將行銷預算浪費在 WiFi 註冊期間收集到的無效或非作用中號碼上。
RSSI (Received Signal Strength Indicator)
接收到的無線電訊號功率測量值,在 WiFi 分析中用於估計與 Access Point 的距離。
它有助於確定使用者是實際在場館內還是只是路過,從而防止錯誤的簡訊觸發。
Webhook
一種透過自訂回呼來變更網頁或網路應用程式行為的方法,在此用於將即時數據從 Purple 傳送至簡訊閘道器。
它能使 WiFi 分析引擎與簡訊傳送平台之間進行即時通訊。
MAC Hashing
將媒體存取控制 (MAC) 位址轉換為安全、不可逆的密碼編譯字串之過程,以在追蹤重複造訪時保護使用者隱私。
它能確保符合隱私法規,同時仍允許系統識別再次造訪的裝置。
Opt-in Rate
在 Captive Portal 註冊過程中,明確同意接收行銷資訊的 WiFi 使用者百分比。
這是衡量數據收集漏斗健全狀況的關鍵指標;低訂閱率表示入口網站設計不佳或價值主張不明確。
Attribution Window
傳送簡訊後的指定時間段(例如 7 天),在此期間使用者返回場館會歸功於該特定行銷活動。
它能防止過度歸因於那些在沒有簡訊誘因的情況下也會自然發生的重複造訪。
範例
一家擁有 150 家分店的連鎖量販店希望針對「流失」客戶發送行銷訊息。流失客戶定義為過去曾透過 WiFi Captive Portal 註冊,但已連續 45 天未在任何分店被偵測到的個人。他們希望在週四上午觸發,發送一條自動簡訊,提供僅在即將到來的週末有效的 9 折優惠券代碼。
若要實施此方案,IT 與行銷團隊必須執行以下設定:
- 客群建立:在 Purple Portal 中,建立一個名為
Lapsed_45_Days_Retail的動態客群。- 篩選條件:
Last Seen(最後出現時間)大於 45 天,且Opt-in SMS(同意接收簡訊)等於True。
- 篩選條件:
- 活動設定:建立針對此客群的排程活動。
- 將執行排程設定為每週四上午 09:30。
- 此時間點可確保客戶在規劃週末購物時收到訊息。
- 簡訊網關承載資料設定:設定至 Twilio 的 Webhook 整合。Webhook 承載資料必須傳遞使用者的電話號碼、名字,以及由零售鏈 ERP 系統產生的不重複單次使用優惠券代碼。
- Webhook URL:
https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages.json - 承載資料範本:
{ "To": "{{visitor.phone_number}}", "From": "RETAILCO", "Body": "嗨 {{visitor.first_name}},好久不見了!這個週末使用代碼 {{coupon.code}} 即可享 9 折優惠。請在結帳時出示此簡訊。退訂請點擊:{{sms.opt_out_link}}" }
- Webhook URL:
- 歸因追蹤:將 Purple 中的歸因視窗設定為 4 天(週四至週日)。系統將監控所有 150 家分店的 RADIUS 記錄。在週四 09:30 至週日 23:59 之間,與接收者電話號碼相關聯的任何 MAC 位址若在訪客 WiFi 上完成驗證,即會被標記為「歸因回訪」。
一家舉辦為期數天會議的大型展覽中心希望提高其館內餐廳的回訪率。他們希望向在活動第 1 天連線到 WiFi,但截至第 2 天中午 12:00 仍未重新連線的與會者發送簡訊優惠券,以吸引他們返回餐廳享用午餐。
這需要高度時效性與特定位置的設計流程:
- SSID 與位置對應:確保展覽中心的 AP 已按區域分組。餐飲大廳的 AP 必須歸入名為
Dining_Zone的區域,而主展覽館則歸入Exhibition_Zone。 - 客群定義:建立一個名為
Day_1_Attendees_Missing_Day_2的客群。- 篩選條件:昨天已連線至
Exhibition_Zone且今天上午 08:00 至中午 12:00 之間尚未連線至任何區域。
- 篩選條件:昨天已連線至
- 觸發器設定:設定在多天活動期間,每日中午 12:05 執行排程行銷活動。
- 目標客群:
Day_1_Attendees_Missing_Day_2。 - 簡訊內容:"肚子餓了嗎,{{visitor.first_name}}?避開外面的排隊人潮。回到中央餐飲大廳,購買任何午餐即享免費咖啡。出示此簡訊即可兌換!"
- 目標客群:
- 兌換與驗證:為防止舞弊並追蹤投資報酬率,餐飲大廳的 POS(收銀系統)必須進行更新以接受此簡訊促銷。當收銀員掃描條碼或輸入簡訊中的代碼時,POS 會記錄該筆交易。此數據稍後會與 Purple 簡訊傳送記錄進行比對,以計算產生的直接收益。
練習題
Q1. 體育場營運總監希望向在半場休息期間連接至 WiFi 的與會者發送簡訊優惠券。然而,簡訊閘道面臨 15 分鐘的佇列延遲。您該如何解決此問題,以確保訊息在下半場開始前被接收到?
提示:考慮觸發機制以及在高度密集活動期間如何繞過閘道器佇列。
查看標準答案
要解決此問題,您必須繞過標準的共享簡訊閘道佇列,並向您的簡訊供應商申請專用的簡訊簡碼或高吞吐量的免付費號碼,以確保更高的每秒訊息數 (MPS)。此外,在 Purple 平台上配置觸發器,使其在半場休息 前 10 分鐘觸發,這可以基於預測性工作階段資料,或與體育場比賽時鐘 API 綁定的排程事件觸發器,而不是等待實際半場休息時的連線尖峰。最後,在簡訊承載資料上實施嚴格的「過期」參數,如此一來,如果訊息延遲超過下半場開始時間,電信業者就會將其丟棄,而不是遲到發送一條無關緊要的訊息。
Q2. 某家連鎖零售商跨多個時區營運。IT 團隊應如何配置 Webhook 整合,以確保簡訊不會違反當地的安靜時間規定?
提示:思考時區資料儲存在哪裡,以及排程引擎如何處理觸發器。
查看標準答案
IT 團隊必須確保 Purple 平台配置了每個獨立場地位置 (Called-Station-ID) 的正確當地時區。當行為觸發器發生時,Purple 行銷活動引擎在執行 Webhook 之前,必須評估使用者最後註冊的特定場地的當地時間。如果當地時間落在定義的安靜時間內(例如:20:00 至 09:00),平台必須將 Webhook 承載資料排隊存入本地緩衝資料庫。排程引擎接著必須在隔天早上當地場地時間 09:30 開始,依序釋放佇列中的 Webhook。
Q3. 某家連鎖飯店發現其簡訊行銷活動的退信率很高。應在 Captive Portal 和簡訊閘道整合中實施哪些技術驗證步驟來解決此問題?
提示:同時處理 Portal 頁面層級的輸入驗證與電信業者層級的驗證。
查看標準答案
要解決高退信率問題,請實施兩階段驗證流程。首先,在 Captive Portal 層級,使用 Regex 驗證來強制執行國際 E.164 格式,並防止提交明顯虛假的號碼序列(例如 "123456789")。其次,在註冊點整合即時 HLR (Home Location Register) 查詢 API。當使用者提交其號碼時,系統會執行背景檢查以驗證該號碼是否為有效號碼且能接收簡訊。如果 HLR 查詢返回 "市話" 或 "無效" 狀態,Captive Portal 將顯示錯誤訊息,要求使用者在獲取網際網路存取權限之前提供有效的行動電話號碼。